Managing Risks in Projects

Sponsors

Project Management Institute Upper Derby, USA

Building Technology Helsinki University of Technology Department of Industrial Management

PROJECT MANAGEMENT ASSOCIATION FINLAND

I&#

Managing Risks in Projects Proceedings of the IPMA Symposium on Project Management 1997 Helsinki, Finland 17-19 September, 1997

EDITED BY

K. Kahkonen VTT Building Technology, Espoo, Finland AND

K.A. Artto Department of Industrial Management, Helsinki University of Technology, Espoo, Finland

An lrnpr~nlof Chapman & Hall

London . Weinheim . New York . Tokyo . Melbourne. Madras

Published by E & FN Spon, an imprint of Thomson Professional, 2-6 Boundary Row, London SE1 8HN, UK Thomson Science & Professional, 2-6 Boundary Row, London SE1 8HN, UK Thomson Science & Professional, GmbH, Pappelallee 3, D-69469 Weinheim, Germany Thomson Science & Professional USA, 115 Fifth Avenue, New York, NY 10003, USA Thomson Science & Professional Japan, ITP-Japan, Kyowa Building, 3F, 2-2-1 Hirakawacho, Chiyoda-ku, Tokyo 102, Japan Thomson Science & Professional Australia, 102 Dodds Street, South Melbourne, Victoria 3205, Australia Thomson Science & Professional India, R. Seshadri, 32 Second Main Road, CIT East, Madras 600 035, India

First edition 1997 O 1997 E & FN Spon

"Procurement risks and uncertainty in support of the United States Antarctic Program" (pp 62-71) covers work done for the US Government and is in the public domain and q is not subject to copyright. Printed by St Edmundsbury Press Ltd, Bury St Edmunds, Suffolk ISBN 0 419 22990 6 Apart from any fair dealing for the purposes of research or private study, or criticism or review, as permitted under the UK Copyright Designs and Patents Act, 1988, this publication may not be reproduced, stored, or transmitted, in any form or by any means, without the prior permission in writing of the publishers, or in the case of reprographic reproduction only in accordance with the terms of the licences issued by the Copyright Licensing Agency in the UK, or in accordance with the terms of licences issued by the appropriate Reproduction Rights Organization outside the UK. Enquiries concerning reproduction outside the terms stated here should be sent to the publishers at the London address printed on this page. The publisher makes no representation, express or implied, with regard to the accuracy of the information contained in this book and cannot accept any legal responsibility or liability for any errors or omissions that may be made. A catalogue record for this book is available from the British Library Publisher's Note This book has been prepared from camera-ready copy provided by the individual contributors in order to make the book available for the symposium. @

Printed on acid-free text paper, manufactured in accordance with ANSIINISO 239.48-1992. (Permanence of Paper).

CONTENTS International Advisory Board Preface PART 1

PUTlTNG PROJECT RISK MANAGEMENT INTO PERSPECTIVE

Fifteen years of project risk management applications where are we going? K.A. Artto

Proactive risk management - myth or real it,^? F. Hartman

Establishing project risk assessment teams J.D. Frame

PART 2

CASE PROJECTS - PROJECT FAILURES, RISK HISTORY AND LESSONS LEARNED

In search of best practices in risk management J.I.M. Halman and P.M. van der Weijden

Understanding project risk: lessons from past failures J. K. Pinto

Soft risk management for the implementation of an information systems project R. W. Stewart

Risks in projects and project oriented business desigdbuild - optimum solution for biopharm projects W.R. Brydges

Procurement risks and uncertainty in support of the United States Antarctic Program R.P. Thomas

vi

Contents

PART 3

IMPLEMENTATION OF SYSTEMATIC RISK MANAGEMENT IN PROJECT BUSINESS

Implementation of systematic project risk management in companies - fiom immediate needs to the prospects of the hture K. Kahkonen

Training for project success 0. Reitan and L. H. Hauge

Establishing a formal project risk management process S.C. Ward and C.B. Chapman

Institutional risk management S.H. Wearne

PART 4

NEW SKlLLS AND TECHNIQUES FOR PROJECT RISK MANAGEMENT

Managing risk management processes: navigating a multidimensional space C.B. Chapman and S.C. Ward

Implementing the successive principle 0.1 Klakegg

Project risk management and organisational learning J.F. Wright

Integration of subjective judgements and historical data E. Cagno and F. Caron

Exploring the value of project complexity - beyond lump sum contracting P.W. Hetland and HJ. Fevang

Using a systematic project delivery approach to better manage project risks J.M Vandeusen

Contents vii

Risk sharing partnerships

171

G.S. Hough

No-risk move from TQM to I S 0 to bounclaryless organisation T. Al-Sulimani and.D. Sharad

PART 5

PROJECT RISK MANAGEMENT IN DEVELOPMENT, SOFIWARE AND RE-ENGINEERING PROJECTS

Method of reliability analysis in the project information management process

195

R. Gautier, P. Truchot and T. Gidel

The risk diagnosing methodology RDM J. I.M. Halman and J. A. Keizer

Risks in change project management A.K. Salminen, H C. Lanning and M J . Roiha

A risk-driven approach for software process improvement

223

C. Maupetit, J. Palo, P. Kuvaja, M. Belli and M. lsokaanta

Risk management focus in business reengineering initiatives

233

J. VQlirnakiand T. Tissari

Risks in projects and project oriented small and medium companies A. del CaAo, M.P. de la Cruz, M. Dominguez and M.M. Espinosa

PART 6

PROJECT RISK MANAGEMENT IN ENGIIWERING AND CONSTRUCTION

Constructing reasonably believable edifices: lessons from software, implications for construction K.L. Hansen and J. E. Millar

Towards a qualitative risk assessment fi-amework for construction projects J. H.M. Tah

243

viii Contents

Risk sources and drivers in construction projects M. Radujkovic

The risk of safety regulation changes in transport development projects T.M. Williams

Clients' risks associated with different building procurement methods P. Pernu, J. Kiiras and T. Peltonen

Development of a risk management approach for allowing dependency and uncertainty between activities' duration N.N. Dawood

The importance of a quality management in civil projects I. Psunder

PART 7

UNDERSTANDING NATURE OF RISK-MODELLING ASPECTS

Crisis avoidance through proactive project management MA. Browne and C.M. Keown-McMullan

Coping with environmental uncertainty in projects J. T. Karlsen and B. 0.Elvenes

Project risk: systemicity, cause mapping and a scenario approach T. M. Williams, F. R. Ackermann and C. L. Eden

Focusing on risk response development and risk measures to be taken - can risk estimating even be skipped in an RM application? K.A. Artto

Deciding which risks are important S.C. Ward

Keyword Index

INTERNATIONAL ADVISORY BOARD

Professor Luis Alarcon, Universidad Catolica de Chile Associate Professor Karlos A. Artto, Helsinki University of Technology Professor David Ashley, University of California, Berkeley, USA Professor John Bale, Leeds Metropolitan University, United Kingdom Professor Juan L. Cano, Unversity of Zaragoza, Spain Profesor Franco Caron, Politecnico di Milano, Italy Professor Chris Chapman, University of Southampton, United Kingdom Dr. David I. Cleland, University of Pittsburgh, USA Dr. Nashwan Dawood, University of Teesside, United Kingdom Professor Mats Engwall, Royal Institute of Technology, Sweden Asst Professor Pernille Eskerod, Southern Denmark Business School, Denmark Professor Roger Flanagan, University of Reading, UK Professor Carlos Formoso, Univesidade Federal do Rio Grande do Sul, Brazil Professor J. Davidson Frame, George Washington University, USA Dr. Keith Hampson, Queensland University of Technology, Australia Dr. Francis Hartman, The University of Calgary, Canada Otto Husby, Control Bridge AS, Norway Simon Indola, Nokia Telecommunications Oy, Finland Dr. Kalle Kmonen, VTT Building Technology, Finland Dr. Steen Lichtenberg, Lichtenberg & Partners ApS, Denmark Marko Luhtala, Nokia Telecommunications Oy, Finland Anders Soderholm, Umed Business School, Sweden Professor Jens 0 . Riis, Aalborg Universitetscenter, Denmark Asbjom Rolstadas, University of Trondheim, Norway John Russell-Hodge, University of the South Pacific, Fidji Islands Dr J R Turner, Henley Management College, United Kingdom Veikko Valila, Industrial Insurance Ltd, Finland Stephen Ward, University of Southampton, United Kingdom Kim Wikstrom, Abo Akademi, Finland Dr. Terry Williams, The University of Strathclyde:, United Kingdom

PREFACE

The unique nature of projects implies that managing risk and uncertainty is one of the most important areas in project management. During the recent decades, empirical risk management applications have gradually become more integrated as a part of the overall project management. By experience one might say that the definition of risk management in relation to project management in general is not clear. This; implies that risk management will take different definitions depending on the purpose and empirical application. It is challenging to try to understand risk and risk management in a conceptual stage. In the context of empirical applications the debate on risk and uncertainty and their definitions is everlasting. There is no clear result for the discussion: Risk can be defined in different ways and approached from different angles. In the literature and in empirical applications, new risk management methodologies are introduced partly as new approaches to be applied as integral parts of modern project management. Understanding project risk management and its implementation in companies

Being dedicated to the risk management field, there is no need to say much about our high motivation to make a book on project risk management. However, it is more important to say few words about the rationales why the book we have created makes a contribution to the risk management field. First, we saw that it is important to collect the discussion about risk management and this way provide different and also controversial perspectives. We believe that the discussion provided in this book will contribute to future development in the risk management field. Second, the contents of risk management and project management cannot be separated from the environment and overall purpose for applying such disciplines. It is obvious that there are differences in business processes in different application areas and in different project industries. This book will also promote understanding differences in risk management in case of different project types, application areas and industries. The variability of the aspects presented in this book serves as a kind of benchmarking across application areas and industries which on the long run - so we hope - helps in identifying best practices for each application area and industry. The structure of the book

'Managing Risks in Projects' comprises seven themes which are 1. Putting project risk management into perspective 2. Case projects - project failures, risk history and lessons learned 3. Implementation of systematic risk management in project business 4. New skills and techniques for project risk management

xii

Preface

5. Project risk management in development, software and re-engineering projects 6 . Project risk management in engineering and construction 7. Understanding the nature of risk -modelling aspects The first theme looks at the history of the project risk management and provides a view over our current understanding. Within the following theme significant lessons and experience gained from past projects are presented. These past experiences about project problems have been called project risks whose time have come. The lessons about past failures and how to avoid them have proved to be an important means to improve our understanding relating to the world of project risks. In the theme three the development of project risk management practice in companies is being discussed in several papers. This is what we eventually would like to see - a change in our project business practice. To have a real change in how projects are prepared, planned and management has proved to be a challenging task. Project risk management take very much shape in the form of different techniques and tools. In this book the themes from four to seven cover different approaches, techniques and tools of project risk management. Particularly within last three decades plenty of knowledge and experience have been gained in applying and building various techniques and tools for different types of projects.

Acknowledgements We would like to record our special thanks to the members of our international advisory board who have provided their expertise to evaluate papers of this book. These individuals are listed on page ix.

Finally, we wish you enjoyable moments with the book, good feeling for systematic risk management, and also a bit of good luck with your future projects.

Kalle Kiihkonen

16 June, Espoo, Finland

Karlos A. Artto

PART 1

PUTTING PROJECT RISK MANAGEMENT INTO PERSPECTIVE

Fifteen years of project risk management applications - where are we going? K.A. ARTTO Helsinki University of Technology, Finland

Abstract The paper discusses content and scope of project risk management. The purpose of the paper is to reflect future trends in the field of prqject risk management. Understanding evolution in a historical time span is essential to be able to draw conclusions of potential trends of future developments. The fifteen years in the topic of the paper refers to the length of the author's past experience in the project risk management field. Keywords: Project management, risk management, risk analysis, quantification, project company, organizing for risk management, risk history, risk knowledge base 1. Introduction An appropriate project risk management content is sought for. New aspects of project risk management are introduced. Also, a widler perspective is provided with a discussion about the role and content of risk management in a project company. One basic aim of the paper is to give insight about future trends in the field of project risk management. In order to understan'd the trends and potential future outcomes, we will first lay a brief glimpse on recent history and current status of project risk management discipline. Understanding evolution in a historical time span is essential to be able to draw conclusions of potential trends in future developments. Project risk management practices within the author's own fifteen-year sphere of experience form one basic starting point for the discussion.

2. Project risk management - definitions and ttwls There are several project management standards tlhat provide a definition of project risk management. The project risk management content defined according to Project Managing Risks in Projects, edited by K. Kakonen and K.A. Artto. Published in 1997 by E & FN Spon, 2-6 Boundary Row, London SEl SHN, UK. ISBN: 0 419 22990 6.

Management Institute's (PMI) definition is shown in Fig. 1 [I]. Risk management content is also reported in recent documentation for the project management quality guideline I S 0 [21 that recognize following risk related processes: risk identification risk estimation risk response development risk control The I S 0 [2] definition about risk management content above is similar to that of PMI's, and in general, risk management literature defines risk management in similar manner. In some contexts, the terms risk analysis or risk appraisal are used to refer to the first stages of identification and estimation and quantification.

led Project Risk

- INPUTS:

-

INPUTS: -Sources of Risk -Potential Risk Events Stakeholder Tolerances -TOOLS: -Expected Monelaly Value Statistkal Sums -Schedule Simulation -Decision Trees -0urPUTs: OUTPIITS: -Sources of Risk Opponunities to Pursue Pnenliil Risk Events -Threats to Respond to -Risk Synptoms Opponunitie~to lgnwe -Threats to Accept -Product Description -Constraints Assumptbns -TOOLS: Checklisis Historkal Results Intewiening

--

--

-

-

-

INPUTS: Opp~nunit~es to Threats to (see quantification) TOOLS: Contacting Contingency Planning Altematiue Stratepies Insurance OUTPUTS: Risk Mngmt Plan Inputs to Other Processes hntngoncy P h s

...

...

C4ntiaauslAgmsmenta

-INWlB: -Risk Mngmt Phn -Actual Risk Events -Additional Ri& Identification -TOOLS: Workamunds -Add~tional Response Devebpnent

--

-OUTPUTS: -Corrective Actim -Updates to Risk Mngmt Plan

-

--

Fig. 1. Risk management overview (according to [I])

In project companies, there are risk response sheets in use as empirical tools that are designed to guide identification, estimating, and risk response planning. The structure of those sheets in use usually is consistent with the standards (cf. [I] and [2] referred to above). A hypothetical and simplified presentation of a risk management sheet visualising a tool used in several Finnish project companies is depicted in Fig. 2.

Project risk management applications

Identification

Estimate

Response

(Risk Description)

(Probabilily & Impact)

(&Responsible Person)

5

Item 1 Item 2

Item 3

Fig. 2. A risk management sheet as a visualisation about empirical tools in use

-

3. Historical perspective risk management of the 80's 3.1.

Quantitative and risk analysis oriented risk management in the 80's

In the beginning of the 80's, project risk management was a well recognized area in project management literature. The content consisting of risk identification, estimation, risk response development and risk control was generally known. In the discussion of risk management at that time, quantitative risk arialysis was emphasized. For example, the stochastic three point estimate features of the PERT methodology vere widely referred to. The PERT methodology with a probabilistic interpretation of optimistic, pessimistic and most probable value estimates has its origin in developing the PERT methodology in the 50's. In project context, it is natural that subjective jludgment is required. Historical data is valuable for getting a conception about risks in previous projects. However, because of the individual nature of each project, weight must be given to subjective estimates based on the expertise of the project personnel. Subjective probabilities are derived from people's knowledge, and they are not based on measuring frequencies which would be the starting point of the objectivistic probability approach. The discussion about using subjective probabilities and allowing subjective elements in probabilities dates back to the probability research of Bayes [3] and Laplace (ca. 1800). Also remarkable more recent developments for using subjective probabilities in the decision theory were made in the 50's, 60's and 70's. In the 80's, the quantitative side of estimating probabilities and probability distributions, and methods of combining quantitative estimates were discussed and

developed. Risk modeling and the use of different probability distribution forms were considered an important and interesting features to develop. Also risk analysis software with mainly features to support risk modeling and quantification was developed at that time. The risk quantification in empirical applications were mainly based on subjective probabilities and subjective probability distributions.

3.2.

Risk management applications in the 80's

Applications in industries were mainly time and cost risk analysis applications. In many cases, a software with subjective time and cost probability distributions was used to support risk analysis. Process plant construction and engineering industries were the users of main risk management and risk analysis. In the author's own risk management development efforts in go's, risk management was developed for electric utility and energy system construction projects. Further, while developing the risk management in mid-go's, the author visited, among others, British Petroleum (BP) in the UK and Norwegian Petroleum Consultants in Norway. At that time, BP developed CATRAP (Cost and Time Risk Analysis Program) software for in-house use only. The software allowed modeling risks with several distribution forms of subjective probability distributions as inputs. The software was used in e.g. North Sea oil platform construction projects. For the same use, Norwegian Petroleum Consultants developed NPC software for Norwegian construction and engineering companies and oil platform and related system suppliers. The software was developed for certain consortium of Norwegian companies, and accordingly, was not a commercial product. NPC allowed also risk modeling and quantifying risks by using different probability distributions. An interesting feature in the software was that besides subjective distributions, also objective (frequency based) probability distributions were calculated from durations or cost data. The software allowed combining subjective and objective distributions by using pre-determined weights, and the integration of time and cost risks was enabled in modeling features. When discussing risk management applications and software used in the go's, the successive principle developed by Steen Lichtenberg in Denmark is worth mentioning. Also commercial software was developed on ideas of successive principle. The basic features of successive principle are the following. Project cost items (or durations of tasks of the project schedule) are estimated quantitatively employing three point value estimates. A list is generated showing the items in order of decreasing risk (variance). The item or parameter contributing most to the uncertainty is further specified and divided into subitems. This way, the most critical items are specified in an aditional stage, until atl the significant items are specified in a detailed manner by further subdivisions. An interested reader is adviced to consult Lichtenberg [4] for more details about the successive principle developed in the 80's. The interested reader might find [5] [6] and [7] interesting as short but rather comprehensive overviews of systematic risk management of the 80's with much emphasis on risk analysis and risk quantification methods. In the quantification side, Hayes et. al. [5] describe not only the methods for probabilistic risk analysis, but also a methodology of sensitivity analyses is introduced.

Project risk management applications

7

-

4. Quantitative risk analyses today using software for team work support A common feature for a majority of commerc:ially distributed risk management software is that they allow building complex risk models. In the software, inputs are subjective time and cost or other quantity probability distributions. To look at the quantitative risk analysis for risk modeling and risk estimating from a software point of view, there are several software products today that support quantitative risk analysis. The categories consisting of some commercial software products are (see risk management software discussion also in [8]): Decision Support & Modeling: Temper System / VTT, Finland Futura / Proha, Finland Different AHP applications in general (AHP = Analytical Hierarchy Process) Modeling tools: DynRisk /Terramar, Norway DPL /ADA Decision Support, USA REPPC / Decision Sciences, USA Spreadsheet add-in: Crystal Ball / Desicioneering, USA @Risk (Excel) / Palisade, USA Planning Package add-in: @Risk (MS Project) Palisade, USA Monte Carlo (Primavera) / Primavera, USA Opera (Open Plan) /Wellcome Software, USA Risk+ (MS Project) / PMSI, USA The basic risk management software features that are in use today were developed in the 80's. The situation today is that a major effort is required for planning how to use the current software rather than to develop modeling and quantification features further in different software solutions. Whereas risk management software were serving as tools for risk analysts in the go's, the tendency today has been to use quantification and risk modeling more as vehicles that promote communication, team work, and risk response planning among project personnel. The focus in risk management today is to develop processes that enable team work and the use of people's and organizations' experience and knowledge when planning risk management and risk responses. Thus, risk analysis software should be considered as tools promoting communication in the team. This could be accomplished by arranging team analysis sessions where the software is used to both initiate and summarize communication about risks and risk responses.

5. Project risk management in the 90's and in the future 5.1.

General

Although risk analysis and risk quantification were emphasized in the risk management development in the go's, it is true that many other risk management methodologies used

today were known already in the 80's. For example, when visiting BP in mid-80's, the author recognized that influence diagramming, risk check lists and questionnaires, and risk-response diagramming methods were in use. Further, important principles associated with risk sharing by construction contracts were defined. Such methodologies were recognized also in literature, e.g. in those risk management overviews referred to above in context of risk analysis and quantification (see e.g. [5] [61 and 171). Influence diagramming and other corresponding qualitative methods are appropriate for the risk types which should be treated only qualitatively by a careful documentation. Such risk types comprise typically risks with a severe financial impact but minimal probability of occurrence, and on the other hand risks with no substantial consequences even if they occur.

5.2.

Risk management knowledge bases as organizational memories

The approach of risk check lists and questionnaires of the 80's has been developed further till today. And development will continue in this field. The direction is toward the creating of risk management knowledge bases. However, recent developments show that risk knowledge bases do not comprise only a description of risks to be used as check list items, but there might be other valuable data such as suggestions about responses to be used for risk response planning. The author's forecast is that the development and growth of applying such knowledge bases will continue. Risk knowledge bases are used as organizational memories where experience about risks and e.g. potential risk responses is continuously recorded during the project execution in a multi-project environment of e.g. a project company. Real-life cases of risks occurred in projects may be included in the knowledge base. The knowledge base then provides access to the organization's understanding about risks in real time. The knowledge base is easily accessible for risk management procedures, and it may contain possibilities to make different selections concerning e.g. the project type , or the content of information retrieved.

5.3.

Risk response planning

The use of risk-response diagramming in BP already in the 80's was based on the rationale that risks cannot be explicitly modeled or quantified without taking risk responses into account. There are three reasons why the including of risk responses is important already at the risk analysis and quantification stage. First, the estimate of the risk remaining will be different in case of different response scenarios. Second, responses consume time and cost, and adjustments to schedules and cost estimates are required accordingly. Third, perhaps the most natural phase for risk response planning is when committed simultaneously with risk analysis considerations. The author's forecast is that risk response planning will be more emphasized in many future developments. The new systematic forms of risk response planning might be based on solutions for integrating the planning with risk estimation. The 'decision support' oriented software referred to above as one category differ from standard modeling software by having features that provide better support for interactive risk modeling with understanding the nature of the risks and this way better enable simultaneous

Project risk management applications

9

choices and decision making about responses. Also existing knowledge base applications will support response planning more effectively if they include both risks and risk responses in an integrative manner to support risk response planning (see the knowledge base discussion above). 5.4.

Using contracts as risk management vehicles

The risk for carrying risk is transferred or allocated by contracts, usually between the client and the contractor. The construction risk is inherent in the work itself. When transferring a risk by contracts, contractual risks arise from the lack of contract clarity, the absence of perfect communications between the parties involved and the problems in contract administration. Problems in construction contracts are caused also by conflicting objectives between the client and contractor. Developing partnership strategies, networking and cooperation between the client and contractor today implies development needs for the contract management as well.. Contracts must be recognized as important risk management vehicles, and the future development is likely to provide us with new contract strategies, contract forrrmlas, contract types, and contract conditions.

5.5.

Learning from project failures

The knowledge accumulated from project failures or unfavourable events in projects can be used for creating a learn - or understanding - of unfavourable outcomes, their reasons and responses required. The basic idea is to learn from the experiences and to introduce experience-based solutions of how risks could be (or could have been) avoided. An increasing number of studies can be found which report project failures, or unfavourable project outcomes. Project failures and measures to be taken are discussed in [9] [lo] [ I l l [12] [13] [14] and [IS].

5.6.

Risk management processes and organizing for risk management

The focus on project risk management development has slightly turned from developing the quantitative side into developing the understanding of the risk management process. The risk management process and how it should be organized in a project or in a project organization will also be the focal point in the future. The trend could be orserved not only from the author's own research in the field of risk management, but also observations from other times series indicate similar trends: While developing the risk management in the SO'S, the author visited Chris Chapman and Dale Cooper at the University of Southampton in the UK. At that time, the emphasis was on developing risk modeling and the quantitative treatment of risks, see e.g. Chapman [16], Chapman [17], Cooper [18], Cooper and Chapman [19]. From a recent publication of Chapman and Ward [20], we can draw a conclusion that the emphasis of the risk management development of today is on rather developing and understanding risk management processes in different phases of the project life cycle, and organizing for risk management.

6. Project company perspective 6.1.

Project life cycle

Risk management is continuously applied in atl phases of the project life cycle. The specifications and plans are made more specific and accurate over the project life cycle. Partly due to this, and partly due to the constantly increasing number of activities accomplished and risks occurred, the remaining risk associated with project cost and time is reduced. Decreasing risk throughout the project is shown in Fig. 3 as the decreasing area where the final outcome is estimated to occur.

cOsti.O Time

L a ! ?

Fig. 3. A decreasing risk through the project life

6.2.

Project company related issues

The risk management discussion has mostly focused on managing risks in single projects. As there are an increasing number of organizations - e.g. project companies with several projects in their production lines, a widening of the risk management perspective to concern such a multi-project environment, is important in the future. In developing the risk management for a project company, there are two important new areas of future development. They are risk management associated with bids and bidding, and risk management associated with project portfolios.

6.3.

Risk management associated with bidding

It is important to take into account that in a project company there are two kinds of projects. First, those to be executed according to existing contracts. And second, bids which represent potential or hypothetical projects with some probability of turning into

Project risk management applications

11

a contract and an executable project if agreed with the client. In the case of a bid, the risk is present in two ways: there is the risk inherent in execution if ordered by the client, and there is a risk associated with the likellihood of getting the order from the client. Accordingly, bids can be thought to cause uncertainty and risk when allocating efforts to bidding and on the other hand when making resourse reservations for potential an uncertain future projects. The author's forecast is that bids and bidding processes of a project company will be in a developmental focus in the future. Important developmental areas are related to contingencies, profit, and contingency strategies, and strategic decision making associated with operating with the likelihoods of turning the bid into a profitable project. Project simulation and project models are seen as effective tools to support risk management in the pre-project phase discussed here. For the interested reader, project simulation issues are discussed in [21]. 6.4.

Risk management associated with project portfolios

As far as the risk management associated with project portfolios is concerned, there might be several aspects in analyzing and making strategic choices associated with projects at the company or business unit level. For example, for a project company operating in international markets, the country and area specific local risks are important to take into account. The country risks affect not only one single project in the specific country or area, but the whole portfolio of bids and projects in that area. There are many country and area specific risk reviews issued in regular intervals. For example, for analyzing local creditworthiness of different project portfolio areas of a project company, Institutional Investor (see [22]) provides global country credit ratings and analysis for ca. 135 countries, and separate ratings for North America, Eastern Europe, Western Europe, Africa, Middle East, Asia-Pacific, and Latin America. There are not many studies reported on risk management developments associated with project portfolio risk aspects of a project company. The author's forecast is that there will be increasing number of project company related research and developments also in this important area or application.

7. Conclusion The paper discussed content and scope of project risk management. The purpose of the paper was to reflect future trends in the field of project risk management. Understanding the evolution in a historical time span is essential to be able to draw conclusions of the potential trends of future developments. New aspects of project risk management are introduced. Also, a wider perspective is provided with a discussion about the role and content of risk management in a project company. Risk management is generally defined by the sequence of risk identification, risk estimation, risk response development, and risk control. In project companies, there are risk response sheets in use as empirical tools which are designed to guide identification, estimating, and risk response planning. In the discussion of risk management in the 80's, quantitative risk analysis was emphasized. In the 801s,the quantitative side of estimating probabilities and probability

12

Artto

distributions, and methods of combining quantitative estimates were discussed and developed. Applications in industries were mainly time and cost risk analysis applications. In many cases, a software with subjective time and cost probability distributions was used to support risk analysis. Whereas risk management software were serving as tools for risk analysts in the 80's, the tendency today has been to use quantification and risk modeling more as vehicles that promote communication, team work, and risk response planning among project personnel. Risk knowledge bases are used as organizational memories where experience about risks and e.g. potential risk responses is continuously recorded during the project execution in a multi-project environment of e.g. a project company. The author's forecast is that the development and the growth of applying knowledge bases will continue. Also, the author's forecast is that risk response planning will be more emphasized in many future developments. The new systematic forms risk response planning will take might be based on integration of risk estimation and risk response planning. Also existing knowledge base applications will support response planning more effectively if they include both risks and risk responses in an integrative manner. The knowledge accumulated from project failures or unfavourable events in projects can be used for creating a learn - or understanding - of unfavourable outcomes, their reasons and responses required. The basic idea is to learn from experiences and to introduce experience-based solutions of how risks could be (or could have been) avoided. Contracts must be recognized as important risk management vehicles, and the future development is likely to provide us with new contract strategies, contract formulas, contract types, and contract conditions. The focus on project risk management development has slightly turned from development of the quantitative side into development understanding about the risk management process. Important areas of today's risk management are the developing and understanding of risk management processes in different phases of the project life cycle, and the organizing for risk management. In recent years, the risk management perspective in empirical applications has widened from a single project to a perspective of risks associated with a project company having projects in its product line. The project company perspective implies not only portfolios of projects under execution but also portfolios of bids that represent potential future projects with other kinds of aspects and dimensions of uncertainty inherent.

8. About the author The fifteen years in the topic of the paper refers to the length of the author's past experience in the project risk management field. It is appropriate to provide the reader with some information about the author's background. The author began his risk management oriented career in the early 80's as a risk management engineer in a major Finnish electricity company. At that time his perspective to risk management concerned mainly applying risk management in capital expenditure projects from investment

Project risk management applications

13

project point of view in the energy field. The author has contributed to the project risk management field ever since while working for various companies or business units having one-of-a-kind investment products in their product line. Before moving to the university career in half-90's, he was working for a major Finnish turnkey supplier of power plants, power transmission l i e s and other energy systems. The author is currently associate professor of International Prioject-oriented Business at Helsinki University of Technology, Finland. He is responsible for developing research and education in the project business area. He has a ,wide cooperation in different forms with the projectized industry in Finland and with both domestic and foreign universities and research institutes. Project risk management is one important area in the scope of the cooperation.

9. References PMBOK, 1996. A Guide to the Project :Management Body of Knowledge, Project Management Institute Standards Committee, Project Management Institute PMI, Upper Darby, PA, USA (and PMBOK Exposure Draft - August 1994) I S 0 10006, 1996. Guidelines to Quality in Project Management, ISOIDIS 10006, Document 176-2-8-N160. Bayes T., 1763. Essay Towards Solving a Problem in the Doctrine of Changes. The Philosophical Transactions 53 (1763), 370-418. Reprinted: 1) Facsimiles of Two Papers by Bayes, Deming W. E. (ed.), The Graduate School, Washington D. C. (1940); 2) Thomas Bayes' Essay Towards Solving A Problem in the Doctrine of Changes, Biometrica 45 (1958), 293-315 Lichtenberg S., 1981. Real World Uncertainties in Project Budgets and Schedules, Proceedings of the Project Management Institute & International Project Management Association Symposium, Boston, pp. 179-193 Hayes R. W., Perry J. G., Thompson P. A., Willmer G., 1986. Risk Management in Engineering Construction - Implications for Project Managers, The Project Management Group UMIST, SERC Report, Thomas Telford, United Kingdom Artto, K. A., 1986. Risk Management in Cost Engineering (Partl: Abstract, Introduction and Risk Management), The Cost Engineer, Vol. 24., No. 3. Artto, K. A., 1986. Risk Management in Cost Engineering (Part2: Risk Analysis Methodology and its Advantages, Conclusions), The Cost Engineer, Vol. 24., No. 4. NFP, 1996. Project Survival Kit: Risk Management Methods & Tools, Prosjektledelse, Project Management Association NFP, No. 3, 1996. pp. 10-12 Kharbanda 0 . P., Stallworthy E. A. , 1983. How to Learn from Project Disasters -True-life Stories with a Moral for Management, Gower Publishing Company, Hampshire, United Kingdom Standish Group, 1995. Chaos - Study on Software Project Failures, http://www.standishgroup.com/chaos.html Kharbanda 0 . P., Pinto J. K. , 1996. What Made Gertie Gallop? Lessons from Project Failures, Van Nostrand Reinhold, USA, New York, USA

Kiihkonen K., 1997. How to Learn from Project Failures, l'rojektitoiminta (Finnish Project Management Journal), Vol. XX, No. 1, pp. 17-19, in Finnish Artto, K. A., 1997. The Anatomy of Project Risk Management, Projektitoirninta (Finnish Project Management Journal), Vol. XX, No. 2, in Finnish Artto K. A., 1997. Focusing on Risk Response Development and Risk Measures to Be Taken - Can Risk Estimating Even Be Skipped in an RM Application? in W o n e n K., Artto K. A. (eds.): Managing Risks in Projects, E & FN Spon, London, United Kingdom Pinto J. K., 1997. Twelve Ways to Get the Least from Yourself and Your Project, PM Network, Vol. 11, No. 5, pp. 29-31 Chapman C., 1979. Large Engineering Project Risk Analysis, IEEE Transactions on Engineering Management, Vol. EM-26., No. 3., pp. 78-87 Chapman C., 1983. , Time Schedule Risk Analysis - Causal Dependence, Operational Research Society National Event, July 1983, University of Reading, United Kingdom Cooper D. F., 1983. Basic Cost Risk Uncertainty, Operational Research Society National Event, July 1983, University of Reading, United Kingdom Cooper D. F., Chapman C. B., 1987. Risk Analysis for Large Projects; Models, Methods and Cases, John Wiley & Sons Chapman C., Ward S., 1997. Project Risk Management; Processes, Techniques and Insights, John Wiley & Sons, United Kingdom Andrews T., Cox R., Paris A., Suda L., 1996. The Project Leadership simulation: A Computer-Based Simulation Excercise, Simulation & Gaming, Vol. 27, No. 2, June 1996, pp. 277-281 Shapiro H. D., 1997. How High is Up?; Global Creditworthiness is Flirting with Levels not Seen in More than a Decade; Eastern Europe Continues to Set the Pace, Institutional Investor, Vol. XXII, No. 3, March 1997

Proactive risk management - myth or reality? F. HARTMAN Project Management Specialization, The University of Calgary, Canada

Abstract

Project Management is not a new concept. It ha:;, in fact, been around in some form for many centuries. An early example of a project manager was the master builder who was contracted to put up a castle, cathedral or other significant edifice. What is different today is that the technologies and liabilities have changed. Because of these changes, we are increasingly open to risks including disputes, technological failure, environmental problems, economic shifts politics and more. These risks were always there, but now they are more significant because of the compressed time in which they may change and the awareness of the public. The best way to manage a risk is not to have it in the first place. There are many advantages to this type of thinking. No risk means no time wasted in recovering from it. It also means that we have the freed-up resources to provide a better service and to make a larger profit - everyone wins. Finally, if vve can be confident that we will have no risks, we will be more open to collaboration and cooperation between project stakeholders. Further, the working relationship between project participants will be more open and therefore more conducive to creative and effective collaboration. There is strong evidence that close collaboration, based on trust will yield significant savings. The approach to risk identification, classification and management proposed in this paper is based on both research and practice - with an emphasis on the practical.

Managing Risks in Projects, edited by K. Ktihkonen and K.A. Artto. Published in 1997 by E & FN Spon, 2 6 Boundary Row, London SEI 8HN, UK. ISBN: 0 419 22990 6.

16

Hartman

1 Background and assumptions Risk IS not new to anyone who has been involved in projects. What is new is its intensity, which grows day by day. Technology doubles roughly every three years. Regulation is becoming increasingly precise and focused. Traditional barriers are becoming blurred and irrelevant. We are losing the ability and the need to be logical in all we do. These are bold -and perhaps risky - statements, so we should explore them a bit further.

1.1 Technology doubles roughly every three years Depending on the source, technology growth may be reported as more or less than this rate. The precise figure does not matter, but the impact of all of this new technology and the associated need for knowledge and language to describe the technology and the language is very real indeed. New technology carries risks simply by being new. It introduces risks associated with reliability, acceptance and compatibility with other technologies. It creates risks associated with adopting or not. It affects our competitiveness and that of the competition. But that is just the start. From a project perspective new technology has added a resource need for its development, application and operation. If we double technology every three years or so, we need to do one of three things to keep pace. We can double our staff. This is not an option for most businesses and is not happening. We could double the intelligence of the staff we have. Again, neither a real option nor one that anybody seems to have had success in! Or we can do something else. And that is precisely what we are doing. The most significant element in the suite of options we have is to outsource any work that is not core to our business. We are doing this. We are also relying on suppliers for their expertise more, as we eliminate duplicate organizations within our own business. Engineering teams in owner organizations are becoming leaner or even disappearing altogether. Our definition of core business is also becoming more focused as we try to cope with the exponential growth in technology. A bare five years ago most companies would not have even contemplated outsourcing Information Technology (IT) as it was the life and soul of proprietary information in the company. Yet today this is a booming business. As we push out more of our previously "core" business to specialist suppliers, so we create a new risk area: that of effective communication of our needs. Language has not been doubling every three years. In stead we are recycling words with different and specific meanings to them. The words' meanings now vary by company, department and discipline within a department. To add some spice to this already messy pot, we move people within a company, and hire them from other companies. Each project today is increasingly becoming a tower of Babel. To illustrate this point, consider the word "function". Does it mean someone's job, a celebration or formal occasion, a process, part of a software algorithm, is it something to do with object oriented programming? In one company recently there was a big debate on this word. The definitions were numerous. Other words are suffering similar fates. But most of us are blissfully unaware of the problem and its extent. As a result communication itself has become a huge risk factor in projects.

Proactive risk management

17

1.2 Regulation is becoming increasingly precise and focused Possibly related to technological growth is both awareness of items (such as environmental issues, radio frequencies and privacy) and a need to provide regulations to protect the general public from harm as a result of misuse or damage to these elements. Thus regulatory requirements are growing apace. A few years ago this became an interesting problem for real estate developers, who wanted to develop a database of existing regulatory requirements so that they could manage compliance more scientifically. The project was canceled when they found they were unlikely to capture all the regulations at national, regional andl municipal levels, let alone keep up with the changes! As we look at changes in regulatory requirements and their impact on our projects, we need to consider not just today's regulations, but their interpretation and how they may change and subsequently affect the outcome of our project. Clearly this represents a further set of risks for the project. 1.3 Traditional barriers are becoming blurred and irrelevant The dividing lines between nations, technologies, trade groups, corporations, cultures and more are becoming increasingly blurred with the progress of time. We are seeing an evolution in almost every aspect of living, let alone projects and how they are to be managed. As the various barriers we have been used to for so long disappear or become harder to define, so we enter a world with changing rules for behaviour, business practice and technological development. At least two, and probably all three of these factors will affect our projects. The risks here lie in understanding the new order of business, technology and society in which we live in order to manage the project and the associated resources in a way that keeps us competitive.

1.4 We are losing the ability and the need to be logical in all we do Not being logical in what we do probably comes more naturally than we like to think it does! According to Taylor and Wacker [I], we are leaving the age of logic and entering one of chaos. Their arguments are very persuasive. Simply put, we are working in compressed time and are being influenced by a growing number of things. Using nature rather than logic as a model in which to frame our decisions and actions is arguably a more accurate reflection of today's reality. Most things in nature respond and try to adapt to their environment. With so much that is unpredictable or, at best, hard to predict with any degree of accuracy, the approach to planning a project must, of necessity, include a strong element of risk. Therefore, it should include a proportional amount of risk analysis and management. Our challenge, then, is how do we do this in today's rapidly changing world.

2 The changing world of projects

Today's projects already show signs of change in how they are being managed for success. As we look at some of the breakthrough performance of projects in the North

18

Hartman

Sea, in telecommunications and in other areas, we may be able to discern certain trends. Based on benchmarking and other studies, the most significant elements that are to be found in projects that approach absolute performance are the following. The project leaders take a holistic view of what the project is trying to achieve for the client and the team doing the work, in the context in which the project is happening. The project and the project team is strategically managed. In other words, there is a clear line of sight between the project objectives and those of the businesses involved in it. Each stakeholder can see how the project will benefit themselves and others. The importance of alignment between the stakeholders is recognized and addressed. This means that both common ground and differences are put on the table, discussed, negotiated and modified if need be, and then made part of the project and how the project will be delivered. Effective (regenerative) teams are developed and used in delivery of the project. In other words, the team's well-being is an important part of the project development and implementation process. Projects are all about change or transformation. Transformation management implies uncertainty. If we compare uncertainty and risk, we will see that the essential difference is awareness. Crossing a busy street is a risk. It is a risk if we look both ways, listen for anything we may not have seen, make a decision to cross - presumably because we believe we will not be part of an accident on the way across - then go. If, however, we were to close our eyes, block our ears and stride across at random, that would be more than risky, it would be uncertain! Specifically from the last point, we can see that a large part of risk management is to eliminate uncertainty. In today's world where perception is, to a large extent reality, there are two steps to effective risk management. The first part is a question of moving project elements from "uncertain" to being a risk. This means creating visibility on the issue. If we know about a problem we are half way to solving it. It is the things we did not think about that cause us grief! The second part to today's risk management is to move the risk from a perceived high one to a perceived low risk.

3 Using existing tools If we look at our inventory of tools that are used in risk management, none of them are obsolete: Monte Carlo simulations (probabilistic analysis) Decision Trees Sensitivity Analyses Influence Diagrams Tornado Diagrams

Proactive risk management

19

These tools serve useful purposes in helping us to understand the nature and likely impact of specific risks, once we have identified them. Conventionally we use these tools based on historical information on project outcomes and the application of past information to the development of a plan for a current or future project. To build on the use of these tools, one option i!j to look at LEAD Indicators not just lag indicators in developing the project models that we use to test the outcomes of specific risk events. A useful analogy is to consider how we opt:rate when driving a car. You are driving on a clear road, dry conditions, not only no other traffic, but no pedestrians, excellent visibility and you know exactly where you are going. Most likely the primary information you need is how much fuel you have left, and how fast you are going, so you can determine if you will get there and when you might arrive. Avoiding accidents in such conditions is easy. We have dealt with cost (fuel) schedule (speed) and quality (safe driving). The whole is easy to deal with under perfect conditions. Now what happens if we change the conditions to night time, add fog and ice on the roads, lots of traffic that we can hear but not see, the sound of children playing nearby . . . The first thing that happens is that we look less at the speedometer and the fuel gauge, and focus more on getting to where we are going as safely as possible. In the absence of clear landmarks, we may even wony that we are on the right road! The point of this is that the second set of conditions is closer to reality than the first one. When driving we will probably slow down and readjust our time of arrival. We may consider a different route - usually a safer one that will use more fuel or more time than the original one. This is where the analogy breaks down, because the time and cost pressures of real projects do not allow us to slow clown or consider more expensive but safer options for project delivery just because the project has become a bit more difficult! What we need is the technology to see through the fog and not skid on the ice. We need to know exactly where we are in our plan at all times and we need a flexible enough plan that we can avoid all the other traffic: on the road. To do this we need to go beyond standard use of standard tools.

4 Risk radar and defense system Going beyond these normal tools is what is being given a lot of attention by researchers and practitioners. At the Construction Industry Institute, predictive tools for contract disputes and effective communication have been developed for construction projects. Other predictive tools and models are being developed and tested elsewhere. Three examples of how these are being pursued are summarized below.

4.1 Past tracking design and construction The decision to fast track projects is made regularly on many projects around the world. The decision is normally intuitive, based on consideration of a number of key variables. The variables, and the degree to which any science is used varies

20

Hartman

considerably, with mixed results. Fortunately, projects are different enough that it is easy to hide our less effective decisions! At The University of Calgary, we are just completing a study that will allow project owners to more accurately determine the degree to which they should fast track a project based on required rate of return for the project, completion date imperatives and penalties, contracting strategies, project complexity and other factors. The result will be more effective use of time and money on projects to help optimize the outcome. The risk of fast-tracking to much (and overpaying) or too little (and being too late) are thus minimized. 4.2 The cost of risk assignment in contracts There is risk in assigning risk to others. Often the premium associated with the risk being assigned (usually through a contract) to another party, is unknown. Very occasionally we get to see what the real cost of such a contract condition is. Two relatively recent examples will help illustrate this. A pump supplier bid on a request from a process plant to supply replacement pumps. The order came to a value of about $10 million. However the owner had included a clause that held the supplier responsible for any and all consequential damages arising out of failure for whatever reason of any of their pumps. As this potential cost was in the hundreds of millions of dollars, this supplier offered two prices: $10 million if the clause in question was removed, and $15 million if it was left in place. The owner awarded the contract to another supplier from a different country for $12 million. So here we know the owner paid $2 million at least for the inclusion of this clause. The sad part is that if anything does go wrong, they will be unlikely to recover the money from the successful supplier! In another example, someone wanted to build a wood processing plant. This plant was priced on a turnkey basis by a contractor at $90 million. When the bank that was to provide the project financing saw the contract, they added one clause that held the contractor responsible for the performance of the plant as operated by the owner for five years. This added $10 million to the contractor's price. The project was canceled. Another project at The University of Calgary has collected data from across Canada to determine the impact of adding specific clauses to contracts to assign risk. These cost impacts have never been quantified before. While we wait with bated breath for the result, we do already know that the costs are significant, are dependent of a number of variables that will likely include who is contracting with whom and the probability of the related risk event arising. This knowledge will help us to develop more effective risk management strategies, as the likely cost of different options are unearthed and made visible to business. 4.3 Predicting success of projects using neural networks Certainty of outcome is important to many businesses when investing in projects. This probably increases with the size and complexity of the contemplated project. In the belief that there are a number of factors that can be assessed at the outset (when the project is being identified and developed) we are using neural networks to help predict outcomes of these future projects. The plot study, based on a number of petrochemical projects, suggests that this technology is very promising. Based on

Proactive risk management

21

using a pool of over 100 bench mark study projects, the neural net has been trained with a random 80 projects and the input data from the remaining ones was then used to test the resulting model. The results were always better than any we could obtain using normal statistical models. New factors will be introduced to the next berichmark study to capture some new potential lead indicators of project success. The challenge will be to find effective and repeatable measures for these variables. These variables shed light on the biggest issues that we see affecting project success. Some of these include: alignment of stakeholders openness of communication propensity to take risks trust between stakeholders number of project participants complexity of the project This list should give us a clue as to the risk factors that we need to learn to understand and measure if we are to manage risk more effectively in today's projects.

5 Conclusions The complexity of today's projects is increasing. This means that risk management is not only more complex, but it is more important than ever. To be competitive today we benchmark against the competition and against ourselves, then try to improve on that. This is really no longer good enough. We need to start at the end of this road to absolute perfect performance, and find out how we can get there faster. This applies in all facets of projects. As one example, we understand the need for avoiding killing or maiming anyone on our projects. This equates to a zero accident policy. The perennial discussion on this topic is the debate between the ideal (zero accidents) and better than average (a few accidents are OK as long as it is less than what the average person is doing). If one or the other is set as the project target, does it really affect success. A project had a few accidents - fewer than any other of its kind ever. Ff we set the absolute result as a target, was this "best ever" result a failure? If we are in double jeopardy when we set standards that are difficult to achieve, is this a disincentive to try to attain optimal prqject performance? The business of managing risk involves setting such targets for performance and finding the best way of achieving it. Simply put, if we achieve optimal performance on a project it can only be done if we have found and de-fused every bomb and land mine that lies in the way to success.

7 References 1. Taylor, J. and Wacker, W. The 500 year Delta - what happens after what comes next Harper Business Books, New York, NY, 1997

Establishing project risk assessment teams J.D. FRAME Director of Educational Services, Project Management Institute Director, International Center for Project Management Excellence, The George Washington University, Washington DC, USA

Project-based organizations in both business and government are developing a strong interest in the management of risk. There are several reasons for this new-found interest: The consequences of failure can be catastrophic in today's brutally competitive world, so organizations are seeking ways to avoid failure and to mitigate its effects when it occurs Classical risk assessment methodologies, such as Monte Carlo simulation, are now within the reach of non-specialists through user-friendly, PC-based software (e.g., Palisade Software's @Risk) People in organizations are gradually developing insights into risk management methodologies and philosophies as education and training have grown in this area In 1987, the Project Management Institute declared risk management to be one of the core elements of the Project Management Body of Knowledge (PMBOK) -one consequence is that anyone who wants to pass PMI's project management certification examination must develop basic risk management competencies Naturally, with the growing interest in the management of risk, there are moves to introduce risk assessment processes formally into project organizations. One reflection of this activity is the creation of risk assessment teams in an increasing number of project-based organizations. These teams carry out a variety of functions, from performing independent risk assessments, to serving as risk mentors, to offering justin- time training. This paper examines the function, staffing, and value of risk assessment teams in project-based organizations. Managing Risks in Projects, edited by K. Ki3hk6nen and K.A. Artto. Published in 1997 by E & FN Spon, 2-6 Boundary Row, London SEl 8HN, UK. ISBN: 0 419 22990 6.

Establishing assessment teams

23

1 Risks on Projects A 1994 study of more than 8,000 projects conducted by the Standish Group found that only 16 percent were able to satisfy the famous triple constraints of project management: to get the job done on time, within budget, and according to specifications. Some preliminary research I have carried out confirms the finding that project teams are struggling mightily to do their jobs effectively. In my survey of some 80 project managers I found that one-third reported having cost overruns, one-third had difficulty meeting the specifications, and two-thirds faced schedule slippages. (This last point has led me to label "time" as the killer constraint.) By all accounts, we are not doing a great job in implementing our projects. To rephrase this observation in the context of this paper, we can say that we are falling down in our ability to manage risk. We seem to be having difficulty handling problems that arise within and without our organizations. The sources of risk on projects are well-known. Following is a partial list describing some of the better-known sources: Technical problems -the addition of a new line of code to a database management system causes the whole system to crash; a nuclear power plant turns out to be built on a hitherto unknown geological fault line Incompetent staff -an analyst fails to proofread an important customer report, with the result that the report is error-laden; a data-emtry clerk transposes numbers in an entry, resulting in a $3,000,000 accounting error Regulatory changes -a new municipal building code fobids the use of lead-based solder in water pipes; small business owners are required to provide health insurance to their employees Changes in the players - a new management team decides to wipe the slate clean and implement a whole new set of project procedures; our most important client has a new boss, who decides to change the requirements on a deliverable that has been under production for one year Actions of competitors - a competitor introduces a new product that makes the product we have on the drawing board obsolete; our competitors have dramatically dropped the price on an important product, causing us to lose market share Environmental traumas - a surge of inflation causes project costs to skyrocket; the attempt to repair the damages created by a devastating hurricane in Florida leads to nationwide shortages of plywood Poor time and cost estimates - sales staff promise customers that the project team will do a ten month job in six months; when presented with project budgets by the engineering staff, a district manager automaticalXy cuts them by twenty percent Some of these risks and their associated difficulties are predictable, others are surprises. Some arise within the organization, others outside. In some cases we can take steps to avoid the risks, in others the risks are unavoidable. Until recently, problems like those enumerated above were addressed in a haphazard way. If we happened to become aware of a possible difficulty, we would, of course, take steps to

24

Frame

deal with it. The problem is that awareness of the problem would occur largely by accident. By the time the problem was discerned, the damage had been done. The current focus on conscious risk assessment tries to reduce the level of accident in our identification of possible risks. It is hoped that through the employment of systematic risk assessment techniques and the establishment of risk assessment teams we can get a good handle on risk on our organizations.

2 Functions of Risk Assessment Teams Risk assessment teams can serve their organizations in a number of different ways. They can: conduct independent risk assessments for different projects As a project is being carried out, it may be appropriate from time-to-time to bring in a risk assessment team to review the project's risk status. This is particularly helpful during the project selection stage and at crucial milestones. develop risk assessment standards and procedures for the organization Effective risk management requires the development and analysis of data, the creation and employment of risk checklists, and the selection of specific risk assessment techniques (such as Monte Carlo simulation, scenario building, and decision tree analysis). Well-established risk assessment teams are obvious candidates to play the role of the guardians of standards and procedures serve a mentoring and consulting role for players in the organization who need guidance on appropriate risk assessment practices The members of risk assessment teams can offer their organizations their availability as risk consultants and mentors. This can be helpful to project teams that do not seek full-scale risk assessments of their projects, but who nonetheless would like to receive occasional guidance on appropriate risk assessment practices. Mentoring may also entail working closely with senior management to help them understand risk-related issues. offer risk management training, both formally in the classroom as well as through just-in-time modalities In order to introduce risk management principles into the organization, it may be a good idea to offer training in this area to employees. Risk assessment team members should certainly play a significant role in this effort. They can either develop and teach short risk management courses, or can play an instrumental role in working with contractors to create an appropriate risk management training curriculum. It should be noted that in their capacity as consultants and mentors, members of risk assessment teams are offering just-in-time training to their colleagues. select and maintain risk management tools Members of the risk management team are best positioned to identify what software offerings can be used in their organizations. They should review new offerings as they emerge and determine which should be included in their organization's basic risk assessment toolkit.

Establishing assessment teams

25

serve as the central resource repository for the distribution of risk management resources to the organization The risk management team may be comprised of only two or three people whose job is to distribute resources to people within the organization to enable them to deal with risks effectively. (That is, these people have a measure of control over a risk through the efforts of the risk management budget.) Some risks are ident~~fied management team members, who are continually scanning the organization in an attempt to discover sources of risk. In addition, the team may allocate resources to other employees who have identified risks on their own during the course of their work.

3 Real World Example of a Functioning Risk Assessment Office ABC Company is a large information systems cornpany --operating in more than thirty c o u n t r i e H h a t produces computer hardware and also offers systems integration services. Some key decision-makers at ABC grew concerned in the mid-1990s about the fact that the majority of projects that the company had launched were in "recovery" mode. That is, these projects were failing to meet their objectives and steps were being taken to get them back on track. A review of the troubled projects led management to believe that many of the failures were rooted in the fact that ABC staff (e.g., sales personnel) were making promises to customers that the company could not keep. For example, they might promise that a six-month job can be completed in four months. Or they might tell customers that ABC's engineers could offer product features that, in reality, simply could not be realized. In order to deal with excessively optimistic promises, ABC's management decided to establish a risk assessment office, whose key function would be to review promises made by ABC staff before major contracts were signed. The risk assessment office was staffed with a dozen senior project managers who received training on risk management principles. They would be assigned either individually or in groups to conduct risk assessments on projects that were about to be launched as contracted efforts. They were given two weeks in which to conduct their assessments. At the end of their investigations, they would write up a report describing their findings about the risk worthiness of the proposed project. The risk assessment team members did not have the power to kill a project. If they believed a potential project was a bad risk, they would state this in the write-up and provide a rationale for their view. The project sponsor (often a high level official at the vice president level) had the power to decide how to proceed. They could abandon the idea if it was deemed to be too risky, or they could modify it to reduce risk levels. They could even decide to move ahead with the project despite the risk assessment team's contrary advice. However, if they moved ahead, they would have to sign a statement saying that they understood that the team advised against moving forward and that they were contravening this recommendation. Interestingly, within a few months of implementing this new process, project initiatives decreased by more than twenty percemt. What happened was that the new

26

Frame

process held senior managers accountable for the initiatives they sponsored and few of them now dared to promote project ideas that made unrealistic promises to customers. A feeling quickly developed at ABC that the risk assessment office was succeeding beyond initial expectations. As their reputation for effectiveness grew, risk assessment team members found that their services were being requested by a wide array of colleagues in the company. Increasingly, they performed mentoring, small-scale training and consulting activities. ABC also explored using their risk assessment approach in areas outside of project management.

4 Staffing the Risk Assessment Team The composition and qualifications of the risk assessment team depend, of course, on the precise nature of the work the team is charged to carry out. The staffing requirements for a full-blown risk management office will be different than for a twoperson risk assessment team. Following is a list of possible professional staff positions that may be appropriate for a wide variety of risk assessment efforts. Risk management professionals-general comment. Risk management professionals are very much like financial auditors. They must be capable of assessing situations independently, without prejudice. They must also be willing to report the truth, no matter how distasteful this may be. This means that they must be tough: their decisions will occasionally be unpopular with powerful players in the organization, and they must be capable of resisting pressure from these players to change their verdicts. Like auditors, risk management professionals must also be superlatively competent. They should be masters of the facts and techniques of their trade. If they are hesitant about a methodological point or are uncertain of a small fact, this can destroy their credibility. Senior professionals. These individuals should be highly experienced project professionals, with more than fifteen years of successful project management experience under their belts. Because they are highly experienced, they should be able to identify risky situations readily and should know what steps to take to handle them properly. Their backlog of experience is also valuable in enabling them to cope with the politics of mitigating risk. For example, their risk assessment may lead them to conclude that a given project initiative sponsored by a powerful vice president is likely to fail - do they have the skills to present their arguments in a politically acceptable fashion? The senior professionals need explicit training on risk management principles. They should study, learn and master techniques of risk identification, risk impact analysis, and risk response planning. They should be literate in the use of computerized spreadsheets and scheduling packages. In 1997, the salaries of these individuals ranged from $85,000 to $120,000 per year. Mid-level professionals. These individuals should have at least five to ten years of successful project management experience. They should understand the basic risk management process (risk identification, risk impact analysis, risk response planning, and implementation of solutions). They should also possess total mastery of risk management techniques, including the conduct of "what-if' analyses using PERTICPM

Establishing assessment teams

27

software and Monte Carlo simulations. They should be literate in the use of computerized spreadsheets and scheduling packages. In 1997, the salaries of these individuals ranged from $55,000 to $90,000 per year. Entry-level professionals. Entry-level professionals engage in the detail work of the risk management effort. They collect the data needed conduct effective risk assessments.Typically, these people have limited project management experience (e.g., from one to five years of experience working on projects). They should be familiar with basic risk management techniques, including the conduct of "what if' analyses using PERTICPM software and Monte Carlo simulations. They should be literate in the use of a wide range of computer software, including electronic spreadsheets and scheduling packages. In 1997, the salaries of these individuals ranged from $35,000 to $65,000 per year.

5 Conclusion As managers within organizations become more aware of the need to manage the risks they face in their operations, they will support efforts to conduct risk assessments and implement risk mitigation actions in a systematic fashion. One consequence of this orientation will be the move to develop risk assessment teams comprised of seasoned professionals. The primary function of these teams will be to carry out risk assessment reviews on projects in order to identify possible sources of risk and to suggest actions to deal with them. Beyond this, team members are likely to find themselves carrying out broad range of risk management activities, including consulting, training, mentoring, and maintaining risk management standards for the organization.

PART 2

CASE PROJECTS - PROJECT FAILURES, RISK HISTORY AND LESSONS LEARNED

In search of best practices in risk management J.I.M. HALMAN and P.M. VAN DER. WEIJDEN Faculty of Technology Management, Eindhoven University of Technology, Eindhoven, The Netherlands

Abstract In the paper three development projects will be described and analyzed on the way the project risks were managed. This risk evaluation study was carried out within three separate business units of a multinational company in the electronics industry. As a result of the analyses, a risk reference frame has been developed and will be explained and discussed in the paper. This framework consists of points of attention and possible risk measures and solutions that have proven their value in practice. Key words: Risk Management, Product development projects, Best practices in risk management

1 Introduction The study reported in this paper has been carried out within a multinational company in the electronics industry. It has been carried out on request of senior staff members of the Centre for Development Support within the company concerned. The primary goal of the Centre for Development Support is to increase the chances of successful product developments within the different business units of the company. One group within this Centre has its focus on Product Creation Process (PCP) improvement. This PCP-improvement group often receives questions from business units within the firm about possibilities to improve their product creation processes through the application of risk management. Purpose of the study reported here has been to support the PCP-improvementgroup in developing a frame of reference on the role and successful application of risk management in product development projects. For the field research three product

Managing Risks in Projects, edited by K. K&kilnen and K.A. Artto. Published in 1997 by E & FN Spon, 2 4 Boundary Row, London SEI 8HN, UK. ISBN: 0 419 22990 6.

32

Halman and van der Weijden

development projects have been extensively evaluated on the way the project risks were identified, assessed and managed. Twenty-two persons who have been involved in the projects concerned were interviewed and the relevant available documentation was studied. Each of the three evaluated projects was carried out within a separate Business Unit (BU). In the first BU, the project concerned the development of a new type of interactive CD player. This project had been initiated by a central Product Division responsible for the development and launching of interactive media systems. The Product Division had the ambition to force a breakthrough with the interactive compact disk in the USA. Therefore an interactive CD player had to be developed which would cost half the price, but with the same functions as players launched before. The new project had to be carried out in a relatively short throughput time. In the second BU, a new range of electric shavers had to be developed as a successor of the former range of electric shavers. This BU is the biggest manufacturer of electric shavers in the world and it has a leading position in many regional markets. Characteristic for this BU is that almost all activities to develop and manufacture a new range of shavers are carried out without external supply. This means that almost all the parts of the devices and tools for production processes are developed and produced within this same BU. The third BU, that has been part of study, develops and manufactures analytical X-ray tubes. The X-ray tubes are an important part of systems for material analysis. These systems are used in industrial and scientific environments. The BU has a few major competitors. In order to keep or increase its market share products should not only have a good quality but also a competitive price. The quality of an X-ray tube is determined by the reliability and the lifespan of the tube. This depends on the design of the X-ray tube, the quality of the parts delivered by suppliers and the degree to which the production processes are controlled. Many steps in the production are carried out by hand. The three evaluation studies have resulted in a first draft for a frame of reference. Business units may use this frame of reference to improve the way risks are managed in their product development projects. In this frame of reference four phases in risk management are distinguished. Each phase comprehends a number of activities that should be carried out in the respective phase. On the basis of the evaluation analyses, areas that need special attention have been formulated. The study resulted finally in a description of several good practises which may be transferable to other development projects within the company. The main outcomes of the study will be presented in the next sections. 2 Conceptual framework Risk management as an essential part of the development process emphasises the importance of a well structured, planned and reliable approach of risk management. The risk management structure as advocated by the Centre for Development Support (see figure 1) has been derived from the US Department of Defense [I]. This structure

Best practices in risk management

33

consists of four separated but related phases. Each phase comprehends a number of defined activities: RISK STRATEG Y

L

RISK ASSESSMENT Quantify Qualify 8 Prioritise

L

RISK ANALYSIS Options Decision making

L

RISK'HANDLING Accept Avoid

Fig. 1. The Risk Management Structure

1 . Risk Strategy To secure an effective and efficient risk management process, it is important to decide on the purpose of risk management and to prepare in advance an appropriate way to assess, analyze and management the project risks. In this respect it is important to select the right method and tools, to assign appropriate and sufficient resources and to agree on authorities and responsibilities for the whole process. An important topic in this phase also concerns the possibilities to tune and integrate the risk management activities with the usual product development activities. 2 . Risk Assessment Purpose of the risk assessment phase is to identify, to qualify and to prioritise the project risks. The sooner risks are identified, the more options will be open to adequately respond to the identified risks. In order to prioritise the identified risks it will be necessary to qualify them in terms of low, medium, high, or even fatal risks.

34

Halman and van der Weijden

3. Risk Analysis Purpose of this phase is to analyze more in-depth the causes and consequences of the assessed risks. Based upon this analysis potential options to control the diagnosed risks are devised and further worked out. Decisions are made on alternative risk actions that can be taken. 4 . Risk Handling Risk handling is the action or inaction taken to address the risk issues identified and evaluated in the risk assessment and risk analysis efforts. Generally these actions fall into one of the following categories: Risk avoidance (selecting a lower risk choice from the alternatives available); Risk acceptance (a conscious decision to accept the consequences should the event occur); Risk transfer (reduce the risk exposure by sharing the risk with a third party); and Risk control (the process of continually monitoring and correcting the conditions of a project).

The risk management structure as described above has been used as a conceptual framework to structure and record the risk management activities carried out in the respective projects that were part of the evaluation research. First a list was made of the explicitly planned risk activities. After that the list was extended with regular activities and measures in the project which implicitly contributed to the management of project risks. The complete overview was subsequently used to thoroughly analyze the available data. As a result of the analysis for each phase of the risk management structure a number of 'points of attention' have been formulated with accompanying practices which have proven their added value in at least one of the investigated projects. The three case studies will be explained further on in the next sections.

3 Case Study 1: The development of an interactive CD player Project "Saturnus" concerned the development of a new type of interactive CD player. Considering the ambitious objectives to realize a halving in cost price within a relatively short period of time, project Saturnus could be characterised as a technical breakthrough project. This was the reason for the project team, to formulate a risk management driven strategy for project Saturnus. The core of this strategy was to focus already from a very early stage in the development process, on the identification and as far as possible the avoidance of potential technical bottlenecks in the product and production design process. In the concept phase of the project opportunities were investigated to reduce the cost price by developing cheaper product design solutions. Out of four alternatives, one definitive concept was selected for further development. The risk strategy in the project was to have this selection on the basis of an evaluation on potential bottlenecks in the product design process and production process. To enable a simultaneous development of parts of the interactive CD player, a relatively independent development of parts of the interactive CD player was chosen

Best practices in risk management

35

Non conformity with safety standard Results in product which no customer will buy or which cannot be produced on industrial scale Results in product which critical customer will not buy or which is difficult to be produced on industrial scale Results in product which customers will buy and produced satisfactory on industrial scale Technical Evolution

Fig. 2. Example of a Maturity Grid as design strategy. This could prevent the need far intensive exchange of information and consultation between sub-groups in the project team. The approach was supported by four FMEA's (Failure Mode and Effects Analyses), executed during the course of the project in subsequent stages of development. With every subsequent step, it appeared to be possible to identify potential technical risks more accurately and to analyze these risks more into detail. Each risk factor identified and analyzed through an FMEA, was recorded into a so called 'Maturity grid' (see figure 2). In the Maturity grid risk factors are graphically categorised according to their impact (varying from a serious safety problem because of non conformity with standards up to a well accepted product) and the solution degree of the technical problem (varying from solution to solve problem unknown up to solution known and satisfactory industrially tested and implemented). After each FMEA, the maturity grid was adapted to the actual technical progress of the project. Through the FMEA's it was possible to discuss thoroughly on a beforehand basis the available technological possibilities. Unnecessary delays caused by changes could be prevented to a1 great extent in this way. A serious point in this respect concerns the involvement of suppliers in the risk 'management process. If a product consists of several parts delivered by suppliers, it is essential for the product design to also take into consideration the limitations imposed by the production process systems of these suppliers. Considering the advocated risk management strategy to focus on bottlenecks, an early involvement of critical suppliers participating in the FMEA process is essential. For the control of technical risks the approach proved to be successful. There were no major problems in realising the intended product functions and to come up to the

36

Halman and van der Weijden

demands concerning reproducibility of product design. At the end it appeared feasible to realise a halving in cost price within a relatively short time period. 4 Case Study 2: A new range of electric shavers Project "Jupiter" concerned the development of a new range of electric shavers as a successor of the former range of electric shavers. Because of the very complex device with heavy demands on the quality it was considered as a risky project. Risk management in project Jupiter was aimed at synchronising the activities and decisions in the PCP. To achieve integration across the functions in a timely and efficient way, intensive communication between all members of the project team played an important role in the development process and the control of risks. Except for executing tests and risk analysis sessions, for an important part risks in the Jupiter shaver project were controlled by the applied project approach of intensified communication. First of all was the communication facilitated by a one-room approach. Not only core members of the project but also satellite members worked on the same floor without separating walls. The close exchange of information was also facilitated by CAD drawings, shared via a computer network system on location. Project team members were further encouraged and felt free to speak up immediately when they foresaw problems. Besides the CAD model also a physical model of the Jupiter shaver was available, and team members were urged to hold periodically this model in their hands for a critical look and to bring up potential problems directly. Because of the created conditions, all members of the project team were simultaneously and constantly kept informed on the progress of the project and could immediately give their feedback. The assessment and control of project risks were supported (as in project Saturnus) by FMEA's, recorded and kept up in Maturity grids. FMEA's were carried out for the shaver modules and also for the complete shaver. Focus of the FMEA's was to consider the risks of the device from the perspective of the consumer, the producibility of the shaver and the manufacturing performance. To verify the appropriateness of the device several tests were carried out. Besides mechanical and thermal tests, in the development phase of the project a prototype version of the shaver was also sent to consumers to get their feed back. This was done to test the relevance of several aspects on their marketing potential. The complexity of the device is to a great extent created by a large number of components in a relatively small device. To be also commercially viable, it is required that the devices are economical producible in high volumes using a relatively automated and connected production process. Every change in the product design will also have its effect on the production process design. To meet all commercial and technical requirements, a product had to be designed at the edge of what was at that time technical feasible. At the end the project team succeeded in realizing a successful new shaving system, with a new power supply system and with new software. The applied risk management strategy to concentrate all vital activities on the same floor, and facilitate the process with supporting risk methods and tools have contributed to a great extent in achieving this result.

Best practices in risk management

37

5 Case Study 3: The development and manufacturing of X-ray tubes The third Business Unit that has been part of our search to find good practises in risk management develops an manufactures analytical X-ray tubes. X-ray tubes are developed and manufactured according to the 'engineering to order' principles. This means that the X-ray tubes are custom-made developed for specific applications. Although custom-made, X-ray tubes are always made up by similar parts. An X-ray tube has an electronic part to generate the X-rays in vacuum in a glass tube, a construction to support the parts, and a beryllium window. Tubes with a high potential also have a cooling system. The number of X-ray tubes which are produced of a certain type varies from only a few up to some hundreds in case of a more common type. To maintain or enlarge its current market share, the Business Unit will have to deliver against a competitive price and within a time agreed on beforehand, a good quality product. This quality is especially determined by the reliability and life span of the Xray tube. These factors are dependent on the tube design, of the components delivered by suppliers and the degree to which the manufacturing processes are controlled. Although the designers and engineers within the Business Unit have built up a lot of experience with developing X-ray tubes, still there are design decisions of which the consequences for the X-ray tube behaviour iin production or in-use with the client are not exactly known and as a consequence difficult to predict. FMEA's are carried out to evaluate in a structured way the different solutions. An important subject of the risk analyses therefore are the uncertain consequences of design decisions. After determination of these uncertainties a study is made of possibilities how to reduce these uncertainties. A specific problem for X-ray tubes is that not all properties of this tube can be tested. No possibilities are available for instance, to accelerate the process of wear in order to determine the expected life span of the product. Considering the high cost price of the product and the limited numbers that are produced, also destructive tests are beyond reach. To acquire more certainty.,the project team utilizes the available knowledge and experience of several colleagues within the Business Unit. For this, a project risk consultation forum has been created within this Business Unit. On a regularly basis this consultation forum meets to discuss and reflect on potential risks in current projects. Project managers present the uncertainties they are facing in their projects and based upon their experience with former projects, members within this forum contribute by thinking of potential solutions. Dependent on the application of the X-ray tube, the size and material of the parts differ. These differences can have important consequences for the construction of the X-ray tube. To secure that components from suppliers meet the required quality standards, SPCJs(Statistical Process Control) are carried out to verify if their processes are within acceptable tolerances. Because of the extreme accuracy required during the assembling process of the X-ray tube, the producibility of the product design demands for special attention and is always considered one of the key risks. Several of the steps in the production process need to be carried out by hand by skilled operators. Time to train an operator takes more than one year. In addition to this a special training period is needed for the operator to get used to the production of specific types of Xray tubes. To secure a good transfer in knowledge from engineering to production, the

38

Halman and van der Weijden

first production run of a new developed X-ray tube is carried out by a team consisting of both members from Engineering as well as operators from Manufacturing. The degree to which risks are controlled in this Business Unit is highly dependent on how well the experiences of the members within the organization are effectively utilised. Because the Business Unit is a relatively small organization, it is relatively easy to consult colleagues in an informal way. The project risk consultation forum helps to structure this process of mutual learning.

6 A draft for a Risk Reference Framework As a result of an analysis of the evaluation studies, for each phase of the Risk Management Structure a number of 'points of attention' were formulated. Along with the points of attention a number of solutions and measures to respond to (potential) risks were found in the three case studies. The points of attention, together with the risk measures and solutions that have proven their value in practice have been divided according to the phases as distinguished in the Risk Management Structure. The following points of attention have been included in this Risk Reference Framework: 1 . Risk Strategy A clear purpose of risk management and an effective approach to follow Appropriate moments to assess, analyze and decide on identified project risks 2 . Risk Assessment An effective utilization of the relevant available knowledge within and outside the organization Determination of relevant interrelations between technical, financial, commercial and organisational aspects Completeness of the assessment insofar possible through a systematic approach Openness between groups and individuals to express perceived potential risks

3. Risk Analysis An appropriate fit between invited participants and the risks to be analyzed A decision making process leading to commitment by all parties involved 4 . Risk Handling

A timely identification of new or unforeseen risks via an adequate process of risk monitoring and control Outcomes of the risk analysis formulated in such a way that these can also be used as guidelines for decisions in the development process Figure 3 shows a first draft for this Risk Reference Framework. The points of attention as just described are connected in this reference framework with the risk measures and solutions as found in the three evaluation studies and described in the previous paragraphs. The overview with 'points of attention' gives a broad spectrum of aspects which are relevant for a successful management of project risks. The solutions are

Best practices in risk management POINTS OF AlTENTION

39

POTENTIAL MEASURES 81 SOLUTIONS

RISK STRATEGY A dear purpose of risk ma1:agement and an effective a0~roach

..

H

Appropriate moments to assess, analyze 8 decide on identified risks

i

Independentdevelopment of modules by diaanosina knowledaeconstraints (pr&ct ~zturnus) Integration across functions by a one-room approach (project Jupiter)

t

i

FMEA0srepeated in subsequent stages of technical development (project Satumus 8 Jupiter)

RISK ASSESSMENT

I

I

Effective utilization of available knowledge Determination of relevant interelations between technical, financial, commercial and organizational aspects Completeness of the assessment

Besides mechanical and thermal tests also prototype testing by consumers (project Jupiter)

Openness between groups and individuals to express perceived risks

1

I

I

Installation of a project risk consultation forum (x-ray tubes) Encourage informal contacts (project Jupiter)

For technical risk assessments: use layered CAD-drawings as reference (project Jupiter)

i

Create project culture to bring up potential problems (project Jupiter) i

I

RISK ANALYSIS An appropriate fit between invited participants and the risks to be analyzed A decision making process leading to commitment by all parties involved

t h

Invite key suppliers for risk sessions (project Saturnus) A well considered balance between plenary subgroup and individual risk analyses (project Jupiter)

9

Everyone's vkwpoht is valid and focus on pmject objectives

RISK HANDLING A timely identificationof new unforeseen risks Outcome of risk analyzes are guidelines ta decisions in development process

-

,

1i - i

Fig. 3.

Shared CADdrawings will enable anticipation of risks (project Jupiter) Expert consultation (X-ray tubes)

Determinedesign rules and select preferred components (project Satumus) Use Maturity grids as reference

Risk reference frame: collected points of attention with risk management measures and solutions

I

40

Halman and van der Weijden

examples of good practices. This does not mean, that they will always be just as appropriate as has been described in the case examples. It is important in this respect to consider the pros and cons and to also think of potential alternatives which may better fit with the specific situation. The elements and examples included in the risk reference framework are explained in more detail in a reference guide [2]. 7

Conclusion

This field research has confirmed the conviction [see e.g. 3,4,5] that risk management is a strong vehicle to increase the chances for a successful (development) project. Purpose of the study reported here has been to develop a frame of reference on the role and successful application of risk management in product development projects. Through the evaluation studies several examples of risk management with proven value into practice have been collected. Based upon an analysis of the field research, for each phase of the Risk Management Structure a number of 'points of attention' have been deduced. The Risk Management Structure combined with the 'points of attention' and potential risk measures and solutions is the first draft for a frame of reference which can be used by firms to improve their application of risk management. This framework is based so far on a limited number of product development projects carried out within three Business Units of the same multinational company. Further evaluation studies within varying empirical settings may enrich the framework with more examples of good practices in risk management. This will enable the development of a body of knowledge on good practices in risk management that may be useful for both project management professionals as well as consultants in the field of risk management.

8 References 1. US Department of Defense, Risk Management - concept and guidance, Defense Systems Management College, USA, March 1989.

2. Weijden, P.M. van der, Risk Management in Product Creation Processes (in Dutch), Eindhovenuniversity of Technology, Faculty of Technology Management, Eindhoven, 1997. 83 pp. 3. Project Management Institute (PMI), Project and Program Risk Management: a guide to managing project risks and opportunities, the PMBOK Handbook series, volume No 6, 1992. 4. Halman, J.I. M., Keizer, J. A., Diagnosing risks in product-innovation projects, International Journal of Project Management, Volume 12, no 2, May 1994, pp 75-81. 5. Philips CFT Development Support, Concurrent Engineering Handbook, Philips CFT Eindhoven, Eindhoven, 1994.

Understanding project risk: lessons from past failures J.K. PINTO Penn State University, Erie, USA

Abstract One underexplored method of project risk assessment lies in the use of past project failures as a method for suggesting likely forms of future risk and reasonable approaches for mitigating these concerns. The study of famous project failures holds a number of important lessons for project managers. The obvious difficulty in loolung at disaster lies in our willingness to objectively mine these failures for their relevant lessons. This paper offers twelve principles on how to ruin a project, based on the author's recent book looking at famous examples of project failure. Each of these principles can, by itself, go far toward ensuring that a project is destined to fail. KEYWORDS: Project Failure, New Product Development, Case Studies 1 Introduction

The challenges inherent in new product development are truly daunting. One of the problems with attempting to assess project risk for these projects lies in the exploratory nature of many of the endeavors; that is, when an organization is exploring a new technology or pushing out the edges of the innovative boundary, they are, by definition, dealing in new, uncharted waters. The challenge lies in accurately measuring and assessing project risk when there are few past efforts that allow US to establish reasonable parameters. This paper will suggest one method for creating parametric estimates of new product development risk - examining cases of past project failure. I argue that there are a number of theoretical as well as practical lessons that can be learned from the study of project failures. The common error of many organizations is to ascribe all past failures to unique characteristics in the recent failure and move on, often without a backward glance as to why a particular project never lived up to expectations in the marketplace. This attitude is indeed a pity because it negates the availability of abundant information for establishing reasonable levels of future project risk. What are the lessons all organizations involved in new product development can learn from

Managing Risks in Projects, edited by K. K2hkirnen and K.A. Artto. Published in 1997 by E & FN Spon, 2 4 Boundary Row, London SEI SHN, UK. ISBN: 0 419 22990 6.

42

Pinto

failure? This paper will explore twelve of the most common forms of error based on famous examples of past project failure. Readers need to draw appropriate lessons from these examples, seeking to determine how they shape risk assessment for their ongoing project efforts. For most of us, there is a fascination that comes from analyzing past project failures. Not our own, of course. About those, we often feel that the less said, the better! No, our sometimes morbid curiosity is peaked by knowledge of how other projects, with other project managers, have failed. Sometimes these failures occurred quietly, with funding being withdrawn from projects that became increasingly nonviable. Other project failures have been far more spectacular and sometimes deadly. The collapse of the overhead walkway at a hotel in Kansas City some years ago resulted in the deaths or serious injuries of hundreds of people. The famous collapse of the Tacoma Narrows suspension bridge in 1940 led to a reassessment of bridgebuilding techniques and the role that aerodynamics must play in bridge design. All these examples, both the famous and mundane, have important lessons for project managers, if we are willing to listen to them objectively. When analyzing project mistakes and their principal causes, there are two important lessons that should be apparent to every careful reader. First, all organizations, no matter how successful they have been or will continue to be, make mistakes. Ford Motor Company, IBM, Mitsui, Sears, and other corporate giants have all had their share of disasters to go along with other, more talked about, successes. This is the nature of business events - the cycle moves through both highs and lows. For every project success, there will always be one or more failures. The second lesson is equally clear: where there is failure, there is the potential for learning. This second lesson, however, is also potentially threatening. It says, in effect, that failure (particularly past failures) is not to be pushed aside, but studied. 2 How to Position New Projects for Failure

Not every project deserving of success achieves it. Conversely, not every project heading for the scrap heap amves. Clearly, there are any number of events beyond the control of the project team and parent organization that can help or hinder a project's chances of success. Nevertheless, when we consider those activities and decisions which can play an important role in a project's failure, our research and experience point toward some important contributing causes of project failure. Consider the list of a dozen sure-fire methods for ruining your project's chances of success: 2.1 Ignore the project environment (including stakeholders) One of the best ways to consign a project to almost certain failure is to manage it without regard for the organization's external environment, including those project stakeholders who can play such an important part in a project's success or failure. Project "stakeholders" is the term used to refer to any group, internal or external to the company, that has an active stake in the project's development. As such, stakeholders include clients, the overall marketplace, internal functional departments, top management, the project team, and external groups who have been termed "intervenors" by Cleland [I]. Intervenors include any environmental, social, political, community-activist, or consumer groups that can have an impact on a project's successful development and launch. T o ignore the potential power of such stakeholder groups is foolhardy and often results from either ignorance o r complacency on the part of the developing organization. There are numerous examples of problems that can occur when project organizations forget their client base or assume that they know more than their

Project failure and risk assessment

43

stakeholder groups. One clear message that comes through time after time is the prevailing power of such stakeholder groups in aiding or thwarting a project's successful development. The corollary is to bear in mind that not all stakeholders are external to the organization. Many projects have been derailed due to opposition (either overt or covert) from other functional groups or operating divisions. Prior to the "go" decision, one highly important factor must be considered: The receptivity of the organization's internal environment to the proposed project. If there is the faintest suspicion of disharmony, it is important to take time to reassess the reasons and take corrective action, including working with stakeholder groups to understand their concerns or malang necessary adjustments to the project.

2.2 Push a New Technology to Market Too Quickly New technologies imply new and unknown risks. Sometimes the allure of being first to market with a new technology causes companies to cut comers, marginalize safety factors, or make quality trade-offs. In the end, these decisions almost invariably come back to haunt that company's executives, sometimes with tragic results. DeHavilland's desire to be first to the market ~ 1 1 tah commercial jet resulted in the creation in 1952 of the Comet, a faulty design that ultimately killed scores of people and by 1954, was withdrawn from the market. In contrast, the first American jetliner, Boeing's 707, made appropriate use of many of the engineering lessons from the Comet and created a safer and hugely profitable p~roduct. New technologies are very tempting to exploit for exactly that reason: They are new. They offer the company a leg-up on competition. Unfortunately, in our rush to push these new designs or technical achievements, there is a strong likelihood of inadequate or cursory pre-testing that can result in disaster. There must be a proper balance asserted between being the first to market and ensuring that the product will perform in positive, expected ways. 2.3 Do not Bother Building in Fallback Options All projects run into trouble at one time or another. The question is not whether problems will occur but rather, to what matter of degree. When these difficulties start impeding progress, one of the tests of good project management is how quickly the project is brought back on course. This point irs important because it disputes the notion some readers may have that "good" project managers are those whose projects never get into trouble. That belief is patently untrue. Not all problems are foreseeable. Consequently, the true test of succe:ssful project managers lies in their flexibility and capacity to respond in clear-headed ways to problems once they occur. A logical exercise in which project managers must engage is to continually ask a series of "What if?" questions. These sorts of questions force the project manager and team to proactively search out likely problem areas rather than waiting for trouble to find them. An important side note: Research has shown that the project managers who spend adequate up-front time developing a series of "what if?" scenarios and their responses to them are more successful than those who operate in a purely reactive manner, waiting until problems occur before weighing their various responses to them. In fact, one of the authors once conducted a large-scale study of project failure and found that the number one cause of failure was the lack of adequate trouble-shooting [2]. The study demonsfrated the strength of this underlying message: namely, that problems are inevitable. However, the successful project managers are those who are best able to adapt to the new situation with flexibility, look for opportunities, and bring their projects back up to speed rapidly.

2.4 When Problems Occur, Shoot the Most Visible Problems with projects, particularly on a large scale, tend to induce an element of panic from top management. Many times, such panic leads to foreseeable and

44

Pinto

regrettable outcomes: the knee-jerk sanctioning of key personnel. For example, once top management 1s in the panic state, 11is common to see heads begin to roll, starting with the project manager and anyone else who is clearly seen m part of the decisionmaking team. Such a mindset is no different than that which used to be regularly practiced within unsuccessful armies - shooting a scapegoal porir encoltrager les aztfres. The similar belief exists in many corporations: A public sacrifice will keep everyone else working productively. I n the absence of obvious incompetence or misbehavior, the consequences of this extreme reaction should be clearly considered before it is acted upon. Frederick Brooks, in his classic, The Mvtlrical Mna-Month, demonstrates that personnel changes in the midst of a project, particularly when an element of urgency has crept in, are almost invariably counter-productive. Because of the learning curve, it takes that much longer to bring new personnel up to speed on the project, delaying it further into the future. Pnor to making personnel changes. ask the question "What do we hope to accomplish by this change?" While there is no doubt that in the face of ongoing problems with a project i t is tempting to demonstrate decisive action in the form of reorganizing and punishing. it is important lo first consider the reason for such actions and the message we intend to send. Project managers who are constantly looking over their shoulders out of paranoia and fear of retribution are not projcct managers who are capable of taking necessary risks and acting in ways to further project success. 2.5 Let New Ideas Starve to Death Through Inertia The flip side of pushing new technologies out the door without having spent adequate time assessing problem areas is to allow new products to remain in a holding pattern indefinitely. For example, few readers will recognize the Xerox Alto personal computer, in spite of the fact that personal distributed computing is a concept that was developed at their Palo Alto Research Center (PARC) in the early 1970s. In fact, Xerox had a working prototype of a personal computer, complete with mouse, word processing software, and a laser printer by 1974. And yet, during the decade of the 1970fs, Xerox, through a combination of political in-fighting and bureaucratic roadblocks never developed the Alto personal computer into a commercial product, thereby sacrificing millions in profits over the next two decades. How did a company create a sure-fire winner and then sit on it? Certainly, organizational inertia played a role. There was no obvious avenue for bringing these products to market and Xerox executives lacked the will to take a gamble. Further, the training of their top management team was predominantly financial: The numbers game, with its low propensity for risk, enthralled them. The result was Xerox's apparent willingness to forgo huge profits in order to take the safe route. The irony, of course, is that this same company had made its reputation by taking a large risk in introducing the model 914 copier in the early 1960's and at the same time, revolutionizing office technology. For want of the will to take another calculated risk, Xerox lost a dominant position in personal computers. The rest is, as they say, history.

2.6 Never Bother Conducting Feasibility Studies Why waste time checking to determine if a new technology will work? Why wony about harmful side-effects? Why bother considering customer concerns? Obviously, the answer to each of these questions is because failing to do so is one of the surest roads to project failure. Feasibility planning implies an organization doing their upfront homework to put themselves in the position to conclude a project successfully. Feasibility studies require that project managers and upper management devote sufficient time to understanding the project's risk analysis, cost analysis, time frame to completion, stakeholder analysis, and other relevant information before funding is

Project failure and risk assessment

45

approved. Certainly, the real danger of such analyses is that they operate under a "Garbage in - Garbage out" philosophy; that is, one where someone purposely loads up the evidence in one direction or the other to support an a priori attitude. Stories have been told of the selection procedure for the Sydney Opera House, known for its dramatic architecture. The panel of judges selected the design of a liltle known Danish architect, Jorn Utzon, on the basis of a single design. No detailed schematics or engineering estimates had been done when the design was selected. The judges blightly assured the government that the building could be wmplcted for 7 million dollars (Australian). When the structure was finally dedicated. 15 years later, the cost had soared to over 100 million dollars. Clearly. more comprehensive feasibility testing could have determined the numerous engineering challenges that lay ahead for the Opera House. Another example of the effects of a lack of complete feasibility testing is represented by the current financial state of the tunnel under the English Channel. The Eurotunnel is indeed a monument to technological achievement. Boring three tunnels under the English Channel to link Great Britain with France will become a textbook example in Civil Engineering courses. And yet, one year after commissioning. the Eurotunnel Corporation is set to default on over $1,9 billion dollars of debt. Economic analysis 1s demonstrating that the revenue streams the Thunnel"was hoping for are not materializing. nor are they likely to through the end of this decade [3]. Quite simply, most travelers find the prospect of traveling in a stuffy, dark environment not worth the prospcct of merely saving one hour in travel time. The Channel Tunnel represents a technical achievement be sure, but it is also a financial morass. 2.7 Never Admit a Project is a Failure Sooner or later, every project will turn itself around, right? Wrong. Many projects fail through mismanagement, miscalculation, or through fundamental changes in the external environment. To continue to push a project through to fruition regardless of whether or not it is still viable is obstinacy bordering on foolishness. It is the equivalent to the well-known story of thc optim~stwho, when placed on a large pile of horse manure began enthusiastically digging in the belief that therc must be a pony down there somewhere! One of the most difficult lessons to learn about managing projects is to know the circumstances when, due to impending or inevitable failure, it is no longer sensible to continue them. Making termination decisions is extremely difficult, particularly aq i t must often be done in the face of resistance from the project manager, team members. and upper management proponents. Their opposilion is understandable because they, by this time, have a personal, ego stake in the project. Consequently. they keep digging. convinced that somewhere under all the detritus of escalating costs. poor performance, and sliding schedules, there must be a pony! A common thread running through many of the more well-known project failures is the company's unwillingness to back away from a poorly managed development process or product introduct~on,even when the project manager. team, and top management know the project is in trouble. This phenomenon is often referred to as escalation of commitment to a bad decision [4]. In essence, the theory demonstrates that more often than not, managers do recognize the serious (even fatal) problems that exist In their projects. Nevertheless, there is a strong tendency to follow the prescribed course of action in the face of this failure. Worse, it is common to actually commit more and more resources to a losing hand. Research bears out this point: Managers are usually loath to admit to a bad dccision and will actually continue to support that course, even in the face of compelling evidence of failure [5].

46

Pinto

2.8 Overmanage Your Project Managers and Their Teams Large corporations, loaded with layers of oversight and bureaucracy, are increasingly becoming some of the worst settings for achieving cutting-edge innovation. We see the same phenomenon with so-called "big science" projects, involving hundreds of researchers, multi-billion dollar budgets, and bloated bureaucracies and administration. Is it possible to achieve greatness inside a large corporation? Certainly, but the odds are stacked against you. Consider the example of IBM who, for years, regularly devoted 10% of its revenues to research and development. In 1989 alone, "Big Blue" spent over $6.8 billion dollars on R&D, by themselves spending almost the equivalent of what was spent in all of Japan for that year. And yet, in spite of these huge expenditures, innovations never seemed to find their way to the marketplace. The sheer size and inertia of the organization made it virtually impossible to react quickly or expedite technology transfer to exploit commercial opportunities. The term "lean and mean" has come into our vocabulary regarding the types of organizations that enjoy better than average success with new product development. The lean and mean organization is one that has not layered itself in the cloak of bureaucracy, that is flexible, has pushed decision-making authority down to low levels where project managers can make product development decisions without endless rounds of review and modification. The lean and mean philosophy has the potential to transform the American corporation precisely to the degree that companies practice what they are beginning to preach. 2.9 Never, Never Conduct Post-Failure Reviews What can we possibly learn from a failed project? We have heard this question voiced many times, usually by managers who are frustrated andlor embarrassed with the leftovers from a failed project. The first inclination is to sweep the results under the rug as quietly as possible and then move on as though nothing happened. Fails are written off as flukes or due to events beyond our control. We strongly disagree: Mistakes are a natural side-effect of many new ventures. Learning from them without an occasional push, however, is a trait that is much harder to acquire. While the attitude of denial is psychologically appealing, it is the worst attitude one can possibly take toward business in general and project management in particular. Failure teaches us a number of valuable lessons, provided we can review them objectively and non-defensibly. Consider the alternative: Ignore the evidence and lessons of past project failures and treat each situation and challenge as though it were unique and not previously understood. The results are predictable - they point to the difference between a manager with ten years experience and one with one year's experience ten times. Clearly, such an attitude cannot be in the best interests of the organization nor does it help a project manager's career, particularly in the long run. Learning from mistakes becomes more than simply a personal luxury, from the organization's point of view, it is a duty. 2.10 Never Bother to Understand Project Trade-offs Like it o r not, when managing projects we are often faced with a series of unappetizing alternatives. These trade-offs often come down to a "dollar-day" determination. This question points to the nature of project trade-off decisions: They are frequently balancing acts among rival (and seemingly equally compelling) demands. Do we understand the implications of crashing a project? Have we taken the time to consider the budget impact of such a decision? If the answer to either or both of these questions is no, clearly we are not making decisions on the basis of rational insight. Hard decisions are the perquisite of project management. Uninformed decisions, however, are its bane.

Project failure and risk assessment

47

2.11 Allow political expediency to dictate important project decisions It will not surprise most canny readers that many operating decisions are made with less-than-perfect motives; that is, the desire to maximize corporate success and profitability. Unfortunately, in the politicized environment of most organizations, any number of potentially momentous decisions are motivated far more by personal agendas than any desire to satisfy overall corporate needs. Project decisions that are made on the basis of power-plays and maintaining executive prerogatives are bound to be less than effective. In effect, the project becomes a hostage pawn in a larger, more personal game of acquiring and keeping power. Under such circumstances, it is not surprising that excessively political environments have a much more difficult time in successfully developing innovative projects. 2.12 Make sure the project is run by a weak leader The term "weak leader" is oxymoronic: successful leaders exhibit many traits but a fundamental weakness is not one of them. Leadership is an essential ingredient in project success. T o borrow a concept from the physical sciences, projects, if left to their own devices, tend to run toward entropy. That is, the natural project state is more often chaotic and disordered than logical and pragmatic. In the absence of a strong leader to keep the project team operating on track, most projects begin to experience the vacuum of indecision, orders given and rescinded, and a general sense of aimlessness. Weak leaders are not merely unhelpful to a project's successful completion, there are actively counter-productive. In the entropic state into which a project can easily fall, money and time are wasted and productivity is minimized, all because there is no firm hand at the tiller. The key is the project leader; this is the one person who has to make the project succeed by marshaling resources, motivating team personnel, negotiating with stakeholders, cheerleading the development process, and constantly keeping an eye on the ultimate prize: the successfully completed project. Naturally, when described in these terms, it is no wonder that successful project managers are a special breed, one that needs to be carefully cultivated and guarded within our companies. Their role in successful project development is almost always highly visible. Conversely, in the preponderance of projects that failed, the project manager either was essentially invisible to team members or exhibited the worst sorts of characteristics a project manager can have: weakness and laxity in place of decisiveness and determination. 3 Conclusions

What are the conclusions we can draw from our study of project failure? First, that failure is a byproduct of risky ventures. Projects often involve untested or novel technologies and processes. Risk of technical failure is always present in these circumstances. Further, projects upset the status quo of the organization. They operate outside formal channels with temporary groups of diverse individuals pulled together for one purpose. They oftentimes violate political relationships and established chains of command. Given the environment within which many projects operate, it is not surprising that failure is a very real possibility with any project undertalung. The second conclusion is that past failure need not discourage us from future efforts. Indeed, it is through these past failures that we gain the experience and wisdom to push on toward successful conclusions. There are two equally erroneous responses managers can have toward past failure. The first is to brush it aside with as little thought as possible; in effect, push it out of sight and out of mind. The other error is the mirror opposite: T o become so focused on past failure that it handcuffs an organization from taking the necessary steps for new ventures and project start-ups.

48

Pinto

Consequently, these firms suffer from a form of paralysis that precludes quick responses to competitors, to say nothing of their inability to move proactively. It is important not to become a victim of past failure, either through a mulish unwillingness to learn from it or through excessive timidity in trying again. 4 Copyright

Portions of this paper were adapted from What Made Gertie Gallop? Learning From Project Faihres, by O.P. Kharbanda and J.K. Plnto, Van Nostrand Reinhold, 19%. 5 References

1. Cleland, D.I. (1988) Project stakeholder management, in Project Management Handbook, 2nd ed, (ed. D.I. Cleland and W.R. King), Van Nostrand Reinhold, New Y ork, pp. 275-301.

2. Plnto, J.K. and Mantel, Jr., S.J. (1990) The causes of project failure. ZEEE Transactions on Engineering Management, Vol. EM-37, No. 4, pp. 269-276. 3. Wall Street Journal, (1995) Eurotunnel suspends interest payments. vol. 76 (234), September 15, p. A7. 4. Staw, B.M. and Ross, J. (1987) Behavior in escalation situation: Antecedents, prototypes, and solutions, in Research in Organizational Behavior, Vol. 9, JAI Press, Greenwich, CT, pp. 39-78.

5. Brockner, J. (1992) The escalation of commitment to a failing course of action: Toward theoretical progress. Academy of Management Review, 17; pp. 39-61.

Soft risk management for the implementation of an information systems project R.W. STEWART School of Information Systems, Kingston University, Kingston upon Thames, UK

Abstract This paper describes the use of soft systems analysis workshops to augment the risk management process of the implementation of the Community Information Systems Project (CISP) in Wandsworth Community Health Trust. It describes the systems development and implementation approach adopted by the trust, how the workshops enabled the identification of soft risks and their subsequent input into the change management programme. Keywords: Soft Risks, Soft Systems Analysis, Information Systems, Healthcare.

1 Introduction Wandsworth Community Health Trust (WCHT) provides primary and community care services in close association with general practitioners, social services, voluntary organisations and other local health and social care organisations. The services provided are diverse and include areas such as: district nursing; health visiting; chiropody; physical and learning disabilities; family planning and community child health services. The current information systems have been developed over a period of years and on different computer platforms. They have significant technical and operational problems, for example, the existing portfolio of applications are disparate, exhibit little connectivity, produce minimal management information and will not support the future business objectives. It was therefore decided to replace these systems with a new second-generation, person based, integrated system that would facilitate the planning and delivery of integrated multi-agency care within a community setting. Managing Risk in Projects, edited by K. Kiihkonen and K.A. AMo. Published in 1997 by E & FN Spon, 2 4 Boundary Row, London SEl SHN, UK. ISBN: 0 419 22990 6.

50

Stewart

The objectives for the new system were established during a detailed audit of user and organisational requirements and encompassed the needs of different stakeholders including management and general practitioners. An example of needs can be seen in the requirements of the clinical care providers: care assessment/planning and delivery; case list management; increased sharing of up to date patient information across professions and disciplines; multi-disciplinary working.

2. WCHT approach An early decision was taken to source the system from a third party, the final selection being the Reuters Template Healthcare system. This product required some tailoring in terms of functionality and screen design and therefore a prototyping approach was adopted. Pilot sites from different areas of the trust examined the system for functionality and ease of use, made recommendations for change, and when satisfied with the system, full rollout of the system occurred and parallel running ceased. The project was controlled using an approach based on PRINCE, a CCTA project management methodology. Part of this was the risk identification and planning process for the business case and technology implications. However it was realised that the project involved not only procedural changes in the users but also cultural change and the management of expectations. In addition to normal risk analysis techniques and cost benefit analyses, soft risks and people problems would need to be addressed as one of the project's objectives was to 'facilitate change' within the trust and to recognise the changing models of service delivery. Soft systems analysis workshops were seen as a complementary process to the work of the prototyping teams, seeking to develop organisational learning of the impact on cultural and social changes engendered by CISP associated with the changes in working practices. The outcome of the workshops was intended to identify key operational issues and resulting actions required to manage the change. These would form part of the risks to be managed, critical success factors and to develop a sense of joint ownership of the system and service processes between service staff, internal information systems staff and Reuters the software suppliers . Soft risk management approach The linking of Soft Systems Analysis with an Information Systems project is normally found in the context of developing a single or suite of applications. In many cases Checkland's seven stage model [I] is used to develop a set of conceptual models and derived information flows. These are used in conjunction with more structured approaches, such as in SSADM and Multiview [2], to create DFD's and Function Event matrices. In the case of Wilson [3] it was used to compare information transformation processes, generated by the Soft Systems Methodology (SSM), with those present in an existing IT system in order to establish the changes. The situation at WCHT was somewhat different in that an information Systems package provided by Reuters was being tailored using a prototyping approach to meet specific requirements. The benefits of the prototyping approach adopted come from

Soft risk management

51

involving the users in the iterative and interactive development of the system. Thus making, as certain as is possible, that the system is appropriate for its operating environment and generating a sense of 'ownership' by the users. A key part of the implementation of the system is the identification and management of the cultural and operational changes that this new system will entail. It is for this area that the 1990 SSM version [4] with the stream of Cultural Enquiry was seen as providing a basis for workshops during the implementation phases. As the primary use of Soft Systems analysis in the CISP project is to identify the cultural issues involved in the implementation the IS system, rather than the initial development of the system itself, an approach which combines IS prototyping and soft analysis has been developed and shown in figure 1. Wmld be improvers of the situation

History k g . legacy systems)

u ,

S d l Syaten.

Chawc Mnnyrment (Cultural Analysis

k g . Nan camplufblesystems.

lack of information)

Inrormation Sptnn Implemcntatlon

and Intervention) 1)

Figure 1 CISP and SSA Approach The version of SSM upon which this approach was based contains a Cultural Stream of analysis that runs in parallel to the Logic Based Stream of analysis (essentially the

52

Stewart

seven stage model). It was proposed to use the concepts underpinning the Cultural Stream of analysis to identify those areas in culture and operating procedures that may need changes as a result of prototyping the system in the pilot sites. It could also suggest changes that could be made to the new system. In essence it is a process of alignment between the users and what they do in the course of their jobs, and the Information System. It is similar in concept to the strategic alignment process in Business Process Reengineering. The analyses 1 to 3 in figure 1 refer to the Checkland methodology whereby analysis 1 considers the nature of the 'systems' intervention examined in terms of 'Client(s), 'problem Owner(s)' and 'Problem Solvers'. Analysis 2 is the Social System analysis where the 'Roles', 'Norms', 'Values', and their interactions in the problem area are examined. Analysis 3 is a 'political' analysis of the processes by which differing interests reach accommodation and how power is expressed in the problem area. The ways in which this type of cultural analysis has been used varies according to the nature of the problem area under investigation and the type of organisation. The approach envisaged at Wandsworth did not try to accomplish these analyses separately but used these ideas to establish what needs to be managed, from a human perspective, in implementing the IS system within the pilot areas. The manner in which this was accomplished using two types of soft systems workshops is described as follows. Awareness Workshop This focus of this workshop was to gain an awareness of the impact of implementing the Information System in the pilot areas. This was accomplished by using the first three stages of the Logic Based Stream of analysis. Figure 2 shows examples of the main links between the SSA stages and the elements that can comprise the change management process. Soft Systems Analysis

Change Management (Cultural Analysis and Intervention)

t Roles

Pictures

Issues K

Figure 2 Awareness Workshop Model

Soft risk management

53

An explanation of each stage was given to the workshop attendees followed by a practical session in which each attendee used the technique, for example constructing an individual rich picture, and a verbal explanation given to the group as a whole and discussed. Summary findings of each stage were collected and formed the basis for any resulting actions. The information gathered from each stage was used to feed into the cultural analysis and the management of change process. This process is described below. The aim of these Workshops was to develop a sense of ownership of the IS system, by not just identifying the requirements of change in operation, but also to develop an attitude of how can we get the best out of the system.

Rich Pictures The rich pictures gave an holistic picture of how the workshop attendees saw the situation in the pilot site. The pictures' contents included the people working in the area, what they did, what information they needed to do their jobs, and what the IS system provided. In essence they provided the structural elements of peoples jobs and their relationships to the environment, the tasks or processes they undertook and the problems they encountered in the pilot running. This information was used in role analyses, comments on the key stakeholders and their expectations being met or otherwise, the communication requirements, and problems that have been experienced. Issues and Tasks In examining the rich pictures a list of tasks and issues were extracted and clustered into groups of related tasks and the issues surrounding them. These clusters were examined for the information requirements and compared to the information provided by the IS system. Where the tasks and information requirements identified as a result of the soft systems analysis were satisfied by the IS system, this provided confirmation that the system was appropriate for the users needs. Where a major task was missing it was identified as a required IS system change. The issues reflected the operational and cultural needs. Again where the comparison to the prototyping phase showed there were no discrepancies, then there were no changes needed to be made to the culture and operational procedures. Where issues were not addressed it indicated that cultural or operational changes were required and the clusters of issues form the Problem Drivers (operational changes) and Cultural Drivers (attitude changes or cultural constraints such as user Norms and Values) to be addressed. These were input as risk areas into the project management process. Relevant Systems The Problem Drivers and Cultural Drivers indicated from the previous analysis were classified in terms of requiring simple changes and given a name with plans constructed for the implementation of the changes. Critical Success Factors were identified to monitor the progress of the changes. Where the changes were more comprehensive, although none identified to date, these can be the subject for a future Action Workshop.

54

Stewart

Action Workshop Although none of these have been run to date, an explanation of the process is given. The format of this type of workshop is similar to the Awareness Workshop in that an explanation of each stage is given to the workshop attendees followed by a practical session in which each attendee uses the technique. Verbal explanations are given to the group as a whole and discussed. The summary findings of the comparison stage are collected and form the basis for an action plan. This process is shown in figure 3.

/1

Conceptual hT;e,q

1

Figure 3 Action Planning Cycle. The majority of cultural and operational changes have been handled by Awareness Workshops and subsequent actions, however there may be some changes in the future that are more extensive. These will have been 'named' and will provide the focus for these workshops to develop an action plan. For the named area of change a root definition is constructed and conceptual models of the activities developed. A comparison to what happens at present. reveals those changes required to put this culture or operational change into practice. The agreement of these changes and subsequent implementation can be the subject of an intervention meeting with involved parties. Similar to the Awareness Workshop these changes will be input to the risk analysis process and critical success factors identified.

3 Results to date Four Awareness Workshops have been run to date with groups from Information Management & Technology, Family Planning, District Nursing and Child Health. The workshops of the three care disciplines were mixed groups involving administrative, nursing, clinical and IT personnel, with some personnel having direct experience of prototyping the CISP system. The techniques involved in the workshops worked extremely well. The outcomes of the workshops did, however, produce some unexpected results. The focus of the workshops was explained to the participants in the following manner. "As a result of the prototyping and in your working experience, how well does the CISP system meet your needs, and what needs to be managed in the change process." The response on the prototyping results was that generally it looked OK

Soft risk management

55

with some revisions. The overwhelming amount of information related to the problems they felt were important in the existing systems and the organisation and what expectations individuals had. Examples of the issues raised and their categorisation are as follows. Problem Drivers: Duplication of information; scattered and non-linked information; information held in multiple places; previously failed systems; lack of information; failure of existing hardware; systems communication links; hardware and project delivery. Cultural Drivers: Access to staff; privacy and security of information; people relationships; feelings of isolation; feedback on statistics and aggregated information to data providers; information seen as for management not for workers; broken management promises. Critical Success Factors: Project delivery in terms of functionality and delivery timings; the very high expectations of the CISP system addressing user needs; project benefits being realised; continuous involvement with the users. Organisational Issues: Space shortages; no strategic direction information passed down the organisation; telephone call handling; lack of funds. The problem drivers and cultural drivers were incorporated into the preventative action plans and contingency plans. within the risk management process. The critical success factors were incorporated into the stage review processes and the organisational issues were fed back to the trust management.

4 Conclusions In terms of the approach the workshops were highly interactive, well receive& and produced a wealth of Information. Comments from the participants indicated that they welcomed the chance to participate in the evaluation of the CISP system and the opportunity to express their thoughts on what was important in the cultural and operational changes to the organisation. A sense of ownership of the new system was engendered in both CISP users and developers. Two main conclusions have been drawn from this approach to soft risk analysis. 1. The information gained from the soft systems workshops addressed the human issues in a way that more traditional risk identification and assessment techniques do not normally manage. 2. It achieved the effect of organisational learning by the sharing of perceptions about the problems and expectations of the users and developers, contributing to a shared ownership of the new system.

56

Stewart

In summary it was seen to be a successful and worthwhile activity which will enhance the cultural and operational changes in Wandsworth Community Health Trust.

5

References

1 . Checkland, P.B., 1981, Systems Thinking, Systems Practice. Wiley, Chichester. 2. Avison D.E..Wood-Harper. A.T., 1990. Multiview: An Exploration in Information Systems Development, Blackwell. Oxford. 3. Wilson. B., 1990, Systems: Concepts Methodologies and Applications, Wiley, Chichester. 4. Checkland, P. B., Scholes, J., 1990, Soft Systems Methodology in Action, Wiley, Chichester.

Risks in projects and project oriented business designbuild - optimum solution for biopham projects W.R. BRYDGES bioKINETICS, Inc., Philadelphia, PA, USA

Abstract Historically, companies that produce high-purity biotechnology or pharmaceutical products face a host of complex challenges when planning and executing new or retrofitted facility projects. They must manage multiple relationships with separate suppliers who are contracted independently of one another, often leading to confusion regarding responsibilities. These responsibilities include the areas of engineeringldesign, procurement, construction, startup and validation, frequently resulting in cost overruns, change orders, rework and general duplication of efforts across supplier and contractors. Most importantly, this traditional approach to the design and construction of process systems creates scheduling problems that delay product time to market, potentially representing millions in lost or delayed revenues for Owners.

1 Uncertainty and Risks

The biotech and pharmaceutical sector is a very high-tech process industry. Until engineering is complete and construction packages are issued for bids, total project cost is a moving and uncertain target. Because of the potential revenues to be gained by earlier market entry, any method which will increase the speed to market holds tremendous value. Speed to market in a pharmaceutical facility is of primary importance. Typically, many products can produce within a six-month period enough profit to more than pay for the entire capital cost of the project itself That is why, in many cases, clinical trials are being performed in parallel with the process development associated with scale-up to manufacturing, as well as the design and construction of the manufacturing facility. Process development continues to be Managing Risks in Projects, edited by K . Kahkonen and K.A. Artto. Published in 1997 by E & FN Spon, 2 4 Boundary Row, London SEl SHN, UK. ISBN: 0 419 22990 6.

refined throughout the construction phases of the project which produces continuous change and greater risk towards cost and schedule overruns. In the past, the biotech and pharmaceutical industry has tried to meet their needs for a speedy project delivery by adapting the fast track EPCM approach typical of DesignfConstruction projects for their own use. This approach provides a compressed schedule by overlapping the engineering, procurement and construction activities. The impact of changes throughout the design and construction of this project are minimized by three basic functions: Integrated Change Control, Flexible Design/Construction, and Communications Systems. An Integrated Change Control system is at the heart of this process. It includes an established cost and schedule basis, and a team approach to minimizing the cost and schedule impact of necessary changes through continuous value engineering and constructability reviews. Typically, the project starts out with a design and engineering team, with procurement brought on as required. A construction management firm is later brought on as the procurement portion of the project is in a position to obtain bids on construction packages. This is a disjointed approach to project production, and can be riddled with change orders affecting both the cost and schedule of the project, as each group on the project; engineering, procurement, construction management, and startup teams, are each independent organizations with their own contracts and goals. The Owner is left to manage the focus of each of these organizations toward their final desired result of an operational facility. Changes ripple through this project organization as each entity evaluates the impact of these changes with respect to their portion of the project. Project continuity is also impacted by this approach as communication can be difficult between the different factions within the organization.. The answer is a Desigauild project delivery approach. An early preliminary engineering package is developed designed around client performance, quality, budget and schedule requirements. Once determined, and approved by the client, a commitment to cost and schedule is established and controlled by the Desigauild Project Team for the duration of the project. Because all team members are brought on from the beginning of the engineering, procurement and construction phase, we can monitor changes and associated risks to the project allowing the client to make better informed decisions on whether or not to proceed with those changes. Also, because the entire project team is on board from the beginning, changes early in the project are flagged, constructability reviews conducted and value engineering monitored as a part of an ongoing process as opposed to one that happens at various intervals. This process ensures continual constructability evaluation and enhanced value engineering during the course of the project. 2 Innovative Methods and Tools for Project Risk Management

The Program Manager, controlling all facets of the project, also has the ability to control and minimize risk by instituting proper program management. A technical lead from the design and engineering side of the project, a procurement manager and a construction manager are assigned to the project from the beginning. The technical lead for design and engineering of the project is also the lead for the startup of the

Risks in biopharm projects

59

project. This approach provides for a complete cycle of accountability, from concept through to operation of the project. A valuable tool utilized by the Program Manager is an Earned Value System. This System provides an objective projection of the indicated final cost and schedule on the project for all activities on the project, from conceptual design through startup and validation. The Program Management approach manages the entire project, from conceptual design through startup. The individual project managers for each of the various phases; engineering, procurement, construction and startup, report to the Program Manager. This individual controls the overall project and makes decisions on a daily basis concerning trade-offs between engineering, construction, startup, etc., activities. Instead of concentrating only on their own phase of the project, each Project Manager is encouraged to identify additional services they could perform that would reduce the efforts in other phases. Sensitivity and probability analyses are developed on the project for both cost and schedule. An initial project cost estimate is developed. This conceptualized estimate, based on minimal data, is the basis of a Job Cost Report. The format of the Job Cost Report allows for project tracking from the conceptual phase through the completion of the job. The job cost report also provides the capability to benchmark the comparison between our original estimate and the final cost of the project. Cost, schedule, quality and performance goals of the project are structured in the contract between the DesigdBuild Program Management firm and the Owner. The contract provides common goals between the client and the Desigauild firm, and assures the Owner that the DesigdBuild Manager is continuously monitoring the Owner's interests as well as the Desigauild fiim's optimum performance and profit on the project. Rework in the Desigauild approach puts the cost of this rework in the hands of the managing entity. The Program Manager in the Desigauild scenario has complete responsibility and cost accountability for the rework on the project.

3 Information/Communication Flow

Timely flow of information and communication, both with the Client and especially internal dialog, is essential in a well managed Desigauild project. Some of the documentation and studies critical to all Desigauild projects include drawings and specifications, constructability reviews, piping and ductwork lane studies, engineering and construction change orders, client initiated change orders, vendor submittals and shop drawings. When only one firm is responsible for the total project, from conceptual design through construction and start-up, as is the case with DesigdBuild projects, there is much less of an opportunity for information slipping through the cracks or being missed. Team members involved with the engineering portion of the work remain involved during the transition period when the project moves into the field for the construction phase. Also, key construction team members are involved with the project during the early conceptual engineering phases to help steer the project toward the most economical and efficient design. This also minimizes questions and Requests For Information (RFI's) from the field personnel.

60

Brydges

Once drawings and specifications for a project are approved, major equipment bid packages can be prepared and issued for inquiry. In many cases, due to the fast track nature of a project, drawings and specifications are issued simultaneously both for approval and inquiry. By doing this, Supplements must be issued to the bidders incorporating comments fiom the client. It is much easier to issue bid packages which contain client approved documents, however this is not normally the case. Timely responses from the client are essential in order for this to work and to keep the project on track. General reports/procedures generated for any project include the following: Conference Reports for recording the minutes from any project meetings. Project logs for tracking project documentation and information. Action Items list which is a living document that tracks all outstanding issues that require additional action or information, both from the client and internally. Study Reports which summarize the results fiom any project studies. Project Numbering system, which can be set up to tie together not only process equipment, piping and instrumentation, but also the Room numbers and even the building mechanical equipment. This can be set up to serve as a 'map' for orienting project personnel as to the area of the building where a numbered item is located. An 'Equipment List' or data base for all pre-purchased equipment. If this list is set up as a data base, a large amount of time is saved from not having to repeat information in different reports. Also, there is no chance of having different information on the same piece of equipment due to typos or errors. Transmittals, which identif) everything that is issued out of the office, including to the client, field staff, consultants or vendors.

4 Facility Design

In the biotech and pharmaceutical sector, the traditional designlbidhuild approach to construction is being replaced by a more expeditious, desigdbuild process where design and construction happen simultaneously, thus enhancing a product's speed to market. In order for the desigrhuild approach to be effective, the elements of the facility's design must be clearly established and approved by the client. Timely responses by the client are critical to keep the project on track. There are several major advantages to be gained from a designhuild approach. Some of these advantages include: Client's concerns about additional, unexpected costs which fall within the defined design parameters are alleviated. The DesignJBuilder assumes responsibility for the entire project. Designhuild requires a critical and thorough understanding of the design criteria. This reduces the possibility of construction interference. For example, the use of piping and ductwork lanes gives each subcontractor flexibility to install material with minimal construction documentation.

Risks in biopharm projects

61

Construction typically proceeds at a faster pace because standard materials and assemblies are used instead of custom fabrications. Another technique to speed up the construction process is to schedule documentation to closely follow long lead equipment procurement. Facilities designers and engineers remain involved in all phases of the project from design through start-up. The most significant advantage to the client is a reduction of financial and finctional risk which has now been assumed by the design builder. A DesignBuild approach is subject to several constraints. Constraints include: Construction details cannot be filly reviewed and approved prior to bidding because detailed design documentation occurs during the "build portion of the project. The level of documentation is more general in nature compared to designhidhuild documents. The designbuild process requires an overlap of the approval and inquiry steps. Drawings and specifications for materials and equipment are released concurrently with their inquiry packages. The most significant constraint to the client is the reduction of detailed design client involvement. It is, however, critical that the client be thoroughly involved in the initial (conceptual/prelirninary) design of the project to establish the design criteria. Unless proprietary vendors are identified by the client, the contractor will be responsible for vendor selection and construction means and methods. Certain facilities design techniques are desirable in the design~buildapproach. These include: Flexible facility design to accommodate changing process criteria Establish piping and ductwork lanes Concrete slab sizing to accommodate the installation and setting of large equipment Removable exterior wall panel system Large interior corridor widths to provide for the transportation of equipment for installation Large standard size doors for equipment access Delay installation of the concrete slab on grade as long as possible to allow as much flexibility as possible for drainage pipe installation Documentation is evaluated on the basis of what is minimally necessary for a constructor to understand the nature of the project and to develop a cost for construction. This approach enhances the speed of construction due to the resultant reduction of bid documentation time and earlier construction start. Specifications describe all necessary requirements allowing the contractor to choose appropriate equipment and material vendors. In many cases, due to the fast track nature of a project, drawings and specifications are issued simultaneously both for approval and inquiry. Much of the detailed design occurs during construction. Record documentation are provided for client archiving and regulatory requirements.

Procurement risks and uncertainty in support of the United States Antarctic Program R.P. THOMAS Antarctic Support Associates, Englewood, Colorado, USA

Abstract The remote location of the three United States Antarctic stations (McMurdo, South Pole, and Palmer) along with the uncertainty of funding and weather, leaves little margin for last-minute procurement of supplies, scientific equipment, or services required for the scientists and contractor personnel working in support the United States Antarctic Program (USAP). To minimize the procurement risk associated with the USAP, Antarctic Support Associates (ASA) has identified areas likely to impact the USAP, and utilizes several systems to minimize disruptions to the program. In the 1996-97 season, ASA supported over 650 grantees affiliated with 168 projects at the three U.S. stations and aboard the two research vessels. The systems utilized to coordinate the availability of supplies and materials are Maintenance and Planning Control (MAPCON), Power 1000, and Cargo Tracking System (CTS). ASA also utilizes the Support Information Package (SIP) on the World Wide Web for various project planning.

1 The United States Antartic program The United States involvement in Antarctica has been ongoing since 1775 with sealers and whalers performing their trade around the subantarctic islands, followed by various expeditions headed by the U.S. Navy. Operation Highjump from 1946-1947 was the largest single expedition ever to explore Antarctica involving 13 ships, numerous airplanes, and more than 4,700 men. The United States established a year-round presence during the 1957-1958 International Geophysical Year (IGY). The IGY emphasized Antarctic exploration and included research by 12 nations at 67 stations in Antarctica. The United States established seven IGY Antarctic wintering stations: four Managing Risks in Projects, edited by K. K&kGnen and K.A. Artto. Published in 1997 by E & FN Spon, 2 4 Boundary Row, London SE1 8HN, UK. ISBN: 0 419 22990 6 .

Procurement risks and uncertainty for USAP

63

on the coast (Little America, Hallett, Wilkes, and Ellsworth), two inland (Byrd, and South Pole), and a logistics base (McMurdo Sound). The National Science Foundation (NSF) was established in 1950 as a federal agency responsible for U.S. activities in Antarctica including support for basic research and education. In 1959 the NSF was given responsibility for the U.S. research effort, and established the United States Antarctic Research Program (USARP). Examples of research supported in Antarctica include mapping, biology, ocean science, geophysics, glaciology, meteorology, and upper atmosphere physics. In 1961 the Antarctic Treaty was signed and enforced by the original 12 signatories active in Antarctica during the IGY. The treaty, which covers the area 60 degrees south latitude, prohibits measures of a military nature such as fortifications, nuclear explosions, and the disposal of radioactive waste. Each treaty nation has the right to inspect all areas of Antarctica including stations, installations equipment, vessels, and airplanes, to ensure adherence to the treaty. Several supplements to the treaty include: The Agreed Measures for the Conservation of Antarctic Fauna and Flora; the Antarctic Conservation Act of 1978; the Conservation of Antarctic Seals; the Conservation of Antarctic Marine Living Resources; and a protocol for comprehensive environmental protection and a ban on mining. After 1971, the NSF was assigned overall responsibility for U.S. activities in Antarctica. The term United States Antarctic Program (USAP) was accepted for both the United States Antarctic Research Program and the operational activities such as Operation Deep Freeze, a designation used by the Naval Support Force Antarctica. The U.S. Antarctic Policy is based on four principles: 1) to recognize no foreign territorial claims, 2) to reserve the right to participate in any future use of the region, 3) to use Antarctica for peaceful purposes only, and 4) ensure free access for scientific investigation and other peaceful pursuits.

2 Antarctic Support Associates Antarctic Support Associates (ASA), a joint venture of Holmes & Narver Services, Inc., and EG&G, Inc., was established in 1989 to provide logistical support to the USAP. ASA is headquarter just outside Denver, Colorado. ASA's required tasks are established by an annual Program Plan and budget submitted in June to the National Science Foundation for approval. During Contract Year Seven (1 April 1996 - 31 March 1997) ASA had a full-time professional staff of approximately 270 employees (principally at ASA Headquarters), and approximately 700 contract personnel of all disciplines working in Antarctica. ASA is the single point manager for the shipment of all cargo to Antarctica. This encompasses construction activities at all U.S. Antarctic stations, construction and operations of temporary field camps during the Antarctic field season, and operations and maintenance of facilities, vehicles, and equipment at all U.S. Antarctic locations. Additionally, direct support to NSF-sponsored research projects, operations and maintenance of the research vessels NATHANIEL B. PALMER and POLAR DUKE (to be replaced by the vessel LAURENCE M. GOULD in late 1997), and other

64

Thomas

specialized tasks such as research and development projects, and studies as directed by the NSF.

3 Risk identification The various risks associated with the USAP include: 1. planning, procurement and delivery of material/supplies for the resupply vessel, 2. procurement of requested scientific equipment, 3. loss of capitallgovernment equipment, and 4. government funding. Procurement requirements for supplies, equipment, materials, and services totaled approximately US$38,000,000 for Contract Year 1996-1997. This represents about 35,000 line items identified, purchased, and shipped to Antarctica via the resupply vessel GREEN WAVE. ASA directors and area managers discuss and meet with their counterparts of the NSF on a regular basis to outline and plan the myriad of requirements for the upcoming seasons. Based on these meetings and final approval from the NSF, ASA inputs this information into its software systems. Most scientists who conduct experiments in the Antarctic are accustomed to utilizing the same brand equipment used at their institution or in past research trips to the Antarctic. In some cases, cost is of little concern. However, ASA has to adhere to various government procurement laws and guidelines, such as the Federal Acquisition Regulations, to ensure that taxpaper dollars are being spent wisely. Such action on the part of ASA has resulted in lower cost of brand equipment and the identification of compatible andlor better equipment for scientific use. The software systems used by ASA helps ensure the proper quantities and minimal duplications. Maintaining accountability of purchased capitallgovernment equipment is a challenge due to the numerous locations of such equipment in South America, New Zealand, Antarctica, California, Virginia, and on board the research vessels. The software systems used by ASA maintains a data base of all capitallgovernment equipment which is updated on a monthly basis. ASA is funded on a fiscal year basis (1 October - 30 September), but the contract year is 1 April - 31 March. This arrangement has caused some interesting procurement problems in that some projects such as vessel support and operation are continuous the whole year. Three years ago, and years prior, the U.S. President and the U.S. Congress could not agree on a budget in a timely manner. resulting in ASA almost having to implement its contingency plan for lack of funds which included the lay-up of the research vessels, stoppage of new procurements and construction, shutting down of the stations, layoff of workers. Again, the s o h a r e system at ASA allows for the ongoing tracking and status reports required for such a situation.

4 Software systems A comprehensive integrated software system designed by ASA is used to minimize risk and to plan, manage and control the acquisition, shipping, and receiving of supplies necessary for continuous USAP operations. The integrated software solution

Procurement risks and uncertainty for USAP

65

combines three software programs that provide efficient data management to produce automated purchasing, receiving, and shipping documentation. The three integrated software programs are Maintenance and Planning Control (MAPCON), Power 1000 (used for purchasing), and the Cargo Tracking System (CTS). 4.1 Maintenance and Planning Control (MAPCON) MAPCON is comprised of five integrated modules: 1. Inventory, 2. Purchasing, 3. Equipment, 4. Maintenance, and 5. Human Resources. This discussion will be limited to the Inventory and Purchasing Modules because they relate directly to the procurement process. These MAPCON modules provide the user a tool to either replenish stocks using existing stock record information or to purchase new stock items, or to purchase services. In addition, these modules provide the user an efficient tool for inventory management and control, determining resupply quantities and initiating requisitions.

4.2 Inventory The Inventory Module contains the standard stock record information which includes last receipt, price, stock location, quantities available, quantities currently reserved for maintenance actions, quantities on order, manufacturers, vendors, and usage history. The usage history is a summation of the issues by stock item for a specific period and is the primary element used to forecast future resupply needs. The Inventory Module is programatically linked to the Purchasing, Maintenance, and Equipment Modules and is functional at all three U.S. Antarctic stations. 4.3 Purchasing The Purchasing Module is used to create and track the status of purchase requisitions (see below) at all U.S. Antarctic stations and at ASA Headquarters. In addition to creating purchase requisitions on-site, a requester at a remote station can use the module to determine the status of a particular order. The integration with Power 1000 permits purchase requisitions to be updated with purchase order information, expected vendor ship date, quantities shipped, shipment identification, date of receipt at Port Hueneme, California, etc.

4.4 Purchase Requisition to Shipment A purchase requisition is the initial electronic request for goods or services and can be initiapted from any Antarctic station in addition to ASA Headquarters. A typical requisition originates in the Antarctic and is transmitted to Denver for funding approval and Logistics review before it is passed to the Purchasing Branch or Contracts Branch at ASA Headquarters. The integrated system allows the reviewer to automatically convert the MAPCON requisition into a Power 1000 requisition. Purchasing solicits vendor response, negotiates the prices and terms, issues the order to the selected vendor and expedites shipment to Port Hueneme, California. Only the buyers or subcontract administrators of the Procurement Division are authorized to create a purchase order or to otherwise make a financial commitment on behalf of ASA and the NSF.

66

Thomas

4.5 Purchase Requisition Preparation Requisitions are prepared by a variety of people at numerous locations. The requisition can be prepared any time a new requirement or a resupply need becomes apparent. MAPCON has the capability to automatically generate requisitions by comparing inventory balances with user-defined minimum and maximum stock levels. Currently the ordering decision is based on past usage history, on-hand stock levels and knowledge of future events or projects. The lead-time required from submitting a request to receipt differs between the Continental area (McMurdo and South Pole Stations) and Peninsula area (Palmer Station) due to the various transportation modes available at these locations. Requisition schedules are maintained for the Antarctic stations and research vessels which list standard procurement and transportation lead-times for each required-on-site date. Adherence to these schedules enables ASA to take advantage of the least expensive mode of transportation, which is commercial surface. 4.6 Power 1000 Power 1000 is the actual purchasing software that supports all purchasing related activities. It allows receipt documentation at several locations. The vast majority of materials are shipped by vendors directly to Port Hueneme, California, which is the staging point and transportation hub for worldwide shipment of supplies by commercial air, land and sea transportation modes and military airlifl and sealift. Additionally, a stand alone Power 1000 system is maintained in Christchurch, New Zealand specifically for New Zealand procurements. Power 1000 is not used at the Antarctic stations because purchase orders are not placed from Antarctica. When the material is received into Power 1000 at Port Hueneme, a dynamic link creates a shipping document, a bar coded label, and updates both the CTS and MAPCON with purchase order and receiving information. The vendor's invoice is certified for payment at the time of material receipt at Port Hueneme. Purchase order information is linked to the accounting software when the purchase is made, which provides the justification for vendor payment. The MAPCON inventory module is not updated until the material is received on station. Power 1000 updates MAPCON and CTS with current requisition or procurement information. These updates are passed to the Antarctic stations so the remote users also have current real-time status of their requisitions. This module is hctional at all three Antarctic stations, and at the ASA Headquarters. 4.7 Cargo Tracking System (CTS) CTS is the software package to track cargo. A "smart" shipping number known as a transportation control number (TCN) is assigned in CTS and marked on each piece of cargo to ensure 100% traceability. This TCN works within the military cargo system and communicates the mode of transportation, the project for which it was purchased, and individual package serialization. Requisitioned materials are considered to be cargo from the time they are received and packed for shipment at Port Hueneme until they are turned over to USAP employees for receipt into the inventory system. Shipment status information is available at all Antarctic stations. The bar coded label affords fast and

Procurement risks and uncertainty for USAP

67

efficient tracking of cargo as it passes through the transportation hubs at Christchurch, New Zealand and McMurdo Station, and Palmer Station on the Peninsula.

5 The Integrated Functionality of MAPCON, Power 1000, and CTS Each software package plays a distinct role in the processing of information. A brief

1

Power 1 0 0 0 ~ De;ver

4

it

-

MAPCON

1

I

1 , 5 , 9 , 11

illustration of the process follows. An initial purchase requisition is created in the MAPCON Purchasing Module. It is converted into a Power 1000 purchase requisition and becomes a purchase order when an agreement is reached with a vendor. When the goods are received in Port Hueneme, the information is entered into Power 1000, the goods are packed and a transportation control number is assigned. A dynamic link between Power 1000 and CTS creates a shipping record, a bar coded label and a shipping document. The package is tracked by the TCN from its entry into the transportation system until it is delivered to USAP employees who enter the material into the inventory module. Its progress across the 12,000 mile pipeline to Antarctica is recorded at each USAP transportation hub. Fig. 1. Interface of Programs Figure 1 illustrates the interfaces between the programs. The drawing traces an inventory item from the discovery of need and requisition to its receipt on station. The numbers provide the order for each step in the process and emphasize the interrelational aspects of this integrated procurement system. For example, a worker sees that the on-hand quantity of cable at South Pole Station is low, and asks the staffto reorder. 1. After confirming the quantity is not on site or available at another site, a MAPCON requisition is created and approved by the work center (1). 2. The requisition is placed in an electronic file and sent to ASA Headquarters where it is loaded into MAPCON and distributed to the work centers where budget approval resides (2). 3. After budgetary approval and Logistics review, the MAPCON requisition is converted to a Power 1000 requisition and electronically passed to the Purchasing or Contracts

68

Thomas

Branch. The Power 1000 purchase requisition becomes a purchase order when a vendor is selected (3). 4. The purchase order information is fed back to MAPCON (4 and 5). 5. Upon receipt from the vendor, Port Hueneme personnel receive the cable into Power 1000 where a shipping record, bar coded label, and slzlpping document are created (6). The cable is packed into a box with the TCN marked on the exterior for South Pole Station (7). Power 1000 feeds the TCN into both CTS and back into MAPCON in Denver. 8. MAPCON in Denver, in turn, updates the station MAPCON with the TCN. 9. The station receives real-time status and a tracking number. As the cable passes through Christchurch and McMurdo Station, the record in CTS is updated with receipt and location information. This information remains in CTS only. When the cable is entered as 'received' at its final destination, CTS is updated 10, and the item is turned over to designated personnel. In MAPCON, the individual item is received and the open purchase requisition in the MAPCON Inventory Module is closed out. This updates the inventory on station 11 which then updates MAPCON at ASA Headquarters 12. The USAP provides the inter and intracontinental transportation. For the Peninsula Area the Research Vessel POLAR DUKE doubles as a cargo and passenger vessel by providing regularly scheduled trips between Punta Arenas, Chile and Palmer Station. The RN POLAR DUKE can carry nine sea containers and other loose load cargo. For the Continental Area, aircraft are used to move material to McMurdo Station and onward to field camps and South Pole Station. LC-130 aircraft are used to resupply South Pole Station from McMurdo Station during the austral summer season. McMurdo Station is re-supplied via LC-130, C-141, and C-5 aircraft throughout the austral summer. These military flights are provided by the United States Air Force, Navy, and New York Air National Guard and are supplemented by New Zealand and Italian LC-130 aircraft. Near the end of the summer season the annual resupply vessel, M N GREEN WAVE, delivers the majority of the material requirements. Port Hueneme Operations is the transportation hub for the receipt and onward shipment of all USAP cargo for Antarctic station(s). In addition to transportation management, Port Hueneme packs and crates 90% of the cargo being shipped, manages the USAP sea container pool, handles container stuffing and certifies vendor invoices for payment. Port Hueneme transports cargo by commercial air and surface modes. For the Continental area, military airlift and sealift provide additional transportation modes in the form of regularly scheduled flights or aircraft charter flights known as Special Assigned Airlift Missions (SAAMs) and a chartered container vessel, the M N GREEN WAVE. The M N GREEN WAVE is also referred to as the annual resupply vessel. The operation in Port Hueneme also develops a cargo load plan which is coordinated with the vessel's master to maximize space utilization. The vessel can carry 600 containers and up to 30 million pounds of cargo.

Procurement risks and uncertainty for USAP

69

6 General Cargo System Overview

As previously stated, most cargo is transported to Antarctica by ship. The place of embarkation is Port Hueneme, California. There are several types of departures each year:

1. McMurdo cargo via Navy contract ship. A contract ship (normally the MN GREEN WAVE) goes from Port Hueneme to McMurdo Station, arriving in late January. Cargo for this ship should be delivered to Port Hueneme, California by 8 November but receipt and loading will continue until the vessel sails. This ship is the preferred transport for delivering materials to McMurdo Station for subsequent delivery to the inland stations because it is the least expensive mode and it has the capacity to deliver annual resupply volume, special project materials, and is the most secure means of transportation. The vessel GREEN WAVE is a container and break-bulk vessel chartered from the United States Military Sealift Command. It has a capacity of 600 twenty-foot sea containers. 2. McMurdo cargo via "Kilo-air ". This transportation method is used for material that cannot be sent to McMurdo Station on the resupply ship the year before. The term, "Kilo-air", refers to both the mode of transport and the time frame for shipment. The time frame is the first Tuesday in October until mid-December. Kilo-air cargo is sent by commercial ship from Port Hueneme, California, and arrives in Lyttelton (near Christchurch, New Zealand). Two major Kilo-air shipments are planned from Port Hueneme to take advantage of the improved freight rates for full sea container shipments. Cargo is then flown from Christchurch to McMurdo Station. Kilo-air cargo must amve in Port Hueneme by 30 August and 30 September coinciding with the planning for the two major container shipments . 3. Antarctic Peninsula cargo via commercial ship. Cargo must reach Port Hueneme, California, at least 60 days before it is to be loaded aboard the vessels RN POLAR DUKE or RN NATHANIEL B. PALMER in Punta Arenas, Chile, for forwarding to U.S. Antarctica. 4. WINFLY WINFLY means "Winter Fly-in'' and occurs approximately six weeks before the start of the austral summer season. Additional employees and materials required to re-open the station are delivered to McMurdo Station to prepare the station for a population increase from about 230 to 1,200 inhabitants. Figures 2 and 3 graphically describe the logistics and cargo flow to Antarctica.

70

Thomas

ANNUAL CARGO FLOW Customers, Methods, Dastinatlons

ig. 2. Cargo Flow to Antarctica

7 Summary The USAP is unique to any other project in the world. The risk associated with operations in the Antarctic in general is high. Continued proper planning between ASA, the NSF, and scientists woking in the Antarctic will ensure that the myriad of projects are supported in a manner which will result in successful research. The specialized software used by ASA, which can be adapted for other projects, is just one means of ensuring such success.

Procurement risks and uncertainty for USAP

I

USAP LOGlSTlCS

u ANTARCTICA

GizE PCIIM*h

Fig. 3. Logistics Flow to Antarctica

8 References 1. Antarctic Support Associates (1993) Cargo Tracking System Manual. 2. Antarctic Support Associates (1995) M P C O N Manual. 3. National Science Foundation (1996) United States Antarctic Program Participant Guide.

71

PART 3

IMPLEMENTATION OF SYSTEMATIC RISK MANAGEMENT IN PROJECT BUSINESS

Implementation of systematic project risk management in companies - from immediate needs to the prospects of the future K. KAHKONEN VTT Building Technology, Finland

Abstract Systematic project risk management is nowadays widely acknowledged as a significant skill which enables successful implementation of projects of various types within turbulent project environment, and, likewise under very tight delivery time, cost and quality constraints. Companies are increasingly trying to identify and, eventually, to tailor project risk management methods and tools to meet their needs. The current project risk management software packages unfortunately too often fail to meet the characteristics of systematic project risk management process. The major shortcoming is to focus too much on risk analysis and ignoring to provide enough support for the remaining phases of the process. Several important issues need to be addressed by those involved in the development of these tools. The most important ones are: i) Flexible set of techniques; ii) Dynamic checklists & risk knowledge base; iii) Integration of project management tools and project risk management tools; and iv) Integration of concepts 'risk' and 'opportunity'. Keywords: Project management, risk management, project management tools, project planning, risk knowledge base, experiences

1. Introduction Recently many progressive companies and professional institutions have 'reinvented' the existence and importance project risk management. It is likely that this change is very much caused by the characteristics of our time when companies are facing increasing global competition, all the time shortening life times of key products, new kind of social problems, unexpected changes in client's and individuals' values etc. Mamging Risks in Projects, edited by K. Ktihkonen and K.A. Amo. Published in 1997 by E & FN Spon, 2-6 Boundary Row, London SEI 8HN, UK. ISBN: 0 419 22990 6.

76

Kahkonen

In practice this reinvention has meant acknowledgement of project risk management as one of the main skills and knowledge areas of project managers and those executives in charge of companies' major projects (for example see [I],[2] and [3]). However, what eventually makes the difference is the successful implementation of systematic project risk management practice in companies. Characteristics of successful implementation are Improved understanding over the applicable project risk management practice and tools. Appropriate project risk management practice and tools can vary great a deal between companies and projects. Successful implementation results in a proper understanding of the most beneficial combination of risk management techniques and tools. Acknowledgement of the role of project risk management. The identified and determined role of project risk management is acknowledged widely providing basis for new emerging risk management culture in company. Change in working practice. Pro-active and reactive risk management is not any more just an intuitive working practice if this is an appropriate solution. Continuity in the development and organisational learning relating to all aspects of project risk management. Chapman and Ward have in several occasions pointed out that project risk management is an organisational learning process where sustainable results can be only reached gradually [4]. This paper discusses author's experiences and lessons learned from 1) distribution of project risk management software tool; 2) project risk analysis and management workshops; and 3) project risk management training. These activities have been carried out in Finnish companies within last three years. Starting point of this effort was the development of Temper - project risk management software tool which has been later used as a platform to carry out training and project risk analysis and management workshops. The Temper tool is briefly described in the paper. The activities described above have provided a very useful means to test various project risk analysis and management approaches, to obtain deeper understanding about the needs of company people and finally to develop further some specific techniques. The lessons learned provides a starting point for the development of new kind of tools, and particularly computer programs, for project risk management. 2. Project risk management process and its characteristics The most beneficial project risk management process can be vary surprisingly between various companies and projects. Even between individual project risks of a single project the techniques and the deepness of necessary analyses can be very different. The model presented in the table one is an early attempt to portray a 'road map' of various reachable levels andlor strategies of pro-active project risk management practice [5].In this table different levels of each sub-process reflect our current understanding of the different learning and performance stages of the pro-active project risk management sub-processes. These levels provide a simple means to explain the

Implementation of systematic risk management spectrum of various possibilities to carry out each sub-process. Table 1.

Project risk management road map: levels and strategies [5].

4.7 Monitor situation 4.8 Accept risk without any actions

77

78

Kahkonen

Each category in this 'road map 'presents first the most simple techniques followed by gradually increasing level of work and complexity. It is important to focus on the added value which is provided by the subsequent level when one is trying to identify the appropriate level for a particular situation. Usually, the use of a single one level project risk modelling and analysis technique results typically a limited portray and understanding of the project risks. Rather one should 1. Know the significant principles of successful project risk management: i) In general, keep it simple; and ii) Make it more complex only when it is useful to do so [4]. 2. Master several practical techniques and understand their relative benefits and possibilities. 3. Apply techniques in a flexible, and, often in a hierarchical manner even in the case a single project (Figure 1).

Identified risks

Necessary levels of various project risk management techniques Level 1

Level 2

...

Level n

Fig. 1. Appropriate level of detail and relevant project risk management techniques (risk and response identification, risk and response effect analysis etc.) vary even inside one project.

Implementation of systematic risk management

79

3. Evolution of computer programs for project risk management Project risk management techniques have been increasingly taking shape as computer programs. These computer programs reflect our understanding of the project risk management and, on the other hand, can provide a basis to explain needs for further developments. These computer programs for project risk management fall generally into four main categories 1. Tools supporting systematic pro-active project risk management processes. These tools are used as guidebooks, checklists or a framework according to which risk identification and analysis process is organised. The tools of this category are simple and easy to use but one must be familiar with the required 'way-of-thinking' and other assumptions when these tools are applied in project practice. 2. Risk modelling and analysis tools. Within these computer programs the attention is on modelling and analysis of risks with the means of probabilistic distributions, Monte Carlo simulation, Latin Hypercube etc. Tools of this type are mathematically oriented. 3. Add-in products to spreadsheet programs. The computer programs of this category are also very much risk analysis oriented tools taking often advantage of the same analysis techniques as in the previous category. 4. Tools integrated with project management software packages. These computer programs are add-inn products to project management software packages. For example, one can model uncertainty with regard to the availability of resources having effects on project schedule. As a result a master schedule showing also effects of identified risks can be obtained. At present most software can provide very little if any contribution towards systematic pro-active project risk management processes, and, thus only a few software packages fall into first category. It seems that more holistic tools in terms on overall integration of systematic working method, and, flexible risk modelling and analysis capabilities are still missing at present. Many current software packages are very much risk analysis oriented ignoring still many key aspects of project risk management. 4. Implementation experiences 4.1 Temper System A computer program termed Temper System for project risk management has been developed in VTT Building Technology using Microsoft Excel for Windows working environment. This system provides a hierarchical approach for project personnel to improve their understanding with respect of risks of the project under preparation. In practice, the mentioned hierarchical approach means starting with the definition of overall plan for risk management followed by the identification of all potential risk items. This results in a list of project risk items. The list can include often from 10 up to 50 risk items. During the next phase the risk items of greatest importance are selected and analysed in a more detailed manner. Finally one can get a graphical

80

Kahkonen

representation of the selected risk items, the relevant responses and their effects using technique called risk map (Figure 2). The approach behind Temper System is an early attempt to comply with the generic systematic project risk management process and its levels presented earlier in this paper. It seems that the hierarchical risk analysis approach of Temper tool meets the requirements for a simple and flexible tool. I

RESPONSE PLAN I Case 95-3

Probability %

1

n design management

Fig 2.

Example of using project risk map technique for response planning

Implementation of systematic risk management

81

4.2 Experiences in implementing Temper System in companies Experiences fiom the first real cases support our original thoughts that the tool is most powerful in the bidding phase and in the early stages of the project when the works start on site. In Temper System the checklists capture experiences fiom past projects which make checklists more dynamic. However, in order to obtain optimal benefit of the tool, the user organisation should update continuously the information captured in the checklist. According to our experience the experience data combined with a traditional checklist provides clearly added value to the project managers or other individuals carrying out systematic project risk management. Our conclusions for the first implementation experiences is, that the tool supports systematic thinking in risk management, documentation of the treated data and produces visual information, "project risk map" for decision makers to form rapidly a clear picture of the project situation in order to make right decisions based rather on facts instead of plain intuition. The implementation of systematic project risk management in companies has proved to be learning process where i) one needs first to obtain a satisfying understanding of most suitable and beneficial techniques, and, ii) the organisation in focus needs to learn gradually new ways of thinking and working.

5. A way towards new generation of tools for project risk management 5.1 Flexible set of techniques This is perhaps the most serious shortcoming of current software packages. It seems that at least in some cases this is result fiom individuals' personal commitment to promote a single project risk management technique. However a somewhat more openminded attitude is required to develop new tools combining several techniques in a flexible and simple manner. The development of Temper System has been an effort towards this direction. 5.2 Dynamic checklists & risk knowledge base According to our learnings and earlier studies by Niva [8] the experiences of problems and failures in past projects are most desirable when project risk identification and response planning is carried out. This data can make plain risk checklists more dynamic and closer to live projects. This feature has proved to be a rather significant one since in many cases project managers felt that the traditional project risk checklists stimulate them to carry out project risk identification and relating thinking too limited way. Here this means that experience data from past project can encourage individuals to evaluate the characteristics of a project in question more carehlly when identifying risks rather than thinking project risks in general terms.

5.3 Integration of project management tools and project risk management tools Generally speaking project management software packages still lack quite dramatically links to the acknowledged systematic project risk management practice. Three types of estimates (target, expected and commitment) explained by Chapman and Ward [4] are

82

Kahkonen

an example of significant means to understand and communicate the project risks within general project management software package. How the most important concepts and sub-processes of project risk management can be integrated within project management software package in a simple and flexible manner is a challenge for all developers and research community.

5.4 Integration of concepts 'risk' and 'opportunity' We still have some problems with the concepts 'risk' and 'opportunity'. These two concepts are not far away from each other but integration of them which could finally take shape as a coherent method, manual tool and computer software is still what is needed (Figure 3). This together with the earlier presented integration of project management tools and risk management tools is perhaps a challenge requiring longer time span than other issues. OPPORTUNITIES

+

+ 10 C

E

-sE n

+loo

+

'ACCEPTABLE PATH' + 1 m

Probabillt

RISKS

2

- 1C)

E

s 2

n

-10-

-I

- 100 - 1 000---

Fig. 3.

'Acceptable Path' of project opportunities and risks.

6. Conclusion

Current software packages are usually very much risk analysis oriented ignoring many key aspects of project risk management. More holistic tools in terms on overall integration of systematic working method, and, flexible risk modelling and analysis

Implementation of systematic risk management

83

capabilities are still missing at present. These tools could help significantly promoting and implementation of systematic project risk management practice in companies. Four important issues have been identified which can be used to explain needs for the development of next generation of tool, and particularly those of computer programs, for project risk management. These are: i) Flexible set of techniques; ii) Dynamic checklists & risk knowledge base; iii) Integration of project management tools and project risk management tools; and iv) Integration of concepts 'risk' and 'opportunity'. 7. References 1.

2.

3. 4. 5.

6.

7.

8.

PMBOK, 1996. A Guide to the Project Management Body of Knowledge, Project Management Institute Standards Committee, Project Management Institute PMI, Upper Darby, PA, USA. I S 0 10006, 1996. Guidelines to Quality in Project Management, ISOIDIS 10006, Document 176-2-8-N160. Body of Knowledge, 1996, APM - Association of Project Managers, United Kingdom. Chapman, Chris and Ward, Stephen 1997. Project Risk Management, John Wiley & Sons Ltd, United Kingdom. Kiihkonen, Kalle 1997. A framework for applying various project risk management methods and tools, A paper to be presented in PMI Annual Symposium on Project Management, September 1997, Chicago, USA. Kiihkonen, K. and Huovila, P. 1995 Risk Managment of Construction Projects in Russia, Proceeding of IPMA (International Project Management Association) Symposium St. Petersburg, Russia, 14-16 September 1995, The Russian Project Management Association SOVNET, pp. 237-241. Kiihkonen, K. and Huovila, P. 1996. Systematic risk management in construction projects, Proceedings of the Fourth Annual Conference of the International Group for Lean Construction - IGLC'96, The University of Bimingham, School of Civil Engineering. Niwa, K. (1988) Knowledge -based risk management in engineering: a case study in human-computer co-operative systems, Wiley series in engineering and technology management, John Wiley & Sons, Inc. USA.

Training for project success 0. REITAN and L.H. HAUGE Det Norske Veritas, Hmik, Norway

Abstract There are a number of important impediments to successfil implementation of project risk management (PRM) in project organisations. Training is a cardinal activity to enable project teams overcome such impediments, and to help them to take full advantage of the benefits of PRM. An introductory training/motivational course focusing on the following elements is required for project organisations with little experience in risk management as a complement to project management: 1. There is room for widely different interpretations of goals, methods and means of a

PRM process. This is due to the widespread and diverse use of the concepts of risk and uncertainty. 2. The objective of PRM is to prepare structured information that enables proactive decisions. This statement is however strikingly similar to the objectives of any management team, and it is therefore necessary to demonstrate and,exemplifyhow PRM represents added value in relation to traditional project management. 3. The means and methods of PRM depend upon structuring and some degree of quantification of subjective and ''fi~zzy''information in order to form decision support. Such methods however interfere with traditional technical and administrative background of the project management, where numbers, expressions and formulae are held to be the primary basis for decisions. The initial implementation of PRM in organisations is usually met with inertia due to lack of understanding around the three issues above. A successfil introductory training course should clarify these points. Keywords: Risk management, project, training, implementation, decision support, threats, opportunities, assessments. Managing Risks in Projects, edited by K. K%hkbnen and K.A. Artto. Published in 1997 by E & FN Spon, 2 4 Boundary Row, London SEI 8HN, UK. ISBN: 0 419 22990 6.

Training for project success

85

1. Introduction

A project is by definition an undertaking involving risk. Whereas management of such risks have been left to the project manager in the past, it is now becoming more and more usual that larger and complex projects encompass a separate risk management function [7]. The main objective of a PRM function is to collect and structure information to i) ensure that all the risks are managed, and ii) ensure that all the actors are aware of the interfaces towards their own work that involve risk. The risk management function may thus be viewed as a quality assurance function of the flow of information in projects, to ensure proactive management of such information, which in turn aims at improved success-rates of projects. However, like any activity of quality-improvement, the direct link between activities and their associated results is normally not obvious. This is why quality improvement techniques are met with scepticism, and the implementation of a separate project risk management function is no exception. A clear and no-nonsense demonstration through training in PRM to explain what it is and what PRM is not in relation to the most normal objections is therefore needed. In this paper, we present typical key concepts or "hidden agendas" of project personnel not familiar with risk management, and how these should be addressed in an initial training course. 2. Goals and methods of a PRM process

Typical statements a training course should address regarding clarification of goals of a PRM process are exemplified in the following: Risk is some expression of what we don't know, study of gap of knowledge is not useful. It is not clear that studies and analyses of issues at risk will help making improved decisions. It is no point being too technical in an exact definition of the risk measure, however the advantages of using risk as an aid to decisions is not easily understood without some comprehension of an appropriate definition. The concepts of risk and uncertainty in popular language are tailored towards lack of knowledge rather than decision making. In nearly all conditions of humans and nature, it is generally accepted that the only thing we know for sure is that we don't know everything, i.e., there are uncertainties and risks to be associated with most conditions of nature. Most often, expressions of risk and uncertainty are related only to the fact that our knowledge is limited, and not with any assessment of magnitude. Example A: There is a risk of rain tomorrow. Could be rephrased as: We do not know whether or not it will rain tomorrow, or It is (a signzficant) possibility for rain tomorrow. However, when it comes to a closer study of the magnitude of risk or uncertainties, expressions in use vary. The magnitude of risk is sometimes seen as the probability of

86

Reitan and Hauge

loss, or the magnitude of loss, but not normally a combination of the two. It is usually neither seen as the magnitude nor the probability of positive opportunities. Example B: The risk of loss is 25%. Could be rephrased as: There is a 25% probability of loss. Example C: There is a risk ojloosing $50,000. Could be rephrased as: The maximum expected loss exposure is $50,000 The definition of a measure of risk in mathematics and decision theory is however related to the magnitude of variability of outcomes, which is widely utilised in parts of the finance sector. Example D: The risk is described by a 20% chance of loss, and a 10% chance of profit greater than $3 million. Example E: The risk exposure on raw material A is described as follows: A 10% increase in unit price will lead to a 50% drop in profit. It is not evident how study of risk according to all of the above concepts may be of help in making proactive decisions in a project. The definition of risk will need to have meanings specifically suited towards the support to decision making-aim of PRM. The basis for the study of risk that are suited to this purpose needs therefore to have forms like: The probability of loss or gain of a certain magnitude The maximum probable magnitudes of loss or gain Identification of structure of causes and contributions to the risk, i.e., probability or consequence magnitudes Identification of possible alterations of this structure to reduce 1 enhance risk, including assessment of associated benefits and costs Example F: There is a 30% chance of a 10-week delay due to quality problems with subcontractor A. Example G: The risk is I in 2 that there will be discovered a compatibility error requiring three months rework on subsystem A during the integration work. By making it explicit that PRM is about assessment around the four issues above, it is easier to understand that risk management is entirely about preparing for decisions and not with the goal of studying the risk. 3. Project Management vs. Project Risk Management

Typical statements a training course needs to address regarding roles of the PRM hnction are exemplified by the following: Managing risks is raison d'ktre of the project management, a separate PRM role will have to be a device for a separate control of the project, and not of support. Additional personnel accessing project information may add value to the project, however, such personnel will be a strain on the time and attention-capacity for the project team, thus the end result is debatable.

Training for project success

87

The inertia from such statements can best be overcome by offering a systematic review of typical projects needs, and the ways to achieve benefits to overcome such needs in a PRM process. 3.1 Key needs and benefits for a structured PRM process The nature of projects vary according to the type of problems they are set out to solve, and the role of the PRM fbnction needs to be tailored according to the specific project requirements. However, the role of collecting, structuring and presenting information has the primary objective of being of support to the PM. According to Williams [2], there are mainly two types of benefits of structured project risk management, and the need for the two types varies according to nature of the project.

I. The first type of benefits is to ensure that all issues prone to posing risks are discovered, assessed and handled proactively 11. The other type of benefits is related to provision of a means of communication to ensure all project actors being aware of interface, with issues at risk in activities they themselves do not participate in The need for the former benefit is high i) in projects that are heavy in technology development, whereas the need for common means of communication is high ii) in projects with complex organisational and technical interfaces. Projects may consist of technology development only, possess complex organisational interfaces only, have both conditions present as well as none of them. Additionally, the two project characteristics may be present to varying degrees. These characteristics represent indications of needs for a separate PRM fbnction in support to the project management. 3.2 How may the key benefits best be achieved There are several good references that describe elements of a good PRM process. Simmons [3] describes a practical approach for use in high technology projects, Defense Systems Mgmt. College [4] provides a good overview of techniques and processes used in the U.S. Defense industry. A risk management process [I], [6], which encompasses the main elements in agreement with these references can best be described as follows:

1. Agreement on the project's important objectives, the format of them, the cut-off values for success and failure, the relative importance between them, potential trade-offs in case of need. 2. Systematic review of the project activity plan with identification of all of the project's concerns, threats and opportunities. 3. Screening of concerns, threats and opportunities by the project management into three groups: Those that are judged to be of minor importance due to concerns raised by personnel with limited insight into the particular subject, or issues raised that appears to be motivated by conflicting interests. It is not going to be spent any fbrther resources on investigation of the realism of these threats.

88

Reitan and Hauge

Those that are judged to be too sensitive for further investigation by the project team. May be issues of a personnel management nature, or sensitive information in relation to subcontractor, client, etc. These threats are to be hrther investigated by PM himself, or personnel especially assigned for this issue. The rest of the threats are neither of minor importance nor too sensitive, and are thus judged worthwhile to expend resources in investigating closer. 4. All threats that are deemed not to belong to the group "minor importance" are to be appointed a risk owner, which is the person who will assist the risk manager in clarifying the threat and propose and implement measures. The risk owner is to be a person with good technical and organisational knowledge of the circumstances of the threat. 5. The worthwhile threats are subsequently to be investigated. Their structure of causes and consequences, and identification of contingencies 6. Preparation of qualitative or quantitative assessments of magnitudes of probabilities and consequences of the elements of each threat 7. Identification of potential measures that could reduce probabilities and 1 or consequences, assessment of reduction potential and coarse cost estimates 8. Presentation of results for the project management 9. The project management chooses the measures that deserve a go-ahead, based on assessments of cost-effectiveness 10. Implementation of measures 11. Follow-up of the risk picture 3.3 Division of tasks between project mgmt, risk manager and the project team First of all, the risk manager will take all initiatives to execute the process of identification, assessment and evaluations of threats and potential measures. The manpower requirement for the risk manager and the project personnel is a function of several factors, such as

The nature or the size of the project, according to the number of activities and the needs of the project for PRM benefits The familiarity of the project personnel with threats and their management In projects over a certain size with high demand for PRM benefits, the risk manager will need an assistant who is active in taking notes during meetings and interviews. The communication requirements with project personnel in each of the above activities are given below: 1. The objectives of the project are to be determined together with the owners of the project in the executing organisation, i.e., the project manager and superiors 2. An initial systematic review of all activities in a project needs to be camed out in a meeting with responsibles for the various roles and functions, a risk management working group (RMWG). This means that representatives from finance, contracts, all subcontractors, all relevant engineering disciplines, as well as the functional departments. If such a group is going to be too large, it is necessary to divide the

Training for project success

89

project into smaller sub-groups. All participants in the RMWG has the opportunity to comment on all activities, but in practice it is commented only on the activities one has good knowledge about or is interfaced with. Only the initial review is to be camed out in a separate meeting with the RMWG, the day-to-day risk identification and follow-up may be carried out as a part of the weekly progress meetings. 3. The screening of issues into the three groups is to be camed out by the project manager, or his deputy, in co-operation with the risk manager. 4. The appointment of risk owners will normally be self-evident, the person who proposed the concern, the person in charge of an activity, etc. 5. The investigation of threats is to be carried out in a joint effort of the appointed risk owner and the risk manager. This may entail typically a few meetings, where the first meeting should accomplish establishment of the main structure, and identification of questions that needs to be answered. A period of a few days follows, where these questions are resolved. Then there is a brief second meeting, where the final structure is established. 6. The structure is documented with explanations, assessments and necessary amendments by the risk manager. 7. The substantiated structure of the threat is then used as basis for a meeting between the risk owner and the risk manager where potential measures and contingencies are discussed, together with coarse estimates on cost and time requirements. 8. The hazards with structures of probabilities and consequences together with potential measures with coarse cost and time requirements showing total impact on project objectives with and without measures is then presented to the project management and the risk management working group (RMWG). 9. Implementation of measures or criteria for implementation are then decided by the project management, possibly upon advice from the RMWG. 10. The risk owners are then given go-ahead to allocate resources to implement the measures 11. The risk manager is to keep track of developments in the risk picture, both those identified and new potential threats. The risk manager will communicate with the risk owners of the various identified risks, and the RMWG may meet as a part of the progress meeting group, or separately to identitjl any potential new issues. 4. Structured fuzzy information as decision basis Typical statements a training course needs to address are: Studying the structure of hazards, and how they may influence the goal achievement of the project's objectives is not useful for decision support Concerns of potential threats or unexploited opportunities are not easily transformed into qualitative or quantitative estimates of impacts and probabilities 4.1 Decision basis from hazard - consequence pairs All concerns of objective achievement are normally based on some items of professional experience of occurred losses or gains, or near-miss loss or gain -situations of similar

90

Reitan and Hauge

nature that resemble the present project. An elicitation of the basis for this concern, the real similarities, as well as positive and negative factors of the present situation relative to the basis of concern is one way of preparing the basis for establishment of structure and assessments of a problem. A stmcture of a problem consist basically of a chain of events, [4] i.e., i) what is the hazard situation, the underlying threat, ii) which (initiating) events will trigger the end consequences, and iii) what is the result of the hazard and the events, i.e., what are the end consequences.

I 1 - I

Consequence

Hazard Figure 1

-

Lntermediate event

Consequence

Examples of simple problem strzrcllcres

4

-

htem~ediate event

Consequence

Hazard

r

n Hazard

LC

Intermediate event A Intermediate event B

L

Consequence A

-

Consequence B

Intermediate event A Consequence Intermediate event B Figure 2

Examples of more complex problem structures

The assessment part follows, consisting of assigning probabilities and consequence magnitudes to individual parts of the problem structure. In this part, if the assessments

Training for project success

91

of probabilities or consequences are found to be complicated, a further sub-division of the problem should be considered, i.e. the hazard, the initiating event and the end consequence could be sub-divided into more than one type. Figures 1 and 2 above illustrate possible combinations. The problem structure needs to be developed until the point where estimates can be made with a reasonable confidence. Once a problem structure and some crude assessments are made, an evaluation of the necessity for continued concern can be produced, since at this point it will be more clear whether the concerns are justified. A simple and straight forward transition from assessments into decisions can be performed by using a risk matrix, with probability and consequence classes on the two axes respectively. The various combinations of consequences and probabilities will then result in different decision-field classes. Figures 3 and 4 illustrate the transition from assessments to decisions.

Figure 3

A risk matrix with decision fields

Figure 4

Decision field classes

4.2 Scenario-based decision basis Typical objections to the usage of hazard-consequence pairs as decision basis are: The uncertainty of the value of a given hazard is ignored. The uncertainty of the effect of a given hazard on a given objective is ignored. The aggregate effect of several hazards on a given objective is ignored. The simultaneous effect of mitigating actions on several objectives are ignored. The relationship to the real-life problem is difficult to understand (e.g. intermediate events are not reflected in the problem structure).

92

Reitan and Hauge

One way of answering these objections is to introduce risk scenarios as the basis for the risk management process. Even though such scenarios may be represented in a number of different metaphors, one candidate is the usage of influence diagrams [ 6 ] .In figure 5 an example of an influence diagram is given.

Compbhrg Rojkts

Customtr requiem...

Pmjut Plan

Pmjut P h

Figure 5 Example of risk scenario in terms of influence diagram.

The main elements of the risk management process; i.e. risk identification, risk assessment, risk mitigation, action deployment and risk surveillance, will now basically consist of the management of such risk scenarios. The risk identification part of the risk management process will consist of identifjrlng the structure of the risk scenarios. The assessment part will consist of quantifjrtng the elements of the risk scenarios and their interdependencies as well as assessing the probability distribution of the objective(s). The quantification of the risk scenario elements will consist of determining probability distributions and fbnctional relationships for each element. Interdependencies are taken into account through the specification of dependent probability distributions. The risk mitigation part consists of evaluating and selecting potential measures. The acceptance of risk corresponds now to the acceptance of probabilities for exceeding critical limits for the objective values. Hence, no usage of risk matrices and decision field classes are necessary. The action deployment part consists of simply changing the quantification of the risk scenario elements corresponding to the selected measures. The risk surveillance corresponds to surveying the information (both structural as well as quantification) residing in the scenarios and modifjrtng it as new information becomes available. The iterative nature of the risk management process corresponds to the revision of risk scenarios, the introduction of new scenarios and the possible removal of old scenarios.

Training for project success

93

5. Conclusions

There are numerous impediments to successful implementation of risk management systems in major projects. Such impediments are often caused by a lack of understanding of objectives and methods of a risk management process. An introductory training course should explain three main facets of a PRM process, i) why the study of risk is helpful, and how risk needs to be defined in order to be a good parameter to base decisions upon, ii) how the risk management function is to be camed out in a project, and iii) how statements of concern may be directly translated into decision support.

6. Acknowledgements

This paper is based on experiences gained during implementation of method and tools developed in the Criticality Management Tools (CMT) project. Det Norske Veritas (DNV) is responsible for developing methods and tools for implementation of PRM for the Norwegian Defence Authorities and Aerospatiale of France. This is accomplished in the CMT-project which now is in its final development phase, with current emphasis on training and implementation in organisations. DNV has, through the CMT-project, camed out several introductory training courses for the Norwegian Defence Authorities to aid their PRM implementation. Experience and feedback from these courses suggest three main areas of hesitation to accept benefits of PRM, each of which needs special emphasis in a training 1 motivational course.

7. References

Wright, J.F. and C. Canal (1996) CMT an innovative system for risk management, TPMA Conference on project management, Paris, France Williams, T. (1993) Risk Management Znfastructures, International Journal of Project Management., Vol. 11, No. 1. pp. 5-10. Simmons, C. (1996) An introduction and discussion on Risk Management together with recommendationsfor its implementation, www.airtime.co.uk Defence Systems Management College (1989) Risk Management Concepts and Guidance DSMC, Ft. Belvoir, VA Criticality Management Tools (1997) Expert judgement guideline: Use of subjective information, CMT WP 3.4, Information collection. Hauge, L.H. and J.F. Wright (1995) A multiobjective risk management model, 4 6 International ~ Astronautical Congress, Oslo, Norway Jablonowsky, M. (1996) Using probabilistic risk analysis to improve risk management Risk Management, March 1996, pp. 23-27.

Establishing a formal project risk management process S.C. WARD and C.B. CHAPMAN School of Management, University of Southampton, Southampton, UK

Abstract The purpose of this paper is to offer guidance to organisations who wish to establish formal risk management for project based activities. Establishing a formal risk management policy (FRMP) can be regarded as a project in its own right with its own attendant risks which ought to be managed in the same way as risks associated with any project. An eight stage characterisation of the project life cycle provides a useful framework for identifying key aspects of establishing a FRMP and accompanying risks which need to be managed. Key words: Benefits, formal risk management policy, project life cycle stages. 1 Introduction Full exploitation of the benefits of project risk management warrants the establishment of a formal risk management policy (FRMP) which will provide for a systematic and consistent approach to risk management on projects undertaken by an organisation. This paper discusses the process of establishing such a FRMP. Elsewhere. Ward and Chapman discuss a generic eight sage framework for considering the project life cycle (PLC) [I]. This is helpful in highlighting the nature of project related tasks and related sources of process risk. In particular, it is helpful in considering the introduction, operation and maintenance of a FRMP as a project in its own right. Table 1 summarises the eight stages of the PLC and the associated activities related to the establishment of a FRMP.

Managing Risks in Projects, edited by K. Kahkonen and K.A. Artto. Published in 1997 by E & FN Spon, 2-6 Boundary Row, London SEI SHN, UK. ISBN: 0 419 22990 6.

Establishing formal risk management process Table 1.

Eight stages in a FRMP project

------------ ----_ _ Stage

-----_-

Conception Design Plan Allocation Execution

Delivery Review Support

95

-_--___________-_Key considerations

------------_--

----

-

_-

--_------

-

Benefits expected and preliminary definition of an appropriate deliverable. Nature of the FRMP, project specific benefits, degree of formality, resources available, range of projects to be covered. Initial implementation strategy, resources required, schedule for introduction, choice of "guinea-pig" projects. Identification of appropriate participants and allocation of tasks between them. Initial learning process applying FRMP to individual (test) projects. (Subsequent routine application of FRMP to projects.) Verification of effectiveness of individual FRMP exercises. Periodically check and appraise the effectiveness of the FRMP and associated procedures. Corporate provision of analytical support and senior management scrutiny to maintain standards and commitment to the execution of FRMP on appropriate projects.

___--____--____-_______________-__ 2 FRMP Conception As noted in Table 1, the Conception stage involves identifying the benefits expected and a preliminary attempt to define a means of delivering these benefits. At this point, a long-term corporate view of potential benefits is the concern, arising from improved project performance in a stream of projects across the range of project performance objectives. In the authors' experience many organisations over the past twenty years have first used formal risk management on projects because of an organisational imperative, sometimes imposed by "nature", sometimes imposed by regulators, bankers or other interested parties. However, once a FRMP is in place, most organisations have expanded their motives as an appreciation of the benefits of formal risk management has been acquired. For a contracting organisation which undertakes risk management prior to and after tendering, a number of interrelated benefits can accrue, all driving up profitability, through lower level benefits like [2]:

1. keener pricing, better design and stronger risk management abilities provide competitive advantage and improve chances of winning contracts; 2. better appreciation of uncertainty means more realistic pricing and the avoidance of potential loss making 'disaster' contracts where uncertainty is too great; 3. ability to manage risks means lower project costs with direct profit implications; 4. reduced tendering costs means higher profits.

96

Ward and Chapman

A further important long-term benefit can be the undermining of a risk-averse culture based on a view that uncertainty and risk have wholly negative implications and are to be avoided as far as possible. The introduction of a FRMP can help to foster a new 'risk management' culture based on a realisation that uncertainty can be a source of opportunities, and available opportunities need to be understood if they are to be effectively exploited. This kind of culture change can make an organisation more exciting to work for. This in turn can lead to higher quality staff wanting to join (and stay with) the organisation, with obvious general benefits. Successful implementation of a FRMP company wide ultimately depends on individuals recognising the direct personal benefits as well as the indirect benefits of enhancing their organisation's business performance. For individual project managers the benefits of a FRMP amount to an increased awareness of risks, greater control, fewer unwelcome surprises, reduced stress and more satisfying outcomes.

3 Design of a FRMP

3.1 Nature of the FRMP The essential task in the Design stage is to define a generic process which will guide the application of risk management to individual projects. This should involve setting out a framework of steps that need to be carried out, expressed in general terms with scope for variation in the details. The aim is to build effective risk management capability which can pursue flexible tactics within the scope of a comprehensive process. A description of an appropriate generic process is beyond the scope of this paper, but such a process is discussed in detail by Chapman and Ward [ 2 ] . Design of a FRMP needs to go beyond defining the process to be applied on each project to include consideration of what administrative structures should be established to operate the FRMP and monitor the application of risk management processes on individual projects. A common approach is to begin with a simplified process, perhaps limited to check-lists of risks, tabulated risk registers, and probability-impact grids, introduced fairly rapidly with a minimum of piloting. Following rapid introduction, the idea is to continue operating the simplified process in a well-defined administrative framework, without major changes in format. There is no doubt that a pro fomza risk register approach is a convenient and relatively simple way of focusing attention on project risk management. However, over-reliance on highly structured check-lists of risks can straight-jacket respondents in an inappropriate and inflexible manner [2]. Even if a set of risks is identified from a more generalised 'prompt list' of possible risks on an individual basis for every project, the resulting list of risks does not necessarily provide a sufficiently structured examination of risks and underlying risk drivers. Tabulated risk registers also tend to encourage a superficial approach to the structuring and quantification of risk, and may delay and even hinder subsequent efforts to develop more sophisticated analysis for individual projects. The authors would argue for a more comprehensive approach from the start, on the basis that to understand the nature of effective risk management it is essential to understand the nature of a comprehensive FRMP. Ideally this understanding needs

Establishing formal risk management process

97

to be developed on a widespread basis, not confined to one or two individuals charged with the rapid introduction of a FRMP, to be perceived as just another piece of bureaucracy by busy project managers.

3.2 Benefits of formalisation The application of formal risk management to individual projects should not be driven simply by a wish to measure risk, but by the search for opportunities to modify project designs and plans which will improve project performance. Formal risk management procedures need to reflect this motivation. In addition the documentation associated with formal processes brings other benefits in its own right, in terms of [2]: 1. increasing the visibility of key risks and related assumptions to all interested parties; 2. improving communication and reducing the scope for misunderstandings; 3. recording the rationale for decisions; 4. assisting project team members to "get up to speed" quickly; 5. capturing corporate knowledge and experience for future use; and 6 . highlighting the value of collecting data.

If only the first of these six purposes is of interest, limited documentation may be appropriate. The other benefits deserve careful prior attention, even if the design of the documentation has a fairly free format. Important factors which should influence the design of documentation include [2]: 1. the nature of existing documentation related to past projects;

2. the likelihood of similar projects in future; 3. for contractor organisations, the potential competitive value of documentation; 4. for client organisations, the potential value of documentation for assisting with choice of contractors and terms of contract, and for communicating effectively with contractors during negotiations and subsequently during project execution; 5. the need for "visibility", involving non-technical readers who require a carefully crafted summary, for example, non-executive directors or various stakeholder groups. In addition, the format and level of documentation will be influenced by project specific features. As a general rule, a single rigid policy on risk management documentation for all projects is not usually appropriate.

3.3 Range of applicable projects Another design consideration is the range of projects which will be subject to a FRMP. All projects warrant some level of risk management effort, but different levels of formalisation in risk management will be cost effective for different sizes and types of projects. Therefore the design question is what variations in formal processes are appropriate for the different kinds of project undertaken by the organisation? In general, comprehensive risk management will tend to be most useful when projects involve one or more of the following:

98

Ward and Chapman

1. substantial resources; 2. significant novelty (technological, geographical,environmental, or organisational); 3. long planning horizons; 4. large size; 5. complexity; 6. several organisations; 7. significant political issues.

Over time, organisations institutionalising project risk management may apply different guidelines for project risk management dependent on the presence of the factors listed above. However, such sophistication really needs to wait on the development of experience with a comprehensive process on selected projects. A further design consideration is at what stage of a project's PLC formal risk management processes will be applied. In general they are best applied as early as possible in a project's PLC. This is a significant point for contracting organisations who could usefully undertake risk analysis in respect of a given contract first, as part of tender development to help determine whether to bid or not and at what price, and second, as ongoing risk management of a contract that has actually been won 131.

4 Planning for a FRMP The Plan stage of establishing a FRMP involves formulating the initial implementation strategy, what resources are required in broad terms, determining a schedule for introduction, and identifying suitable "guinea pig" projects on which to first apply formal risk management. This involves determining specific targets for establishing an operative FRMP, particularly in terms of the scope of the projects to be covered and the time scale in which this is to be achieved. To a large degree these targets will depend on the impetus behind the initiative, related to the parties involved and perceived need. The Plan stage also needs to include the development of arrangements for capturing existing risk management data and experience, and disseminating it, as part of developing risk management thinking and expertise in individual personnel. This may include in-house training courses and special interest group seminars (as a form of "quality circle ").

5 Allocation of tasks As noted in Table 1, the Allocate stage involves the identification of appropriate participants in the FRMP, and allocation of tasks between them. Most organisations introduce project risk management processes using a "risk analyst" who may be an external consultant, an internal consultant, or an experienced project manager who has undertaken some form of training or self-study programme on risk management. A sizeable team of analysts may be involved, or the part-time efforts of a single individual. Even a very small organisation needs somebody to act as an advisor and facilitator. However, effective project risk management requires

Establishing formal risk management process

99

that project managers are closely involved in the application of risk management processes to their projects. The provision of analytical support, while useful, is only part of establishing a FRMP. There is an additional need to ensure that application of the FRMP is effective. The experience, seniority and role of the FRMP project manager is obviously of critical importance here. That such a manager is appointed with these responsibilities in the Conception stage is a basic tenet of effective project management.

6 Execution of the FRMP The introduction of a FRMP into an organisation is likely to be part of a long-term change in project management processes and organisational culture. Consequently, it is very important to view early applications of formal risk management processes as part of an ongoing corporate learning process. In particular, the first project subjected to a FRMP should be carefully selected to realise the long-term benefits. Thus the authors advocate a pilot study approach, applying a comprehensive process framework to an appropriate project to learn on. A pilot study approach may ultimately lead to more effective risk management procedures but may be relatively slow as a learning process. In contracting organisations retrospective analysis of recently completed projects may provide more time for the necessary analysis and learning, divorced from tight time schedules associated with tender formulation. Key tasks in the Execute stage of the PLC include [I]:

1. 2. 3. 4.

coordination and control of activities; monitoring progress; modification of targets and milestones; possible reallocation of activities.

These steps are part of the management of a FRMP on a continuing basis and are likely to be carried out in a continuous, iterative manner. From this perspective the FRMP project never terminates and the Deliver, Review and Support stages become part of the Execute stage. However, lessons from a pilot exercise may influence the design of the FRMP in a subsequent pass back through the Design, Plan and Allocate stages before application of the FRMP on another project. This experience might also provide data in respect of sources of risk and the efficacy of responses of direct relevance to other concurrent and subsequent projects. Such feedback,clearly need not wait for termination of the subject project. Any FRMP should include ongoing arrangements to disseminate the latest experience in managing risk as rapidly as possible.

7 FRMP Delivery In a production project context the Delivery stage involves commissioning and handover of the completed product. In a FRMP context this stage involves a

100 Ward and Chapman

systematic appraisal of each FRMP application is appropriate to evaluate the likely relevance and usefulness of both project specific results and process specific results to inform both future projects and future risk management practice. In respect of completion of a pilot study, this stage is likely to be postponed in favour of a loop back through the Design, Plan and Allocate stages prior to further application of the FRMP on a wider scale. 8 FRMP Review

Periodically, a broadly based review of FRMP procedures is appropriate to check and appraise the operation of the FRMP across the organisation. Over time this can lead to significant changes in the way the FRMP operates.

9 FRMP Support To maintain the effectiveness of a FRMP it is desirable to provide continuing support for project risk management in both a facilitating and supervisory sense. Aside from corporate analytical expertise which may be called upon by project management teams, there may well be a need for corporate management involvement in scrutinising risk management practice on individual projects to monitor the effectiveness of processes, to facilitate improvements in risk management practice, and to monitor the effectiveness of FRMP procedures. The level of such support will need to be reassessed periodically to ensure it remains cost-effective. The level of analytical support may need to be increased over time, depending on the expertise and resources available within project teams. Policy decisions may need to be made about the composition of project teams if the need for risk analysis increases. Apart from analytical support, senior management scrutiny of risk analyses and risk management plans may well be worth maintaining indefinitely as part of standard project appraisal procedures. This will help to maintain and improve standards of risk management, particularly through changes in personnel at all levels [2].

10 Managing the risks The process of establishing a FRMP for all projects as a standard corporate policy is not without risk. The essential risk is that the FRMP fails to bring sufficient benefits, perhaps because procedures are inappropriate, not properly implemented or only partially adopted. Moreover, if difficulties are encountered with applying the FRMP to particular projects, the credibility of the whole initiative may suffer, making it very difficult to revive any FRMP initiative at a later date. An important benefit of discussing the establishment of a FRMP in terms of eight stages in the PLC is that such risks are more naturally identified as standard project management process risks. As with any corporate initiative, senior management support is crucial to empower the process, and to ensure the FRMP reflects the needs and concerns of senior management. As with any project, a manager for the FRMP project should also be

Establishing formal risk management process 101 appointed in the Conception stage so that he or she can actively participate in elaborating the FRMP concept and clarifying its purpose before the more detailed Design and Plan stages. It can be useful to involve a wider group of parties, including project managers and individuals in functional departments in the organisation, key customers, key contractors, potential partners, and external consultants to facilitate the FRMP design and introduction. Other strategies to ensure effective management of implementation risks can be inferred from general principles for the effective management of change. For example, one area of risk is that the initiative fails because of resistance to its introduction. Strategies for reducing such resistance should typically include education, communication, participation and involvement of affected personnel, facilitation and support to users, and incentives to implement the FRMP. Discussing the introduction of strategic planning as a significant organisational change, Ansoff [4] has argued that maximum resistance is produced by a change process which seeks to impose administrative systems before addressing sources of resistance to the change. In contrast, minimum resistance is created when a change process builds acceptance of change before introducing administrative systems. In the context of introducing a FRMP, the minimum resistance route implies a process which first clarifies the need for and relevance of a FRMP, seeks to improve stakeholders' understanding of what is involved, and then provides incentives for individuals to apply the FRMP. Additionally, there is a need to ensure that risk management skills are developed, and that individuals have sufficient time and resources to operate the FRMP.

5 References 1. Ward, S.C., and Chapman, C.B. (1995) A risk management perspective on the project life cycle. International Journal of Project Management, Vol.13, No.3. pp.145-149. 2. Chapman, C.B., and Ward, S.C. (1997) Project risk management: processes, techniques and insights, John Wiley & Sons, Chichester. 3. Ward, S.C., and Chapman, C.B. (1991) Extending the use of risk analysis in project management. International Journal of Project Management, Vo1.9, No .2. pp.117-123. 4. Ansoff, H.I. (1984) Implanting strategic management, Prentice-Hall, Englewood Cliffs, New Jersey.

Institutional risk management S.H. WEARNE Chairman, Speczjic Interest Group on Contracts & Procurement, UK Association for Project Management; Visiting Senior Lecturer, Project Management Group, University of Manchester Institute of Science and Technology; Emeritus Professor of Technological Management, University of Bradford, UK

Abstract New projects to produce services or goods can suffer 'institutional' risks of their promoters' lack of agreed objectives, stakeholders' different criteria for success, uncertainty in committing resources, poor control of changes to objectives, illconsidered shifts in priorities and late preparation for the effects of a project on established business. A common result is reluctance to recognise, analyse and manage their project risks. The causes of institutional risks are well known and the remedies often stated. The remedies cost effort and time, but what are the costs of inaction ? Keywords: Changes, commitment, costs, institutional risks, motivation, objectives, priorities, scope. Institutional risks and their causes The term 'institutional' is used to mean risks caused by organizational structure and behaviour. These risks occur in companies and state bodies. They affect projects large and small. Causes of institutional risks are discussed in reports, case studies and other publications from various countries[l-41. These and our observationsin organizations and industrial courses indicate that they comprise:

Managing Risks in Projects, edited by K. K%hkbnen and K.A. Artto. Published in 1997 by E & FN Spon, 2-6 Boundary Row, London SEl BHN, UK. ISBN: 0 419 22990 6.

Institutional risk management 103 Lack of agreed project objectives Causes: Ultimate user is unknown, misrepresented or not committed to the project. Decisions on the objectives, financing, planning, design and implementation of a project are divided between departments in the promoter's organization each with their individual or corporate culture. Failure to communicate objectives. Lack of agreed criteria for project success Causes: To its promoter* a project is only a means to an end. Failure to obtain agreement of all stakeholders. Institutional time scales are shorter than project time scales. Lessons of successes and problems of previous projects are not applied. Inadequate risk analysis and risk management Causes: Not all downstream parties are consulted at the start of projects. Lack of resources to study risks stage by stage from the start of the project. Refusal to use the word risk. Inadequate project scope Causes: Many of the above, plus Lack of resources. Imposed limit to cost. Inadequate definition of project scope Causes: Many of the above, plus Lack of resources to study options and uncertainties early in a project. Lack of project implementation plan Causes: Many of the above, plus Individuals know that logically they should give more attention to the start of a project, but under the pressures of their jobs they tend to concentrate on immediate problems as these arise rather than avoiding future problems. Changes to priorities Causes: Inadequate agreed planning. Individual executive power indifferent to facts.

*

By 'promoter' meaning the organization, individual or joint venture responsible for rhe decision to invest in a project, as variously also called client, sponsor, owner, employer, etc

104 Wearne

Changes to scope Causes: Many of the above, plus Market forces and force majeure. Late preparation for handover of completed project. Mistakes. Disputes Causes: Many of the above, plus Departmental self-interest. Imposition of standard procedures. Haste to get work started given the decision to proceed with a project. A quick start is achieved, but often the haste causes extra costs and late completion of the project. Inter-organizational risks This paper concentrates on risks within organizations. The separation of customer, designer and supplier for construction and other projects can cause similar problems, but actions to remedy them are the subject of other discussions on contract strategies[5]. Joint ventures, consortia and alliances can also cause similar problems, but the remedies to these are the subject of other discussions of inter-organizational relationships and contracts between their partners[6]. Remedies to institutional risks

Recommendations The remedies for anticipating and minimising institutional risks are frequently stated in books, papers and courses, though in varying ways. Not all are stated with evidence of their effectiveness and the lessons, but they provide a check list to consider for projects large and small: Appoint a 'project champion' to represent the promoter and authorised to wntrol changes to swpe and schedule. Plan projects and priorities collectively with all stakeholders. Designate a project manager with defined authority on behalf of the project champion. Attend to institution building. The promoter's or other parties to a project may be lacking, immature or politically concentrated on unproductive interests[2,7]. Develop teamwork to draw together the experience and interests of all stakeholders and overcome differences in understanding objectives and perceptions of risks[8]. Locate all a project team together. Locate the project team where the critical problems may arise. Ensure that a single organization is responsible for programme management of a set of related projects[9]. Define the urgency of a project in terms of the financial value of time saved[lO].

Institutional risk management

105

Include a first risk analysis with the first ideas for a project, and continue it in more detail stage by stage with decisions on whether to proceed with the project, how and when. Search and prepare for the time-critical and the crucial activities of a project[l 11. Base the first estimate of cost and benefits on a realistic programme for a project. Time and money interact; they should not be input of separate experts[3]. Calculate ranges of cost and time estimates, with specific contingencies and tolerances for uncertainty derived from risk analysis[3]. If the word risk is not allowed, use "uncertainty". Risk or uncertainty is the only reason why managers are needed. Agree a project execution plan with all stakeholders. Write project procedures jointly with their expected users and agree how many hours each class of user is to devote to reading them. Specify in all procedures how they may be varied to suit differences in the size, complexity, urgency, risk and novelty of projects. Allocate resources to reviewing and codifying the causes of successes and problems of the project. As in all learning from problems of projects, most of these remedies mean earlier attention to potential risks, moving upstream from where problems become apparent to actions to anticipate and avoid them. Onus on project promoters The promoters of projects have the greatest interest and the greatest scope to think ahead to achieve the objectives of their projects and anticipate problems. All other parties are limited by what a promoter agrees needs time and other resources. Unless the promoter pays for a problem to be avoided the other parties will tend to give attention only to what may directly affect their own interests. The promoter's institutional risks thus encompass all other risks. An organization is a means for people to achieve more collectively than they could alone. Institutional risks can counter this. Their obvious results are failures to deliver projects right first time, safely, on time and at best value for money. If the above is a list of known and logical remedies, why are institutional risks allowed to continue to affect projects ? The remedies are restated frequently. Does this indicate that they are wrong ? Or does it indicate that many promoter organizations have institutional problems of making collectively intelligent decisions. Are many managers collectively less sensible than their average employee ? If so, logic may not be enough. Individual managers tend "to protect their own turf...It takes a lot of management commitment and personal dedication to work through the process of translating a commitment into deedsW[l2].Given this effort, a remedy may be accepted as logical, but is opposed because of cost. But what is the cost of continuing to live with a problem ? The promoters of projects ought to study the costs of lack of attention to their institutional risks. They might then agree the potential value of risk analysis stage by stage through their projects to show how to avoid and minimise these selfinflicted losses.

106

Wearne

Selected References 1. Johnson, J K (1984) Organizational Structures and the Development Project Planning Sequence, Public Administration & Development, Vol4, pp 111-131. 2. Miles, D, & Neale, R H (1991) Building for Tomorrow: International Experience in Construction Industry Development, International Labour Office. 3. Thompson, P A, & Perry, J G, eds (1992) Engineering Construction Risks - A Guide to Project Risk Analysis and Risk Management, Thomas Telford Publications. 4. Tobelem, A (1992) Institutional Capacity Analysis and Development System (ICADS), Occasional Paper 9, Public Sector Management Division, World Bank. 5. Procurement - A Key to Innovation ? (1997) Working Commission W92, International Council for Construction Research, Studies and Documentation (CIB), symposium, MontrM. 6. Wearne, S H, & Wright, D (1996) Organizational Risks of Joint Ventures, Consortia and Alliance Partnerships, International Project Management Association congress, Paris. 7. Tobelem, A (1994) Revisiting the Role of the State, Occasional Paper 17, Public Sector Modernization Division, World Bank. 8. Thompson, P A (1996) Contribution of Teamwork to Project Risk Management, International Project Management Association congress, Paris. 9. Schmitz, J (1995) Communicating Restraints: Schedule Baseline and Recovery Measures on the Hong Kong Airport Projects, Annual Seminar/Symposium, Project Management Institute, New Orleans. LO. Wearne, S H (1996) Economic urgency in project management, Project, November, Vol 10, No 6, p 10. 11. Williams, T (1993) What is critical ? Znt. J1. of Project Mngmt. , Vol 11, No 4, pp 197-220. 12. Larson, E, & Drexler, J A (1997) Bamers to project partnering: Report from the firing line, Project Mngmt. Jl., Vol 28, No 1, pp 46-52.

PART 4

NEW SKILLS AND TECHNIQUES FOR PROJECT RISK MANAGEMENT

Managing risk management processes: navigating a multidimensional space C.B. CHAPMAN and S.C. WARD School of Management, University of Southampton, Southampton, UK

Abstract This paper describes project risk management in terms of five dimensions: programme level, project strategy, life cycle stages, nature of the risk analysis, and maturity of an organisation's experience of risk management processes. These dimensions and the connections between them offer a useful framework for guiding risk management efforts. Keywords: dimensions, guidelines, maturity, project life cycle, processes, risk analyses.

1 Introduction This paper explores the relationships between five sets of dimensions with respect to the management of risk management processes concerned with projects. One is the "programme dimension", concerned with the level of "the project" in a hierarchy of projects defined in terms of the organisation's operations. A second is the "strategy dimension", concerned with the degrees of freedom available to manage the project in terms of: partners involved, objectives, design, resources, timing and task definitions (the six W's). A third is the "life cycle dimension ' which is concerned with the life cycle position of the project. A fourth is the "analysis dimension" which is concerned with the analysis stage of the risk management process: what has been done and what remains to be done. The fifth is the "maturity dimension ' which is concerned with the organisation's position on its risk management learning curve. The paper addresses keeping track of where we are in these spaces, effective and efficient processes for moving about in them without getting lost, and danger areas to be avoided. 1

1

Managing R i s h in Projects, edited by K. Kithkonen and K.A. Artto. Published in 1997 by E & FN Span, 2 6 Boundary Row, London SEl 8HN, UK. ISBN: 0 419 22990 6.

110 Chapman and Ward To explain risk management processes in the simplest possible terms, we might begin by making simplifying assumptions about four of the five sets of dimensions discussed here, then address the fifth. Next, we might address "what happens to this process as we change location in the other four dimension sets, one at a time or simultaneously?" With this in mind, consider the following ordering of dimension sets, with linked assumptions for the first four.

1. 2. 3. 4.

Maturity: we are novices at formal risk management. Programme: we have a simple independent project. Life cycle: we are at the one and only approval point in the project life cycle. Strategy: we have set tasks to achieve a set design and quality with a fixed completion date, with how to perform the tasks and cost as the only degrees of freedom. 5. Analysis.

This paper begins with the Analysis dimensions, using the assumptions noted above for the other four dimension sets. It then explores the other four in ascending (reverse) order, using a simple example to illustrate issues. Navigating guidelines follow, building on the structure provided by the very brief introduction to the five sets of dimensions. The emphasis is connectivity between the dimensions.

2 Analysis dimension Table 1 summarizes the Association for Project Management (APM) Project Risk Analysis and Management (PRAM) Generic Process, described in Chapter 3 of their forthcoming Guideline [I], elaborated elsewhere [2]. Table 1 explains the nature of the nine phases in terms of objectives (purposes) and deliverables. As an illustrative example, assume we have a mutual friend who has bought a large dog for his wife and daughter. He has designed a dog house to be made of brick to match the style of his suburban house and garage (complete with heating and other conveniences), and it must be finished for 1 August when the dog arrives. He wants our approval (as experienced project managers) that he is planning to execute the associated tasks appropriately, using a local builder to deal with tasks requiring skills he is unsure of, and to keep to time. Assuming that our friend is a novice with respect to risk management who wants to learn by doing, and the dog house risk management process (RMP) is viewed as a learning experience, most of us could explain how to apply the APM process or similar alternatives in a reasonably straightforward manner. This might be viewed as project risk management processes (RMPs) at their simplest. For those who are unsure about this, see [2], Part 2.

Multidimensional risk management processes

111

Table 1 A generic risk management process structure Phases

Purposes

Define

Consolidate relevant existing A clear, unambiguous, shared information about the project. understanding of all relevant key aspects of Fill in any gaps uncovered in the project, documented, verified and reported. the consolidation process.

Focus

Scope and provide a strategic plan for RMP. Plan RMP at an operational level.

A clear, unambiguous shared understanding of all relevant key aspects of RMP, documented, verified and reported.

Identify

Identify where risk might arise. Identify what we might do about this risk, in proactive and reactive responses terms. Identify what might go wrong with our responses.

All key risks and responses identified, both threats and opportunities, classified, characterised, documented, verified and reported.

Structure

Testing simplifying assumptions. Providing more complex structure when appropriate.

A clear understanding of the implications of any important simplifying assumptions about relationships between risks, responses and base plan activities.

Ownership

Clientlcontractor allocation of ownership and management of risks and responses. Allocations of client risks to named individuals. Approval of contractor allocations.

Clear ownership and management allocations, effectively and efficiently defined, legally enforceable in practice where appropriate.

Estimate

Identify areas of clear significant uncertainty. Identify areas of possible significant uncertainty.

A basis for understanding which risks and responses are important. Estimates of likelihood and impact in scenario or numeric terms, the latter including identification of assumptions or conditions, sometimes with a focus on "show stoppers".

Evaluate

Synthesis and evaluation of the results of the estimate phase.

Diagnosis of all important difficulties and comparative analysis of the implications of responses to these difficulties, with specific deliverables like a prioritised list of risks, or a comparison of base plan and contingency plans with possible difficulties and revised plans.

Deliverables (may be targets not achieved initially)

112 Chapman and Ward Plan

1. Base plans in activity terms at the Project plan ready for detailed level required for implementation and associated implementation, with timing, risk management plan. precedence, ownership and associated resource usage/contractual terms where appropriate clearly specified, including milestones initiating payments, other events or processes defining expenditure, and an associated base plan expenditure profile. 2. Risk assessment in terms of threats and opportunities, prioritised, assessed in terms of impact given no response is feasible and potentially desirable, along with assessment of alternative potential reactive and proactive responses. 3. Recommended proactive and reactive contingency plans in activity terms, with timing, precedence, ownership and associated resource usagelcontractual terms where appropriate clearly specified, including trigger points initiating reactive contingency responses and impact assessment.

Manage

Monitoring. Control. Developing plans for immediate implementation.

Diagnosis of a need to revisit earlier plans, and initiation of replanning as appropriate, including on a regular basis specific deliverables like the monitoring of achieved performance in relation to planned progress, and prioritised lists of risklresponse issues. Exception (change) reporting after significant events, and associated

3 Strategy dimension Degrees of freedom in the Strategy dimension might be associated with the classical cost-time-performance triangle [ 6 ] .A more general portrayal identifies six sources of project uncertainty, the 'six Ws' of: who, what, whichway, wherewithal, when and why, as shown in Figure 1 [ 2 ] . Exploration of Figure 1 with our friend might reveal he decided to buy the dog for "companionship and security" for his family because he travels a lot, his wife has been very much involved insofar as she insists the dog lives outdoors and the dog house is in keeping with the house, and 1 August is his daughter's birthday. This might clarify the 1 August date and the implications of delay, but suggest no other new issues.

Multidimensional risk management processes

Main feedfonvard /feedback loops

_,

Initial influence

Fig. 1. The six Ws

113

114 Chapman and Ward

4 Life cycle dimension Elsewhere Chapman and Ward [2] have characterised the project life cycle in terms of eight stages which can be usefully employed with Table 1 and Figure 1 dimension sets for risk management purposes, as outlined in Table 2. Two rather different aspects of the life cycle dimension are relevant here. First, we could take our friend through the rest of the life cycle for planning purposes given we are at the end of the plan stage ready to start the allocate stage. This should raise questions like "will his daughter like the dog?", and "will the dog like the dog house?". If the dog refuses to live in the dog house, and barks all night, disturbing the neighbours who call the police, our friend has a serious problem on his hands, especially if his daughter has fallen in love with the dog by the time this problem becomes clear, and his wife is adamant about the dog not living the house. Second, we could suggest that on his next project our friend starts the RMP before he buys the dog and designs the dog house. Earlier analysis in this case might lead him to identify the project in terms of "providing companionship and security", with the design solution "buy a cat and a burglar alarm". An earlier start for the RMP in the life cycle and a wider view of the project go hand-in-hand.

5 Programme dimension The RMP of Table 1 can be viewed as a programme of linked projects, each phase being a component project with its own objectives, tasks and deliverables. This is one of the interesting and useful characteristics of this nine phase portrayal. Moving in the other direction, "providing companionship and security for the family" can be viewed as one project in a programme "look after the family", which is in turn one project in a programme "manage your life". Two rather different aspects of these dimensions are relevant here. First, we could ask our friend whether he really wants to travel so much, particularly if he doesn't like cats and cannot think of any other acceptable way to provide companionship and security. Second, we could suggest that before he starts his next project our friend thinks about his career and family life at a holistic level prior to worrying about travel and cats or dogs.

6 Maturity dimension If our much travelled friend is an RMP novice, the only way to move towards a more mature position is experience. Hilson [7] characterises the maturity dimension in terms of four categories, as indicated in Table 3. The rational for wanting to achieve a more mature position is efficient and effective realisation of a full range of benefits, as discussed widely [I, 2, 8 or 91. Assuming such maturity is desired, a key question is "how do we manage the other four dimensions as we move through the fifth?".

Multidimensional risk management processes 115 Table 2. Applications of risk management in the project life cycle

Stages of the PLC

Roles for risk analysis

Conceive

Identifying stakeholders and their expectations Identifying appropriate performance objectives

Design

Testing the reliability of design Testing the feasibility of design Setting performance criteria Assessing the likely cost of a design Assessing the likely benefits from a design Assessing the effect of changes to a design

Plan

Identifying and allowing for regulatory constraints Assessing the feasibility of a plan Assessing the likely duration of a plan Assessing the likely cost of a plan Determining appropriate milestones Estimating resources required Assessing the effect of changes to the plan Determining appropriate levels of contingency funds and resources

Allocate

Evaluating alternative procurement strategies Defining contractual terms and conditions Determining appropriate risk sharing arrangements Assessing the implications of contract conditions Assessing and comparing competitive tenders Determining appropriate target costs and bid prices for contracts Estimating likely profit following project termination

Execute

Identifying remaining execution risks Assessing implications of changes to design or plan Revising estimates of cost on completion Revising estimates of completion time of execution stage.

Deliver

Identifying risks to delivery Assessing feasibility of delivery schedule Assessing feasibility of meeting performance criteria Assessing reliability of testing equipment Assessing requirement for resources to modify project deliverable Assessing availability of commissioning facilitjeq

Review

Assessing effectiveness of risk management strategies Identification of realised risks and effective responses

Support

Identifying extent of future liabilities Assessing appropriate level of resources required

------------------------------------------------------------------------------

--

-------

-----

----------

Table 3: Attributes of RMM Levels from D.A. Hilson "Towards a maturity model" [7] Level 1 - NAIVE

LEVEL 2 - NOVICE

LEVEL 3 - NORMALISED

LEVEL 4 - NATURAL

DEFINITION

Unaware of the need for management of risk. No structured approach to dealing with uncertainty. Repetitive and reactive management processes. Little or no attempt to learn from past or to prepare for future

Experimenting with risk management, through a small number of individuals. No generic structured approach in place. Aware of potential benefits of managing risk, but ineffective implementation, not gaining full benefits.

Management of risk built into routine business processes. Risk management implemented on most or all projects. Formalised generic risk processes. Benefits understood at all levels of the organisation, although not always consistently achieved.

Risk-aware culture, with proactive approach to risk management in all aspects of the business. Active use of risk information to improve business processes and gain competitive advantage. Emphasis on opportunity management ("positive risk").

CULTURE

No risk awareness. Resistantlreluctant to change. Tendency to continue with existing processes.

Risk process may be viewed as additional overhead with variable benefits. Risk management only used on selected projects.

Accepted policy for risk management. Benefits recognised & expected. Prepared to commit resources in order to reap gains.

Top-down commitment to risk management, with leadership by example. Proactive risk management encouraged & rewarded.

PROCESS

No formal processes.

No generic formal processes, although some specific formal methods may be ~nuse. Process effectiveness depends heavily on the skills of the in-house risk team and availability of external support.

Generic processes applied to most projects. Formal processes, incorporated into quality system. Active allocation & management of risk budgets at all levels. Limited need for external support.

Risk-based business processes. "Total Risk Management" permeating entire business. Regular refreshing & updating of processes. Routine risk metrics with constant feedback for improvement.

EXPERIENCE

No understanding of risk principles or language.

Limited to individuals who may have had little or no formal training.

In-house core of expertise, formally trained in basic skills. Development of specific processes and tools.

All staff risk-aware & using basic skills. Learning from experience as part of the process. Regular external training, to enhance skills.

APPLICATION

No structured application No dedicated resources No risk tools

Inconsistent application Variable availability of staff. Ad hoc collection of tools and methods

Routine & consistent application to all projects. Committed resources. Integrated set of tools and methods.

No structured application No dedicated resources No risk tools.

Multidimensional risk management processes 117 7 Navigating guidelines Having established in outline the nature of the dimensions of interest, consider some suggested guidelines. First, some things to do when getting started.

1. Start with a reasonably separable project, comparable to "providing companionship and security". 2. Start with a project at a well developed approval stage, comparable to a fully designed dog house. 3. Pick a well managed project, which has lots of degrees of freedom, comparable to no commitment to take delivery of an unknown dog already purchased. 4. Consider all six Ws from the outset. 5. Consider the full remaining life cycle, in the sense of looking forward to uncover risks. 6. Consider the wider programme, in the sense of "managing the rest of your life", as an exercise in confirmation of this particular project, rather than as a process for determining the meaning of life. 7. Use a complete and comprehensive version of the formal RMPs available, to develop a feel for where shortcuts can be taken safely based on detailed knowledge of the terrain. 8. Work through the maturity dimension in terms of 1 to 7 above to a reasonable extent before you start to generalise with respect to each of the seven suggested limitations indicated above. Things to avoid when getting started include all the obvious reversals of the above, individually and in combination. When starting to generalise experience in terms of the seven suggested limitations indicated above, consider some further suggestions.

1. Remember that "maturity" will be quite localised when you start to generalise. 2. Maintain a complete and comprehensive RMP (avoid shortcuts) until it is clear what shortcuts are appropriate over new terrain. 3. Try earlier applications of the RMP in the life cycle position before relaxing any of the other limitations. 4. Don't attempt to deal with badly managed projects until you have the reputation and the power to deal with the reasons that the project has been badly managed. 5. Provide useful feedback into programmes containing your projects to find a backdoor into higher levels of programme management before making a direct play to manage risk at a higher level. 6. Maintain a "learning process" and "learning organisation" view of the process as a whole. 7. Remember that introducing risk management processes into an organisation is a management of change project and change involves high risk. 8. Try to ensure that the change process is as much "fun" as possible for all those involved.

118 Chapman and Ward

8 Conclusion This paper is very brief in terms of suggestions, because of the need to establish the dimension sets and space limitations. Elaboration is provided elsewhere [2]. However, a key purpose of this paper is to encourage the development of a dialogue amongst all RMP users about what to do and what not to do within a structure which makes such advice useful. A key issue for discussion is the efficacy or otherwise of the five dimensions used here. For example, has an important sixth dimension been passed over which could usefully be made explicit? A contribution to structuring our learning processes is the underlying goal of this paper. 9 Acknowledgements The authors would like to acknowledge permission from John Wiley and Sons to use Figure 1, and Tables 1 and 2 from "Project Risk Management" [2], and permission from Project Manager Today Publications to use Table 3 from "Towards a maturity model" [7]. They would also like to acknowledge that the initiation of the dog house example and the germination of the basic idea underlying this paper is attributable to Terry Williams and his motivation to write an earlier paper [lo]. 10 References

APM (forthcoming). Association for Project Management Project Risk Analysis and Management (PRAM) Guide. Chapman, C .B. and Ward, S.C. (1997) Project Risk Management: Processes, Techniques and Insights, John Wiley and Sons Ltd., Chichester. MOD (PE) - DPP (PM) (1001) Risk Management in Defence Procurement. reference D/DPP(PM)/2/1/12, Directorate of Procurement Policy (Project Management), Room 6302, Main Building, Whitehall, London. Chapman, C. B. (1979) Large engineering project risk analysis. IEEE Transactions on Engineering Management, EM-26,pp. 78-86. Chapman, C.B. (1990) A risk engineering approach to project management. International Journal of Project Management, Vol. 8,No. 1, pp .5-16. Barnes, M. (1984) Effective project organisation. Building Technology and Management, December, pp.21-23. Hilson, D.A. (1997) Towards a risk maturity model. The International Journal of Project and Business Risk, Spring, pp .35-46. Simister, S.J. (1994) The usage and benefits of project risk analysis and management. The International Journal of Project Risk Management, Vol. 12, No.1. Newland, K. (1997) Benefits of project risk management to an organisation. The International Journal of Project and Business Risk, Spring, pp. 5-14. Chapman, C.B. and Ward, S.C. (1996) Time risk: what it drives and how it is driven. NATO funded workshop, Managing and Modelling Complex Projects, Kiev, all papers and discussion forthcoming as a book edited by Terry Williams in the NATO AS1 Series, Klower, 1997.

Implementing the successive principle O.J. KLAKEGG ProsjektStyring AS, Trondheim, Nonvay

Abstract For many years, managing change and uncertainty has been addressed in project management, without becoming more than an expert tool, used at special occasions. The author has implemented the successive principle as a practical management tool for handling risk and uncertainty in a large number of cases. This has given broad experience from a wide range of different project types and management problems. The paper examines three cases and summarise some of the main findings. The paper includes a summary of guidelines for implementing the successive principle for project managers and moderators. In Nonvay we reach for implementation of risk management as a general tool for managers and practitioners in most kinds of projects. The main conclusion of the paper is that the successive principle and its practical approach to risk management in projects has the potential to give risk management a break trough. Keywords: Management tools, project planning, risk analysis, risk management.

1 The project process and the planning process The PMI Guide to the Body of Knowledge [ l ] defines the four major Project Risk Management processes as follows: Risk Identification, Risk Quantification, Risk Response Development and Risk Response Control. The first three of these elements make up the analysis process. Number four is the integration element which makes the risk management an integrated part of the project management. In other words I define the risk response control a part of the project process, see fig. 1. Managing R i s h in Projects, edited by K . KXhkOnen and K.A. Artto. Published in 1997 by E & FN Spon, 2-6 Boundary Row, London SEl SHN, UK. ISBN: 0 419 22990 6.

120

Klakegg

Fig. 1.

The goal-setting process, the project process and the analysis process

Implementing elements of risk management has been done for a long time in a wide range of projects. In most cases only as a one-time happening in the beginning of the project, or later, in a situation when the project management has already become aware of serious problems in the project. To make the most out of the risk management elements, they have to bee integrated with the appropriate project management principles and tools according to the needs of the project management. Controlling risk and performing risk management activities should be a continuous process. It has proven very difficult to achieve this. Some of the reasons are obvious, like the contract formats, and the deterministic tradition giving a lack of will to use resources in risk management. Other reasons are difficult to grasp. Why do people not want the complete information about their project's situation? Why is it so difficult to make people use the new principles and tools, even if they are relatively easy to understand and use? One answer is that the top managers has too little knowledge of risk management principles and tools. Therefore they seldom ask for it and often tend to reject it. In trying to introduce risk management in project management, a wide range of tools and techniques has been used. In the Scandinavian countries the use of tools supporting either the Successive principle or Monte Carlo simulation has been most usual and most successful. Users of the Monte Carlo simulation technique has got the most elegant, and the biggest number of tools to choose from. Those applying the successive principle and the corresponding techniques have relatively few, but functional and easy tools available. The latter is the easiest to understand and use. Discussing utilising and integrating the risk management methods and tools in the total project management, one has to make a distinction between the diierent processes shown in fig. 1. The strategic goal-setting processes (top circle) is where top management and project management meet to stake out the course and put force into the project process (big circle). The project process is the well known learning circle including planning, doing, checking and correctingAearning. This is the process that produces the results of the projects. The analysing process (right circle) is the most important element of risk management. Risk management processes in the planning and analysis phase has been described by several authors. Examples are Klakegg [2], Lichtenberg [3], Chapman [4] and others. These are all good risk management guidelines, but we have t o put them into the total project process to solve the real problem in project management. The

Implementing the successive principle

121

Criticality Management Tools project [5] and the research programme Project 2000 [6], in Norway has addressed this problem. Most organisations are still not mature enough to hlly utilise the potential of risk management, see fig. 2. Many of the performed risk analysis have basically been too late or too complex to make a lot of difference. Too late means project management has already experienced problems and need help to get out of a tricky situation. The main point of risk management should be identifying possibilities and problems at an early stage, making management able to use the possibilities and avoid problems, to the benefit of the project. This points to the need for an integrated risk management through all project phases and specially is the early stages of a project. Other risk analysis have been made too complex for the decision makers and managers to understand. Information which is not understood can not be trusted, not even if presented by experts. This points to the need for increased knowledge among the users of the analysis results - planners, managers and other decision makers.

MATURETY

A

Risk management

~ntegratedwith other management

b TIME Fig. 2.

Maturity levels towards an integrated risk management

2 The successive principle and its golden rules

The successive principle is an organisational management tool. Dr. Steen Lichtenberg's book [3] presents a family of techniques and tools developed to support the working principles of the successive principle. There is nothing difficult about the successive principle. Actually, this is one of its most important features. However, this simplicity has for a long time been its most important pro and con. On one hand it is easy to understand, on the other hand it is easy to see its limitations. Its accuracy is not impressive and the theoretical foundation includes a few conditions which seems to be week points. Many experts has used this assumed weakness as an argument for avoiding the successive principle and for choosing other tools. The successive principle has never become as popular and widely used as it deserves to be. Actually, the golden rules of the successive principle can be used with almost any known planning and management tool. The same principles are widely used. The successive principle is simply common sense put into system. The most important of the golden rules are:

122 Klakegg Serious planning and risk management should start early in the project life-cycle and be a part of the management responsibility. Always keep a total overview of your project - working top-down from a few main items into more details where this is useful. This will help you from forgetting important aspects of your project and it will give a more balanced view of the situation. Too many details tend to lead to sub-optimisation and turns the focus to the wrong things. Always use both sides of the human brain - both logic and creative. In order to look into the future (which planning is really all about) you need both. For the same reason, you should use a resource group comprising different kinds of people (optimistic, pessimistic, young, old, beginner, expert, man, woman) to be able to see all relevant aspects of the project. You get to know the situation by discussing it with those involved. Always make sure everything about your project comes up - also the things difficult to quantifjl. The more difficult, the more tempting to let out, but also the more important to include in your planning. The difficulty is the uncertainty and should therefore be the focus of the work. The techniques and tools supporting the successive principle includes help to give priority to the most important aspects of the project. 3 The step-by-step principle - a working procedure

Klakegg [2] has developed the successive principle further. With an increased focus on the planning process, the risk identification, quantification and response development, a practical working procedure for planning under uncertainty is described. The step-bystep principle comprise 8 basic steps to improve quality of the basis for making decisions, controlling and managing the project. These steps are: 1. 2. 3. 4.

5. 6. 7.

8.

Defining the objective and scope of the analysis. Identifjrlng the overall internal or external influence factors - risk identification. Structuring the task from an over-all view on a strategic level. Estimating the cost or the time for every item in the plan, including uncertainty - risk quantification. Calculations are performed with computer tools, chosen to optirnise the support of the problem-solving and the planning process. Evaluation of the calculation results. If the plan is not detailed enough or still too uncertain, steps 2 - 5 should be repeated until the plan is accepted. In this process details are added, where details are needed. Conclusion to the analysis. Defining risk responses.

This working procedure is designed to force the resource group to work "top-down" in a way that systematically reduces the uncertainty and adds relevant information into the plan, only where the planning effort really matters. In this way the planning resources are efficiently used.

Implementing the successive principle

123

This working procedure should be implemented with a resource group. When the planners are well trained and familiar with the procedure and the planning techniques, it is no longer important to "go strictly by the book". This flexibility gives the moderator freedom to design his own working procedure to improve his working process.

Fig. 3.

The working procedure of the Step-by-step principle

4 Selected case-stories

To illustrate some effects of the use of the successive principle in risk management, we want to look into some cases performed by the author. Among the most interesting cases are: 1 . A product development project from an international mega-company with a

Norwegian telecommunication branch. Covers cost- and time analysis. 2. Planning a major railroad investment for the Norwegian railroad authorities. Covers cost-, time- and income analysis, 3. Decision making assistance for the local authorities in planning a big regional hospital development project. Covers a cost- and financial analysis. All cases are performed, using the guidelines of the step-by-step principle and simple computer programs supporting successive calculation and successive scheduling, developed by the Department of Building and Construction Engineering at the Norwegian University of Science and Technology. Each case highlights some of the success factors in handling uncertainty in project planning and decision-making. Case 1: Telecommunication product development This is the story of a typical situation where the risk analysis expert is usually called for. The project is big and strategically important to the company, the product is complex, the market enormous but uncertain. The project had been developing too slowly over a period and problems had occurred. At the time of the first risk analysis, a traditional cost-focus was implemented in the project organisation, together with the typical new-technology focus of the Telecom business. An external risk analysis expert was invited to perform a risk analysis of the

124 Klakegg CASE 1 Roiect. company: P10lectCost: Project rceduie: Phase: Malumiylevel:

1 2 3 4 5

Telecom product develolxnent. nternatlonaimega-company wim a Norwegian branch. 65 dl.NOK 1 E 5.9 mlll. 2.5 years. Design. Low. Wsk onabsk prformed when p & m s occur. Cost anaNsls and tlme anoivsls over

t rceduiw Maturetv M

-

l

Unn intsgronon %ern integrab Technical can&& /_I ~ockof comGtence ihtegraticnof parallel developm. CiGG

40 km of ncw rairoa barveganrawom a t & . a p p w 3 ~ I I LNOKI5 273 mil. oppox 9 years Concepl phase Low. Rbk manogementPerfomEd oniv In exiwreh, cmlcal prcjects Decls~on making. Cost. Income and lime onahrsis

Rlsk ploflle (Cost1 2 3 4 5

Bas tor pbrmlng 'he ptqect cxgamatbn Comptence hhouse TecMlcal comWdIv

7 External d e c l h making

_--i

8 Culhlralelements in the organlsotion MolnRisk respcnces: - l m n o e ~bnninaand ODtlmizatbnci schedule. route key people ~&mpetence,copodty). - Make t~met a d6cussng ledmcnl pcoolems K, groups . Make shul.I'Y 01main rules for coord~notianand ulilizonon

11

Rlsk responces: None ofllclaUy MenMled

-

INSanohrslswas peflormed a$o one-the even!. suppoltlng the pdmcol aeclrion regard ng cholca of

-CASE 3 Prolect: Company: Project cost: Project scedule: Phose: MatUreNlevel: Anaws:

(

A new reglonal horptlal. Regional hospitalproject 3.4 billion NOKI E 309 mill 13 years Cancepl phase/ FearjbiliWstudy Hlgh. RiiK manogement through the prom-phCS%. Cost analyrls, Financhi snows.

Risk profile: (Costl

4 Bas~sfor cakulatlon requlrem

5 b 7 B

I Fig. 4.

Cost of bulldlng ConCCptIpnvScd solution

Fhcmc~cll rnoue~ con ot rehablPtatbn

-

3 J

-

U

Man RU resmnces i u ~ on s the organisdiono development pmpd hegotioflcnsconsmhg pan-flnonnng by the note. - Lobbykg for fovord polmcoidecidonr. - Estdlaha pcofecclonalcilent-organlsatlon. -involve end-usersIn the development profess.

:

I

Comparative key information from the selected case-stories

project cost with the argument that the project seems to be too expensive. At the time there was some technical problems and uncertainty about competence of the development department. The project was also behind schedule. During the planning session, it became very clear that development cost, although uncertain, was not the real problem of the project. The analysis revealed that the project organisation had strong doubts about the projects priority within top management of the company. In addition it became clear that the project organisation was an organisation chart, not a team. The most important risk response identified by the resource group was steps to ensure the project high priority and full backing from top management.

Implementing the successive principle

125

The result of the analysis and the steps taken may have come as a shock to some, but it was a natural consequence of the conclusion of the analysis. The project was stopped. However, this intermediate phase was just a tool to get the project back on the track. It was started again after a short period, with a new project manager, new technical specifications and a more precisely defined scope, including a strong declaration of priority from the top management. The target cost and deadline was not altered. The project organisation came out of this process as a stronger and more independant team. The probability of success was dramatically improved. Almost a year later, the project was falling behind schedule again. Therefore, the risk analysis expert was called in once more. This time to do a time-analysis of the project schedule. The analysis was performed according to the same guidelines as the first analysis. Even though a year had gone by since the last time, the resource group shown a tremendous improvement in skills through the planning session. The learning effect of participating in such planning sessions is enormous. Also this second time, the resource group was very happy with the planning session, but not with the conclusion to the analysis. The risk profile is shown in fig. 4. The risk analysis show that the project organisation was not performing real planning. The planners where building schedules according to top management guidelines, in a quite bureaucratic style. However, they where actually performing the project in a totally different way. There is a great need for cross finctional co-ordination and co-operation between different sub-projects. After the risk analysis, every sub-project responsible planner was re-scheduling all activities, taking this cross finctional needs into consideration. Again, the risk analysis was used as a tool to make dramatic changes in the project. These processes was very usefil for the project and the company. However, they did not represent an optimal use of risk management. The risk management should have been implemented from the start and performed frequently throughout the phases of the project. A lot of energy and motivation would have been better utilised if the risk management had been integrated in the project process. This would have made the project management able to make small adjustments instead of having the whole project turned upside down. Case 2: A new railroad

In this case the successive principle was used to support the political decision of choosing main line for the railroad at a very early stage. A large number of different lines was proposed and the planners had made a traditional report comparing the different alternatives in main technical solutions, implications and investment cost. Four of the best alternatives was analysed to use the uncertainty of cost, income and time. The document study, the planning session and analysis as well as the report had to be completed in three weeks by the university staff at NTNU and the co-operating researchers at Sintef This time-pressure was a great challenge to the quality of the analysis and had to be met with some risk responses: Firstly, it meant we had to focus a lot on the conditions under which the plan was made and the basic assumptions concerning the fiture project, not to the technical problems involved. This was a very important and correct choice, allowing the analysis to concentrate on the most important aspects of the project. The planning

126

Klakegg

session was, in this case, totally concentrated the conditions and assumptions built into the project plan. Cost and time data was supplemented by the researchers at a later stage. The main goal of the planning session was to make sure all the researchers and the railroad authorities had a similar and complete understanding of the situation. This was a step of quality assurance in the analysis work. It also speeded up the process. Secondly, we had to use only the best and most experienced researchers in the work with the analysis. This was the necessary precaution when there was not enough time to check everything and no time for the conclusions to mature. Bringing in more people would only slow down the process. Simply giving the process more time would open for better quality at lower cost. Everyone knew the main uncertainties even before the analysis, but during the discussions in the planning session the risk analysis made the participants realise why, how and how much. Based on the common understanding established in the planning session, the researchers performed the three analyses more or less independently in parallel processes. This is the real benefit of the systematic approach. The most important finding of the whole analysis was that the different planning activities performed before this analysis to a great extent was based on an inconsistent basis. Every part of the plan had been allowed to optimise its basic assumptions without consequences for the others. Using the successive principle in a similar way as in this case, this kind of problem in planning would be avoided. Case 3: A new regional hospital In this case the successive principle was used in developing the project organisations strategy for negotiating the financing of the big, new hospital project. The project is the biggest hospital development in Norway and represents a continuous process for 13 years to come. The project includes building a completely new hospital concept where there is an old hospital today. However, at this early stage the project is defined as an organisation development project not a building project. The hospital has to be organised in a totally different way within the frames of the future hospital. This seems to be a bigger challenge to the project organisation than the building-process. The scope of the analysis was to analyse the uncertainty of investment cost, and to give advise about project margins. This was a specially challenging planning session because of the big number of people involved and the complexity of the project. A lot of effort was made in preparing the participants before the session started. This proved very usefbl. The session was very efficient and the participants made it clear afterwards they experienced an increase in understanding for the cost of the project and the complexity of the situation. By focusing on the complex interfaces in the planning session, the basis for cost calculation and for negotiating the financing was dramatically improved. The result of the analysis shows that the organising still is the most uncertain element of the project. At this early stage, it is natural to think that external factors in politics and society will change trough the long development period. The importance of this is also illustrated by the results of the analysis. These elements are more uncertain than the cost of the building work itself This has a strong impact on priority when it comes to defining risk responses. Usually, the most obvious elements and the factors most easy to handle are

Implementing the successive principle

127

the ones in focus. The successive principle offers the best tool of priority available in processes like the one in the case. An important result of the analysis was the quantification of a correct project margin. In a huge project like this, wrong determination of project margins can be the sure track to disaster. By performing a risk analysis of the project cost, using the successive principle or other risk management methods, a well defined and trustworthy project margin can be established. Success is a result of systematic work. Half a year later the project owner wanted to perform a planning session to investigate the consequences of the project to their over-all financial situation. Inspired by the success of the first planning session, the client and the risk analysis expert humed into a rush-performance. In less than a week, the conclusion had to be established because of the political agenda. There was no time for preparing the participants or questioning the scope of the analysis. A lot of effort was put into simplifying the complex picture of the financial consequences into a simple and visual model to use in the analysis. During the one day planning session we experienced the following problems: Some of the participants did not accept the scope of the analysis. The participants where not sufficiently prepared. Only those with experience from the first planning session was able or willing to contribute. Two external consultants, invited because of their relevant, special competence, obviously saw this occasion as a selling opportunity. They repetitively obstructed the process, rejecting the questions asked by the moderator. This should have, but was not, stopped by the client. The simplistic analysis model was possibly too simple for the participants to recognise. Using a simple model for an extremely complex problem is taking a risk. The participants represented the most important parties involved in the project. The project organisation, the owner, the existing hospital organisation and politicians where present. Most of them had very strong preconceptions of the situation. In this situation, with some of the most important decision makers present, they saw this occasion as a possibility to put forward their arguments, not to shed light over the situation. No wonder this planning session and the analysis failed. Almost every rule of the Successive principle and the Step-by-step principle was broken. The analysis and risk response development always has to be planned and performed in a systematic way, taking into consideration the situation in the project, its surroundings and the people involved. This is no different than in every other kind of project work. Breaking this rule is always leading to fiasco. Quite unnecessary but very usual. Like any other tool, the successive principle may be misused. For the project organisation, the use of the successive principle and its implementations are still an important part of their development strategy. Used in the right way, it has proven to be a strong organisational tool.

128 Klakegg 6 Conclusions

Together with experience from a great number of cases in co-operation with the Norwegian Road Authorities and others, these cases improves the basis for understanding and implementing the successive principle as a management tool. Some of this experience can be summarised as follows: The real problem in implementing risk management is not the difficult theory, not the tools, but the culture and the organisational behaviour. To ease the implementation of risk management, it is wise to choose the easiest and most practical methods and tools available. The Successive principle is the easiest to understand and use. Simple models and analysis are easier to understand, and thus, easier to support with good estimates for the planners and easier to trust for the decision makers. This is more important than the apparent accuracy of more complex models and analysis. Implementing new ways of working calls for introducing relevant internal guidelines, pressure from top management and increased knowledge and consciousness in the organisation. To achieve this, there should be someone within the organisation able to be a moderator and to give support to colleagues. Risk management has been, and still is, often introduced as a tool only for handling problems. Examples are the Norwegian Standard for risk analysis and the British Standard ((Guide to project management)) [7]. By focusing more on the positive possibilities in the future, risk management is more complete, balanced and valuable. The best strategy for selling risk management is to make the planning an interesting and successful event, giving good results. The results proves the quality. Integrating the risk management principles with the project planning and other management activities has proven to be a difficult thing to achieve. Experience with the successive principle and its applications, seems to suggest we are close to a possible break-trough. The successive principle and its practical approach to risk management has the potential to give risk management a break trough in everyday life of projects. 7 References

1. Project Management Institute. (1996) The guide to the Body of knowledge. Upper Darby, USA. 2. Klakegg, O.J. (1994) Zhe step-by-stepprinciple. INTERNET'94. Oslo, Norway. 3. Lichtenberg, S. (1990) Projekt planl~gningi en foranderlig verden. Polyteknisk forlag, Lyngby, Denmark. 4. Chapman, C.B. (1996) APM Risk SIG Working group PRAMguidelines. UK. 5 . DnV Industry AS, (1995) Criticality management tools, concept and models. Oslo Norway. 6. Kilde, H.S. and Torp, 0 . (1996) Usikkerhet som styring~parameter.Project 2000, Trondheim, Norway. 7. British Standards Institution. (1996) BS 6079 : 1996 Guide to project management BSI, London, UK.

Project risk management and organisational learning J.F. WRIGHT Det Norske Veritas, Hgvik, Norway

Abstract The CMT (Criticality Management Tools) project is a major development of a risk management system, which now is about to be implemented in several acquisition projects in the Norwegian Defence Authorities (NDA). The implementation of a risk management system, meaning that it shall serve its intended purpose and actually be used, is by no means a trivial task. One of the reasons for starting the CMT development in the first place was to improve the ability of the NDA to manage risks in projects. The development of the systematics and procedures, and the tool development, are probably less difficult compared to the challenge of making it work in projects and line organisations. Some of the critical factors for a successful development and in an organisation will be discussed in the paper, as they have been experienced through the 3 years development period and the 5-6 pilot project applications so far. The CMT development project will be finalised in February 1998, and the implementation of the system will then be on the agenda. Some of the problems experienced during the development and initial pilot applications in the CMT project were of a more principal nature. They prompted ideas and solutions that were used in the design of the PRM system, following the simple logic that if this could happen to us, it can happen to other projects as well. The problems ranged from "When there are no end users" to the human tendency to underestimate or avoid uncertainty. Common to all the problems were that they could have been significantly minimised or solved earlier if the participants in the projects had been trained in action science and organisational learning, thus increasing their communicational and problem solving abilities. The need for such abilities will be even larger when the system is to be implemented in the end user organisation. Managing Risks in Projects, edited by K. Ktihkiinen and K . A . Artto. Published in 1997 by E & FN Spon, 2-6 Boundary Row, London SEl 8HN, U K . ISBN: 0 419 22990 6.

130 Wright 1. Introduction

The objective of the CMT (Criticality Management Tools) development project Ill is to develop a project risk management (PRM) system for both the Norwegian Defence Authorities (NDA) and Aerospatiale Missiles (ASM), a French defence developer. Some of the critical success factors for PRM tool development and implementation will be discussed, as they have been experienced in the CMT project, covering 3 years of development and comprising 5-6 pilot project applications so far. The focus will be on lessons learnt from the interaction between the development and the pilot applications, providing experience useful for the future implementation of any PRM system. Because there were no risk management function established at the client user organisations, the CMT project had to rely on experience feedback from pilot projects where an 'artificial' risk management function was established. The development of project risk analysis methodology and support became more challenging than expected due to several factors or problems which will be described in the following. However, this experience was actively used in the design process to enrich the PRM system because the problems we experienced could also happen to other projects. Since the next phase in the CMT project deals with the implementation of CMT in the end user organisation, some of the lessons learnt or problems were are also discussed with that in mind. To make the CMT risk analysis procedures and tools a successfi~lpart of a larger risk management information system is not a trivial task. It requires a definition of roles and responsibilities, the establishment of a risk information system and last but not least, an understanding and acceptance of risk at all levels in the organisation. The implementation and operation of a risk management system must consider all these factors, and during that implementation process, the organisation is most likely to change. A short overview of the CMT system will be shown in the following, before the development process and the pilot application experience highlights are presented. 2. Project risk analysis In the CMT system, project risk is either defined as the expected deviation from project objectives, or related to the uncertainty associated with the objective outcomes. The first definition is used in the CMT Standard mode, while the advanced mode takes the full uncertainty as well as the interdependence between risk causes (hazards) into account. The standard mode disregards uncertainty, as it - for each hazard - only considers the typical value of the severity of the deviation and the typical or mean probability of occurrence for that deviation. Typical objectives are cost, schedule and performance, but any objective may be defined. Cost and schedule are often referred to as programmatic, while performance relates to how the developed product will behave during its operational phase. Sometimes it may be beneficial to split the performance objective into performance for specific functions, like (for defence systems) range, signature, reliability, impact, etc. The following scenario based logic can be used to explain some central concepts:

PRM and organisational learning 131 A project is executed in order to achieve certain

project objectives which are defined in terns of schedule, budget, performance of system developed, etc. A deviation from achieving the target objectives is defined as a consequence. A risk scenario starts with project hazards which may lead to consequences measured as outcome severity and probability of occurrence. This measure is called risk and is used to categorise the effect of each hazard into risk classes in order to decide whether to ignore, monitor or mitigate the risk(s)

The above (chain of) events and conditions are the 'building blocks' of project risk scenarios. Note that for the action part (monitoring or mitigating), it may be necessary to identif) the most important risk contributors, which of those that can be influenced and the associated cost. This is performed directly (manually) in the standard mode, represented in risk matrices, with and without the effects of actions, and in the advanced mode calculated as probability distributions and presented in e.g. tornado plots. 3. Lessons learnt from PRM pilot projects 3.1 When there are no end users The pilot projects served two main purposes, the primary one was to feed back design changes and new ideas to the development team and secondly to prepare and motivate the end users for a later, full implementation of the CMT system. End user involvement is really a key issue when decision support procedures and SW tools are to be developed, and that is true also for PRM systems. However, in the CMT project, there were no end users available when the project started because project risk assessments were not camed out in the client organisations, consequently the PRM function had to be introduced to selected end users. Existing defence projects were therefore asked if they would serve as pilot projects as a testing ground for how to carry out the risk assessment and for how the risk management and risk documentation system should be designed. The start of the pilot projects was however delayed by almost one year, and it was difficult to get sufficient time from a busy project manager. It was not until people who themselves had been end users, i.e. former project managers, were employed and made part of the CMT project team that the pilot projects started to function as intended. When the pilot projects gained momentum, at the end of the prototyping phase, a significant improvement in the feedback reports took place. A selected and 'processed' sample of feedback information is described in the following. Looking back at the process, the major lesson learnt was probably that we were not able to get the pilot projects started early enough, resulting in an inappropriate prototyping process that did not get the necessary guidance and corrective feedback from real use.

132 Wright 3.2 Information sensitivity

One crucial feedback to the development team from the pilot projects was the sensitivity of the information related to project risk and its causes. People seemed toa be very much aware of the fact that risk information could be misused by, not only the other contractual party, but also by people belonging to the same organisation as the project. In the latter case, the assumption could e.g. be that your chance of getting a promotion was reduced if it became known that you had trouble in your project. Risk information was especially sensitive (and therefore valuable) in re-negotiation of contractual elements, e.g. a change in the requirements. This lack of openness was experienced also in the CMT project, as it at times became difficult for the development team to get information from the pilot projects because confidential information had to be censured before distribution. Although there is reason to believe that risk information will be sensitive to a certain degree, it is likely that the sensitivity of defence projects is higher than civil projects. We also experienced an even higher secrecy at the contractor pilot project than at the N D 4 presumably because they were afraid of the possibility that information could reach competitors and customers. 3.3 Simplification Another important feedback from the pilot projects was the need to simplifjr the risk assessment approach. The project managers - and those who had previously been project managers but who now were engaged as field practitioners, were sceptical to the applicability of the first prototype version of CMT. Initially, CMT was based on a full probabilistic risk assessment using influence diagram methodology. Certain concepts were difficult to understand for people with limited or no training in statistics and probability theory, and when you do not understand a process, you become sceptical to the results produced. So, we needed to simplifjr the approach. That became the birth of the standard mode of CMT, where uncertainty and complex relationships where removed from the assessment process. In the standard mode, project hazards were subjectively evaluated with respect to their consequence severity and probability and risk level illustrated by plotting the hazards in a risk matrix. When the standard approach was introduced, there were some resistance among the risk analysts and mathematicians who had introduced the advanced method. They were of the opinion that the very meaning and 'soul' of risk analysis had been removed, and that what was left was so trivial that it had little value. So there emerged two types of 'camps' within the CMT project, the developers and the field practitioners. The tension between the two was at times a bit high, but there are signs that it also will serve as a source of new insights if proper conditions for learning can be arranged. 3.4 Development process The CMT project was originally planned as a traditional, 'waterfall' development process where the user requirements were to be identified (from non existent end users!) and then converted to a design and solution specification which should be implemented, partly as procedures and partly as SW. There was a strong pressure from the clients to apply this development process, which was eventually accepted. And we were thrown out into the white waters... As it turned out, a traditional process may work for the development of a system that can be specified in detail in advance. It works less well for

PRM and organisational learning 133 a system whose details are only partially known, whose environment and technology are rapidly changing, and where there are no end users at the time when you need them the most, i.e. when the user requirements are to be defined. Lots of resources were spent initially during the requirement specification phase to identifl user needs and describe these as functional requirements. But because PRM was not practised by the end users, it was difficult to specifl what they actually needed except in rather general terms. The specification became quite useless for the development team, especially that part which was related to the risk management process where the future PRM work situation of the end users stands in the focus. The situation was somewhat better for the specification of the analytical steps and calculation algorithms as these are of a more logical than social nature. In order to mitigate the fact that there were no established practise from where the requirements could be derived, the traditional development process was 'softened' with a prototyping approach, and the pilot projects were established to arrange for end user involvement and education. We never managed to correct the development process completely, so we had to live with a hybrid model. In the following period, considerable resources were used to remove redundant requirements, to establish how they should be interpreted and to maintain the traceability to the original requirements. The conclusion is that it is extremely important to choose a development process which is compatible with the 'specificability' of the system to be developed as well as the level of competence both in the development team and among the end users. To put it simply: we should have done it the other way around - we should have started much earlier with pilot projects and real prototyping, and then prepared the specifications and then the SW development... A crucial questions is therefore: why did we not do it the right way? Looking back, there were several signs that a change was needed. However, the rigidity of the development process, the shortage of time combined with conflicts or differences of opinion popping up now and then did not constitute a condition where it was natural to stop and re-think the whole process. 3.5 Hidden agendas There are two clients in the CMT project, one customer (purchaser andlor user) and one contractor (developer), in other words they usually sit on each side of the table. In the CMT project they are sitting on the same side, as customers. But their use of the CMT final product will be as customer and contractor, respectively. The picture is even more complicated. DNV is a developer of CMT, but we are also a customer because we invest about 12% of the budget and we plan to use CMT in our PRM consultancy services afterwards. To further complicate the picture: There are two organisational units from DNV involved in the project, and one unit became engaged in the development and the other in the pilot projects. Remember the two camps? The result of the organisational complexity described above was that the different CMT players had partly overlapping, partly conflicting motivation for their participation in the CMT project. These differences are normally not expressed openly, and they he1 conflicts which tend to pop up, in particular at times when new activities are started or when a change in requirements and priorities are requested. Again we assumed that this was not a situation only experienced in our project. If we had experienced hidden agendas and motivational conflicts, it is likely that other projects have experienced it as well. In other words, we had run into a project (meta) haz-

134 Wright

ard. This led to the development of a separate module in CMT, where the objectives and motives of three players were to be identified and expressed openly: the customer, the contractor and 'the environment'. The environment is related to international standards and agreements, national laws and regulations, etc. During this step of the CMT process, called 'CMT Initiation', it may be necessary to train the representatives of the customer and the contractor in team building and organisational learning principles and practise. Concealed motives and hidden agendas can thus be surfaced, discussed, modified if necessary, and resolved in order to amve at common, agreed objectives for the project. 3.6 Uncertainty avoidance

As mentioned above, the strong adherence to a well defined waterfall and requirement driven development process even though it was not possible to specifj, the most important aspects of the end product puzzled us. Another strange effect was also observed: certain requirements related to details like the size of the hard disk, the type of CPU, etc., were stated with accurate values. To fix the specification of such items as long as four years before the system was to be delivered is really strange, regarding the fast changes taking place in the information technology industry. Even though such peculiarities were pointed out, the resistance against changing them was large. Whenever you experience a paradox, a good rule is to inquire into the perceived understanding of those who live (happily?) with the paradox and then compare what they say with facts from human psychology. It turned out that the reason to stick with the waterfall process was that they believed it would increase the possibility that the CMT project would succeed. And yet the exact opposite would have been the result. So much for the assumptions, then what does psychology tell us? It is a well known fact that humans have a strong tendency to engage in tasks which are familiar and to underestimate and even avoid uncertain issues. This tendency is so strong that we seem to invent a false certainty, and feel better with that than to face and live with an expressed uncertainty. And if you are allowed to continue to conceal uncertainty, you do not develop behavior which are functional and instrumental under uncertainty, an ability which is extremely important and much needed in risk management. We were developing risk management systems, and was confronted with this. Did I mention a paradox? This led to another lesson learnt in the CMT project, because if uncertainty avoidance was the case in our own development project, it is likely to also be the case in other projects and thus constitute another project 'meta' hazard. The limited use of project risk analysis, and the often too optimistic project plans are indications of this. Even a survey of existing PRM methods and tools confirmed that the hazard identification part of the PRM process was not given much attention, and sometimes even neglected totally. And that is where you lay the very foundation for a good uncertainty analysis. PERT techniques, where schedule uncertainties could be estimated as a function of the activity network and optimistic/pessimistic start and end dates, were no exception. Uncertainty was calculated without taking into account the factors (hazards) that caused the uncertainty, because rarely the question of what could cause a delayed start of an activity was raised and taken into account in the risk models except at a very superficial level. The uncertainty analysis became a function of start time guestimates and activity slacks only. How the optimistic and pessimistic fi-actiles were to be estab-

PRM and organisational learning 135 lished did not get much attention, at best it was voted by an expert panel or risk review board in a setting often vulnerable to the cognitive bias' well known in literature 121. We therefore decided to design a CMT module called 'Hazard Analysis' which was based on a survey with almost 30 experienced project managers. They identified more than 90 different project hazard they had experienced, as a threat or as a reality. We then incorporated these hazard into CMT as a computerised check list which can be used in the hazard identification step. Furthermore, the most important of the hazards were modelled in risk scenarios (influence diagrams) and made available in CMT as a generic risk scenario library. Based on selected objectives, the CMT SW tool will search the database and propose generic risk scenarios which then can be further customised, e.g. by adding new hazards or changing parameter values. The work process involved in the Hazard Analysis step requires an open discussion of issues which often may be considered sensitive, especially if the previous CMT INtiation step (where all objectives and motives were to be surfaced) was not carried out properly. The same argument can also be applied for later steps in the CMT process, like 'Action or Countermeasure Analysis' and 'Post Implementation Evaluation'. They both require an open participation by different people who may regard confidentiality a more important issue than shared information. We concluded therefore that it was extremely important to set the stage for an open communication and organisational learning attitude as early as possible in the project. This implies that risk management should be a part of a project from its beginning, and that the human element should be on the agenda from the first day. 4. PRM implementation in the defence organisation A continuation and extension of the pilot project engagements shall form a smooth transition into the implementation of CMT. The pilot projects carried out so far has been a success in the sense that the project managers are satisfied and there are several other defence projects which now volunteer to become CMT pilots or who wants PRM support based on CMT. So, if we gradually increase the number of pilot projects, we will eventually have implemented CMT in the NDA. This is however a high risk situation. We need only one real pilot project failure and the 'rumours' may shift from a success story to the opposite. The demand for our service can easily exceed our capacity, and then our initial success can turn into becoming the very reason why we may fail. Why? Because we may have to use inexperienced people, we must work too much overtime, etc., factors that increase failure probability. In fact, the more successful we have been, the more likely it is that we may fail. Another paradox. Considering the further basis for implementation, it is natural to build upon the experience gained during the pilot projects on issues like the risk manager role and responsibilities, the risk information review system and risk manual. These are technical matters, and are not likely to constitute any difficult problem. The situation is quite another one when it comes to prepare key personnel of the end user organisation so that they can contribute in an active and positive way to the various steps of the risk management process. It is exactly at this point where the implementation is most likely to fail, because to train people in the communication skills required is not a trivial task. It is

136 Wright

probably not easy to teach people open communication and sharing of ideas and information in a culture entrenched in the 'need to know' principle, after all, defence systems have to be secret, and the personnel trained accordingly. Or may be it is exactly in the defence community, where the awareness of confidentiality is sharpened, that an understanding of the need to know in a risk management context can be more easily established than elsewhere? A paradox does not have to be negative.

5. Obstacles ahead The consequences of an implementation failure can be very serious, and the most serious one (except that project risk management will not be in place) is related to the reinforced resistance in both line and project organisations that most likely will occur. If PRM becomes just another management theory fad, it may then go many years before it makes sense to try to implement risk based decision making again. One crucial factor which may reinforce defensiveness is the possible (mis)use of risk information in a way which can be experienced as negative to the information provider, or the risk or project manager. If there is fear that risk information will be used against the camer possibilities of anyone, cover ups are likely. Also, if risk information is used in a portfolio context so that high risk projects are more likely to suffer budget cuts and even termination, then people will refrain from giving other access to risk information. Over time, this attitude will strike back to the risk management process itself, because risk information then becomes a hazard to the project. The result can easily be that defensive routines are activated and used to protect aginst exposure to uncertain information. Risk avoidance and even denial may then be the result. 6. Conclusions

Although the development of PRM systematics, procedures and SW tools were difficult due to the lack of an existing practise, to make it work over time in projects and end user line organisations is probably even more challenging. Thus. the implementation of PRM in end user organisations makes it necessary to shift the emphasis to other professions than those who played a major role in the development. The shift implies a change from software design to organisational design. The lessons which were experienced in the CMT project, and described in section three above, all seem to share one common factor: the problems could have been significantly rninimised if the participants had been trained in communication skills and team building /y/ as part of the project. And if this was the situation in the CMT project, it may also be the case in other projects and therefore relevant to project risk management. The establishment of a learning or rather inquiring attitude and openness to new experience may therefore be a necessary prerequisite for a successful project, at least when the requirement and specification process is demanding. And it is the proposition here, that organisational learning may also be a prerequisite for a successful risk management process. Organisational learning or Action Science, a discipline which started

PRM and organisational learning 137

more than a decade ago at the universities of Harvard and MIT /3,4,5/, provides probably the best practical approach to acquiring this type of skill and understanding. In addition, it may be helpfil to improve the understanding of the interplay between personality based differences I61 and the relative importance of different team roles 171 during the phases of a project. That may make it easier to explain why changing e.g. the project manager is necessary when the project enters into another phase because other abilities become more important. It is however crucial that the assessment of individual differences does not enter into conflict with the organisational learning process, as personal information is rather sensitive in nature. The fear of it being misused is always there and can thus lead to defensive reactions and reinforce the opposite of an open, inquiring attitude. Maybe it is only when a positive attitude to risk is established that risk management and organisational learning can become a reality. One step in the right direction is then to teach people to accept uncertainty, meaning that a high risk project - if the up- and downsides are balanced, is also a high value project. Then it may be possible to introduce attitudes and values which can promote information openness and the inquiring attitude so essential for organisational learning to occur.

7. References 1. 2.

3. 4.

5. 6. 7.

Wright, J. and Canal, C. (1996) CMT, an innovative system for project risk management, '96 World Congress on Project Management - IPMA. Kahnemann & Tversky. (1982) Judgement under uncertainty: Heuristics and Biases. Cambridge University Press. Argyris, C. (1992) On organisational learning. Blackwell Publishers Ltd. Oxford UK. Senge, P. (1990) The fifth discipline. The art & practise of the learning organisation. Currency Doubleday NY. Senge, P. (1994) The fifth discipline fieldbook. NB Publishing Lmt. London. Wright, J. and Lindgren, R. (1996) Competence evaluation in risk management. ESREL '96 - PSAM 111, Crete. Belbin, M. (1993) Team roles at work. Butteworth-Heinemann, London.

Integration of subjective judgements and historical data E. CAGNO and F . CARON Department of Mechanics, Politecnico di Milano, Milan, Italy

Abstract The application of risk analysis methodologies to evaluate possible delays in project completion is tending more and more to become an essential prerequisite for project management quality. Since projects are non repetitive processes, historical data are scarcely usehl and subjective judgements constitute the main source of information on the different factors influencing project development. For predictive purposes, the integration of available historical data - which is inevitably limited by the uniqueness of projects - and the subjective judgement of specialists based on previous experience in similar projects is, therefore, an inherent issue in the project management process. The paper proposes a systematic methodology to collect and integrate the input data needed for simulation analysis by means of specific tools, such as questionnaires, event-trees and bayesian inference. The methodology aims to obtain effective estimates of the duration of elementary activities, in order to evaluate the probability distribution of project completion time. It is applied to a real-world case of practical interest involving the planning of a project concerning a process plant. Keywords: Project time uncertainty, project risk, integration of subjective judgements and historical data, questionnaire, event-tree, bayesian inference, simulation. 1 Introduction

As projects are non repetitive processes, risk is always an inherent feature. If in manufacturing the exhaustive definition of the final product and of the corresponding industrial process is a prerequisite for the start-up of production, in projects such a definition is an output of the production process itself Only when detailed engineering reaches a considerable level of progress, does a sufficiently complete description of the final product configuration and of the production processes needed for its realisation become available, so making a sufficiently Managing Risks in Projects, edited by K. KtihkOnen and K.A. Amo. Published in 1997 by E & FN Spon, 2-6 Boundary Row, London SEI 8HN, UK. ISBN: 0 419 22990 6.

Subjective judgements and historical data 139 approximate estimate of realisation time and cost possible. Any proposal by a potential contractor inevitably involves a considerable amount of uncertainty, as only limited preliminary results of basic engineering will be available or, at best, historical data related to previous, similar experiences. In general, the typical leverages of project management (work breakdown structure, quality assurance procedures, network techniques, cost/schedule control system, etc.. ..) are actually prevention or protection tools able to provide advance indications of the different constraints on project development which may cause deviations in plans [1,2,3]. In this respect, the application of specific methodologies of risk analysis involving the identification and evaluation of major risks in terms of the probability of their occurrence and their consequential severity, tends more and more to become an essential prerequisite for project management quality. This results in a number of advantages to be obtained, such as: availability of more realistic plans with regards to both time and cost; better support for decision-making process; choice of the most appropriate contractual terms; opportunity to collect historical data on project risks; opportunity to evaluate project performance in the most realistic way, highhghting management quality of the project aside from effects caused by exogenous variables, such as, for example, constraints stemming from proposal and negotiation phases. In complex projects involving industrial plants, for instance, potential contractors need ever more frequently to develop specific project risk analyses involving the evaluation of the probability achieving of predetermined goals, especially with regards to time. Suitable risk management policies to limit risk right from the preliminary project phase are necessary. Possible goals of risk management might, for example, be: risk reduction by means of prevention and/or protection actions; risk avoidance by means of project re-engineering; contractual limitation of risk; risk transfer by means of subcontracting specialised firms; risk transfer by means of insurance; risk assumption by means of contingencies. In general, project risk analysis is based on the forecast of possible development trends in projects deriving from uncertain internal andlor external factors. The recourse to simulation techniques broadens the flexibility in the representation of the project system with respect to analytical techniques. In fact, the simulation model can analyse the effect of input variables (decisional and exogenous) with any kind of stochastic distribution, on output variables (performance) related to the former by any logicalmathematical relationships. Project "time" risk analysis aims particularly at estimating the variability of completion date with respect to the variability of the duration of network activities. In this context, the usefblness of results obtained by risk analysis strictly depends on the reliability of the input data [4,5]. Taking into account the nonrepetitive nature of projects, estimation of the variability in the duration of network

140 Cagno and Caron

activities can not be based on anything but the integration between available historical data - which is inevitably limited by the uniqueness of projects - and the subjective judgement of specialists. This approach is an inherent issue in the project management process, since any new information allows the initial estimate based on preliminary assumptions to be adjusted. This issue can be addressed with recourse t o the bayesian approach. The frequentist definition of probability has been criticised with the objection that the repeatability postulate - on which the classical definition of probability is based - is, in fact, never satisfied. In the so called bayesian interpretation of probability theory, the concept of probability as a measure of the degree of belief with respect to a particular event replaces that of probability as a limit of some "measurable" frequency. Probability is thus a measure based on the whole set of available information on the state of knowledge related to the event. This interpretation of the concept of probability allows two drawbacks of classical probability theory to be overcome: the theoretical impossibility of defining probability for events for which there is no set of trials, and the inability to change probability estimates on the basis of hrther information which modifies the previous state of knowledge. For instance, even if a sufficiently large sample of data on the duration of a typical project activity is available, the frequentist interpretation of probability theory does not allow the estimate to be modified on the basis of new information such as the introduction of a new technology for the implementation of the activity itself The use of a probability value drawn from data records, even when available, can be only taken as a reference and cannot be considered "true". With specialists' knowledge, both the differences in a particular project with respect to previous experiences, and the effect of specific project conditions on the probability of completion on time can be taken into account. However, the problem of how to update present knowledge (prior probability) in the light of new information, in order to obtain a probability value which takes account of the whole set of available information (posterior probability) must be addressed. In the bayesian approach, the probabilities obtained from specialists' judgements can be included in the analysis in a rigorous way [ 6 ] . 2 The methodology

The proposed methodology concerns the analysis of project time risk using a simulative approach and thus evaluates the probability that the project duration exceeds the contractual completion deadline. The methodology is divided into the following steps: definition of the logical structure of the project network evaluation of the stochastic distribution of the activity duration: - collection of historical data from records - questionnaires to record subjective judgements from specialists by means of - value terns (optimistic, most likely, pessimistic) - event trees - histograms - the bayesian approach to integrate historical data and subjective judgements simulation experiments analysis of the obtained results

Subjective judgements and historical data 141 The simulation model is described by the logical structure of the project network; the input variables of the model are given by the activity durations defined as stochastic variables with discrete stochastic distributions; the output variable is the project duration; the statistical analysis of the results involves the evaluation of the confidence interval of project duration and the number of iterations of the simulation model has been assessed with respect to the desired degree of confidence. The simulation model has been implemented using the Primavera software package "Montecarlo" [7]. 2.1 Activity duration To evaluate the stochastic distributions of duration, the network activities have been classified in four groups:

engineering; purchasing; sub-contracting; construction.

diwdblc

risk

Fig. 1.

efecr ~ I u m t G n Ofeach come and mregrabon

evol~-tlw

Methods to evaluate activity duration. Activity general classification. Acnvry ~nnovot#ve

consolldared

I

Fig. 2.

i

I Investigation of inner data records even without corrections with specialists' judgements.

Investigation of outer data records andfor outer specialists' judgements. Request for judgement fiom an inner specialist.

Data are abstracted from inner data records. Data presentation to a specialist in order to evaluate possible corrections

Collection of outer judgements, if available, and integration with inner judgements.

Methods to evaluate activity duration. Non-divisible risk inner activity classification.

For each group the risk factors influencing the activity duration have been highlighted. All the possible effects of such factors have to be forecast by describing the activity

142

Cagno and Caron

duration in qualitative terms with discrete stochastic distributions or by means of deterministic (single-point) values, if the variance aspects are, at least in a first approximation, negligible. According to the kind of activity and corresponding risk, different approaches can be adopted using specialists or firms' records. It is wise to consider only those time variance aspects which are a direct risk for the contractor and for which no contractual or insurance protection exists. In figure 1, an initial distinction between those activities carried out directly by the contractor and those for which other actors, such as suppliers or clients are responsible. 2.1.1 Historical Data The development of an effective risk analysis approach requires the encoding and the use of historical knowledge acquired during previous implementation experience. Allowing for the formalisation of company know-how is a fundamental prerequisite. It should be remembered that the use of historical data does not remove the need to proceed to a subsequent integration with subjective judgements. Every project is an implementation process that is hardly comparable in kind, dimension or geographic location to any other. Moreover, in engineering and contracting companies, the scope of the historical records is generally not such that the available data sample is statistically significant. Once the detail level of the project risk analysis is defined, the collection and recording of historical data can be standardised. If the level of detail of the analysis, the availability of detailed data is an advantage but at the cost of greater complexity in data management. In the case study, historical data for each kind of activity have been synthesised as a stochastic distribution of percentage deviations between the expected and the actual duration. Thus, these deviations describe the "historical ability" to forecast activity duration values. Using the historical data on the distfibution of the time deviations collected in the past for the same kind of activity, the risk analysis for a specific project can translate the deterministic (single-point) value of the initially planned duration for each activity into the corresponding stochastic distribution. Such a process can also be applied to a particular kind of activity by using the percentage historical deviations for a characteristic parameter of the activity which decisively influences its duration. In the construction activities, for instance, such a parameter is typically the productivity defined as the ratio of "earned" standard hours to effective hours spent to carry out an activity. The activity duration can be expressed as a function of a number of parameters, i.e., physical quantities to be accomplished, standard rate, productivity, availability of resources, working hours (table 1). Table 1. Calculation of the duration of an activity as a function of a number of characteristic parameters Quantity 1000 m' R Rate 1.05 rn3/shflI P Productivity 0.95 SMWhours M Men 5 men W Hours 8 hours/dav*man T Duration 25 days T=Q/(RaP'M*W)

Q

In the productivity parameter, the effects due to the occurrence of a number of uncertain events, such as weather, are taken into account. For each kind of construction activity the stochastic distribution of the percentage deviations D I P

Subjective judgements and historical data 143 between planned and actual productivity values can be drawn from historical data (table 2; columns 1, 2, 3). Thus a stochastic distribution can be obtained as shown in figure 3 (productivity histogram). Once the forecast productivity for the considered activity is known, the corresponding stochastic distribution of the forecast productivity can be drawn from the stochastic distribution of the historical percentage deviations (table 2; columns 4, 5). Then, assuming the other parameters required for the calculation of the duration are known and deterministic(tab1e I), the corresponding stochastic distribution of duration can be obtained (table 2; columns 6 , 7), as shown in figure 3 (duration histogram). Table 2. Distribution of the historical percentage deviations between planned and actual productivity (hPIP, historical data) for an activity, of the planned deviations with respect to planned productivity (AF', forecast) and of planned activity duration (AT, forecast) APE' (historical data) Probability AP (forecast) AT (forecast) from to from to from to -7.50% 4.50% -1.50% 1.50%

4.50% -1.50% 1.50% 4.50%

0.1 0.3 0.4 0.2

0.8788 0.9073 0.9358 0.9643

PRODUCTIVITY HISTOGRAM -HISTORICAL DATA

hkbilq

1

0.9073 0.9358 0.9643 0.9928

27.095 26.244 25.444 24.692

26.244 25.444 24.692 23.983

-

DURATION HISTOGRAM FORECAST

I

Robabl~ty

Fig. 3. Histogram of the historical percentage deviations between planned and actual productivity for a kind of activity and of the planned duration for an activity.

2.1.2 Specialists' estimates The subjective estimates from specialists are an indispensable tool to adjust stochastic distributions of activity duration to the characteristics of a particular project. A typical tool for the formalisation of specialists' knowledge is questionnaires. The important thing in the arrangement of a questionnaire is that questions have to be defined carefully, so as to be clearly understandable and enable the specialist to give a correct judgement. Table 3 is a tool to identify on the basis of the availability and reliability of historical data the most suitable approach to be followed in establishing the kind of questionnaire to be used.

Cagno and Caron

144

Table 3. Collection methods of specialists' estimates according to the availability and reliability of historical data Historical Kind of Are data Is a comment Are loops Questions examples data question communicated? requested? planned? Available Yes No No, because Historical data are given - as mean and reliable historical and variance, or as graph, the data are modification is reauested reliable Available Closed No Yes, if options Yes, in case The specialist is asked to give but not are insufficient. of weightings to the possible duration reliable remarkable or ranges of duration, drawn kom diversity to historical data be justified Not Open No Yes Yes, because The specialist is asked to elicit the available the activity is estimates of the most likely, innovative optimistic and pessimistic duration

In the case study, the specialists' judgements were collected using two different approaches. The first, concerning activities in which risk factors are not easily identifiable, the specialist is asked to give a direct estimate of the stochastic distribution of the activity duration. Again two ways have been employed. In the first case, the activity duration is described by triangular distribution on the basis of optimistic, pessimistic and most likely values, while in the second, three duration ranges (optimistic, pessimistic and most likely) are proposed, and a value of probability is associated to each of the proposed ranges. In both situations, the specialist is helped to think in a more familiar way without directly evaluating the stochastic parameters characterising the requested distribution (mean, standard deviation, etc.. . .). SUPPLY

SUFFICIENT

DAMAGE

WEATHER

CUSTOMS PROB. DURATIOA

U A r n

vcs 601

no 0

90%

favourable 0

100%

no 0

98%

no 0

yes ZO/"

90% a 10%

0%

0

90% 10%

10%

40%

Fig. 4.

15

15

..-.....-.......10 be continued

35

0,001 1

43

0

30

0

38

0

35

0

43

8

5

90%

0

ves ycs

0,0097

0

no

VdS

no

38

8

no

ver 2Oh

0,0529 8

no

no 98%

30

5 10%

no1 favourable

0,4763 0

1036

8

.............- to be continued

Event-tree related to transportation

The second approach concerns activities where risk factors are easily identifiable, and asks the specialist to give an estimate of the occurrence probability of well-defined elementary events. The information obtained is subsequently processed by means of the event-tree. This situation is shown in figure 4, in which risk factors related to the different phases of the transportation of a plant component to the site are sumrnarised

Subjective judgements and historical data 145 and the structure of the event-tree related to transportation illustrated. As evident in figure 4, two kinds of information are needed to construct the tree: the tree structure, showing the variables of interest and the kind of dependence the variables present; the probabilistic values of occurrence of the node-event and their impact (delay) on the planned completion time. Figure 5 shows the results obtained from information related to figure 4. The usefulness of the approach based on the event-tree is highlighted in the comparison of the duration distribution for transportation with the analogous distribution obtained directly by means of a questionnaire proposed to the transport specialist (figure 5). The event-tree methodology identifies a bi-modal distribution that was impossible to ascertain by means of the questionnaires alone. In fact, with this second approach, the specialist is asked to evaluate the elementary events with which he is acquainted without trying to extrapolate directly the overall time trend of an activity. Prob.

n -

0 50 0 40

Eventtree D~rectEst~mate

0 30 0 20

0 10 30

37

45

53

61

69

77

Tuns

Fig. 5. Comparison between the stochastic dstribution of the duration obtained by means of the event-tree and the specialist's direct estimate.

2. I .3 Integration of subjective judgements and historical data As previously stated, the application of bayesian theorem allows historical data and subjective judgements from specialists to be integrated. In the case study, historical data are used as additional information to modifjr the duration estimates given by specialists. The prior probability is the probability that the activity duration follows the distribution planned by specialists. The posterior probability is the actual probability of such a duration given the historical data. The likelihood is the probability that the historical data occurs if the duration probability is as evaluated by the specialist. By way of example, consider the set of data shown in table 4. Four specialists give their judgement of the probability that the activity duration falls in one of the three ranges optimistic, most likely, pessimistic - defined in the table 4.

146 Cagno and Caron Table 4. Integration of historical data and subjective judgements on activity duration by means of the bayesian approach Optimistic Most likely Pessimistic Range Range Range (60 - 69 days) (40 - 49 days) (50 - 59 days) Historical data Occurred cases 3 18 9 Historical probability 0.10 0.60 0.30 Subjective judgement Specialist 1 0.30 0.65 0.05 Specialist 2 0.15 0.80 0.05 Specialist 3 0.10 0.70 0.20 Specialist 4 0.05 0.90 0.05 Results obtained Mean of subjective 0.150 0.763 0.087 judgements Result of Bayesian 0.109 0.687 0.204 composition Correction -0.041 -0.076 +0.117

If nothing can be said about the "quality" of the specialists' opinion, the prior probability that one of the estimated values occurs is given simply by the frequency of the particular value in the set. The binomial distribution, expressing the probability that k events occur in n trials if the occurrence probability is p, is assumed as the likelihood hnction. Table 4 shows the results obtained for the three duration ranges and points out for each range the comparison between the mean of the specialists' judgements and that modified with historical data. As shown in this case, the specialists' estimates substantially confirm the probability value in the optimistic duration range, whereas the probability value in the pessimistic duration range is significantly reduced. The specialists have therefore introduced new elements of knowledge with respect to historical data (for instance, new working procedures, different geographical site for the project, etc.. . .), leading them to consider delays less likely. On the other hand, if only the subjective probabilities had been considered, the reduction in delay probability would have been too marked. 3 Case study

The methodology described above has been applied in the analysis of a real-world example of practical interest. A program of activities has been developed for a typical implementation project in an industrial plant of average complexity (a plant including an electric power production system designed to desalinate sea water and make it drinkable). The program has been developed from the WBS of the project by means of conventional network techniques using the software package "Primavera Project Planner". Altogether 924 activities have been identified and divided into four groups, placing together activities with similar problems and risk factors (engineering, purchasing, sub-contracting, construction). For each group, the risk factors have been identified in order to identify the most suitable means of data collection among those above-cited (data records, specialists' judgements, event-tree, etc.. . .) for each activity. The simulation of the project was carried out using the software package 'Montecarlo 2.0' [7] on a 486-33 MHz computer. The simulation lasted between 15 minutes and 2 hours, depending on the number of iterations (between 600 and 5000). With 5000 iterations, the error in the project duration estimate is 4%. These times confirm that the

Subjective judgements and historical data 147

simulation approach is suitable for real-world cases where the calculation time is negligible with respect to the duration of the project design phase. The data collection and analysis phases are, on the other hand, considerably more time-consuming. However, it should be noted that the case study is a prototypal application, as no previous experiences were known. Further applications will need less time, both because specialists become more acquainted with uncertainty estimates and because the knowledge base of historical data grows. The main result expected from analysis was the evaluation of whether the planned completion date calculated by means of deterministic techniques significantly differs from that obtained by means of risk analysis techniques. Figure 6 shows the project completion date (minimum (A), maximum (C) and expected value (B)) obtained from 5000 iterations of the simulation program and expressed in terms of the percentage deviation with respect to the solution of the deterministic network based on the most likely activity durations. The project completion time with a probability of 0.8 is given. The simulation gives an expected project duration about 6% greater than with that obtained with deterministic methods. This difference, even if small, shows how overlooking the uncertainties inherent in a structure as complex as a project can lead to the assumption of underestimated risks (for the contractor, the risk of running into penalties; for the buyer, the risk of a delay in the plant start-up date). Figure 7 shows the project duration distribution; from this kind of curves, given the risk level the contractor or the buyer are prepared to assume, the curves indicate the start-up date in a more realistic way. Moreover, the criticality index analysis of each network activity makes it possible to identifjr the activities which should be particularly monitored, in order to keep risk within pre-fixed boundaries.

A

B

C

80%

Dates obtained by means of simulation

Fig. 6. Project duration values obtained by means of 5000 iterations of the simulation program: (A) minimum duration, (B) expected duration and (C) maximum duration. The values are expressed as a percentage deviation with respect to the duration evaluated in deterministic way.

X p

'

:r F -

p

S'

z

p

'

2w X w

F

w

m

Days

Fig. 7.

Project duration mstribution obtained by means of simulation.

The problems concerning the application of risk analysis techniques in project management are not generated by mathematical methodologies or algorithms. In fact, the Montecarlo method and the other stochastic techniques cited above are now widely

148 Cagno and Caron

used. The capacity of present computers is also such as to overcome the traditional drawback related to the length and cost of data processing. Application problems mainly stem fiom the practical availability of reliable input data. The described case shows how the adoption of the subjective approach to probability theory allows both historical data and specialists' experience to be taken into account. References 1. 2.

3. 4. 5. 6. 7.

Thompson, P.A. and Perry, J.G. (1992) Engineering construction risk, Thomas Telford Services Ltd. Clark, R.C., Pledger M. and Needler, H.M.J. (1990) Risk analysis in the evaluation of non-aerospace projects, International Journal of Project Management, Vo1.8, No.1, pp.17-24. Hull, J.K. (1990) Application of risk analysis techniques in proposal assessment, International Journal of Project Management, Vo1.8, No.3, pp.152-157. Bowers, J.A. (1994) Data for project risk analysis, International Journal of Project Management, Vol.12, No.1, pp.9-16. Williams, T.M. (1994) Using a risk register to integrate risk management in project definition, International Journal of Project Management, Vol.12, No.1, pp.17-21. Raflery, J. (1 994) Risk Analysis in Project Management, E&FN Spon Chapman & Hall. Montecarlo 2.0 (1993), Primavera Systems Inc.

Exploring the value of project complexity beyond lump sum contracting P.W. HETLAND European Institute of Advanced Project and Contract Management, Stavanger, Norway

H.J. FEVANG Stavanger College, Stavanger, Norway

Abstract The paper explores the nature of project complexity as it relates to the selection of contracting strategies. Inspired by contemporary thoughts (chaos theory, social systems theory and post-modernistic philosophy), complexity is viewed as a continuum increasing from state order (determinism) towards state disorder (chaos). A number of possible project tracks (planned and/or actual) may be plotted in a complexity-time space. The paper focuses on three such tracks representing alternative families of project strategies. Type A is the well known and well explored owner driven risk reduction lump sum bidding family of project strategies. Type B was put on the agenda in the 90's by cost reduction initiatives in the oil industries in the UK and Norway. Type C family of strategies has been suggested recently by the European Institute of Advanced Project and Contract Management (Epci). As opposed to type A, type B and in particular type C family of strategies exploit the value of uncertainty and indeterminism. The paper concludes that implementing strategies on complex projects to produce extraordinary results certainly extends beyond lump sum contracting and other well known strategies. Keywords: Alliance, complexity, contracting strategies, life cycle, project. 1 Towards a complex perspective of projects Though projects have been managed for perhaps as long as 10,000 years - building the first city wall of Jerico could be the first known construction project - the science of project management is of a rather recent date. Some refer to the emerging tools of project planning and control during and after the 2nd World War leading to the launch of CPM and PERT in the late 1950's as the origin, while others take the view that it all Managing Risks in Projects, edited by K. Kahkonen and K.A. AMo. Published in 1997 by E & FN Spon, 2-6 Boundary Row, London SEl SHN, UK. ISBN: 0 419 22990 6.

150

Hetland and Fevang

started with the article "The Project Manager" published by Gaddis [I] in 1959. Whatever view we take, the science of project management is somewhat 40 years old only. During these 40 years the views of what a project really is have varied considerably. In the early days of the science - though it was not much thought of as a science of its own at the time - practitioners as academics seemed to agree that a project was a unique, well defined task to be carried out within a given time slot under resource constraints, in this paper referred to as the task perspective. In the 70's the task perspective was challenged by a stakeholder perspective, in particular the matrix structures came into focus. In the 80's the system and the process perspectives were added. Originally, the system perspective meant general system theory, but this view was later complemented by various social system positions. In the mid 90's the finite (business) process perspective was suggested to differentiate project processes from ongoing (business) processes of an infinite nature. In the 80's the interest in projects "exploded". The number of projects undertaken multiplied, and the concepts of project accelerated to all sorts of thinkable areas of application. The time was gone when projects were considered exceptions. From now on projects often were the preferred mode of operation in most businesses. This change gave name to management of multi-projects (often referred to as Management of Projects) and project oriented companies (referred to as Management by Projects). At the time of writing this paper, there is no longer an agreed understanding of what a project is and hence it is difficult to have a common understanding of what the management of such an endeavour means. Our position is that the prevailing perspectives may not at all be conflicting, rather they may be considered reflecting different positions from where to view a project. Viewing operational project processes from an inside actor may differ from a project owner focusing on harvesting the result of deploying the project object. This view - that a project may be considered from a number of different and deliberately selected positions - has led to a new perspective, the complex perspective.

2 Task related complexity The task perspective views the project as a set of interrelated tasks. They are separated from other tasks through a project workscope definition. A scope of work document has traditionally been prepared at a very detailed level. However, recent practice has opened up for a number of alternative views. A situation representing determinism may be understood as a set of tasks defined in any detail to be undertaken with no uncertainty related to the availability of resources or to the execution process. Another situation representing indeterminism may be understood as tasks with no goal or even no direction for the project. The two situations may be interpreted as the end points order and chaos. The continuum [2] between order and chaos may then be said to express project task complexity, increasing from zero (determinism) towards infinity (chaos). For practical purposes we suggest to divide task complexity into three zones with different focuses: Zone L Low complexity Efficiency Zone M Medium complexity Effectiveness High complexity Challenge project goal and context Zone H

Project complexity and contracting 151

The deterministic position (order) ignores uncertainty. Uncertainty is either a non issue or it is eliminated through preparation of complete definitions of project work scope, schedules and resources. A frequently used approach is establishment of a detailed Project Baseline [3] consisting of a Work Breakdown Structure (a multi-level hierarchical breakdown of project work scope into manageable pieces of work, Work Packages), a Master Control Schedule (an overall reference schedule for detailed scheduling and performance measurement, time monitoring and forecasting) and a Master Control Estimate (a reference estimate, frequently used as a budget and a reference for performance measurement, cost monitoring, forecasting and earned value assessment). The deterministic position assumes all deviations to baseline as negative, i.e. no discrepancy is planned for. A deviation is something happening that is not supposed to happen. Therefore it must be corrected. Budget overruns should be compensated by lowering budgets for remaining work scope, similarly schedule delays should be recovered by accelerating or paralleling outstanding activities. In zone L focus is on efficient use of resources and time. More precisely the objective is to improve on a given reference case through application of traditional optimisation principles. The starting point may be to find the most efficient working procedure for individual activities seen in isolation. Alternative procedures are tested as are various levels of resource intensity. The result may be drawn as a cost-duration envelope graph. First, the most cost efficient procedure and duration for each activity is found. This solution may have an unacceptable duration for the entire project. TO improve on this solution, the original CPM scheduling technique may be used, where trade-off between project cost and overall project duration is being made. Like the deterministic position, deviations from the project baseline are considered "planninglschedulingfailures" that must be corrected. The challenges in zone M deviate from the one of efficiency as focus is on exploring alternative routes to the given goal of a project. The exercise is no longer solely a matter of optimising a prior given strategy. The prior strategy serves as a part of departure only. Being challenged from whatever perspective, the prior strategy is turned into a number of alternative options. A main route is then selected. However, relevant options are kept open as long as adequately feasible from a practical and cost consideration. The selected overall strategy is flexible in the sense that modifications are made as appropriate over the entire course of the project, continuously focusing on maximising added value to the project stakeholders. The starting point for the challenges in zone H is an a priori goal and context. Rather than simply accepting these as given requirements, this position advocates that the goal, as well as the context, should continuously be challenged to see if a change may enhance the project value. The procedure is dynamic and requires an open and demanding dialogue between key project stakeholders. The indetermistic position (chaos) may be a starting point for a given stakeholder faced with bankruptcy possibilities. A project may, however, turn into an indeterministic situation in the sense that it is no longer controllable. Trivially such an outcome could in many cases be handled by simply increasing the budget or prolonging the schedule. However, such remedial actions may not turn out to be feasible. Some projects may turn into indeterminism because the object goal cannot technically be met, or the application of the object may be obsolete, e.g. due to changes in the market place. For a project that has turned into indeterminism a golno go decision has to be made.

152

Hetland and Fevang

The no go option would imply that the project has been given up. The go option would imply that major changes to the given goal and context will be undertaken.

3 Project stakeholders Project stakeholders are organisations and individuals who have a vested interest - a stake - in a given project. Stakeholders may be actively or passively involved in the planning, execution or management of project work. The former are referred to as actors, the latter as observers. Furthermore, stakeholder interests may be positively or negatively affected as a result of project execution or implementation, hence the project may create winners and losers. Project stakeholders may alternatively be grouped as principals, agents or third parties. Principal is a term used to express the role of an ownerlclient organisation for a given project. The role of the principal is to set an a priori goal of the project given relevant contextual constraints. Further, the principal acceptsldecides on changes to goals and contexts as appropriate to pursue the project mission. The principal role may hence be considered a mechanism for transforming an open system perspective to a contingent closed one. Finally, in certain project strategies the role of the principal may be exercised cooperatively by owner(s) and suppliers, although the degree of formal influence may be higher on the side of the owner(s). In an integrated owner-supplier project organisation (frequently referred to as a project alliance) the principal role must be distinguished from the role of the agent. Agent is a term used to express the role of an individual or organisation supplying, canying out or managing project work as defined by the principal. As project work may be carried out in parallel by several organisations (internal project teams or suppliers' project teams) a need arises for an overall managerial role embracing all agents. This role is being referred to as prime agent role. Certain projects may apply strategies with multiple levels of suppliers. As each supplier, independent of level, claims to work on his own project, there are numerous projects within a project - not necessarily structured in a hierarchy. Consequently, we will face a number of subordinate principal and agent roles. Keeping these roles separate from the role of the prime principal and prime agent, such roles are referred to as secondary/tertiary/etc. principallagent roles. Third parties is a term used to express the role of stakeholders other than those of principals and agents on a given project.

4 Project life cycle A life cycle of a project is a term used to describe the complete life of a given project as seen from a stakeholder perspective - a principal, an agent or a third party. A project - as seen from a selected stakeholder - starts at the time when the stakeholder formally decides to realise an intention expressed in terms of a prior goal and a set of contextual constraints. The starting point is referred to as intention. A project ends for the selected stakeholder when he accepts that the goal has been fulfilled (completion)

Project complexity and contracting 153

or he abandons the project recognising the project goal cannot be met (abort). The end point is in both cases a result of a formal decision referred to as termination. Though life cycle considerations may be applied to all projects as viewed from all relevant stakeholders, the most applied cycle, by far, is the one of the principal. If nothing else is said, the term life cycle will be applied synonymously with the project life cycle as seen from the principal (figure 1). Any project may be characterised through one or more of the following activities of a generic nature: (a) exploring1 concepting, (b) materialising/substantiating, and (c) deploying1 exploiting. The first group of activities is focusing on searching for 1 exploring I developing 1 enhancing ideas I concepts 1 solutions that represent a higher value to the stakeholder(s). The second group is focusing on transforming 1 materialising / substantiating the selected best idea 1 concept / solution into a physical or abstract object. This process may include further enhancement depending on the selected project strategy. The third group is focusing on harvesting value by deploying 1 exploiting the project object. The three sets of generic activities are separated by two major decision points: sanction and implementation. The sanction point represents a (normal) "point of no return". Independent of how far the exploring/concepting activities have been brought (may vary depending on project type and chosen strategy) a decision has now been made to materialiselsubstantiate the project concept. The decision point is irreversible, emergency situations only will apply for a freeze or full stop. The implementation point represents a decision to apply the project object to what it is meant for. A building may be ready for sale or use, a producing facility may be put into operation, a software system may be released for sale etc.

5 Organisational complexity The stakeholder perspective focuses on the needs of and the relations between project stakeholders. Depending on whether the structural elements are organisational units or individuals we refer to the structure as macro or micro. The focus may be intra- or interorganisational. Finally, there is a number of generic structural options to be chosen from.

IMPLEMENTATION Substantiating

Fig. 1 Project life cycle as viewed from the principal

154

Hetland and Fevang

The original position was focusing on intraorganisational microstructures. However, interest was not so much in the structural outline as it was in the formal delegation of authority. Depending on the degree of delegation a differentiation was made between functional organisation (no authority), matrix organisation (shared authority) and project organisation (full authority). Of particular interest was the matrix option, which opened up for cross-organisationalcommunication, integration and supervision. The matrix (intraorganisational microstructure) was complemented by an interorganisational macro position where alternative contracting arrangements were of core interest. Later, three main options were suggested [4]: conventional contracting, relational contracting and alliance contracting. In conventional contracting structures there are one principal and one or several agents. The owner will act as a principal, which means he will decide on how project work is split between different agentslsuppliers, when contract work is supposed to start and end, how suppliers are being selected and changes to the original contract. When it comes to remuneration of contract work, the principal is faced with different options. Frequently, lump sum arrangements are preferred wherever possible. Further, contracts are normally awarded to the lowest bidder in a competitive tendering process. In order to facilitate this arrangement the principal seeks to make contract documents as complete as possible. Everything should be thought through prior to coptract award. This procedure limits the need for communication between the client and the suppliers during the contract period. As a consequence, each supplier works as an autonomous agent within a clearly defined contractual context. There is no rationale for collaborating with other suppliers working on the same project. The same behaviour is observed even if "schedule of rates" types of contracts are used rather than more definitive ones. The project structure is a set of autonomous organisations working within individually defined contractual contexts. The principal sets the different contexts and manages interfaces and contextual changes for all suppliers. Relational contracts [5] represent a frequent interaction between the contracting parties without, however, jeopardising the parties formal responsibilities as set forward in the contract documents. The contract parties often establish an integrated project team to coordinate ongoing project activities. This way a close cooperative environment similar to that of a true alliance is created. The existence of a formal division of work, though, restricts the potential improvements over and above what is expected from the contract as the supplier is not encouraged to take on extra work or costs unless such efforts are considered profitable from the supplier's perspective. To gain the full effect of a relational contracting strategy - i.e. to encourage the supplier to go for project life cycle value - incentive arrangements have to be constructed in such a way that it is possible for the supplier to improve on his expected profit if he directs his efforts towards the overall goal of the the owner and actually creates a project value in excess of the owner's expectation. Alliances, related to complex projects, may be defined as contractually binding agreements between organisations that have decided to work as an ad hoc collectivity to perform contract work on a given project. The implication of this is that they are inseparable and appear commonly responsible for contract work. Benefits as well as risks are shared among the alliance parties according to agreed gainsharing

Project complexity and contracting

155

mechanisms. There appears to be three major types of ad hoc alliances: supplier alliance, project alliance and hybrid alliance (figure 2). Supplier alliance is a structure where two or more suppliers enter into an ad-hoc alliance contract on a particular project. In the alliance contract the suppliers take the role of an integrated organisation (agent) while the client acts as the principal. Project alliance is a structure where the client takes the role of an alliance party. In this case the blurred responsibilities between organisations in the supplier alliance extends to the client. One can no longer distinguish between accountabilities of the client and of the suppliers. They all mingle into an integrated organisation with common goals and obligations. As with supplier alliances, benefits and risks are being shared according to agreed gainsharing mechanisms. In spite of this, it is necessary to differentiate between the role of the principal and the role of the prime agent. One way of dealing with this is to let the board of project stakeholders (a board of representatives from the alliance parties) take on the responsibility of the principal, as illustrated in figure 2. The term "hybrid alliance" is used to describe variants of cooperative contracting strategies that do not fall into one of the pure forms mentioned. In particular we address what may be referred to as "double deckers", i.e. multi-level contracting relations. To our knowledge the first experiment with a two-tier contracting structure was made by BP on the Andrew Project (1994). Single contracts to seven key contractors with complementary work scope were awarded based on ordinary articles of agreement. The only main deviation being the removal of clauses of a potential adversarial nature. The work scope of the selected contractors where then integrated as the seven contractors formed a supplier alliance. The supplier alliance then entered into a risk and reward contract with BP. This way the key contractors had two contract relations to the principal - structured in two layers, as illustrated in figure 2.

Supplier Alliance

Project Alliance ,

= 0= S=

-= -=

Prime Agent role Owner Supplier Alliance relation Conventional relation

Fig. 2. Major types of ad hoc alliances.

Two-tier contracting scheme

156 Hetland and Fevang 6 A framework for complex project strategies We are currently facing major shifts in the way complex projects are being run. The traditional focus on costs and discrete contracts is no longer adequate to deliver profitable developments. The current practice needs to be changed to better align the goals of suppliers with the overall business goals of the owner(s). In order to capitalise on complementary know-how and experience, suppliers need to be contracted earlier, long before comprehensive scope definitions can and should be produced. To provide for this new course of action, detailed specifications are replaced by functional requirements and suppliers are considered - and designed into the project process - as potential partners rather than opportunistic agents. All these changes have made current contracting practices inadequate. The CRINE [6] and Norsok [7] initiatives have been prime catalysts in this change process. We now know where to go, but getting there is demanding. Epci has, through its Contract Engine work-group [4], proceeded with one of the major challenges defined by the cost reduction initiatives, notably the incentivisation of contracts. A comprehensive conceptual framework has been generated to show how to align the goals of contracting parties. The Contract Engine is a set of standard incentive schemes that could replace current contractual agreements. The engine is developed in four different versions/incentive schemes from minimising costs of any single contract (1st order) to enhancing project life cycle value (4th order). To estimate the effect of goal-seeking strategies and contract forms, we need a basis for comparison. The basis is meant to be a description of what we refer to as conventional compensation forms. These are, together with goal-seeking alternative strategies and contract forms, put into a framework [8] in order to make the comparison clearer (figure 3). The comers of figure 3 represent pure forms as discrete market contracts, fully integrated organisations and identical goals for principal and agent. As shown in the figure, the conventional contract forms are in segment CO whilst the more recent CRINE and Norsok based strategies are to be found in R2, A2 and A3. The goal orientation increases as we move from sector C (conventional contracts) through sector R (relational contracts) to sector A (alliance contracts). Similarly the goal orientation increases from level 0 towards level 4.

A

Fmnnci incenlives 4th order

Enhancing project life cycle value

3rd order

Minimising project life cycle costs Minimising capital costs of a project Minimising costs of any single contract

Explicit Formal Rules

Commercial

Relational

Altinnce

Norms

Fig. 3 A framework for alternative contracting strategies.

Project complexity and contracting

157

At this stage we are able to merge the framework for alternative contract strategies with the framework for task complexity. Work in zone L requires a conventional contracting strategy, say CO. Work in zone M is best supported through a cooperative contracting strategy and incentive arrangement of 1st or 2nd order, say R1, R2 or A2. Finally, work in zone H necessitates an alliance based strategy with far reaching incentives, say A3 or A4. For the sake of reference we refer to the various families of strategies as type A, B and C. To complete the big picture we finally include the effect of the "time arrow". Typically, the project relevant timeframe increases as we move from type A towards type C strategies. Suppliers are contracted earlier and are staying on longer on C compared to A strategies. But most important, the zone of possibility is set wider and kept wider for as long as reasonably possible to maximise the enhancement of life cycle value. As an illustration of alternative strategies, a number of possible project tracks are plotted in a complexity-time space (figure 4).

7 Real life complex strategy experiments The origin of full scale experiments with complex strategies in the oil industry may be traced back to the early 90's. The trendsetting company was BP through its Hyde project. To our knowledge this was the very first time a project alliance arrangement was tested out on real life projects. The rationale for taking this route is best described through the following statement from the project team : "... projects have been broken down into constituent elements with relatively large management effort required by the operator to administer contracts. This fragmentation, and associated contract strategy, has led to an approach to project execution that we believed to be anticreative. It seemed to us that the main players could avoid the clientlservant adversarial approach to business, there was scope to drive down costs significantly towards BP's declared goal of 30% for UKCS developments. By way of analogy this was the weight reduction required to escape earth's orbit with limited launch (cash) capability" [9]. The Hyde team (1991 - 93) fulfilled their mission and hit their cost target. The Hyde success was soon disseminated to other projects in the UK and Norway. BP continued to head-up the leading edge by making a new break-through, this time on the Andrew CHAOS

Complexity

Zone H

7

ORDER

Fig. 4 An illustration of alternative project strategy tracks.

Time

158

Hetland and Fevang

project. The three alliance supplier arrangement on Hyde was now extended to embrace not less than seven parties, mingled together in a novel structure the hybrid "double decker" alliance. The Andrew (1993 - 96) gainsharing mechanism [lo] has later developed into the standard for gainsharing contract arrangements. Again the alliance team met the BP business expectations. The story goes on, some disappointments have been notified but generally the experiments with novel strategies have been better than expected. Maybe the most successful BP project so far is the Cleeton project (1993 - 96) where capital expenditures were reduced from 100 mill GBP to 33 mill [ l 11. Originating from the Hyde experience, a similar track record of successfully employed cooperative strategies has taken place in Norway. The supplier alliance on the Statoil Sleipner Vest B project (1993 - 96) reduced capital costs by approx. 200 mill. from a target of 900 mill. NOK. An estimate of the "Norsok effect" on four recent projects (Nome, Njord, Visund and Asgi%rd) shows an increase in asset value (expressed in NPV) from 32 to 64 billion NOK. Comparisons over time have further shown some amazing improvements in unit costs. For example, unit costs for flexible production systems offshore have been reduced by 80% from 1988 to 1996 [12]. Many of the substantial improvements are rooted in change in technology, standardisation and related issues. Whatever the mot, such changes have been made possible through an increasing use of complex contracting strategies producing results far beyond the reach of traditional lump sum contracting strategies.

-

8 References

Gaddis, P.O. (1959) The Project Manager, Harvard Business Review. McMaster, M.D. (1995) The Intelligence Advantage. Organising for Complexity, Knowledge Based Development Co. Ltd., Great Britain. Hetland, P.W. (1992) Praktiskprosjektledelse, Bind I - Teoretisk grunnlag, StatoiVNFP, Stavanger. Hetland, P.W. (1996) The Contract Engine - A superior mechanism for the alignment of project goals with corporate objectives. Proceedings IPMA '96 World Congress on Project Management, Paris. Macneil, I.R. (1990) The New Social Contract. An Inquiry into Modem Contractual Relations, Yale University Press. CRINE Report (1994) Cost Reduction Initiative for the New Era, UKOOA, London. Norsok (1995) Hovedrapport, Styringsgruppen for utbyggings- og driftsforum for petroleumssektoren, Oslo. Hetland, P.W. (1995) Mdls@kendestrategier og kontraktsfonner for gjennomf@ring av komplekse utbyggingsprosjekter, Aalborg Universitetcenter. Rhodes, Finch and Mound - The Hyde Project, SPE 26766. Knott, T. (1996) No business as usual. An extraordinary North Sea result, BP, London. Harrison, L., Daniels, M. and Charnley-Fisher, M. (1996) Cleeton Compression Project, CRINE, UK. Notes, Statoil Corporate Procurement (KIR), Stavanger (1997).

Using a systematic project delivery approach to better manage project risks J.M. VANDEUSEN Work Systems Associates, Inc., Marlborough, USA

1 Introduction My basic premise in this paper is that the management of risks and opportunities is most effective when adequate recognition and attention are given to the development of a project's human resources, within the framework of a structured, systematic approach to project management. Risk assessment and abatement are frequently treated as a procedural matter, best left to the care of technically qualified specialists. This approach is today being replaced by a more strategic one, wherein project risks are viewed as derived from the joint influence of many factors occurring inside and outside the formal boundaries of the project. From the latter perspective, in order to drive down risk one must institute a systematic approach to project management, establishing a set of proactive practices that address technical, financial and social facets. It is widely recognized that satisfactory application of the appropriate technical and financial tools will certainly enhance the precision of risk identification, analysis and decision-making. Yet, the most powerful tools at the project manager's disposal are the sense and sensibilities of the project team members, customer, and others who affect and are affected by the project. It is through these resources that unacceptable risks can be distinguished from unnecessary ones, and unknowable opportunities from unexploited ones. In this paper, I use one such integrated approach to project delivery as a framework to describe how maximum leverage may be obtained from human resourcefulness at key junctures in project life-cycle. After describing the content and development of the system, I will offer several examples of its application to risk- and opportunity-related issues.

Managing Risks in Projects, edited by K. Ktihkonen and K.A. Artto. Published in 1997 by E & FN Spon, 2 4 Boundary Row, London SEl 8HN, UK. ISBN: 0 419 22990 6.

160

Vandeusen

2 Developing a systematic approach to project delivery Project-based companies or departments in larger organizations exist to help their customers move projects from concept to successful completion. As business environments become increasingly competitive, companies seek more comprehensive solutions to their projects, creating a corresponding need for the project manager's orientation to expand from a conventional focus on technical solutions to a broader concept of excellence in every facet of project delivery, including processes, people, tools, and supportive structures. To meet this challenge Work Systems Associates, Inc. joined forces with CH2M HILL, Ltd. to develop a systematic approach to project delivery. An aggressive program of installing this system has permitted CH2M HILL to dramatically enhance the recognition of the project manager's importance to the organization; to adopt a consistent process in organizing, planning, and executing projects; and to develop the capacity for effective collaboration between project teams, upper management, and customers.

2.1 Problem identification Development of the CH2M HILL Project Delivery SystemTMbegan with an exploration of the barriers to good project delivery and performance. As part of its own organizational reengineering, the firm chartered teams to examine where and why difficulties were experienced with projects. Total Quality Management principles were used to identify those factors which were the most frequent and costly contributors to negative performance, across all projects. The teams analyzed the actual methods and procedures used to deliver projects; the documentation and resources made available to project managers and teams; the selection, training, and certification of project personnel; compensation and incentivization; how technology is brought to projects, including software systems for planning and tracking project performance; and other related issues. In a review of over 3,000 projects, it was found that the most basic problems result from a lack of consistent project delivery practices (Fig. 1). If a means could be developed to address these few factors, it was felt that dramatic improvements could be realized, within and across projects. One particular benefit, would be the systematic reduction of risk.

Systematic project delivery approach 161

Fig. 1.

Causes of poor project performance

3 A systematic approach to project execution The real learning to be taken from this inquiry into the barriers to project performance, was an understanding that the way projects are executed is a system, not simply a series of tasks. This system encompasses project planning and work processes; people who are connected through this work; and tools and structures supporting the work. Sustainable improvement requires a balanced approach to improvement of the entire system of people, processes and tools.

3.1 Four basic principles of the system The fundamental principles that create successful projects are universally applicable regardless of project size, scope, technical content, or type of customer. Four such principles underlie the Project Delivery System: customer focus, consistent processes, project manager as leader, and thorough organizational support. 3.1.1 Customer Focus The first principle is that every aspect of project delivery should be driven by a clear focus on customer satisfaction. This is as true for internal customers served through "in-house" projects as it is for external customers. Viewing the customer as an integral part of the project, rather than as an outsider, requires developing and building robust relationships with customers at the outset and maintaining them throughout the project. This principle is of vital importance for risk management, since clarity about the customer's vision of what the project is supposed to produce is a fundamental criterion of success. One cannot effectively manage the customer's expectations during project execution, unless this clarity has been obtained during the procurement and planning stages.

162

Vandeusen

3.1.2 Consistent processes While customer focus and satisfaction are at the heart of the system, the articulation of clearly defined processes for project delivery serves as the primary means to achieve this focus. Although there are many steps in the process, five management subprocesses are critical for success:

Building a high-performing project team Developing a clear, focused project plan Obtaining full endorsement of the project plan Proactively managing changes experienced during project execution Achieving effective closure of tasks and the project In the Project Delivery System, these components are detailed in a series of process flow diagrams. The diagrams show the relationship of the five basic elements with other, more detailed activities that are part of effective project management. When projects are managed through these processes, the task of reviewing status and progress is simplified. Conversely, when any of these basic process elements are missed, or done poorly, there is a heightened likelihood of performance problems occurring during project execution. Kerzner [2] has similarly cautioned, that "cookbook" application of a standard risk management approach as a part of the project management plan may cause unique aspects of risk to be overlooked.

3.1.3 Project manager as leader Effective project execution requires effective leadership, and this in turn requires ongoing commitment to the development of project management personnel. In a process-driven approach, the project manager's primary responsibilities are to ensure that projects achieve customer satisfaction and sound financial performance. This requires competency in five core "disciplines:" Business Skills Interpersonal Skills Project Management Skills Practice and Technical Skills Customer Service Skills Each of these core competencies contains both "leadership" and "management" elements. Leadership can occur at any point int he project lifecycle, and is defined as actions that affect the project in a significant manner, e.g., crafting the vision, building the team, or resolving major changes. Management, similarly, occurs through actions taken to maintain progress within the defined boundaries of time, cost, quality, etc. At CH2M HILL, a state-of-the-art training program was developed as a focal point for installation of the process-driven project delivery approach. Using a curriculum that is closely aligned with the core project delivery processes, the training is conducted in a group format, typically with 24 to 36 project managers divided into teams of six. The training is led by seasoned project managers. The lessons are highly participative, and

Systematic project delivery approach 163

follow a learn-by-doing approach - e.g., how to involve the entire project team in realtime construction of a work breakdown structure. The learning cycle in the project delivery training begins with the presentation of key concepts. Relevant skills are then developed through practical exercises, built The cycle concludes with reflective around appropriate, real-life examples. discussions of the behaviors and attitudes experienced in the exercises, and in the project managers' own practice. To date, over 1,200 CH2M HILL project managers have completed this training. Coaching and mentoring is another element in developing project management leadership. Although the project delivery training is targeted for all project managers, one of the intended outcomes of this training is that senior project managers will become leaders in its application on projects. As champions for the use of the process, the senior project managers can become a strong force for coaching and mentoring other project managers throughout the company. Rounding out the commitment to leadership development, are formal certification and career pathing programs. 3.1.4 Thorough organizational support A final consideration concerns the implications of improved project delivery processes and competencies for the remainder of the organization. Tools, policies and structures should support (or, at a minimum, not detract from) effective project execution. The firm's resources should be directed at supporting the achievement of consistent processes, customer satisfaction, and project manager leadership. In order for the Project Delivery System to achieve its full potential, it must be successfully installed and consistently used throughout the organization. Many behavioral changes will be necessary as the firm continues to incorporate the system into its operations and culture. These changes must be reinforced through continued emphasis by all units of the firm. Corporate support for installation can be expanded through ongoing communication about the system and a variety of additional education and networking activities. A systematic development plan was instituted at CH2M HILL, based upon the Carnegie-Mellon Capability Maturity Model. This plan provides the firm's personnel with a clear sense of their progress in implementing the Project Delivery System. Performance indicators are defined for each of three stages of development:

164

Vandeusen

Table 1.

Three stages of capability maturity

Stage Credibility Generating awareness and buyin through communication and orientation

Project delivery training proceeds in the regions, and project managers are being certified and advocate using the process The link between project delivery application and project performance is understood by project managers Customers are introduced to the process Project-specific workshops build support and confidence in project delivery, and the project delivery process is applied to projects Management is visibly committed to project delivery

Consistency Improving project performance through system application

Project managers continue to introduce project delivery to customers, and CH2M HILL provides training to customers when appropriate Most project managers in the region have been trained to use the project delivery process Project managers use the project delivery process, and performance results improve The project delivery process is part of our marketing strategy during procurement The project delivery managers (PDMs) understand their role, lead the process application, and use established procedures for measurement and feedback.

Stability Obtaining desired results from the system

The project delivery process is routinely applied to all projects, and customers recognize the benefits Customers validate the benefits of using the project delivery process on their projects Performance results are repeatable and have improved to a level of benchmark performance

4 Acknowledging risk The formal side of risk management should be undertaken during the project planning phase, as a part of a change management plan to be developed as a component of the project workplan. The change management plan describes the guidelines and processes the team will use to manage changes as they occur and leads to a thorough and orderly disposition of project changes. The five elements that need to be addressed in a change management plan are to: Identifying the change Analyzing the effects of change Developing a response strategy Communicating and gaining endorsement for the response Revising the workplan and monitoring the effects of change

A large part of change management is the acknowledgment that each project has certain risks or uncertainties associated with it that may affect the project in ways that cannot be specified in advance. The customer must provide guidance on identifying the risk and understand and accept the risks that are inherent in the project. These risks can arise form any source and, depending on how they are handled, may either threaten

Systematic project delivery approach 165 the project or support it. Risk often relates back to the nature of the contract, rather than the scope of the project. It may originate, for instance, as the result of a specific commitment or business decision made to satisfy customer expectations. Although many situations can introduce risk into a project, part of analyzing risk is to determine the likelihood of a particular event occurring. A number of situations have been found to impose a higher likelihood of risk occurring, and project managers should be aware of these: A new customer with whom relationships have not been established A technically complex project An administratively complex project Difficulty in accessing needed resources ' A "hot" regulatory climate 8 Exposure to liability Considering these situations, a number of potential events should be seen as red flags: Customer is making an expensive decision, and the costs of research and testing are high Customer has a severely limited budget for both design and construction Customer has a costly problem imposed on it by external forces such as regulators The solution with the lower initial cost has the higher life-cycle cost An innovative, untested approach may be the best or least expensive solution Whenever possible, a proactive strategy should be developed to respond to (or allay) these situations. The use of a systematic, process-driven and customer-focused project management approach will improve the likelihood that such risks are identified early, that creative solutions are developed, and that all parties are satisfied with the outcomes.

5 Applying the system to manage risks & opportunities: Three case examples 5.1 Applying the team chartering subprocess to a high-risk project The value to be derived from a systematic approach is illustrated by a high-risk project, the Marzone Superfund Site, in Tifton, Georgia. The project focus was the environmental remediation of a former pesticide plant, located in a residential area. The local community was very concerned about the safety of this project. Confronting these challenges head-on, the project leadership decided to adopt an inclusive approach, inviting all key parties to become part of an integrated, highperforming team. Representatives of the owner (Chevron), CH2M HILL, the U.S. Environmental Protection Agency, and Georgia Dept. of Natural Resources agreed to serve as sponsors. Key project personnel from the same organizations, plus key subcontractors, formed a leadership team. And, additional project members from all of these organizations were organized into integrated task teams dealing with soils, groundwater, and community relations issues.

166 Vandeusen In a series of chartering sessions preceding the detailed planning of work, the team agreed to implement the remedial actions in a manner that would: leave the site in a state that posed no unacceptable risk prevent any reportable safety incidents meet community acceptance and support maintain cost-effectiveness "Managing change, risks, and uncertainty to achieve cost-effective results," was one of six critical success factors identified by the team, for this project. It was decided that a proprietary, "Alternative Remedial Construction Process" (c) would be used to help the team identify and manage unquantifiable uncertainties in a timely, cost-effective manner. By having all parties sit at the same table to work out the project goals and objectives, critical success factors, roles, and operating guidelines, a number of "breakthrough" solutions to project management challenges were achieved at the very beginning of the Marzone project. It was agreed to use a thermal desorption treatment methodology that allowed the team to reduce the schedule from 30 years to 2.5 years, reduce the overall project cost by a third, and preserve high levels of quality, safety, and community involvement.

5.2 Rapid installation of the complete project delivery system Lockheed-Martin Energy Systems (LMES), a subsidiary of Lockheed-Martin, administers nuclear operations and facilities at Oak Ridge, Tennessee, under contract to the U.S. Department of Energy (DOE). The situation in this organization is characterized by a complex web of technical, budgetary, and regulatory constraints. In other words, there are many, many possibilities for conflict, confusion to occur, with associated risks. The organization is under a directive from its federal customer to shift from a stable, operational mode to a projectized one, while at the same time delegating an increasing share of the work out to subcontractor firms. LMES opted to adopt the Project Delivery System as a central part of its strategy to manage these crucial transitions. It was felt that there was not time to "grow its own" approach. The fast-track installation of the system began with a series of laboratory training sessions, enabling a total of 250 key project and management personnel to learn and begin applying the basics of the approach within a period of just three months. A core team of internal change agents were then given supplemental skills to facilitate improved application of the approach. The "laboratory" approach to training was designed to help project personnel translate the Project Delivery concepts into familiar terms. E.g., the Project Delivery subprocess for "Closeout" was felt to correlate with work done onsite reporting, cost closing, and lessons learned. Asked how well they felt this subprocess was performed onsite, one group gave a subjective rating of about 32% (about one-third as well as expected), verifying a high level of need for improvements in this area. The lab approach to implementation of the Project Delivery System had two immediate benefits: quick diffusion of basic model throughout the organization, and

Systematic project delivery approach 167 rapid alignment among participants. Given the dramatic nature of the changes going on within the larger organization, these are of substantial value. Within several weeks of initiating its installation, the Project Delivery System had already been used on seven projects, as a means to increase the customer involvement and team collaboration project planning. The approach taken was for all concerned parties to meet to jointly to scope, estimate, and schedule the project. This intervention enabled the planning and approval cycle to be reduced from an average of 6 weeks, to less than 2 weeks. In one instance, the DOE customer stated all projects in the future he was involved with would use this process. Visioning process extremely useful in allowing the EMEF Project Team to understand the customer's needs. As the project delivery process was being implemented on these projects, concurrent work was being performed to reform other facets of the organization to support the new approach: key roles and responsibilities for all four divisions of LMES (Planning & Integration, Project Execution, Project Support, and Administration) were re-aligned around the five major project delivery sub-processes. a resource manual was developed as a means to inventory practices, procedures, glossaries, templates, and other materials that had proven helpful to project teams an assessment of software and other project management tools was made, to determine where improvements were needed the LMES executive team worked jointly with its DOE counterparts, to review where and how they could best support each other in implementation of the Project Delivery System. As a result of these early exercises, a great deal of value had already been derived from the implementation of the Project Delivery System at LMES, within three months of the program's inception: "This system has allowed our customers and us to jointly plan the work to our mutual benefit and clearly identify the requirements and expected outcomes." (Director of Project Execution, Lockheed-Martin Energy Systems)

5.3 Real-time project planning via a large group conference It is not necessary to institute all elements of the systematic approach, before benefits can begin to be obtained. A good example of this occurred in the case of a project serving as the design phase of an initiative that would result in the construction of a new ARCO Chemical facility in the Netherlands. In order to achieve best-in-class results from the project, ARCO desired a means to achieve a high degree of collaboration between the consultants, Raytheon Engineers & Constructors, and its own team. The focus here was on the planning subprocess, which includes the development of a high-performing project team; a clear, focused project plan; and full endorsement of the plan. To begin the team-building, a small group of key ARCO (ACNL) and REC project management personnel met for two days to understand and agree upon broad goals, objectives and strategies regarding the overall project, as well as the related business

168 Vandeusen goals of each organization; and to create a "win-win" that would have the highest positive impact on the project. It was essential that the key management come together to listen and share information with full candor and retain the flexibility required to create the best possible setting for a successful project. In this session, this team also set the vision, boundaries, goals, strategies, key policies, issue resolution process and other key project parameters to be shared with the entire project team. In a second phase, a two-day session was then held for the ACNL Engineering Team. Because of the size of the group (28); the mixture of different cultures; their lack of prior experience together; and the scope of the project, it was essential that this customer team work together to gain: Common understanding and alignment regarding the vision and critical success factors for this project Clarity regarding their relationship with the Manufacturing and Commercial teams Clear definition of their collective roles and responsibilities vis-a-vis REC Definition of their individual roles and responsibilities with each other and with REC Operating guidelines for how they would work with each other and with their REC counterparts As the third phase, additional personnel from various ACNL operating units met with the ACNL Engineering Team for a one-day session. The purpose of this session was to ensure the complete internal alignment of all key ARCO personnel for this essential project. As the fourth and final phase, thirty Raytheon team members paired up with thirty counterparts from the ARCO team to craft the core design processes for project. The two teams worked together for a total of sixteen hours, over two days, to develop the core work processes that would drive the day-to-day work together. Because of the large size of this group, a large group conferencing technology was utilized for the design work. This type of technology has been developed and validated over the past decade with groups of up to 1500 people at a time [3,4]. It is a process that creates a common vision and alignment to that vision very rapidly, as well as activation of the entire group in a remarkably short time period. It was agreed by the conference planners, that eight key facets of the design process needed to be addressed: Project Management and Control EH&S Equipment/Mechanical Power and Control

Civil/Structural/Architectural Process Design PipingIPlot Plan Development Vendor/Subcontractor Qualification

Systematic project delivery approach 169

During the conference, subteams were formed to work on each of these processes. Each subteam addressed the following items for their process: Define Inputs - The Project Design Basis: what else would be included/not included by each group? Define Outputs Develop the Work Flow - Flowchart Define the Roles: individual and organizational Determine decisions: authority, timing Communications: what communication vehicles are required; what needs to be shared with others outside the team? How do we ensure: quality, environmental health and safety, manufacturability, and third party input? How we resolve conflicts? Unresolved issues - questions remaining to be asked When the subteams had finished drafting responses to these items, each team reported out the results to the larger group, collected feedback, and then made final adjustments to their work product. The collective output from this session became the draft for the overall document production process for the design phase of the project. In addition, the intense nature of the collaboration helped to build strong rapport between the consultant and customer teams. The customer derived sufficient value from this realtime, collaborative planning approach, to continue its use in subsequent phases of the construction project.

6 Conclusion Forsberg, Mooz and Cotterman [5] have stated that, "Risk management depends on a good foundation of planning and proactive project management." They go on to define this foundation as including the use of proven processes tailored to the project; an upto-date implementation plan, developed by and committed to by the project team; and active management of the business and technical baselines. The key to all of this is motivating the team to identify project risks. In this paper, it has been shown that a systematic approach to project delivery, which is process-driven and focused on the customer, offers a number of benefits: A consistent template for effective project delivery practices A sounder basis for assessment of project performance. (This is especially valuable for organizations that are applying total quality principles, process improvement principles, or preparing for I S 0 certification.) An ability to provide customers with additional value, both in specific tasks and in entire projects A strong internal capability for continued refinement and innovation of the firm's project delivery processes

170

Vandeusen

An ability to enhance the skills of project managers and project teams in applying project delivery principles, both to internal and external projects Collectively, the elements of this kind of approach can have a significant impact on the occurrence and impact of risk, throughout the project life-cycle. All direct and indirect contributors to the project are provided with greater ability to clarify and adjust goals; communicate important information; make decisions; and resolve issues.

7 References 1. CH2M HILL and Work Systems Associates, Inc. (1996) Project Delivery: A System and Process for Benchmark Peg5omance. Denver, CO: CH2M HILL. 2. Kerzner, H. (1995) Project Management: A Systems Approach to Planning, Scheduling, and Controlling. New York: Van Nostrand Reinhold. 3. VanDeusen, J. (1996), Honing an Effective Tool for Community Improvement, Journal for Quality and Participation, September: in press. 4. VanDeusen, J. (1996), Conferencing Tools in Resnick, H., Team-Based Top Management: Tools to Build a High-Performance Senior Management Team. Volume Five in The High Performance Teams Portfolio. Zurich: Strategic Direction Publishers, Ltd. 5. Forsberg, K., Mooz, H., Cotterman, H. (1996) Visualizing Project Management. New York: John Wiley and Sons, Inc.

Risk sharing partnerships G.S. HOUGH Severn Associates Ltd, London, UK

Abstract Reducing the risk envisaged in a project is a clear aim of any company engaged in project work. One way to achieve this is by sharing that risk amongst a group of companies, who in some way will either share or participate in the project. The intercompany relationship which is then constructed, is critical to the success of the project, especially since a sharing of risk normally requires a corresponding share in project benefits, such as profit or exclusive positioning. Equitable arrangements are required, suitably attractive to all participants. Much effort, therefore, is expended in putting together a contractual model to tie the parties together in a mutually acceptable manner. The choice of arrangement for risk and revenue sharing partnerships is directly dependent on a series of factors, including the type of project, the level of investment and the nature of the envisaged risks. This paper reviews the concepts in typical risk and revenue sharing models, for the type of projects which require research and development activity hnding prior to commencing series production. The advantages and disadvantages are highlighted and implications on the organisation are discussed. The conclusions are that high investment risk projects require increased sophistication in contract models. However, more complexity generally brings higher administrative costs. Nevertheless this is outweighed by commercial attractions in the area of risk. Keywords: Risk, risk sharing, contracts, project management, business risk.

Managing Risks in Projects, edited by K. K2hkOnen and K.A. Amo. Published in 1997 by E & FN Spon, 2 4 Boundary Row, London SEl 8HN, UK. ISBN: 0 419 22990 6.

172 Hough 1 Introduction

The subject of this paper is essentially focused on development projects which result in series production products, rather than capital investment or infrastructure projects. The risks in such projects can be manifold, but in general, the most powerfbl business risks arise in the following areas: Research and development costs of the product. Manufacture cost of the product. Sales price in competitive environment. In service problems resulting in significant warranty claims, and market erosion due to bad reputation. Business case evaluations can be used to show the impact due to variations in these parameters. Other significant risks may lie in such areas as: Meeting contract deadlines. Failure of suppliers to perform. Competitive influences affecting the project specification, goals etc Exchange rate. Many companies give little or no attention to risk, and certainly fail to consider means to reduce their business or technical risk. The first step an organisation should take is to reduce or modify the risks being carried by giving attention to risk in the planning stage. This approach requires a Risk Management Plan (RMP) to be put in place to address each risk of significance [I]. Against some potential, high probability risks, a contingency plan can be constructed and budgeted as part of the RMP. However, even after putting together a set of realistic contingencies, significantly large risks can still remain, particularly for high-tech projects. The ultimate risk concern is when corporate insolvency could result from the risk event occumng. Many stories exist about companies becoming insolvent due to unforeseen R&D problems, causing excessive R&D expenditure, or resulting in uneconomic production costs. So the first step is to set up a proper risk management plan to monitor and contain the risks. Offset of the remaining inherently large risks requires a different strategy, namely risk sharing [2]. The motivation for risk sharing is therefore, at the business level, and is a characteristic practice of companies in high-tech /high-risk/ high-investment industries such as aerospace, IT, and the auto industry, in which very large investments can be at risk (e.g. in excess o f f 100m). This paper considers contract arrangements in which only one party, namely the Principal, is responsible for the project or programme. Arrangements for sharing leadership are outside the scope of this paper.

Risk sharing partnerships 173 2 Risk Sharing Categories

Table 1 describes a range of contract arrangements to illustrate the main categories: risk not shared. risk sharing investors 1 subcontractors / partners. risk and revenue sharing participation. Table 1.

Typical Contract Arrangements

a) Non Risk sharing contracts Product Anything from nuts and bolts to subassemblies can be purchased

Philosop~v Generally, all project risks are handled internally.

Characteristic Management intensive interface.

Supplier R&D costs and production tooling are often paid for by the Principal.

Supplier risks are minimised by adopting a 'hands on' control of their tasks.

Supplier avoids responsibility and takes no risk

This approach may be because suppliers are not

b) Risk Sharing contracts with Investors, Partners and Suppliers Producl Risk Sharing Investors receive (high) rewards for investing in the project.

Philosophy Risk sharing is limited to the financial limitations of the investment.

They may ultimately get involved in production, later in the project life.

Risk Sharing Partners or Suppliers contribute to the project costs by doing R&D work, or may supply free components for the R&D phase, and supply components or assemblies in production.

NB Fixed price contracts are a special form of this.

Risk is taken on by absorbing the costs of their tasks when things go wrong (possibly to some agreed formula).

Characteristics The Principal carries the entire responsibility for managing the venture. The investor avoids the risks involved in what could be a difficult R&D Phase, and contributes only in the production Phase. The partners take on some of the Principal's management task

174

c)

Hough Risk and Revenue Sharing Participation

Product Risk and Revenue Sharing Partners.

Philosouhv They share proportionally in the sales revenue for the project

Invest in the project generally by doing work and contributing to the R&D phase. They supply components or assemblies in ~roduction.

They share losses as well as profits.

Characteristics Complete sharing of the risk associated with managing tasks and ultimately the success of the project.

2.1 Non-Risk Sharing An important characteristic of risk sharing is the degree to which a Principal can shed some of the management responsibility for the programme of activity supporting the project (or venture). Although the non-risk sharing arrangement gives a Principal company complete control across the range of project activities, it thereby carries the entire risk of the project, as well as the burden for managing it. This type of arrangement can breed a close coupled 'hands on' approach across interfaces with suppliers, even to the extent of directly managing the supplier's workforce. This allows the supplier to do only as directed, even if the decisions and management of the Principal generate wasted work. There is little or no incentive to improve performance under these circumstances. 2.2 General Risk Sharing Risk sharing partnerships avoid some of these deficiencies by requiring the subcontractor or partner to provide the investment for the R&D project tasks contracted. If this is a major subassembly, the investment and the management task will be significant, and the partner will need to set up his own management team and monitor his own costs. The production price paid for the subassembly by the project Principal will reflect these costs. Usually, the Principal is required to underwrite a minimum sales quantity, which when combined with the price, allows the subcontractor to recover his costs and generate a justifiable profit. This may be an optimum arrangement in many project situations. However, on becoming a success in production, the Principal may wish to revisit the contract terms, at or before renewal, to negotiate a price reduction. The subcontractor may also feel vulnerable to predator bidding by competitors, under cutting the price and supplanting their contract. The Principal may encourage this competition, and even auction contracts downwards to the lowest bidder without regard to the damaging effect on the current supplier.

Risk sharing partnerships 175 2.3 Sharing Risk at the Business Level

However, a development of the latter arrangement is to seek risk sharing at a business process level, namely in the participation in the overall success of the programme. The philosophy is one in which the total programme (i.e. the complete project lifecycle from concept start to service life completion, many years later) is shared among the Participants. Like stakeholders, they contribute to the costs and share in the rewards.

3 Risk Sharing Objectives

3.1 Motives and Incentives Sharing risk among partner companies and suppliers, will not usually reduce the total project risk, but merely redistribute it amongst the Participants. (Exceptions are sometimes possible by choosing Participants with leading edge specialist skills to match the tasks being undertaken.) The motivation for the Principal to share risk, is essentially driven by the business needs. By creating a risk sharing partnership, the Principal should expect not only to offset the consequential business impact of a risk materialising, but also that his own business case will be enhanced by sharing the investment. This will obviously be at some cost to the business case of the Participants. Thus, the programme Participants will also require an equitable incentive, to accept the burden of both the investment, and the risk associated with this arrangement. 3.2 Risk and Revenue Sharing Model To meet the expectations on both sides, a typical model developed involves the devolution of business accountability, consistent with the tasks and investments each Participant is contributing to the project (see Table 2). The role of the Principal is to provide overall programme leadership, to coordinate the efforts of the Participants, and may involve the Principal in a range of defined technical activities, normally in an integration role. The Participants pick up the responsibility for tasks contracted, together with the investment and direct risks associated with these tasks. Thus the model is summarised as a transference from the Principal to the Participants of the following:

task transfer. investment transfer. management responsibility transfer. reward transfer. Part of the programme leadership role of the Principal is to provide the marketing, sales and customer service activity. This is not usually a role which can be adequately performed by a Participant, although the Participant may bring customer contacts or even a strategic position within a particular market (e.g. by means of favoured supplier status, or in global trade offset).

176

Hough

Table 2.

Risk & Revenue Sharing Model Principal Task Participant Task Costs

Programme Leadership Programme and business integration Product R&D technical integration Marketing Sales Customer Support Warranty Administration Customer contract administration Risk and Revenue Partner contract administration

X

X X X

X X

X

Shared (Principal receives fees from the partners) [I*]

I

Technical Programme - Research and Development X (applies to [2*] Specification X(who1e Prototype design, manufacture product) X and test X subassemblies) Develop, qualifl Interface management X X X X Production Tasks Component/subassernly X X [2*1 manufacture X product final assembly, and check deliver X Other Programme Costs Shared sales discounts warranty costs [3 *I customer purchase financing inventory holding Revenue Revenue Distribution distribute pro New product sales revenue rata+ plus spare parts sales revenue Program share - less costs [3*] - less fees for Principal [I*] = net revenue which is distributed among all parties [2*] Principal and Participants each h n d their own costs in R&D and production parts which includes tooling and parts manufacture costs.

I

1

1

Risk sharing partnerships

177

4 Benefits of Risk Sharing to the Principal

The Risk and Revenue sharing model calls for Participants to share the investment risk. This directly reduces the scale of investment required by the Principal, and hence the financial exposure and investment cash flow is reduced. Even with simple risk sharing subcontract arrangements this can also be the case. A subcontractor will price his production component/assembly, based on amortising his development costs over a defined production quantity. He will write off his investment if the project fails, or take the loss if his component costs more to develop than anticipated. The transfer of responsibility in the model requires the partners to manage their own part of the project (e.g. the complete design and manufacture of a subassembly requires project management in its own right). Thus it follows that the principal may be able either to reduce the size of his project team, or reassign it to other projects. Not only would this apply to the R&D project staffing, but also to the Purchase staff, since there is a corresponding opportunity to simplify the traditional role of purchase, in line with this transfer of responsibility. Effectively this should reduce the costs the Principal has to bear, by increasing the costs the partner has to bear. However, it is often the case that in comparison to the Principal (who is more likely to be a larger corporation), the subcontractor's overheads and labour rates may be smaller, and hence this would turn out to be a reasonable trade. The model also requires participants to retain ownership of their share of production inventory until the 'end customer' has taken title to the product. Not only are warehousing costs and insurance shared, but also the risk or cost of old stock becoming obsolete is shared. Furthermore, the Principal will not pass revenue to the partners until he himself has received revenue from the customer, which could be 30, 60 or even 90 days after title has passed to the customer. This eliminates negative cash flow on production inventory payments to partners, and ensures the risk of cash exposure, should the customer fail to pay, is also shared. In summary, the model for Risk and ~ e v & u eSharing enables the project Principal to achieve the following: Reduce R&D financial exposure. Reduce R&D cash flow. Reduce size of organisation and hence internal costs. Reduce production inventory warehousing and management costs. Eliminate negative cash flow on production inventory payments to participants. Reduce cash exposure, if customer fails to pay. These benefits can ultimately swing a project launch business case from being unacceptable to acceptable, and successfblly allow a launch decision.

178

Hough

5 Benefits to Risk Sharing Suppliers and Partners

By engaging in the risks associated with a particular part of the project, the supplier is in a position to negotiate more strongly for benefits. The prime negotiating element is often the right to a continuous production share for the life of the product. The objective is to eliminate the chance that other parties could bid successfUlly at some later point in the programme. Many Principals and suppliers now seek long term deals which not only guarantee production share and the right to new product work on the one side, but also formulated price levels and responsiveness to programme change on the other. The Model ensures continuity of position by all participants, and such relationships last the complete lifecycle of the product. Additionally, the participant's production programme share, i.e. the right to participate in the sales revenue stream, can conceivably be sold to other worthy parties (by agreement with the Principal), as the production programme builds up and becomes successhl. The sale of a programme share implies an intrinsic value, and therefore can be seen as a company asset. Other benefits are the right to participate in the next product development, the possible prestige value of being a programme partner rather than supplier, and the means to enter a competitive market, which might otherwise be difficult to enter.

6 Costs of Risk Sharing Arrangements

In any programme, with or without risk sharing, there are a number of management tasks which have to be absorbed into the costs of running the programme. Typically these tasks are: Business and Programme Management. Marketing and Sales. Contract Administration. Supplier Administration. Product assembly, delivery and customer support. These tasks are generally the responsibility of the Principal, and unless contracted otherwise, the costs of these activities will also be his responsibility. In the Risk and Revenue model, these tasks are hnded through the partnership, and are seen as service to all Participants (see Table 2). However, one should also compare the cost of running one arrangement against another. So for example, how expensive is a Risk and Revenue arrangement to operate compared with a simple supplier arrangement? In simple contracted supplier arrangements, the administration task is as first sight expected to be relatively low cost. Suppliers are contracted by the Purchase staff to supply to meet the requirements (either in the R&D or Production Phases). However, the risk is carried by the Principal, and as indicated in Table 1, the Principal may need to initiate intensive management of the Supplier to correct performance problems, affecting quality, deliveries or hnctionality. Not only will this involve Purchase staff,

Risk sharing partnerships 179 but also more highly paid specialists and managers. Consequently, this approach can become quite expensive. In contrast, the Risk and Revenue model requires the Participants to pay for whatever contingency management activity may be necessary. Their responsibility is to deliver to the agreed specification, quality and schedule. However, the Risk and Revenue model requires additional administration in the context of the following: Revenue distribution. Evaluation of tasks and corresponding percentage values of the total programme. Programme Status and Prospect reviews with the Participants. Correspondingly, all Participants need to assign staff to administer this contract, and this adds to the overall cost of the arrangement. The relative costs of the range of options varies depending on the following: Size of programmelproject. Complexity and Value of components being supplied. Interface and dependency complexities (between SupplierPartner and Principal). A rating of costs are shown in Table 3 based on typical expectations. Whilst this may provide some guide in assessing which type of contract to aim for to suit the project, the guide in Table 4 also provides a clearer view as to what circumstances these are suited to.

Table 3.

Relative Costs of Contracted Arrangements, costs as experienced by the Principal

Activity

Non Risk Contracts

Cost of interface management effort to control supplier output

High

Risk Sharing Risk and Suppliers and Revenue Sharing ~ubcontractors Medium Low

Management effort to agree and administer supplier I partner contract

Low

Medium

High

Change control administrative effort

Low

vedium

Medium

Production programme instruction and inventory control

Medium

Medium

Low

Payment1 revenue distribution

Low

Medium

High

180 Hough

Table 4.

Choice of Contract arrangement

Type of Contract Non risk contracts

Characteristics Low cost, low risk components or services. May lead to management intensive interfaces with suppliers which could prove expensive.

Risk sharing suppliers and partner contracts

Suited to high tech, high-risk products. Medium to high programme investment size. Sufficient industrial strength of parties to take on the investment risk.

Risk and revenue sharing contracts

Overall size of programme needs to represent a large investment (e.g. around &loomin aerospace industry) High investment and risk level required by participants demands high industrial strength of participants Interfaces with participants may become complex High technical risk projects Highly competitive, risky market scene Principal has to perform many project coordination and business tasks, the cost of which will be shared by the participants.

7 Problems of Managing Risk Shared Projects

In general, risk sharing inevitably makes the practical aspects of running a project more difficult. This is because tasks and task responsibilities are devolved as described in section 3.3. Thus, the organisation running the project, namely the Principal, will need to set up interface controls and reviews with the participants. Although this would in part be true of any contract types, the difference with risk shared arrangements are that the Principal may not have:

Freedom to decide on issues which affect the business case. Freedom to make decisions which influence the risk levels of the programme. Freedom to step in and manage the activities of Participants if they are failing to deliver. Consequently, the terms of the contract need to address these issues and accommodate an acceptable relationship to all parties. The model requires careful evaluation of programme share, both in the R&D and production phases. The Principal and Participants can absorb significant resources in this activity. The process can also be complicated when technical change impacts their efforts. The contract needs to address equitable arrangements in these and other detailed situations. Finally, the comfort level of project managers may well be lowered, due to the fact that they have no direct control over the activities of the Participants, and in many respects management has to develop a more mature mode of mutual trust in which

Risk sharing partnerships

181

personal relationships become important. This is certainly the territory of diplomacy and tact for which not all project management personnel are suited. 8 Conclusions

Risk sharing contracts are more suited to high tech, high-risk projects in which uncertainties also exist in sales and price due to market competition or trends. The Risk and Revenue Sharing model, discussed at length in this paper, is business oriented, and involves devolving responsibilities for tasks, investment and risks across a partnership. Some risk reduction may be possible by choosing partners to undertake tasks corresponding to their speciality. More complex arrangements generally make the task of coordination and management of the programme more onerous and costly. However, for some projects, this provides the only route to achieve an acceptable business case for project launch. Finally, attention to the contract details is essential to ensure adequate motivation and equitable risk and revenue arrangements are set up.

9 References

Chapman, C. and Ward, S. (1997) Project Risk Management - Processes, Techniques and Insights, John Wiley & Son Ltd, Southampton. Ritchie, B. and Marshall, D. (1993) Business Risk Management, Chapman & Hall, London

No-risk move from TQM to IS0 to boundaryless organization T. AL-SULIMANI and D. SHARAD Advanced Electronics Company, Riyadh, KSA

Abstract The TQMization process, that is, introduction and implementation of Total Quality Management, is a never-ending process. However, once introduced properly, it lends itself for letting the organization prepare for IS0 9000 Certification, and go beyond that. Boundaryless Organization (BO), a dream even for industry giants, can be targeted after TQM and IS0 are attained. A story based on practical experience is narrated here to illustrate the transition from TQM to IS0 to BO. Keywords: Boundaryless Organization, ISO, Management By Projects, Reengineering, TQM 1 Introduction In recent years, we have heard a lot about Total Quality Management (TQM), Business Process Re-Engineering (BPR), Boundaryless Organization (BO), and Quality Management Systems through IS0 9000 (ISO). And, we have seen countless accounts of cure-all theories and experiments in the management of today's organizations. Nobody questions anymore the pressing need of changing whatever management styles or organizational approaches that are used in the past half-century to keep up with the maddening pace with which technology is advancing, clients' demands are increasing and markets all over the world are expanding amid cut-throat competition. Apparently, there is a risk involved in forsaking the way business has been conducted with the ingrained company culture that evolves with proven policies, procedures and processes. The risks and fears are natural in having to adopt new approaches that require significant changes in all this, including the attitudinal overhaul to be accomplished among the entire rank and file of the organization. They are compounded when one Managing Risks in Projects, edited by K. Ki4hkirnen and K.A. Amo. Published in 1997 by E & FN Spon, 2 4 Boundary Row, London SEl SHN, UK. ISBN: 0 419 22990 6.

From TQM to boundaryless organisation

183

hears conflicting stories about successes and failures even among industrial giants.

In this paper, a story based on practical experience is narrated, outlining a successful attempt at catching up with the times in managing a growing business organization. It describes the transition in the management approach from TQM to IS0 to BO that continues to be accomplished with patience, forethought, and forceful deliberation by corporate leaders.

'

The secret for success was found in the leading role that the Human Resources (HR) function was called upon to play in using the Management By Projects (MBP) approach for careful planning, training, and implementation for each progressive phase of organizational transformation.

2 Let's Start with TQMization Let us make you the hero of this real-case story! (TQMization, by the way, is intended to mean introducing and implementing TQM. You discover ultimately that it is actually no more than management by common sense.) Let us begin with an assumption that you are the founder-president of an international, manufacturing company in the business of electronic components for telecommunication systems. You have gone through the usual stages of starting and developing your company, namely: 1)

2)

3)

4)

5)

Marketing/Financing. Studying the market, seeking out clients and financiers, formalizing company goals and setting up the business strategy. Organizational Planning. Determination of required functional units to fulfill company objectives, and carry out necessary business activities. Policies & Procedures. Establishing the company policies and operating procedures to facilitate interfunctional activities, evolving as the company grows. Stafing. Selecting right personnel for the required positions, establishing salary administration and employee benefits and training programs. Informution Systems. Utilizing computer technology to generate information necessary for management analysis and corrective actions, and employee and client feedbacks as required.

In about four years' time, the business picks up and sales rise and you begin to show profits. You also recognize that your customers are getting to be more demanding, and competition is becoming tougher. You start exploring various ways to sustain the growth and do even better. This would include considelrations to: (a) improve quality and productivity, (b) restructurelreengineer your organization, (c) look for new product lines or diversify, (d) expand facilities, (e)% enhance e~rnployeebenefits to retain and attract best talents from the industry, (f) intensify R&D efforts to attain technological edge over competition, and so on. [I] By now, you have acquired higher business acumen yourself, and hopefully have competent senior and middle management support. On your own initiative, or one from

184

Al-Sulimani and Sharad

a senior executive, you discover the marvel of TQM being either practised by a competitor or taught somewhere as a seminarlcourse. You study what TQM is all about, and recognize its potential for application to your organization. You decide to go for it. You knew the value of customer satisfaction all along, with a focus on quality in your products and in services you provide. As you and your colleagues come to know more about TQM, and its ramifications and the success it brings, you distinguish it from Quality ControlIAssurance (QCIQA), and begin to value the role of quality thinking, or quality culture, to be invoked in the entire management process. You recognize the importance of each employee having to satisfy internal customers. You appreciate the practical significance of the slogan of "customer satisfaction through employee satisfaction", which one of your colleagues coined. You appoint someone, who has lived TQM, as a Director-TQM, reporting to you, and let your people know that you believe in TQM and strongly support its initiation in the company. You invite a management consultant to make a 1-day presentation to all your senior executives and managers, and a 2-day workshop for all professional staff and supervisors so that they find out about the basic concept and associated tools and techniques, and can actively contribute to the process of introducing TQM in the company. You follow it up with a half-day exposure to the rest of the company personnel so that they all begin to share a common TQM vocabulary, and appreciate the role each one has and can play in the TQMization process.

2.1 Action Items to Initiate TQM For simplicity, let us enumerate various steps that you go through after the indoctrination phase is over. This is what you accomplish with the help of you staff: 1)

2)

3)

4)

5) 6)

Establish a Vision and a Mission Statements, clearly delineating where you and your senior colleagues want the company to be eventually, and what the overall business goals are. Also formulate a long-term business strategy. Develop a 3-year business plan, rolled over each year with a 12-month operating plan, and specific objectives identified by each functional group in keeping with overall company goals. Identify Conditions of Excellence (COEs) and Pulse Points (PPs) as critical success areaslprocesses and indicators of performance and improvements. Conduct a quality fitness review (QFR) by interviewing about 20% of the employees from across the organization to gather their viewslsuggestions about how the company is doing in each success area and in the TQMization process. Determine the strengths and weaknesses or areas of improvement. Select those areas of improvement that otherwise do not fall within normal responsibilities of any functional unit, and require a multidiscipline resolution, and form quality improvement teams (QlTs) to address them. Formulate a yearly TQM Plan covering all the deliverables resulting from the above, and obtain commitment from those responsible. Carry out the TQM Plan during the year, evaluate the accomplishments against its objectives and those of the QlTs. Conduct TQM related in-house

From TQM to boundaryless organisation

7)

8)

185

presentations periodically. Include the subject of TQM in the orientation sessions conducted for new employees. Initiate another QFR and repeat the above steps with new status. Start an instructional publication, or expand your company newsletter, to cover TQM topics. Consider a TQM campaign every other year with posters, awards for best suggestions, best QIT performance, etc. to rejuvenate the TQM spirit and maintain the tempo of ongoing implementation. Remember, TQM is not a destination, it is a journey!

This is a good place to point out the relevance of the Management By Projects (MBP) concept that you see as very pertinent. We may digress from our story briefly to understand the MBP approach.

3 Understanding Management By Projects (MBP) Management By Projects (MBP) is a valuable approach to conduct any business activity; it is a way, an outlook, an attitude cultivated to treat any work item, undertaking, scheme, assignment or a set of activities, as a project. As an essential adjunct to TQM, MBP very much facilitates TQMization. It provides the basis to carry out a business like a project, with a systemized process of planning, executing and controlling. This happens in a more formal way on a project of significant size and complexity, where a project leaderlmanager is designated to manage it. A team of specialists from relevant functional groups is given to him for design, purchasing, productionlconstruction, etc. He is responsible to lead the team into completion of the project and accomplishing the desired results. Implementation of TQM itself can be, and truly has to be, established as a project. Each QIT, dedicated to improving a given process, can be considered as a project team for that improvement as a project. MBP helps immensely in making it easier as you develop the following perspective. The parentheses refer to the usual project management terminology to show the interrelationship.[2]

3.1 10-Point Action Plan for MBP-Oriented TQM 1.

2. 3. 4.

5. 6.

Invoke Management Awareness. Establish Philosophy, Mission. (Management Style, Company Culture) Acknowledge Potential for Improvement, across the Hierarchy. (WorWOrganization Breakdown Structure, WBS/OBS) Develop a Quality Improvement Program (QP). Identify Projects. (Master Implementation Plan) Establish Project Teams by Functions, Services, Products, Processes. (Matrix Management) Let Teams Select Problem Areas for Resolution and Effectiveness. (Scope, Budget, Schedule) Communicate Results, Teams' Report Cards. Arrange for Discussion Forums.

186 Al-Sulimani and Sharad

7.

8. 9. 10.

(Communication) Encourage Suggestions and Self-Development Goals among Employees. (Human Resources Development) Impart Traininghdoctrination before Implementing Changes. (Training) Maintain Ongoing Q P Tempo. RevisitlReassessImprovements. (Followup and Review) Participate in MBP/TQM Related Industry Activities. (Professional Upkeep, Public Relations)

It is not too difficult to see that management by projects and total quality management are quite complementary concepts essential to successful business management. You accept this connection, and further look around for a way to keep the TQM effort going and growing.

4 Finding a Home for TQM

In view of the involved nature of the TQM implementation, and the extent of functional coordination required for the QlTs, etc., you see a need for some organizational adjustment. You notice that in addition to the Director-TQM, you have a Director-QA, a Director-Training & Development and a VP-Administration. You have realized that for generating the new TQM culture, what needs to be imbibed among all employees is the right attitude toward work and coworkers, ownership and quality of work, and employee empowerment. Human Resources Management (HRM) or Administration has a very fundamental role to play in this regard. HRM's emphasis on developing, training, and managing people is reinforced with the TQM outlook. Continuous improvement and training/development are both central to HRM and TQM, which makes them natural partners. HRM has always been a key staff function in any organization, being involved with people from their entry through exit. The line functions need HRM's support, and HRM needs inputs from them to help them in turn. This is a situation where the internal customer-supplier concept inherent in TQM application comes into play in a most profound way. [3] The compatible or common aspects for partnership between TQM and HRM are: (1) Mutuality of people relations, (2) Creating corporate culture, (3) Training and development, (4) Company policies and functional procedures, (5) Attainment of quality through personallpersonnel indulgence, (6) Continuous improvement in the company's products, processes, procedures and services, and (7) Customer satisfaction through employee satisfaction. You now take the decision to ask HRM to take the lead in TQMization. You, in fact, establish a new functional entity, VP, TQM-HR, which consolidates (Personnel) Administration, and Training and Development with TQM. TQM now finds a permanent home in your organization.

From TQM to boundaryless organisation 187

4.1 Documentation of Policies and Procedures Another key activity, namely, Policies and Procedures, has been at the core of the TQMization process, as it helps document the existing workflow, and reflects any organizational changes or new developments in the functioning of any department. Changes are also brought about by the working of the QITs. You recognize that procedures are important, because they bring orderliness in our jobs. They prescribe a preferred sequence of activities, and identify responsibilities to be shared by people for desired results. They provide an easy training tool to familiarize employees with departmental activities. They help us in pursuing our business strategy and objectives. You establish the policy that department heads, managers and supervisors are responsible for developing, maintaining, updating and implementing procedures pertaining to their own functions. They ensure that other functional groups affected by their procedures are consulted before publishing them. You stipulate that TQM-HR should act as the facilitator-coordinator for all company policies and procedures, and provide the necessary assistance in preparing, editing, streamlining-publishingcontrolling distribution and revising as needed. TQM-HR, through a QIT for Procedures Improvement, regularly reviews each department's procedures to ensure practicality, simplification of forms, and elimination of any duplication or redundancy. QA continues to enforce quality in products through inspection for adherence to customer/other requirements. However, you come to know now about the intemational standards IS0 9000 series, which could give QA a new, bigger role to play. You are thinking about IS0 certification.

5 Getting the IS0 Certification The foundation for the international IS0 9000 certification movement rests on the Quality Assurance/Quality Control (QAJQC) approach, which advocates stringent technical specifications, and operating procedures, detailed documentation, qualifying training, and additional levels of inspectionlreview and approval. Whereas, TQM is an operational management philosophy with client satisfaction in the center, surrounded by concerted, dedicated and continuous efforts for improvement in results. IS0 9000 is a guideline for attaining an acceptable level of performance using the prescribed QA models for design, production, installation, inspection, testing and servicing. IS0 9000 and TQM are not mutually exclusive, but are rather complementary concepts.

Being initiated already into TQM, you find IS0 9000 certification much easier to acquire due to quality management being established as an ideology, a system and a function, operational policies/procedures being in place, and employees being in proper quality fitness already. The models for certification accepted as the highest intemational standard of Quality Assurance include: 1.

IS0 9000, Basic definitions and concepts; guidelines for using the 9000 series.

188 Al-Sulimani and Sharad 2. 3. 4. 5.

IS0 9001, Model for QA In Design, Development, Production, Installation & Servicing. IS0 9002, Model for QA In Production, Installation & Servicing. IS0 9003, Model for QA in Final Inspection & Test. IS0 9004, Guidelines for Total Quality from initial identification of market needs to satisfaction of customer requirements.

I S 0 9000 models, like TQM, are intended to inspire quality thinking among their users such that they establish a suitable quality management system as a good business practice rather than a statutory requirement. QA requirements of these 9000s are complementary and not alternatives for technical specifications for a given product. Notable points about IS0 are: $ Not intended to impose uniformity of Quality Systems; allow flexibility to tailor to a business's needs. $ Generic, independent of any specific industry or economic sector; promotes Quality Culture. $ Subject to Evidence of: Policy, Plan, System, Management, Implementation, Control, Improvement For Quality Assurance. $ Careful Documentation: What is being done in each functional area, and how & why it is so done to be documented as verified evidence reflecting reality. (Say what you do, and do what you say!) $ Companywide Training: IS0 9000 overview, procedureslwork instructions, internal audits. $ Implementation: Effective internal audits, feedback from users, management reviews. $ Preassessment: Preferably by an IS0 certified customer or consultant, not by "registrar" auditors; non-conformances to be removed. $ Assessment: Criteria determined before audits; a registrar may do a prior "Desk Review". With the help of the outside consultant, you carry out the IS0 project with QA's lead, and win the certification in less than six months. You obtained IS0 9002 Certification because you happen to manufacture per customer's design at this time. As you move into designing your own products, you will go for IS0 9001. You now have an Internal Auditors' Team formed and trained to conduct at least once-a-year audit of dl processes and implementation of procedures. The Team will also prepare for the &monthly followups done by the IS0 certifiers. Now, I S 0 is being looked upon as a positive move ensuring consistency, compliance and cooperation among functional groups. During I S 0 preparation, the focus shifted from improvement and innovation to conformance, streamlining and stabilizing. You build confidence that quality awareness is all-pervading in your organization, which is in tune with the internationally recognized management practices. 6 Boundaryless Organization, A Dream

Now you turn to fulfilling the ultimate dream even of industrial giants to develop the

From TQM to boundaryless organisation 189 ideal organization, one without any boundaries. You read about the four types of boundaries that characterize most organizations: (1) Vertical, between status-driven levels & ranks of people, (2) Horizontal, between functions & disciplines driven by specialization, expertise, socialization, (3) External, between the organization & its suppliers, customers, regulators, and (4) Geographic, between nations, cultures, markets. [4] Boundaryless organization (BO) entails understanding and changing human nature and company culture. It requires a different state of mind, free from personal biases and parochialism. It thrives on an environment of openness and cooperation for the common good. There is no room for ugly rivalries and corporate politics in BO. This can result from congenial rapport established by extensive personal communication among employees and supervisors and managers, and taking them into management's confidence, through personal interviews, company bulletins, and use of well-designed questionnaires for building boundaryless strategies with their participation. You realize that the chief executive has to set an example of professional behavior, of open mind and forthrightness, for others to emulate. Whoever can contribute value - whether he or she is a production worker, middle manager, specialist, vendor, or customer - needs to be encouraged to collaborate with others and make things happen, without waiting for being asked, or for permission from some central authority. The old questions of status, role and all traditional boundaries that we have used for years to define and control the way we work, are much less relevant than getting the best people possible to work together effectively. There are many interesting ideas relative to BO; here are some highlights: 1. Boundaryless behavior is not about eliminating the organizational hierarchy and administrative procedures and rules. It is about the threshold of pain and patience, and of entrepreneurship, when creating new patterns of collaboration, learning, and productive work. It is about removing the restrictions, real and imaginary, imposed on individuals and teams by formal structures. 2. Becoming boundaryless is not easy for most senior people; it often sounds threatening and risky. After all, it means transferring decisionmaking authority away from executives and out to frontline workers; it means listening to customers and changing our products, delivery systems and services to meet their needs; it means forming partnerships with our suppliers; and it means establishing coalition with others in the company rather than defending our turf. This means that the role of manager, executive, and leader changes drastically from controller/authority and "boss" to stimulator, facilitator, catalyst, cheerleader, coach and "friend". 3. To become really boundaryless, we have to try substituting watertight concrete partitions or separators (vertical, horizontal, geographic & external) in our organization, taking a biological view of boundaries, with permeable, flexible membranes in a living, evolving organism. In a living organism, membranes exist to give it shape, definition and strength to prevent it from a collapse into an amorphous mass. Yet they are permeable. Food, blood, oxygen, chemicals, etc. flow through them relatively unimpeded

190 Al-Sulimani and Sharad

4.

5.

such that each part of the organism can support others. So it is with the boundaryless organization. Information, ideas, resources and energy pass unimpeded through these membranes. There is a need to develop a new managerial scorecard in search of high collective performance, and prescribe a new focus on speed (not size), flexibility (not rigidity, disguised as role clarity), integration (not specialization), and innovation (not control of status quo). The exhilarating task of transformation to a boundaryless organization requires leaders to face the following challenges: Transform for tomorrow while doing business today. $ You cannot stop what you are doing now to focus exclusively on future. You have to ensure that your focus on short-term results does not compromise your long-term agenda. Look for trends as you act on current data. Manage an uncontrollable change process. $ Inevitably, handling changes in one variable (like shifts in levels of hierarchy) will influence other variables (like ways in which functions work together). The essence of creative management lies in channeling the tremendous energy unleashed by letting people have the opportunity to control their own destiny. Lead to an unclear destination. $ The indefiniteness of the boundaryless end state derives from the corporation becoming a live entity in the process of evolution ("a journey, not a destination", like TQM!). The challenge for executives is to get comfortable with the anxiety that an undefined end can generate. $ Deal with disruption. Shifts in roles and career definitions have enormous implications for people as the organization is driven for speed, flexibility, integration and innovation. Those who can not cope with this face career disruptions, layoffs, and family crisis. The challenge for leadership is not to be hardhearted, but help everyone be realistic about how to succeed in the transformation despite one's limitations. Confront the need for personal change. $ Instead of driving decisions, leaders need to drive discussion, and instead of ordering, have to create buy-in. The boundaryless world will be a new world for leadership as much as for the troops. Personal shifts toward new styles of boundaryless leadership will require looking at the familiar face in the mirror and asking him to change.

You know, of course, that all this boundarylessness is easier preached than practised! However, when you consider from where you started, and how far you have come in less than six years, you feel that you are not too far from where you want to reach. You have successfully created quality consciousness, team spirit, and sense of common struggle and resolution to move on and up collectively. You have created teams for studying and settling issues, and you have reduced or consolidated functional units. You have established rules of the game that people can play and enjoy with a

From TQM to boundaryless organisation 191 boundaryless open field. You admit that you could not have done all this alone. You had help from your senior colleagues and your employees, and from the industry at large, for feeding you good ideas and enlightening you with the latest management practices. You have concluded that TQM, ISO, BO, business process reengineering, etc. are more or less synonymous. A robust common sense with honest intentions, and a lot of good luck, are the prime prerequisite for succeeding in business.

7 THE MORAL LESSON The moral lesson of this story is that with patience and perseverance, a dynamic, fearless leader can lead an organization in its evolution from formation to becoming a successful business. The journey through TQM, IS0 and up to an ideal BO is fraught with difficulties. People resist change, as the cliche goes; but people can change if they see no hidden dangers, see potential growth and professional recognition, a spirit of wellmeaning experimentation, and sincere camaraderie among coworkers and senior management. As a leader, you have to develop an unsatiating appetite for learning, a real passion to grow and the desire to take your fellowmen with you. Enthusiasm could become contagious, and could spread among your people like wild fire.

8 References 1. Sharad, Dick and Sulimani, Tarik. (1994) "Advent of TQM in Saudi Arabia." Proceedings of 38th Annual Meeting of the American Association of Cost Engineers, AACE, San Francisco, CA, USA. 2. Sharad, Dick. (June 1993) "TQM Through MBP." PMNetwork Journal, Project Management Institute, Drexel Hill, Penn., USA. 3. Sharad, Dick. (1995) "Transition in HRM Through TQM." Udyog Pragati, Special October-December Issue on "Managing Transition", National Institute of Industrial Engineering, Bombay, India. 4. Ashkenas, Ron; Ulrich, Dave; Jick Todd and Kerr, Steve. (1995) "The Boundaryless Organization, Breaking the Chains of Organizational Structure." Jossy-Bass Publishers, San Francisco, Cal., USA.

PART 5

PROJECT RISK MANAGEMENT IN DEVELOPMENT, SOFTWARE AND RE-ENGINEERING PROJECTS

Method of reliability analysis in the project information management process R. GAUTIER, P. TRUCHOT and T. GIDEL Laboratoire Conception de Produits Nouveaux, Ecole Nationale Supkrieure d 'Arts et Mktiers, Paris, France

Abstract The object of this paper is to propose a method of project risk management in new product design. This method, called Project Information Failure Analysis (PIFA), is destined to project managers, within the scope of quality assurance methodology (IS0 9001). It is based on an original concept of project modelling in the form of information processors. The concept that we propose enables risk failure analysis of these processors and studies the effect of these failures on the different project scenarios developed with processors. The method contains a preliminary forecast analysis when the project scenario is developed, a corrective analysis during project management, and allows to capitalise on the acquired experience concerning risks management for future projects. This method has been applied until now in addition to methods of costs and time management in focusing more particularly to the capacity of a project to ensure that technical requirements of the product are reached. It has been applied in a spirit of quality assurance in new product design. Keywords: failure, functional analysis, information, process, product design, project risks, quality, reliability.

1 A project manager's responsibility: risk management in project Projects of new product design take place generally over several years. They put in relationship several disciplines, and necessitate a great number of resources. Consequently, they are exposed to risks deriving from these factors, and their combinations. These risks could be defined as the possibilities that a project does not meet estimates of date completion, cost and specifications. These gaps, as compared to estimates, are being considered hardly acceptable or even unacceptable [I]. Managing Risks in Projects, edited by K. KLLhkOnen and K.A. Artto. Published in 1997 by E & FN Spon, 2 4 Boundary Row, London SEI 8HN, UK. ISBN: 0 419 22990 6.

196 Gautier, Truchot and Gidel

Some talented project managers have the potential to anticipate risks and to develop strategies to decrease some effects. But for most of them, it is necessary to include in the project organisation, activities of identification and risks analysis. The experience of the project manager is very important in estimating risks. But he is limited by his capacity to extrapolate risks, from his own experience, in cases of unusual projects. This is why, without a recognised methodology, decisions implying risks for the project can be judged on a very irrational manner. According to the result, it can be either brilliant or foolish. We consider that this personal value judgement is too restrictive. It does not develop a spirit of quality assurance. The use of a methodology in project risk management is therefore necessary. But which method? 2 What concept of project risk management?

There are several methods to be considered. Some are based on check-lists [2] [3] [4]. Others are based on statistical methods to establish criteria conditioning the success or failure of a project [5] [6] [7]. The third way in our research consists of building a conceptual model of the new product design process in terms of functions to which it is then possible to attribute probabilities of failures [S]. These probabilities are considered as being risks. The methods that we have identified are interesting because they answer in a practical manner the need that we have defined concerning project risk management, in the scope of the implementation of a quality approach in project management. Focused on the identification of risks, they become tasks of management and control of planning and costs. These methods show that meeting costs and deadlines are important for the success of a project. But what lacks in all these approaches is the third aspect of project success: product quality. This quality is developed from the design stage. To do so, there are design techniques, but it appears to us that no method makes the link between product design quality and project design quality. We can now identify the bridge remaining to build between product design and control of the project management process. We have therefore focused on the need for modelling projects of new product design as processes whose failures are identifiable. These failures have consequences that one can formalise in relation to product quality. 3 Project functions definitions

The functional analysis of a new product design project brings us to identify the elements linked to the external environment of the project. They are: 1. Clients'needrs:these are expressed in the form of preliminary data, that are going to be improved, modified, completed during the project. 2. Information deJining the solution: this solution is expressed in the form of output data, and is the achievement of the project at the end of development. These data are going to be used to find the solution.

Risk in new product design 197 3. Development schedules and costs: they are imposed by the company, as well as for material and human resources that are put at the disposal of the project manager and his team. The main hnction of a project can be then defined as acquiring, transforming and distributing information, allowing to define a solution to clients'needs concerning the hture new product. The adaptation of the project to criteria of cost, schedules, and use of already-defined resources are constraint hnctions (Fig. 1). A project can therefore be modelised as being a sequence of information treatment processors (Fig. 2). These processors have their own reliability, and their organisation confers to the global project the capacity to reach the objectives (Fig. 3). On the one hand at the level of processors potentiality to have failures, and in the other hand at the level of the relation of these processors between themselves. The purpose of this method is to identify and to evaluate risks, in order to classify and to process them.

Fig. 1. Functional Analysis of project management.

Fig. 2. Information treatment processor

200 Gautier, Truchot and Gidel detection). For major corrective actions, the type of project is unacceptable in terms of risks and is corrected according to the risk analysis. When there is no corrective action, the project is unchanged, risks being taken with full knowledge of the facts. Alternative scenarios are defined to reorientate the project, if necessary, in failure. 6. Scenario cho~ce:the choice of the first scenario is made in comparison with the critical function steps of each of the scenarios. Non retained scenarios are kept as alternative solutions, if necessary, during the project. 4.2 Corrective level During the project reviews two cases may appear

1. i%e project is conducted as expected: the evaluation of the project leads to suppose that the finality of the process fbnctions have been understood by those who were in charge of it, that those fbnctions have been the object of relevant task definitions, that necessary information for the execution of these tasks have been identified and taken into consideration in a relevant way, that these tasks have been correctly executed. This positive evaluation allows to relativise risks that were supposed to be taken initially. and to validate preventive measures taken thanks to the Project F.M.E.C.A., to the level of some functions of the process. 2. Xbe project has jailttres: the analyse of this evaluation can be a problem in the determination of the failures reasons. Several hypotheses can be taken into consideration: the finality of the process enctions have not been understood by those who were in charge of it , they have been the object of non relevant tasks definitions, that necessary information for the execution of these tasks have been badly identified or taken into account in a non relevant manner, or that these tasks have been badly executed. It is therefore necessary to establish a precise diagnosis to settle corrective actions for the on going project, and to define reliability actions for fbture projects. 5 Definition of the proposed Project F.M.E.C.A.

concept

The fbnctional analysis of the new product design process has allowed us to define several processors that can be assimilated to components of a product. These processors fill fbnctions. This is at the level of the study of failures of these hnctions that a risk analysis will be possible. 5.1 Example of information processing functions on a generic model As an example of a Project F.M.E.C.A., we can define information treatment processors as being those having for inputloutput the different states of the life cycle of a product (Table 1). Product design process failure modes are expressed then on the levels of acquisition, processing and distribution of information. This work is realised in the scope of the project team. The experience and the creativity of each is necessary to identify these failure modes, causes and effects (Table 2).

Risk in new product design 201 Table 1. Example of function analysis: Functional Expression of Need information information processingcollection collect the products to translate the perception of the client need in marketing cost functional terms: -to express service and constraint functions -to associate to these functions and constraints an evaluation, their level and flexibility

information transmission write the products functional cost

Table 2. Example of function F.M.E.C.A.: Functional Expression of Need tasks: modes of elementary function failure G P.a. P.n.d C main function functional expression translation in functional terms of the client's * misinterpretation 9 1 9 CM * mid-term 3 3 1 Cm perceived needs 1 9 1 Cm * in term of solution bad appreciation criteria 9 1 3 Cm 3 1 9 CM error of level 1 9 9 Cm maladjusted flexibility 5.2 definition of the critical step The critical step is defined by C= gravity x failure probability to appear x Probability of non-detection of the failure. The know-how and the experience of the enterprise are used to establish a scale of value of the gravity, the risk of appearance of a failure and non-detection of a failure. The gravity is evaluated by notes allowing to differentiate clearly the critical steps of functions, in order to focus on the most critical. It is not to analyse the absolute value, very precise, of each critical steps, but their relative value. Indeed, notes attributed to the different parameters of the critical steps include a great part of subjective value, and choices of a project organisation are never totally rational. We have retained a scale of the 1.3.9 type (Table 3).

Table 3. Scale of value for gravity, probability to appear and non-detection of a failure probability to appear probability of non-detection note gravity/consequence on product qualification 1 weak weak risks weak risks 3 important in time or cost important risk important risk terms for product qualification 9 non-qualification of the very important risks very important risks

6 Conclusion on the method of project risk management proposed

In New Products design projects in which we have experimented this method, we have been able to observe the project team members' initial reluctance, to consider and to

202 Gautier, Truchot and Gidel

expose risks of project failure in a formalised manner. Moreover, the difficulty to imagine the consequences of these failures, appealing to experiences whose transposition is not always obvious, can lead to doubts on the efficiency and therefore the interest of the method. But these first difficulties of the method overcome, we observed that, when highlighting the capacity of the project members team to anticipate risks and to manage effects of failure of their management information system, it was motivating for them to persevere in the application of the method. This constant attention about risks, during all the stages of the project, from design associated with the conventional techniques of project management and quality assurance, allows new products development at conditions the enterprise did not dare envisage at first. The method of project risk management that we propose partially answers the project managers needs in terms of quality assurance: to give confidence a priori, to perform well the first time, to capitalise the know-how in order to use it again. It can be considered as a complement to project management techniques because this method helps the analysis of the risks of failure to comply with quality requirements, by faulty management of information related tasks in a project, and not resulting in defining a hiquality product. This method is mainly qualitative, it is based on experts advice, which is often subjective. It involves building a conceptual model analysis with a voluntarily simple use. It is not sure indeed that a complex method brings a substantial gain on the visibility of the project risks evolution. It is almost certain, on the other hand, that a too heavy method is rapidly destined to desertion, project managers and their teams being in general very busy. It has not the goal to give a guarantee, inevitably illusory, of control of all the risks of a project. On the other hand, it allows to federate a project team around risk management of a project, and more especially risks due to the circulation of information. The method registers the project team in a continuous improvement dynamics, in a spirit of projects management quality. The field of application of our method is new industrial products design. Steps taken into account by this method start with the perception of a latent need of qualification of the definition of the product. It is an evaluation and communication tool which facilitates this evaluation. Current limits of the method are linked to the association of both a procedural aspect and subjective judgements. This implies a type of formalised project management, a sensitivity to the principle of the quality management, and imposes team work for risk analysis and recording events. The PIFA is essentially a group method and supposes therefore that such a culture exists in the enterprise. The critical step of hnction evaluation, based on intuition and experience, must limit the interest in figures of the Project F.M.E.C.A. The efficiency of the method is more in the dynamics that it generates around the reflection on project risks, rather than in the calculation of the critical steps. Quantified values are only very subjective reflection of the confidence that the project manager and his team has in the way to process and to provide the necessary circulation of information for the success of the project. This analysis presents on the other hand the advantage to process only relevant problems on preventive actions. Finally, the capitalisation of experience on new products design projects should allow to harmonise the evaluation of the critical steps based on increasingly tangible facts.

Risk in new product design 203 Perspectives of this research are numerous. They encompass the causes of failure combinations. The computerisation of the method is an important means to increase its efficiency.

7 References

Giard, V. (1991) Gestion de Projet, Economica, Paris. Vergnenegre, A. (1991) Grilles d7Analyse Qualitative du Risque-Fondements et Experimentation. Actes de la 7eme Convention Nationale de 1'AFZTEP, Direction et Contr6le de Projet, Paris, pp. C30.1-C30.12. 3. Giard, V., Midler, C. (1993) Pilotages de Projet et Entreprises-Diversite et Convergences, Ecosip Economica, Paris. 4. Benssoussan, M. (1991) La Methode A.M.D.E.C. Planning. Actes de la 7eme Convention Nationale de 1'AFITEP, Direction et Contrble de Projet, Paris, pp. C32.1-C32.10. 5. Ashley, D. (1989) Project Risk Identification using inference subjective expert assessment and historical data, proceedings of the INTERNET international Expert Seminar on the State of the Art in Project Risk Management, INTERNET Association, Atlanta, pp 9-28. 6 . Ashley, D., Stokes, L., Perng, Y.H. (1987) Combining Multiple Expert Assessments for Construction Risk Identification, Proceedings of the Seventh International Symposium on Offshore Mechanics and Arctic Engineering, Houston. 7. Jaselskis, E., Ashley, D. (1988) Achieving Construction Project Success through Predictive Discrete Choice Models, INTERNET'88, The Ninth World Congress on Project Management, Glasgow. 8. Gautier, R. (1995) Qualite en conception: proposition d'une methode de fiabilisation du processus de traitement de l'information, these de doctorat en genie industriel, ENSAM, Paris.

1. 2.

The risk diagnosing methodology RDM J.I.M. HALMAN and J.A. KEIZER Eindhoven University of Technology, Faculty of Technology Management, Eindhoven, The Netherlands

Abstract A risk method should be effective, efficient and accepted. Based upon the experiences with the development and application of the Risk Diagnosing Methodology RDM the requirements for a successful approach are discussed. The basics of the method have been developed a few years ago [I]. Since experience has been gained in several R&D intensive firms. It has become clear that for a risk method to be successfully anchored within an organisation, it is necessary to anticipate a number of organisational conditions. In this paper these contextual requirements are described and analysed. Key words: Risk Management, Product-innovation projects, Implementation of a risk method

1 Introduction

Risk management has become an important issue in product innovation. Because of tough competition companies continuously have to develop and launch improved or completely new products. Failures in product innovation can have severe consequences, in terms of financial losses and damage to market share and brand positioning. Although companies recognise the need to develop new or improved risk assessment methods and invest time and resources in such development activities, the longer term results are often disappointingly low. A risk assessment method can only be successful if it fits with a company's innovation process is perceived by project leaders and project teams as a substantial contribution to their success rather as another bureaucratic burden or as an audit or inspection from higher management. Efficacy and acceptance are key success factors. In figure 1 a selection is presented of perceived forces against a more systematic Managing Risks in Projects, edited by K. Ktkonen and K.A. Amo. Published in 1997 by E & FN Spon, 2-6 Boundary Row, London SEI 8HN, UK. ISBN: 0 419 22990 6.

Risk diagnosing methodology

205

Again something new ?! Doing risk management is not doing research Risk management is risk avoidance How can you plan the unknown ? How much time is this going to cost me ? We cannot stop this project anymore, so why a risk assessment ? Fig. 1. Perceived forces against a systematic risk assessment

risk assessment. In this paper first a number of general problems with the efficacy and acceptance of risk assessment methods are raised. Next a description is given of the way efficacy issues have been resolved within the RDM. After that a number of acceptance issues are addressed. In the final section some conclusions are drawn. 2 Efficacy and acceptance issues in risk assessment

The Risk Diagnosing Methodology has been developed through case study investigations within companies in different industrial sectors: glass, lighting, automobile tires, ship propellers, helicopter landing gear systems and fast moving consumer goods. At the start of these case studies we encountered several problems concerning the efficacy, efficiency and acceptance of existing methods. In most cases companies were motivated to improve and enlarge their repertoire of techniques for risk assessment to resolve such problems. 2.1 Eff~cacyissues Dramatic experiences that might have been prevented Many companies have a vivid recollection of projects that dramatically went wrong. Afterwards it often becomes clear that through a thorough analysis of the risks in an early stage of the project while there was still time, problems that later on caused problems could have been identified. Improved risk methods to diagnose and manage can help to overcome a tendency to be risk avoiding.

Parts rather than whole project While an integral analysis of risks is required - technology, business and organisation many risk assessment methods have a limited focus. For instance the well known FMEA focuses only on technological issues. For the identification of commercial and organisational risks other more or less mature methods are used. Within their own defined focus these methods can be very powerfill. Yet working with parts implies a considerable chance of missing risks. Emphasis on brainstorming In frequently applied methods like the Potential Problem Analysis brainstorming is an important ingredient. Brainstorming stimulates people in a group to think of issues that

206

Halman and Keizer

can go wrong. In the context of risk assessment brainstorming has at least two disadvantages. Brainstorming in principle does not structure much. There is a chance that the smaller problems that can have severe consequences for the success of the project are not identified. Grovpthink Working together in an innovation project team means being liable to all kinds of group processes and as such to the phenomenon of groupthink. Especially when people of different hierarchical levels and or of different functional backgrounds work together and discuss risks in a project there is a chance that the differences in position affect people's spontaneity to express worries concerning issues that regard each other's level or discipline. Lack of consequent management actions After having identified the risks the point is: can we manage the risks? A check must be made whether given the identified risks the current project planning warrants a successful product launch. If not, a revised project planning must be made. Ad hoc application In most companies not for every project within the project portfolio the risks are being assessed, only for the projects that are seen by higher management as critical for the business. Companies often lack a formalised procedure to decide whether a risk assessment has to be carried out. Lack of an eficientfiamework There are different ways to identify risks with more or less formalised steps. Many complaints about risk management concern the efficiency with which it is carried out: mandatory bureaucratic procedures, piles of papenvork, investments in time for project leader and project team. 2.2 Acceptance issues No anchoring within existing innovation processes In a number of cases risk assessment methods were developed and applied because the company concerned faced one big project where they were worried about. The efforts were directed at the detection and management of the risks within this single project. After the risk assessment had been carried out the method was laid aside as it had no structural embedment in the company's standing procedures. Big chance that in a future case they have to reinvent the wheel.

No stafland skills to carry out risk assessments Especially when risk assessment methods have been developed with outside assistance it is often critical to get and keep internal expertise available to cany out risk assessments. What was initially welcomed as an important new tool soon can expire because of lack of people who can apply it.

Risk diagnosing methodology

207

3 Main characteristics of the RDM: efficacy In developing the Risk Diagnosis and Management Method we have attempted to resolve the main deficiencies we had encountered. Facing risks in stead of risk avoiding: 'inJluenceabilityl A company in the business of innovation sometimes is carrying out many projects at the same time. Each project brings about its own risks. The point is how to determine these risks in a practical way. In search for a useful concept of risk we have chosen as focal point the degree of novelty within a project. A risk is involved whenever in a single project routine is abandoned, to a large or a small extent. To put it in a conceptual way: risk is the chance that a given gap between acquired and required knowledge and skills will not be bridged within time and resource limits. The level of risk is determined in three dimensions: certainty, 1nfluc:nceability and Importance. A high risk is involved whenever for a given aspect of a product innovation project within limits of time and resources the project team: - is uncertain that a satisfactory solution will be found; - cannot influence the process of finding a satisfactory solution; - considers finding a satisfactory solution as key to the project success. By implication risk is not seen as an aggregate characteristic of a project as a whole but as an attribute of every single critical issue within a project that cannot be solved. Integral approach of technology, organisation and business issues in stead of a limited focus on parts The RDM approach is aimed to deliver an integral description of the risks in an innovation project. Therefore risks are identified in three domains: - technology: product, process, production equipment, production systems; - organisation: project management within the innovation project and the influences of the company policies and context on the project; - business: issues like the impact of a new product on the company's brand positioning, and the commercial viability of a new product. For all domains the main question is: what is new or different in this project in terms of knowledge and skills for the company in general and the project team in particular. Systematic approach: big issues and small deviations @om routine, in stead of brainstorming In the RDM approach the focus is on deviations from existing knowledge and skills. The first response of members of the project team to the question what the risky issues are they mention the big ones that usually are already on the team's agenda. The 'little ones' that are only mentioned by one member of the team are in terms of risk identification and management just as much or even more important than the big issues. The RDM triggers people to express not only the big issues but also their personal worries about the small deviations from routine. These small deviations may just as well cause big problems if they are not identified in time.

208 Halman and Keizer Focus on people individually and as a team toprevent 'groupthink' On the one hand in the RDM people directly involved and sometimes also some who are indirectly involved get the opportunity to contribute individually. They are asked to indicate from their personal perspective what is new or different in this project, first of all with respect to aspects within their own competence, but after that also for the whole project, technologically, organisationally and commercially. On the other hand there is a team meeting where the risks that have been brought forward are discussed. If a few general rules of engagement are maintained the experience is that in such group sessions very creative and usell new directions are found to solve problems that have come on the table. Both the opportunities to express personal views and to talk as a team about possible solutions appear to strengthen team ownership for the whole project considerably. Action driven The aim of the RDM is to build a complete list of the project risks and to get new ideas to manage them while there is still time. In most cases the end result of applying the RDM to a given innovation project is that the existing project planning is reconsidered to incorporate these new ideas. Sometimes the result is that given the risks and the team's inability to manage them appropriately within time and resources constraints a no go decision is made. Company specific in stead of ad hoc Complementary to a generic process approach - focusing on individual and team contributions - the RDM provides a company and or project specific content approach. A list of 'trigger questions' is given to those whose individual contribution is requested. In this list a comprehensive collection is given of issues that are characteristic for the company's technology, organisation and business. This list triggers individuals to think of issues that are or can become critical for the project not only within the range of the obvious ones people think of spontaneously, but also the ones that are less obvious. CoherentJi.amework:stepwise approach To enable an effective risk identification and management in RDM a coherent framework (see figure 2) has been designed in which four main steps are distinguished. Step 1: Identification ofproject risk In the RDM the risks are collected through individually interviewing the members of the product innovation project team and people outside this team who can from their (expert) knowledge and skills contribute to the identification of the project risks. In most cases a number of 10 to 20 persons are interviewed. When the list of persons to be interviewed is made special care is given to business and marketing to make sure that these subjects are addressed properly. Each individual interview takes about 1,5 hour. From these interviews a list of issues is collected that are seen by the interviewees as risky (within the RDM definition of risk).

Risk diagnosing methodology

209

Identification of project risks use a systematic overview of critical issues as reference interview the participants individually identify technological, organisational & business risks

J

Valuation of project risks rank the potential technological, organizational and business risks with a Risk Questionnaire map the risks in a Risk Topography quantify the risks for the project as a whole 7

Decision making about the diagnosed risks decide about the risk solution processes: individual - subgroups - plenary sessions decide about the risk measures: accept - reduce - transfer - reject

work out the risk measures in terms of time, resources, responsibilities monitor & control the risk measures

Fig. 2. Outline of Risk Diagnosing Methodology

Step 2: Valuation ofproject risk In the second phase a Risk Questionnaire is made and presented to all who have been interviewed. The Risk Questionnaire contains the collected risks translated into positive statements that can be seen as project objectives. For example: if in one of the interviews a project team member tells: 'I am worried about the safety of a particular part of the new product', the risk statement would be: 'The assembied product will fulfil safety requirements'. The respondents are asked to score the risk statements on three five-point scales:

- certainty that an appropriate solution will be created - ability to influence as a team finding an appropriate solution - importance of the issue concerned for the overall success of the project After the respondents have filled in this questionnaire the scores are being processed and a Risk Topography is made. For every risk statement the scores for the three

210 Halman and Keizer 1

Every one's viewpoint is valid ! No holding back - say what's worrying you ! No management hierarchy The things we don't like hearing are probably the key issues Explain your area of expertise 1

Fig. 3. Rules of engagement for a risk management session

evaluation parameters are summarised and expressed as a 'risk score'. Finally for every risk statement the three risk scores are combined and classified into a 'risk class', ranging form 'safe' through 'low', 'medium' and 'high' to 'fatal'. A risk statement is classified as 'fatal' if finding an appropriate solution is seen as very uncertain, not easy to influence and very important for the overall project success. Step 3: Decision making about the diagnosed r i s k With the project team a risk management session is held. The team discusses the outcomes of the risk assessment both through plenary and syndicate meetings. The earlier described 'general rules of engagement' (see also figure 3) are applied in this plenary risk session. At the end of the one-day meeting consensus has been achieved about action plans to manage the big risks and about a procedure to deal with the 'medium' and 'lower' risks. Step 4: Risk Management Planning The process ends when all risks that came out of the RDM have been addressed and the action plans to manage them have been incorporated into the project planning.

4 Implementation of the RDM: acceptance and roll out Besides efficacy and efficiency, also acceptance is a determinative condition for a risk method to be successfully applied and implemented within a company. Based upon recent experiences with implementing the Risk Diagnosing Methodology RDM within an R&D intensive firm (referred here as "Innoforce"), this section will explore the conditions to successfully implement a risk method within an organisation. 4.1 Orientation phase The assignment to assist Innoforce with the development of a company specific version of RDM started with an orientation phase (see fig. 4.). Purpose of this phase for the authors was to build an understanding of the nature of the business and to get familiarised with the innovation practice and procedures of the company and to explore the requirements that must be fulfilled to realise an effective, efficient and accepted version of RDM.

Risk diagnosing methodology 211 When asked about experiences with risks in product-innovation projects, interviewees almost unanimously started with a recent dramatic project failure that shocked the whole organisation. Also other incidents were reported: projects that failed in the market and projects that were terminated late on the project route at the expense of large resources. Interviewees indicated that due to these recent experiences, a clearly perceptible readiness originated within the organisation to deal more systematically with risks in product-innovation projects. The interviewees welcomed the idea of senior management to develop and implement a dedicated version of RDM. One may state that this receptivity for change is far from common. In many cases, the introduction of new methods is often perceived as a bureaucratic interference with no real added value. With respect to the introduction of risk methods questions are raised like: 'Risk management is risk avoidance shouldn't we be innovative ?'; 'How can you plan the unknowns?'; 'Risk management doesn't fit with my research task';' Is this another bureaucratic tool invented by higher management?'; and 'How much time is this going to cost me?. For a successful long term implementation it is of paramount importance that this resistance is taken seriously. Although the idea to develop and implement a dedicated RDM was welcomed within Innoforce, people within the organisation also stressed the importance that the system should be perceived by project leaders and project team members as supportive and not as a control and inspection system. In this respect it was seen as important not to impose the use of RDM for all innovation projects but to be selective. For each project a deliberate selection based upon a positive balance of expected value versus demanded effort was recommended. To secure a tailor made development, close cooperation between Innoforce and the developers was seen by both parties as a must. For the dedicated adaptation of RDM a committee with a sounding boardfinction was formed, consisting of key innovation managers and potential users. The chairman of this committee was disengaged from most of his regular tasks, especially to give maximum support to the process of tailoring and embedding the risk diagnosing and management approach within the whole organisation. 4.2 Adaptations to arrive at a company specific risk process On the basis of the orientation study it was concluded that the characteristics of the existing RDM were also very suitable for Innoforce. The content and process steps however, had to be refined for the innovation context of Innoforce. A first adaptation was made for the identification of potential risks. Due to the fact that Innoforce operates as a fast moving consumer firm, the systematic overview of technological, organisational and business risk issues were adapted for the Innoforce situation and also expanded with issues related to e.g. brand positioning, supply chain, safety and environmental risks. For the selection of projects for which an RDM should be required a dedicated Risk Quick Scan was developed. The organisation decided to focus on breakthrough projects and on projects with a significant impact on the business.

4.3 Pilot Testing of RDM Innoforce selected a number of representative projects which could serve as pilot case studies for application of the adapted RDM. This selection was also based on

212 Halman and Keizer

voluntariness from the side of Project Leaders. In the end from each Division within Innoforce one project was selected as a pilot. The results of the pilot studies were twofold. In the first place the pilot studies served as a check on the suitability of the method in the empirical setting of Innoforce. For each project also a full risk diagnosis and management plan was delivered, so the project team could immediately benefit from this. From the feed back sessions it became clear that participants were positive about the added value of RDM. RDM was evaluated as: 'A very powerful and robust process'; 'That helped a lot to overcome the critical issues in the project'; 'That allows you to confront the risks, to address the risks, and decide what they are and how to manage them'; 'That has done a lot for strengthening team ownership for the whole project' and 'That helped the team to do their job more effectively'. Based upon a formal questionnaire and the personal feed back from participating project leaders and project team members, Senior management decided to incorporate the Innoforce version of RDM within its innovation practices.

4.4 Anchoring RDM within current innovation practices People within the organisation were rightly reluctant to expand the number of side by side systems. For a new risk management system it was demanded that this should naturally fit within the current innovation management process. A decision in this respect concerned the responsibility and the moment in time to initiate a Risk Quick Scan and to decide whether it is appropriate to cany out an RDM. It was widely agreed to perform the Risk Quick Scan in the ideas phase of development and dependent on the outcome of this quick scan, the RDM in the feasibility phase of development. In line with existing innovation practices it was also decided that the project leader was the first responsible to initiate a Risk Quick Scan and RDM. An important decision concerned further the role of risk consultant. It was required to transfer the knowledge and experience of facilitating the RDM process to independent persons within the organisation with enough seniority but also consulting skills. For this purpose the authors produced a detailed risk reference guide. Innoforce identified world-wide 35 persons within their organisation who were nominated for a part-time job as risk management consultant. 4.5 Roll out To secure a successful diffusion of RDM within Innoforce, a roll out planning was made by the internal steering committee. The following actions were agreed and taken:

Awareness creation During the development of the company specific risk management approach, employees working on innovation projects were kept informed on the progress being made. The steering committee seized also the opportunity to use the yearly 'Lock Away Day' for project leaders to brief them about the developed risk management approach. A special risk video was made for this purpose. Project leaders, project team members but also Senior management are interviewed on this video on the experiences they had with the Risk Quick Scan and RDM. Also the steps and main principles of the Risk Quick Scan and RDM are explained on this video. Besides the briefings, Innoforce also embedded the discussion on the use of the Risk Quick Scan

Risk diagnosing methodology 213 and RDM in a more formal way. The start of an innovation project within Innoforce is supported with a formal workshop. One of the topics addressed during such a projectstart-up session are the Risk Quick Scan and potential application of RDM. This will stimulate a culture to deliberately discuss the potential opportunities of a thorough risk diagnosing and management habit. Risk consultant training Four RDM training sessions were organised for Innoforce. All 35 persons nominated for a part-time job as risk consultant followed a 2,5 day training course to familiarise with the RDM techniques and software. This course was organised as a 'real life' simulation of all RDM process steps. The training sessions were also utilised to discuss future cooperation between risk consultants. One of the risk consultants will perform a coordinating role. This coordinator will be approachable for the diffusion of new developments in risk techniques and software, and organise the exchange of experiences between risk consultants. The coordinator will also update if necessary the available RQS and RDM reference guide and monitor if replacement of risk consultants and training of new consultants is required. As such this coordinator will also perform a 'broker function' if risk consultants are required to cany out an RDM.

5 Conclusions

The success of the design and implementation of a risk management method depends on how efficacy and acceptance issues are incorporated in the development process. A start of the process with and orientation on expectations and receptiveness within the company is recommended. If at the end staff members of the company are expected to apply the method, their early commitment is important. A co-design model with a group of future users is key. A single risk assessment delivers points of attention for the project involved. A number of risk assessments provides the company with a marked opportunity to disclose its structural weaknesses and so learn and enhance its innovation capabilities and by this increase its innovation success.

6 References 1. Halman, J.I.M. and Keizer, J.A., Diagnosing risks in product-innovation projects, International Journal of Project Management, Volume 12, no 2, May 1994, pp 75-81.

2. Maidique, M.A. and Zirger, B.J., The new product learning cycle, In: Burgelman, R.A., Maidique M.A., Wheelwright, S.C., Strategic management of technology and innovation, Irwin, 1995 3. Cooper, R.G. and Kleinschmidt, E.J., New products: what separates winners from losers?, Journal of Product Innovation Management, vol4, no 3,1987, pp 169-184

Risks in change project management A.K. SALMINEN, H.C. LANNING and M.J. ROIHA Helsinki University of Technology, TAI Research Centre, Helsinki, Finland

Abstract Change project management faces challenges and problems which are likely to occur in certain phases of a project's life span. This paper presents a framework which connects typical problems to different phases of change projects. The objective of the framework is to help find possible problem areas in a specific organization and thus avoid problems. When different kinds of problems and barriers to development arise it is often too late or at least difficultto take corrective action. In order to help predict problems and reduce risk associated with them it is essential to identify their root causes. In addition to problems, this paper also introduces the cause-effect relationships of typical problems in change projects. The results are derived from several case studies and action research the authors have carried out in Finnish companies in different fields of industry. Keywords: Change projects, Project management, Change management, Risk management, Development projects 1 Introduction and background

The present dynamic business environment requires frequent changes in the way organizations operate and in the organizational structure. Typical aims of operative changes are the improved quality of products and processes, shorter throughput times and better delivery performance. Changes in organizational structure are intended to drive organizations towards process organization, lean organization and team-based organizations. These operational changes are usually managed as projects, here referred to as change projects. Managing R i s k in Projects, edited by K. KahkSnen and K.A. Artto. Published in 1997 by E & FN Spon, 2 4 Boundary Row, London SEI 8HN, UK. ISBN: 0 419 22990 6.

Change project management

215

Change has become an integral part of everyday life and the ability to change one of the critical success factors of most organizations. The risks and problems involved in change project management have also become an important issue which is not appropriately covered in risk management or project management research. The results presented in this paper are based on a three year research programme concentrating on successfbl implementation of change projects. The research programme consists of action research carried out in different fields of Finnish industry and of a change project benchmarking network. The goals of case projects vary from planning a manufacturing strategy for a new production site to creating a good working atmosphere and solving human relations problems in project organization. The authors' role in these change projects has varied from acting as project manager to mere observer.

2 The phases of a change project

The change project can be divided into different phases as shown in Figure 1 [I]. The approach used here is a modification of a general model of change introduced by Kurt Lewin. These phases of a change project are derived from the change management viewpoint and their basic purpose is to describe the shift in the very nature of a change project during its life cycle. The model can be seen as an application of the traditional project life cycle models such as the model presented by Morris [ 2 ] ,which consists of four phases: feasibility, planning and design, construction and turnover and start up.

Time

Fig 1.

The phases of a change project.

The project begins to take shape in the feasibility (preparation in change project model) phase when the preliminary feasibility studies are made and the first plans and scenarios are presented to top management. In the planning and design (unfreezing) phase the final project plans are completed, the necessary resources are allocated to the project, the project organization is formed and the former organizational structure and operating systems are dissolved in order to enable change. During this phase also learning and

216

Salminen, Lanning and Roiha

change potential and readiness is created and the old ways of doing things are challenged. The production (change) phase is where the physical realization of the project takes place. In the development or change projects this often includes actual implementation of changes. In the turnover and start up (refreezing) phase the new system is taken through final testing and introduction and the responsibilities are retransferred to the line organization. During this phase it is important to become familiar with new operating procedures and to realize their superiority compared to former ones.

3 Typical problems of change projects

Suzanne Kezbom [3] has studied the problems most often experienced by project managers and technical specialists in the technically oriented Fortune 500 companies. She classifies the problems into thirteen categories presented in Table 1. Kezbom found out that the most common of these are disagreements in goal or priority definition and disagreements between personalities or in interpersonal relations, even though more technical problem categories such as disagreements concerning schedules and project priorities are usually mentioned in project management literature. So it seems that even in traditional technical projects the human side of project management deserves more attention than it usually receives. Table 1.

The problem categories by Suzan Kezbom

Scheduling Managerial and Administrative Procedures Communication Goal or Priority Definition Resource Allocation Reward Structure / Performance Appraisal or Personality and Interpersonal Relations Costs Technical Opinion Politics Leadership: Poor Input or Direction Ambiguous Roles / Structure Unresolved Prior Conflict A recent research project [4] carried out for the Finnish Ministry of Trade and Industry (MTI) revealed some interesting patterns in the most common problem areas in change projects implemented in small and medium sized enterprises (SME). The study was based on a questionnaire sent to 400 SMEs that had recently participated in a

Change project management 217 productivity enhancement campaign administrated by the MTI. For the 150 general managers and project managers that answered, the problem most often mentioned was lack of time. Other problems mentioned and their relative shares are shown in the Figure 2.

Fig 2.

The problems encountered by the SMEs that participated in the productivity campaign.

The study shows that resistance to change is very commonly experienced as a problem by general managers and project managers of SMEs. Lack of time can usually be considered a mere symptom of lack of sufficient resources and too low priority of the change project. The relatively high position of financial problems is characteristic of SMEs with very limited resources but as well reflects the recent problems in the Finnish economy. The actions of an external consultant are often blamed when project implementation fails. Naturally the abilities of consultants vary as does the co-operation between a consultant and a project manager. In the same study it was found that the factors differentiating successfbl change endeavours from unsuccessfbl (as perceived by key personnel) were connected with the goal setting of the project, strict enough project co-ordination as well as training and rewarding issues. Resistance to change is perhaps the most well-known of the problems associated with change projects. Resistance to change is expressed in the form of active resistance and intentional passiveness. The tendency of human beings to resist and fear new and unknown things and the willingness to stick to the old well-proved procedures has been studied widely as well as the conflicts between individuals' interests and the needs of an organization. However, resistance to change is merely a symptom of more fbndamental problems rather than the disease. It is a natural phenomenon which should be prevented and dealt with rather than overcome.

218 Salminen, Lanning and Roiha

The problems of managing change projects go beyond the resistance to change; these less studied problems combined with resistance to change form the actual obstacles to achieving the required change. A slow learning process, unexpected turnover of key personnel, inability to keep up with schedules, difficulties in implementing the participatorily developed solutions and the habit of concentrating on secondary matters are examples of typical problems inhibiting effective change within organizations. These can be considered major risk factors respectively. They emerge for different reasons in different phases of a change project and therefore it is usefil to examine them in the context of the progress of a typical project. Different risks and problems dominate in different phases of a change project. Risk management within a change project is more efficient if the problems likely to emerge can be identified beforehand and recognition efforts focused on them rather than the whole scale of problems. Figure 3 presents the most likely occurrence of the key problems in change project management.

Fig 3 .

The main problems of change projects in relation to each phase.

Change project management

219

4 The causes behind the problems

In order to avoid these problems and in order to reduce the risk associated with them it is crucial to identifl their manifestations and to be able to distinguish causes from effects. Change resistance and practical problems in change projects may take different forms depending on personal and organizational characteristics. The main focus here should be placed, on the one hand , on what employees experience and feel during the changes and on the other, on organizational structures and procedures which jeopardize the success of the project and cause problems.

Fig 4.

The cause of a problem

1

Problem

3

Cause-effect relationships of typical problems in change projects.

Figure 4 shows how the problems, negative feelings and organizational atmosphere and the unsuccessfkl development actions relate to each other. When the resistance to change or other practical barriers to development efforts start to show it is often too late and too difficult to correct the actions. Corrective measures would be easier and more efficient if inadequate or insufficient actions could be identified on the basis of peoples' feelings and changes in the organizational atmosphere instead of on the reactions such as resistance to change. Typical emotional and organizational indicators of erratic change methods are presented in Figure 5.

220 Salminen, Lanning and Roiha FEELINGS OF PEOPLE OR ORGANIZATIONALSTRUCTURES AND PROCEDURES

.. . . .

Fig 5.

Uncertainty of the project Fear Not understanding the basic idea and goals of the project Not understanding the need of change Frustration Lack of belief in the success of the project Lack of personal benefit and incentives Negative atmosphere Diminishing authority Insufkient understanding of one's own role in the project Lack of knowledge Lack of guiding incentives Insufficient resources Rema~n~ng old structures wh~chdon't support the des~reddevelopment Lack of support fmm top management Project not In l~new~thcompany vlslon and strategy Unclear rules of the game for development No clear improvement potential

b (1.

a3. . . X

y

&

T?

-' 6

"

& b2

Change resistance

2

The feelings and structures underlying the problems in change projects.

One solution is to manage possible problems as risks which are to be prevented from becoming actual problems by eliminating the root causes. Identification of the actions leading to negative human influences is necessary. This raises the question of what should be done to minimize the problems of a change project and when. What are the actual sources of change project success or failure? The problems of projects usually arise from poor performance in critical fields of management. The critical success factors are those phases or fields of action that ultimately determine how successfUl a project is. The approach of success factors in itself is not new and has in fact been used as the basis for some project audit methods, such as the Project Implementation Profile [5]. Traditionally subjects such as scheduling, budgeting and goal setting are considered the critical success factors of project management. However, some distinctive features in change and development projects restrict the applicability of traditional project management concepts in change projects. These include lack of experience from similar projects, difficulties in determining resources and time required, induced additional change needs in other parts of the organization, importance of the learning process, part-time project organization including the project manager and competition with day-to-day operations. [6, 71 The effect of these and some other features of change projects is that the critical success factors of change projects are somewhat different from the success factors of traditional external projects. Change project management needs to emphasize the human, organizational and political aspects of the change as well as the hard dimensions of project management. Case studies [S, 91 reveal that the six most critical success factors in change projects are

Change project management 221 commitment of top management, participation, communication, clearly defined goals, allocation of sufficient resources and having sufficient problem area specific skills, which also seem to carry the largest risk potential of failure to the change project. Figure 6 shows the most critical action errors which lead to resistance to change and the practical problems in change projects.

Fig 6.

Classification of causes behind the problems.

5 Conclusions

There is no reason for pessimism despite the great variety of possible problems in change project management. On the contrary, the awareness of problems helps to identifj their emergence before they endanger the project. The real opportunity to avoid problems arises when the cause-effect relationships of problems are studied and thought through. It is reasonable to focus scarce resources into repairing root causes of a problem and not just react to problems whenever they emerge. This also means that a project manager tring to discover problem triggers in his or her own actions and ways of doing things is a good sign. The framework introduced in this paper enables the systematic management of problems and risks of change projects and helps project managers apply other risk management methods to change projects as well.

6 References 1.

2.

Lanning, H., (1996) Implementing Change in Organisation - Typical Problems in Internal Projects and their Avoidance (in Finnish). TKK, Teollisuustalouden raporttisarja, no: 166, 167 p. Morris, P. (1982) Project Organizations: Structures for Managing Change in Kelley (ed.), 1982. New Dimensions of Project Management. Lexington (MA), D.C. Heath & Co, pp. 155-179

222 Salminen, Lanning and Roiha 3.

4.

5.

6. 7.

8.

9.

Kezsbom, Deborah S. (1992) Re-Opening Pandora's Box: Sources Of Project Conflict In The '90s. Industrial Engineering, Vol. 24, No. 5, May 1992. pp. 54-59. Salminen, A. and Perkiomaki, P. (1996) Assessment of the Productivity Campaign (in Finnish). Unpublished report of Ministry of Trade and Industry. 31 p. Pinto, J. K. and Slevin, D. P. (1988) Critical Success Factors in Effective Project Implementation in Cleland and King (editors), 1988. Project Management Handbook. New York, Van Nostrand Reinhold, pp. 479-512. Boddy, D. and Buchanan, D. A. (1992) Take the Lead: Interpersonal Skills for Project Managers. Cornwall (UK), Prentice Hall International Ltd, 183 p. Mikkelsen, H., Olsen, W. and Riis, J. (199 1) Management of Internal Projects. InternationalJournal of Project Management, Vol9, No. 2, May 1991, pp. 77-81. Lanning, H. and Salminen A. (1997) A Step By Step Path for Implementing Change. Pztblications of IrMS 1997, lnternmionalConference on Industry, Engineering, andManagemenf Systems. (forthcoming) Salminen, A. (1 995) 7he As.~emmentofImprovemen~Projects- a method for the eval?tationand enhancement of operational change projects (in Finnish). TKK, Teollisuustalouden raporttisarja, no: 163, 83 p.

A risk-driven approach for software process improvement C. MAUPETIT CR2A-DI (CGI Group), Courbevoie, France

J. PAL0 CCC Software Professionals Oy, Oulunsalo, Finland

P. KUVAJA Department of Information Processing Science, University of Oulu, Oulu, Finland

M. BELL1 Informatique cdc, Bagneux, France

M . ISOKAANTA Rautaruukki Oy, Raahe, Finland Abstract This paper reflects the approach of the D ~ ~ V ~Esprit S P I IV ~ project (1011995 - 911997). DriveSPI aims at producing and validating by large applications a European framework for improving the software process maturity with a strong emphasis on risk management. Such an integration of risk management within process improvement concerns is recognized by the software community as being a major challenge for the next decade. This risk management approach is characterized by the tight integration with project management all along the realization process. This paper first tries to make the point on process improvement techniques, then positions risk management towards "traditional" project management. Then it emphasizes on the need for a riskdriven software process improvement and on the DriveSPI approach. Keywords: Risk management of software projects, software process improvement, software process assessment. 1 Process improvement

Organisation's needs and business goals are mostly related to software quality, development and maintenance costs, time to market, and increased predictability of product and processes which are, therefore, the main drivers of software process improvment in industrial software production. Higher quality, lower development and maintenance costs, reduced time to market and better predictability improve customer satisfaction and increase the organisation competitiveness in the market place. These

0 Members of the DriveSPI Consortium are CWA-Dl (coordinator), Informatique CDC, CCC Software Rofessionak Rautaruukki. DriveSPI benefits 6on1the f m c i a l support of the European Commission in the 4th programme for RTD in InformationTechnology.

Managing Risks in Projects, edited by K. Kiihkonen and K.A. Artto. Published in 1997 by E & FN Spon, 2 4 Boundary Row, London SEl SHN, UK. ISBN: 0 419 22990 6.

224 Maupetit et al. satisfaction and increase the organisation competitiveness in the market place. These key concerns for the organisation's management become drivers that initiate process improvement throughout the organisation. Process improvement is therefore an essential part of hlfilling the organisation's business goals, which are used to set specific software process improvement goals that will direct the improvement activities. The improvement goals set the basis for predicting the success and measuring the impacts of specific planned or implemented improvement actions. The success of improvement implementation is dependent on many factors such as current process maturity, staff skill base, and business issues such as costs, risks, implementation speed, etc. Therefore the software process improvement is recommended to start with an assessment of the maturity and risks of the current practices and organisation. The maturity assessment in specific shows the weaknesses and strengths of the processes and whether they are capable enough to adopt certain improvement in place. The risk assessment shows at the same time the risks involved in current software process performance , possibilities to decrease the risk level and the risks involved in the improvement actions themselves. In specific st& skills, improvement acceptance inertia, training effectiveness and improvement efficiency should be involved in the risk analysis. The process improvement approaches may in principle address the organisation, methodology or technology of the software process either separately or combined appropriately. The following table summarises some of the state of the art approaches and show their potential improvement target areas. Table 1.

Software process improvement approaches ( 0 = Organisation, M = Methodology, T = Technology)

Risk management of software projects 225

Software process assessment has been topic of interest among the international software engineering community during the recent years and several assessment approaches have been developed. The Capability Maturity Model (CMM) assessment approach, which has been developed in the Software Engineering Institute at Carnegie Mellon University (SEI) [I], has been a starting point for the development of several subsequent assessment approaches. In addition to CMM, the IS0 9001 standard has also been used as a reference model for assessment approaches. An excellent example of that is the most well-known European assessment methodology, BOOTSTRAP [2]. The process model standards have double role in process improvement. They can be used to describe the processes but also as reference models behind the assessment methodologies. For example the BOOTSTRAP methodology [3] was developed to

226 Maupetit et al. adopt both the characteristics of the CMM and the European Space Agency's process model standard (ESA-PSS 005). Software Process Improvement and Capability of dEtermination, SPICE, is an international project started as a result of a study period approved in June 1991 by the International Standards Group for Software Engineering to investigate the need and the requirement for a standard addressing software process management. The SPICE project started at the beginning of 1993 and its results will form an international agreed framework for software process improvement, improvement and capability determination [4]. One approach for software process improvement has traditionally been the application of software metrics. The recent development in the area has been the establishment of company-wide metrication program in order to help to manage the software process. Software metrics help both the management and the IT line organisation by serving solid feedback information if gathered systematically in the whole company. The most promising metrication framework published in the area are: Goal Question Metrics approach that was defined by V. Basili at the University of Maryland and is now widely adopted in software community. AMI - Analyze, assess, metricate and improve - is a European approach for improving the software process management by metricating. Quality Function Deployment (QFD) is an approach which was defined within the Total Quality framework and helps in managing towards defined goal.

2 Risk management

Facing with risks in the realization of software projects is becoming more and more a crucial issue. Many publications deal with experiences in project realization that turned down [5], [6], [7], [8]. Sometimes, the project goes wrong from a project management perspective. Among those, a lack of clarity of specifications, a poor architectural design that does not allow for a proper integration of the software components, misevaluations of duration and cost, a sudden quitting of a key member, a late detection of external events likely to impact on the project, etc. Some other times, projects fail from risks that do not relate directly to the project realization. Although financial (shortage of funding, ...), legal (property rights, ...) and strategic risks (positionning of product, ...) are most of the time not under the responsibility of the project manager, they strongly impact on the project success. Questions are how and who is managing all those risks, which are of various natures. In the same way as the level of maturity of an organization reflects the way its parts interact and cooperate, is there an overall risk management approach for coordinating and managing the various risks? Consequently, is there a "risk officer" in charge of all the risks that may occur on a project? Answering those questions is important as it conditions the positionning of risk management into organizations. We believe that risk management shall be actor-oriented. Risk management shall be under the responsibility of the persons that would endorse the outcomes of the risks in case of occurence. Responsibility does not mean individualism: a condition for

Risk management of sofhvare projects 227 mastering the risks is Mahng every one a winner with the project [9] and we saw that risks affecting the project are outcorning from multiple sources (financial, legal, ...) that are not under the responsibility of a unique actor.

Environment

1 Fig 1.

-

Overall risk management is a matter of maturity and cooperation among actors

As an illustration, the project manager does not care the way the financial department tackles financial risks. The project manager needs accurate resources over the project life and warranties on it. In return, the success of the project affects positively the turn-over and the profit of the organization. In this example, an appropriate management of each part's risks and the maturity of the cooperation between the project manager and the financial department allow each part to poise the risks. They consequently allow to make adequate and consistent decisions towards the global strategy that leads to the project success. Accordingly, we believe that risk management is not a new issue with its own finalities. It seems difficult to find a criterion for measuring the quality of risk management. Risk management is complementary to each dimension of a project and helps in making right decisions within each dimension. We also believe that such a view of risk management strongly impacts on the people's role and responsibility in the organization. We'd rather see officers in charge of the traditional dimensions of project realization with appropriate risk management skills than an officer transversaly assigned to global risk management. Taking this into account, the following section presents the RiskMan risk and project management approach. This approach (and the toolset implementing it) reflects the project manager standpoint. RiskManTM (EUREKA project started in 1992) goals were to develop a methodology and a toolset to improve and integrate risk management as a part of project management. CR2A-DI (acting as Chairman), CCC and OPL are partners in RiskMan. The purpose of RiskMan is to provide a framework for professional project risk analysis and control, and guidance for its implementation. In RiskMan, risk management is viewed as a continuous activity of global project management which

228 Maupetit et al. aims at identifjring and assessing risks and consequently defining, selecting, treating and monitoring risk management actions. The main results of RiskMan are: the RiskMan methodology [lo], [l 11, [12], [13], and RiskMan toolset available for Unix platform. Project management stages aim respectively at answering the series of questions raised while managing a project, from its start to its completion. Risk management should be tightly embedded to the globality of project management. Taking those challenges RISK MAN^ software proposes to manage locally - stagewise - those risks along with the corresponding project management issue offering practical step-by-step approach and easy-to-use software which supports all phases of project management.

Risk identification

I

I Risk evaluation

l

Risk follow-up I

Fig 2.

The RISKMAN integrated project and risk management approach

3 The DriveSPI approach

The risk-driven process improvement framework definition strongly rests on successfil European and international projects, namely RiskMan, BOOTSTRAP and SPICE. DriveSPI aims at integrating stagewise the risk management methodology @skManbased) into the assessment (BOOTSTRAP-based) and improvement frameworks (SPICE-based) that have proven their value - but precisely to the restriction of risk management for the two latter. The Risk-driven Software Process Improvement approach proposed in DriveSPI is integrated into the SPICE Process Improvement framework, as shown in figure 3 .

Risk management of sofnvare projects 229

Figure 3 .

DriveSPI risk-driven software process improvement

At each stage, DriveSPI integrates risk management in a constructive manner. The DriveSPI approach is validated by two large applications in the course of the DriveSPI ESPRIT project. These applications are large sized in addition, they are of very different nature which allows to realistically experiment and validate the approach for a wide range of European sw companies - especially, companies dealing with business information systems and industrial companies coping with control systems for which reliability, system integration, constraints are major issues. The application of Informatique CDC is the new information system of CDC Group 'DABF' branch (Direction des Activites Bancaires et Financieres). The SAPCO (SAles Planning and Control System) project is the application for Rautaruukki. It will ensure the sales planning and control system of Rautaruukki's Thin Sheet Division. 3.1 Examine organization's needs Analysis of software project failures in the last decades indicates that most of the problems can be traced back from one or more project high level risk areas. Each company should seek to adopt a risk identification method that is suited to its culture and organization. High level risk areas are identified by a combination of methods, mainly brainstorming sessions gathering experienced project managers, but also standard questionnaires and checklists, help of outside experimented consultants, use of RISKMAN toolset features to identify risks stored in a database of risks and their associated recommendations.

230 Maupetit et al. 3.2 Initiate process improvement Among the whole set, high level risk area candidates are selected with respect to the application purpose. The Process Improvement Program includes risk management concerns and it should be considered as a project in its own right, and planned and managed accordingly. A dedicated Risk Management Plan (RMP) is at that stage created and documents: the risk management objectives and road map for the application, the monitoring of risk management including roles, responsibilities and procedures. 3.3 Prepare and conduct process assessment The BOOTSTRAP assessments are made to determine maturity level of target projects and Software Producing Units. DriveSPI delivers a specific risk-driven process assessment questionnaire focusing to risk management process itself. The questionnaire is resulting from the crossing of BOOTSTRAP and RiskMan complementary views. The conduct of the DriveSPI process assessment provides the organization current capability profile together with detailed risks identified. 3.4 Analyse assessment results and derive action plan In the light of the organization's needs and high level risks, this stage aims at: Identifying and prioritizing areas of improvement based on the organization assessment results, deriving a action plan including risk-driven PI actions, and integrating it within the revised PI program plan. Also, the Risk Management Plan which is the reference for risk management, is updated in compliance with the action plan. 3.5 Implement improvements The risk-driven PI action plan is at this stage implemented in order to improve the organization's software processes and especially project and risk management processes. Improvement scope is focusing to both project and organization. Three main tasks are involved: selecting the operational approach to implementation. Where there are alternative approaches, they should be evaluated and the most suitable selected based on costs, delays and risks to meet the expected goal, preparing and agreeing a short & long term risk-driven PI action plan. The short term plan will include a selection of the priority risk-driven PI actions previously defined, monitoring in using the RISKMAN system, the overall PI project and its inherent risks. 3.6 Confirm improvements When the PI project has been completed, the organization must: confirm that the planned goals have been achieved: Among those, the validity of the risk-driven PI actions. Confirm that the desired organizational culture (practises) has been established and whether practices and subsequent changes are easily accepted and used within projects Target is also to re-evaluate costs and benefits: Especially those inherent to risk-driven PI actions with regards to former experiences without risk-driven PI actions.

Risk management of software projects 231 A new risk-driven process assessment is carried out on the application for improvement confirmation. It provides a picture of the improvement results. 3.7 Sustain improvement gains and monitor performance After piloted on a project, the software process needs to be sustained and deployed within the user' organizations. Responsibilities for deployment have to be defined as well as how this will be practically done. From the risk management standpoint, users sustain the improvement through the institutionalization of Models for risk-driven PI actions (risk management shall become even more pro-active, i.e., so that risk-driven PI actions are launched earlier as soon as threatening risks are identified). The day to day practice of risk management, risk-driven PI actions plans, and risk budget guidelines

4 The DriveSPI results

The DriveSPI methodology enhances RiskMan in the direction of process improvement for software developments and extends BOOTSTRAP assessment methodology to risk management issues. Following are DriveSPI methodology components : guidelines to projects for identifying and selecting the risks (catalog of techniques), guidelines to projects for developing their Risk Management Plan, guidelines to organisation and projects for using risk management to improve their software process, formalization of a complementary risk assessment compliant with BOOTSTRAP, socalled a risk-driven process assessment (questionnaire and guide). These guidelines are consolidated by two applications experiment. They need to be used in association with RiskMan and BOOTSTRAP (SPICE) ;they help to fill the gap between the two methodologies in order to apply risk assessment and risk management to improve software process. DriveSPI intents to comply with the existing international standards dealing with: project management and quality: I S 0 9001, I S 0 9000-4. software maturity and assessment: "Guide to Metrics Planning" ISOIIECIJTC 1/SC7/WG6 document, draft version of the ISO/IEC/JTCllSC7/WGlO (SPICE project) risk management: UK MOD "Risk Guidelines", British Telecommunications Agency "Risk Analysis Guidelines", DGA "Manual of Risk Management"[l4]. DriveSPI is designed to help organizations improve their software process by using best practices of risk management through risk assessment and risk-driven process improvement. The aim is not to define yet-another methodology to develop software but to provide practical guidelines to introduce risk management both for organisation and projects level approach.

232 Maupetit et al, 5 References

Humphrey, W.S. and Sweet, W.L. (1987) A Methodfor Assessing the Software Engineering Capability of Contractors, SEI Technical Report SEI-87-TR-23, Software Engineering Institute, Pittsburgh. Kuvaja, P. and Bicego, A. (1993) B0OTSTRAP:Europe's assessment method IEEE Software, Vol. 10, Nr 3, May 1993, pp. 93-95. Kuvaja, P., Simila, J., Krzanik, L., Bicego, A., Koch,G. and Saukkonen, S. (1994) Softwae Process Assessment and Improvement. The BOOTSTRAP Approach lackwell Business, Oxford, UK and Cambridge. Kuvaja, P., Bicego, A. and Dorling, A,, (1995) SPICE: Software Process Architecture to be published in the Proceedings of the ESI-ISCNP5 Conference: Measurement and Training Based Process Improvement - Practical Improvement of Software Processes and Products, to be held in Vienna, Austria, September 11-12, 1995. DGA (1990) Special Issue on the Conduct of Armement Programs, in "L'Armement", Delegation Generale pour 1'Armement Edt, NS-N021, 160 pages, february / march 1990. DGA (1990) Special Issue on Communication, Command, Control and Intelligence Systems, in "LtArmement",DBegation Generale pour 1'Armement Edt, NS-N023, 192 pages, july 1 august 1990. Charette, R.N. (1989) S o h a r e Engineering Risk Analysis and Management, Mac Graw Hill Software Engineering Series, 325 pages. Rothfeder, J., (1989) It's Late, Costly, Incompetent - But Try Firing a Computer System, Business Week, Nov. 7, pp. 164 - 165, 1988, also reprinted in Tutorial: Sofhare RiskManagement, B. Boehm Edt, IEEE Computer Society Press, 498 pages. Boehrn, B. W. and Ross, R., (1989) Theory-W Sojiware Project Management: Princples and Examples, IEEE Transactions on Software Engineering, 1989 also preliminary version reprinted in Tutorial: Software RiskManagement, B. Boehrn Edt, IEEE Computer Society Press, 498 pages. Carter, B., Hancock, T., Morin, J. M., Robins, N., (1994) Introducing RISKMAN Methodology : The European Project Risk Management Methodology, NCC Blackwell, 210 p., Oxford. Morin,J. M., Robins, N., Legall, A,, Sterling, C., Xanthakis, S. and Faure, J.F. (1993) Risk Driven Project Management: A Practical Approach, Proceedings of the 2nd SEI Conference on Software Risk, Pittsburgh, 2-4 march 1993. Kess, P., Krzanik, L., Rommel, Y., Saukkonen, S. and Simila, J. (1993) Risk Identity Engmeering, position paper presented birds-of-a-feather meeting of the 2ndSEZ Conference on Software Risk, Pittsburgh, 2-4 march 1993, 5 pages. Palo, J.T., Simila, J., Kess, P., Maupetit,C. and Rommel, Y., (1995) Tackling risks in project management to be published in the Proceedings of the 13th International Conference on Production Research, Jerusalem, 6- 10 august 1995. DGA Manual of Risk Management, DGAIAQ 923-924, to be published.

Risk management focus in business reengineering initiatives J. v ~ I M & Uand T . TISSARI Andersen Consulting, Helsinki, Finland

Abstract Business reengineering programmes are set up to create competitive advantage. These programmes typically involve multiple, inter-related and mission-critical projects that are very large and complex in nature. The purpose of the programme management is to ensure that programme objectives are met. Risks stand in the way, and therefore risk management is the key element in successful implementation of business change. A risk does not have a "goodness ' or "badness" component. It is just a fact of life that needs to be controlled in a well-organised and disciplined manner. Keywords: Business reengineering, restructuring, risk management, change projects 7

1 Introduction

Companies across the world have undertaken and continue to conduct fbndamental business reengineering programmes. In all too many cases, these programmes are unable to produce bottom-line business results. For example, based on a 1995 study by the Standish Group International (USA) consisting of 8,380 business reengineering projects at 365 companies, 84 % of all projects failed or at least experienced some major problems. Consequently, 3 1 % of the projects were canceled before *ey ever got completed, and 53 % of these projects cost 89 % over their original baseline budgets. These findings are in accordance with similar studies. It is understood that trying to approach every change program as a radical reengineering programme is like trying to hit a home run every time - impossible. While the reengineering of single functions can be important to companies, a narrow approach to redesing cannot however produce the kind of widespread results that many companies are looking for. Managing Risks in Projects, edited by K. Ktihkonen and K.A. Artto. Published in 1997 by E & FN Spon, 2 4 Boundary Row, London SEl 8HN, UK. ISBN: 0 419 22990 6.

234

Valimaki and Tissari

This consequently means that real business reengineering programmes are always large and complex in nature (see Figure 1 on business reengineering scope). Considering the presented study results on reengineering success and the complexity of these programmes, we suggest that risk management is the key in successfil business reengineering. In this paper we intend to show that while the core approach to risk identification, management, mitigation, monitoring and risk contingency budgeting may remain unchanged there is a need to consider some new risk management perspectives as well. We will present what kind of risks are characteristic for business change programmes. We will also discuss the importance of comprehensive risk measures, in addition to informal feedback and personal judgment, as an approach to control their probability and/or impact. /TWEOF CHANGE

4

/ SCOPE OF S R d

Fig 1.

cosl-*

CHANGE

Business reengineering scope

The following assumptions have been made: Business reengineering programmes discussed in this paper aim to produce findamental changes in companies' business performance. It is not easy to measure if a business reengineering programme is a success or failure. We have excluded these considerations from the paper, and for us a reengineering programme is a success when it meets its business objectives. Risk management is considered in the wide context. A risk can be anything which can have a significant impact on the success of a business reengineering programme.

2 Major risk areas in business reengineering Our study approach has been practical. We conducted a series of face-to-face discussions with business managers and management consultants who have participated reengineering programmes in Finnish companies. The main focus was on defining the most significant risk areas which are extremely common and damaging in business reengineering programmes undertaken by Finnish companies. Our intention is to help companies to recognise and focus enough management attention on those areas which,

Risk in business re-engineering

235

based on our interviewees, are the most significant pitfalls in the business reengineering context. The following major risk areas were identified: Unsuccessful balancing of development elements Unstructured target setting and project initiation Unsuccessful management of conflicts between vision and "leg works" Unsuccesshl management of conflicts between objectives and development effort Right things are done in wrong way Each of five risk areas are discussed in detail below. 2.1 Unsuccessful Balancing of Development Elements A business reengineering programme usually leads to the significant restructuring of an organisation. Job descriptions and roles of employees are redefined at all levels. Training and rewarding systems are altered to be in accordance with new organisational objectives, and there might even be a need to have some long-term changes to the corporate culture. Moreover, new information and measurement systems are implemented to support new operational models. One of the most common project risk in business reengineering initiative is unsuccessful balancing of these development elements with which required change is to be achieved. The following situations were mentioned in the interviews:

Companies are unwilling to change their organisation structure Business reengineering programmes put too much effort on process redesign Accounting and performance management systems are not changed to support new management models Companies are reluctant to change their operational information systems to support new operational models A company had started a large initiative just to learn that, in the end of a day, they are reluctant to change their organisation structure, and corresponding management roles and responsibilities. We do not suggest that it would be impossible to achieve significant changes in the organisational performance without touching organisation structures, but it eliminates an important option which could be used. Unwillingness to accept changes in organisation structure is often based on two alternative reasons. Firstly, company managers object these changes because of a threat that their own management profile would be reduced. Secondly, they are too busy to support changes because of ongoing pressures to produce short-team earnings. Numerous business reengineering programmes seem to fail because too much development effort is focused on the redesign of business processes. This is, of course, an important phase in any business reengineering programme and it needs to be done properly. Spending too much effort on design works might however exhaust key resources, or even the whole organisation, before the process implementation starts. If the momentum is lost at start of the implementation phase, success of the whole programme is in serious danger.

236

Valimaki and Tissari

Consequently, when the focus of development work is clearly on process design, other important elements, such as organisation, information systems and accounting 1 performance management principles, can be ignored with damaging consequences. In one case, a company had redesigned their sales and delivery processes based on worldclass best practices. At start of the implementation phase they noticed that their current IT systems could not be tailored to support new processes. The company was eventually forced to start investing on new information technology, but late change in development approach caused significant delays to the implementation schedule. Information technology has a key role in the majority of business reengineering initiatives, and its importance as a enabler and implementation tool should be remembered throughout change programmes. 2.2 Unstructured Target Setting and Project Initiation Too often, management attention and other resources are focused on change projects which fail to produce desired bottom-line business results. Organisations can even report dramatic improvements on individual processes only to notice their overall results to decline. Based on our experience, companies focus on trivial and wrong operations or processes because they fail to implement target setting and development project initiation process properly. This results in two common situations:

Operations and process selection and project initiation are based on wrong objectives Objectives are correct, but inappropriate operations and processes are targeted All business reengineering programmes are setup to create competitive advantage. According to Porter competitive advantage can be gained in three different ways. A firm can either operate with lower costs than its competitors, or it can create additional value to its customers. Thirdly, a company can differentiate its products and operate as a niche player in a selected market place. There is a need to identify principles on how a firm can operate at a lower cost and/or generate more value than the omp petition at the early stages of any reengineering programme. The next step then is to transfer defined principles into quantified objectives and expectations. The decision on objectives has a crucial nature, because this information is consequently used to target operations and processes which are reengineered through a set of development projects. Failure to select appropriate targets for a programme may jeopardize the success of whole initiative. Let's take an example, and assume that a company wants to improve its return on net assets. Return on net assets can be broken down to two explanatory components which are profit margin and net asset turnover. Let's also assume that the company is satisfied with its profit margins and turnover, thereby leading to a conclusion that company's operating costs are acceptable, and targets for reengineering need to be found from its asset management. Net asset turnover can be explained with fixed asset turnover and working capital in days. Presuming that fixed asset turnover is satisfactory, there is a need to improve our performance in stock days, debtor days and creditor days that present an explanatory breakdown for company's working capital status. Thus, in order to be able to meet an initial target which was to improve company's return on net asset we are left with three options:

Risk in business re-engineering 237 Renegotiate better contracts with suppliers (i.e. payment terms) Renegotiate better contracts with clients (i.e. payment terms) Reengineer appropriate processes within the company's value chain to cut down stock days The next step in a structured target setting process would be to quantifl all targets. In the example above, we would calculate exact days needed to be taken off from stock days in order to meet desired improvement percentage for return on net assets. This presentation intentionally concentrated on financial objectives to focus attention on bottom-line business results. Depending on overall objectives of a programme, detailed targets could alternatively be based on other perspectives (e.g, on-time-delivery %, time-to-market,...). The second situation in which there is a gap between overall objectives and targets which steer day-to-day development works is also surprisingly common. We suggest that it is mostly due to the fact that company management have a good intuitive understanding on required improvements, and they then manage to define overall objectives for their initiatives. However, they fail to break their objectives down to development projects in a structured manner, thereby leaving overall objectives represent more like wishes than real steering targets. If project managers do not get exact targets which they can understand and manage, they usually invent their own ones with good intentions. Accidentally, these targets can of course be in accordance with company management's wishes. Too often they aren't. Many companies set up business reengineering programmes under the false assumption that if they conduct a set of almost randomly selected improvement activities, company's business performance will improve accordingly. We suggest that successfbl change begins with results in mind. 2.3 Conflict between Vision and "Leg Works"

In a business reengineering programme the company management is usually responsible for illustrating a blueprint for desired solution. This blueprint is called operational vision, and it is usually created at the early stages of a programme in conjunction with target setting process. A somewhat similar risk than the above mentioned target gap problem is unsuccessfU1linking of overall visions and detailed solutions. According to our interviewees this is usually due to the following reasons: Company management fails to communicate their vision properly to development teams Company management fails to obtain a buy-in for their solution Operational vision is unrealistic and cannot thus be implemented Visioning process is conducted in parallel with detailed design, leading to the situation in which detailed design work is based on incomplete, and changing, operational vision Development teams have a tendency to slip from preset operational vision and corresponding target levels

238

Valimaki and Tissari

At this point it is obviously impossible to give comprehensive explanations on why these situations are so common in business reengineering programmes. One interesting way to look at the problem is in terms of organisational ownership. In some instances we were told about companies which have set up dedicated development teams to oversee their change programmes. This isn't unusual, but these teams had hrthermore managed to take over responsibility in such a manner that employees from companies' top management to staff level considered them as outsiders to these initiatives. A few possible pitfalls emerge. For example, it is possible that the top management can't tolerate their limited role, and they would then ignore whole programme resulting to poor conduct of the visioning phase. In some cases the lack of ownership across top management has led to situations where, despite of significant quantity of communication, conflicting and ever changing messages on operational vision seriously confhes development teams. In one case a company had changed their hll set of key processes several times during the early phases of a business reengineering programme. This could naturally be acceptable as operational visioning must be an iterative process, but the real problem was that each set of key processes was presented to the company. Just picture the situation - last week we had these key processes, but now we have a new set, and obviously we will change our minds next week as well. It would be surprising if credibility of the company management and change programme wasn't damaged. 2.4 Conflict between Objectives and Development Effort Business Reengineering must go beyond departmental and hnctional streamlining to reinventing the way a business operates. We must think of it as starting from scratch in order to achieve hndamental changes in the way a business operates. There are unfortunately no shortcuts available, and the scope of a business reengineering programme has to always be significant. In all too many companies this fact has been ignored. While in some companies the biggest challenge is to find enough time from top management and other key change resources, in others a major problem seems to be the unwillingness to invest money, for example, on information technology. An interviewee told about a large international company which had undertaken a major change programme in order to transform the whole company to be "the best in its business". They however managed to dedicate only 1.5 hll-time persons to their development team. This creates a situation that, in a sense, forces to question company management's motives for the programme. In some cases it was evident that programmes were only started to identifl potential benefits that a real change initiative could later produce, and maybe additionally to learn more about business reengineering hndamentals in order to be well-prepared next time. Despite of good intentions, this approach can cause a lot of harm, and, in fact, many reengineering initiatives fail because of overall frustration created by these test projects. How many times have heard comments like this: "OK, this is just one of those change programmes that we start every year. I'll do what I am tasked to, but I hope that it doesn't take too much time from my real work. I haven't noticed any benefits from previous projects, so why would I bother?". It is important to understand that in order to be able to achieve significant benefits one must be willing to spend, and accept corresponding risks as well. As mentioned,

Risk in business re-engineering 239 there are no shortcuts available. We also suggest that company management should be much more careful in separating TQM and business streamlining programmes from real business reengineering in their communication. By creating high expectations with unrealistic promises in programmes which are clearly targeted to produce minor changes, companies threaten their possibility to succeed in upcoming business reengineering initiatives. 2.5 Right Things are done in Wrong Way In order to be able to be successfbl in business reengineering programmes there is an obvious need to guarantee that all right things are done in the right way. This is of course a naive statement, but, in the end of a day, it all comes down to the fact that the proper technical conduct of different phases, such as operational visioning, process design and conference room pilots, is not good enough. Major changes in performance can only be achieved if all persons involved thoroughly understand and appreciate objectives, reasons, roles and deliverables for their proportion of the work, and for the whole programme. This of course puts a lot of pressure to the development teams, and requires a comprehensive shift in mindset. It is no longer acceptable just to produce what they are tasked to - they need to commit themselves to meet and exceed all expectations and objectives in any possible way. As a conclusion we suggest that the key for reengineering success is to allocate right persons and teams to oversee and implement the change. These persons require tremendous insight, creativity, diverse skills and knowledge, and perhaps above all the ability to facilitate change in their organisations. Unfortunately, these are always the top people who nobody wants to give up. If company management however refuses to release the best people for their business reengineering programmes, why would they bother to start in the first place. In fact, no manager, who is responsible for initiating a business reengineering programme or project, should afford to ignore this fact.

3 Risk management in business reengineering

3.1 Qualitative Risk Measures Risk management in business reengineering projects, like in any projects, includes applying the general risk management tools and techniques. Business reengineering projects have however many risk elements which are qualitative in nature and can not be addressed with traditional measures. To manage these risks that are both systematic and behavioral we suggest that a comprehensive qualitative risk management system is established in projects. An objective of the system is to collect systematic, comprehensive and reliable status information on the project using a set of questionnaires. Good questionnaires for collecting the qualitative risk information should meet the following criteria: I . Addressed to all relevant stakeholders of a project. Too often risk management is based on the subjective observations and perceptions of the project management team. The problem then is that only the voice of the loudest and most aggressive people will be heard. This way the risk management is far from objective and comprehensive. It is therefore important to include all parties involved in the project to the target group

240 Valimaki and Tissari

for the questionnaires, for example employees, line managers, operative project management, and the steering group. 2. Action oriented. Questions in the questionnaires must be practical enough so that the required reactions can easily be identified based on the answers. If the questions are too abstract or too broad they can not be used as a tool in decision making and have no practical importance. If the measurement process results do not lead to clear actions, people feel very little motivated to answer next time. 3. Continuous. Because these measures are qualitative it is not the absolute values that are informative, but the changes in the results. It is important to follow-up the progress of the different aspects of the project, and therefore at least a part of the measures should remain unchanged for a longer period of time. 4. Short and relevant. If the questionnaires are too large and it takes too much time to understand and answer the questions, people refise to participate. So, it is essential to concentrate on the most relevant things in the questionnaires. What is relevant may vary during the life cycle of a project, so some of the questions may be left out and new ones may be added in as the project evolves. 5. Integrated to other possible measures. It may be value adding to use qualitative measures for evaluating and measuring other aspects of the project, such as customer expectations, customer satisfaction and achieved progress, as well. If questionnaires are used for several purposes they must be integrated in the best possible way so that as little effort as possible is is spent for designing, collecting, analysing and reporting the measures. It must also be noted that designing measures and collecting feedback using questionnaires is only the beginning. How the measures will be used, analysed, reported and acted upon, must also be planned together with the questionnaires. If the information included in the qualitative measures is not delivered to the right persons with enough authority and motivation to react on the results, the measures are of no use. The results must be communicated to the people who are responsible of the activities and corrective actions must be carried out rapidly. 3.2 Examples of Qualitative Risk Measures How this risk management approach can be brought into practice is illustrated using examples. The existence of risks in the presented five areas (see Chapter 2) can be recognised by addressing different stakeholders of the project with statements that they rate according to if they do or do not agree. The statements naturally vary between programmes and projects according to the objectives, organisation and environment. However, general examples of the possible statements in a questionnaire are presented. The target group of the question is in brackets in the end of the question. In the examples the target group is either the project sponsor, line management, employees or project management. 3.2.1 Unsuccessful balancing of development elements All levels of organisation are able to give their point of view whether the change is comprehensive enough and whether the different elements of change are well integrated. Radical changes in business processes may be difficult to implement without any technical support. Alternatively, the change will not be thorough and lasting, if the organisational aspects are ignored. However, the different elements are just tools for

Risk in business re-engineering 241

change, and only the elements relevant to achieve the programme objectives need to be considered. Strategy, processes, organisation and technology elements are properly balanced in the project (sponsors) Company's accounting principles, performance measurement system and management reporting support your new role and responsibilities (line management) Company's contribution rewarding, training and development systems are in accordance with new operational model (line management) I understand and accept my role in the new process (employees) I understand and accept new expectations against which my performance is measured (employees) Information systems support me properly in my new responsibilities (employees) 3.2.2 Unstructured target setting and project initiation In the project initiation phase, usually only management is actively involved. The statements below reveal whether the management considers the programme objectives relevant and consistent with the business needs. Additionally, the activities and approach selected to achieve the objectives is evaluated. Although the questions deal with project initiation, it may be usefil to assess the meaningfidness of the programme also in later phases and adjust plans if necessary. The programme corresponds well to business needs (sponsors) The programme objectives will be achieved using the selected approach (sponsors, project management) The objectives of the programme are among the most important improvement areas (line management) 3.2.3 Conflict between Vision and "Leg Works" The operational vision behind the change has no value if it is not visible and possible to implement. It must be linked to concrete objectives and activities in the programme, and everyone involved must know and understand the meaning of the vision. Operational vision has been successfUlly implemented during the programme (sponsors) Operational vision is realistic and thus possible to implement (project management) All development actions in my project or sub project are in line with the operational vision (project management) 3.2.4 Conflicts between Objectives and Development Effort This risk area considers how realistic the programme objectives are in relation to the effort. The more radical improvements are to be gained by the programme, the more effort must be put in the development. Enough qualified resources must be dedicated to the programme in all levels of an organisation, both in the programme and in the line organisation.

244

del Caiio et al,

At a short or medtum term, surely it will be impossible to return to the 70's market volumes. The main cause of it is that Spain was involved in a process of progressive industry saturation, beginning in the 70's and endmg in 1985. Since that year Spain has had enough industrial level to compete in Europe and in other industrialized countries. So since 1985 the main activities in this subsector have been natural gas pipelines, power cogeneration facilities (with a certain support by the Spanish administration) and expanding and revamping of existing plants. The construction of new large industrial plants has been rare in the last ten years. In relation to the public infrastructures sub-sector, between the years 1987 and 1992 the contracting volume was dramatically increased to construct several public infrastructures for the Seville's EXP0'92 and Barcelona's Olympiad. For instance, in years 1989 and 1990 the market growth rate for this sub-sector was 12% per year. After 1992, the public works contracting volume decreased in a very high amount, with a slight recovery in 1996. 1987-1992 was, in fact, aperiod of general boom for the construction sector (excludmg the industrial construction), and specially for singular buildings construction (EXP0'92, Olympiad). Some other sub-sectors, such as office buildmg, also underwent a certain recession process from 1992 to 1996. That process was very similar in other European countries, with the property and rental prices frozen and even slightly decreasing. The recession was slight for the residential architecture and for the construction of commercial areas and buildmgs from 1992 to 1996, with a certain increase in its markets during the last year. In that environment, many small and medium contractors have had large problems to survive. Nevertheless, the sector is very competitive and aggressive. And a substantial part of the medum sized and most of the large companies have good financial health, thanks to contracts awarded outside of Spain (in the European, North-African, Latin-American, and Asian areas) and to business dversdying strategies (such as the property, the waste management and the BuildOperate-Transfer fields dedcation). The diversification rate can be as high as 40% or even 50% in some companies. 1.1.2 Construction engineering companies The Spanish sub-sector related to industrial and building construction engineering is suffering the consequences of this situation. In addition, there are also some intemal problems that threaten to reduce it to just a few companies. Many companies have had an important loss of human capital, with many of the best (and most experienced) persons escaping to other sectors or roles (such as working in a contracting firm or as part of the owner organization, in project oriented companies). Although the contracting firms general competitive and aggressive character alluded to in the precedmg paragraph has not been as high in this case, this sub-sector is maintained mainly by the big and multinational companies and by companies performing both engineering and contracting (design+build contracts) andlor competing outside Spain. The case for the public infrastructures construction engmeering is a f e r e n t because some years ago (before the boom of the 1987-92 period) the Spanish Ministry of Public Infrastructures decided to change from an intemal design elaboration to contracting engineering companies for that purpose. This measure has led to a very good environment for this sub-sector, and the evolution has been satisfactory.

Risks in small and medium companies 245 1.2 The company internal environment at the beginning of the clisis Our case study company was founded to be an engineering firm in the field of buildmg electrical and control services. As time went by, the firm specialized in high-tech bddmgs. The company is a public corporation working at a national level. At the end of the 1978-1992 boom, the company permanent workforce was oscillating around 15 professionals, and with temporary collaborating persons had up to a total amount of 18-25 staff, dependmg on the moment. The main characteristic of the company in that times was the extremely high qualification of the technical personnel. That has been conceived by the board as a key to success. About 1990 the management detected bidding and contract downward trends with a probable turn-over decrease for the company at a short or medium-term. The board began immehately to study the environment and the company, and they designed a strategic plan to respond to the risk. 1.3 Risk response slrategies at the company level The main strategy was organized in three progressive phases, to evolve from a consultancy firm to a group of companies in the fields of consultancy and contracting. One of these companies initially existed, to own the group property (essentially office flats) and to rent it to the other group companies (with tax advantages achieved from that circumstance). Other applied strategies will also be explained later. 1.3.1 Main strategy: first step The first step was to recruit a few experienced people in HVAC (heat, ventilating and air conhtioning), coming from the best engineering and contracting firms in the country (one of them to be a partner). And immehately they began to offer both consultancy services and design+build contracts in the field of electrical, communications, HVAC, safety, security, and control systems for buiidmg (factories, offices, hospitals, pharmaceutical laboratories, hotels, commercial centers, sports centers, cinemas), specially for high-tech offices. The launching took place in a very few months and after a year they were performing the two kind of activities with a large increase in turn-over and a slight increase in profit rate.

1.3.2 Main strategy: second step About 1993 the previous action was consolidated at a minimum level with satisfactory results. The second step was to create a new company to be a contractor in the field of electrical, communications, safety, security and control systems. This company was also conceived to perform maintenance contracts for those kinds of systems. The share-holders were the same parent company partners. The initial key technical personnel was progressively re-assigned from the parent company when contracts were awarded. Other technical and administrative personnel and the labor was also recruited when contracts were awarded to support them. The company was conceived to be normally contracted by the parent company for their d+b (design+build) contracts. And also to gain new clients and grow in terms of volume and independence from the parent company. It took less than one year to have a completely running company with enough contracts to be self-supported.

246 del CaAo et al. 1.3.3 Main strategy: third step The previous step was a success that irnmedately allowed a third step to almost simultaneously create two new companies, again owned by the same partners. The first one was a company to be a contractor in the field of HVAC systems and civil works for buildmg construction. It was also conceived to perform maintenance contracts in those fields, performing integrated maintenance contracts in joint-venture with the company created at the second step, and together covering all the building contracting needs. Again the personnel was progressively re-assigned or recruited when contracts were awarded. The key staff came from the parent company except for one person experienced in civil works and coming from outside of the group. The company was also conceived to be normally contracted by the parent company for their d+b contracts, and to have a certain independence like in the previous case. The second new company in this third step was born to be an engineering firm specializing in energy cogeneration, but also oriented to small and medium power stations for industrial plants (gas, fuel), to small and medium hydroelectric power stations and to the exploitation of natural resources energy (solar, wind). This was conceived to open a new field of engineering activity for the group, and was destined to satisfy the previously referred to trends related to cogeneration in the several Spanish industrial sectors. The operation was supported by the parent company and began through assigning part time some of the parent company personnel and recruiting a very few highly experienced professionals in this field coming from one of the best engmeering firms in the country. The new company has a very reduced workforce and shares the offices with the parent company. The firms' launching in this third step was slow for the engineering company, and took one year and some months for the contracting firm to be self-supported.

1.3.4 Other strategies While implementing the referred main strategy, other strategies have been respected (if existing) or implemented (Ifnew). Some of these strategies have been:

To generate a continuous and steady client portfolio. This has been achieved, firstly, looking specially for project oriented clients. And secondly, inculcating a general willingness for the well done work in the personnel. To continuously improve the marketing force effectiveness. This has been achieved mainly through the existing results-based salary system; recruiting experienced and well connected professionals; signing collaboration agreements with companies to work in joint-ventures; and signing collaboration agreements with free-lance marketing professionals. To maintain a high level in their engineering services and resources, retaining the key technical personnel. This has been possible with salaries over the market average; with wide investments for periodcal training; and offering to exceptional key professionals to be partners in the company (when strictly necessary). To decrease the group internal operation costs for decreasing prices to clients as enough as to be in the market average (and then, if possible, to increase profit). This has been possible establishing a complete general cost reduction plan at all levels including, among other aspects: Outsourcing to limit the staff increasing to the strictly necessary.

Risks in small and medium companies 247 When applicable, moving to other offices in the same area (or in other similar one) to have a lower cost of rent. Optimizing to the maximum the office layout, decreasing the square meter per person ratio, although avoiding adverse effects over functionality. This helped to decrease the cost of office rent and to optimize the use of property offices. Designing and implementing a system for personnel performance assessment connected with a salary system based in work results. Designing and implementing a more comprehensive system for monitoring and control of company expenses. To improve the internal coordination and functions by means of a company general procedures manual. To elaborate a set of standard engineering designs and specifications. This has been helping to facilitate the technical work, to increase the quality of design and to save time while working in engineering and commissioning. To save time working with fast and effective hallmarked computer aided design systems suitable to the company characteristics, trying to obtain the maximum possible automation level in these aspects. To improve the group external image. This has been achieved, firstly, through the well done work, the offices, or the multimedia company presentations towards potential clients. And secondly, interacting with the personnel. For the parent company, to be pioneers, among the engineering and contracting companies with a similar size, in quality system certification. The parent company decided to be one of the first companies obtaining the ISO-9.001 cerhficate. 1.4 Main resulfs Taking into account the referred external environment, the risk of maintaining the initial configuration could be very high for the company survival, maybe both in probability and severity. On the other hand, the risk of implementing the related growth strategies was probably high. Nevertheless, the measures have been successful up to a point and the parent company has currently an important turn-over percentage related to d+b contracts with a minority of consultancy contracts, in economic terms. Their financial health is satisfactory, and they are making the first attempts to work in the nearest European countries. The new partners introduced some minor mfferences but the results have been satisfactory, because the company survived the crisis even slightly increasing the number of staff (the staff number increase could be higher, but the board preferred to maintain the parent company size). In relation to the new companies in the group, the first of the contracting companies has been a success, with a rapid increasing of turn-over and workforce, going in less than one year from 10 to 40 staff. The second contracting company had more normal results and, after one year, the partners decided to merge the two companies. The new engineering company has been the last one to appear and implies a business uferent from contracting. And so, the environment is different and the progression will not be as rapid as in the other cases. This firm could be also a success, but some more time is needed to observe the evolution. Probably the result could be a merger between this company and the parent company. In relation to the group, the total staff has gone from 15 to more than 60 permanent persons, with the correspondmg increasing in turn-over and profit. As we will see, the company was, probably, the first of its size to achieve the ISO-9.001

248 del Caiio et al. certificate in the Spanish construction sector. 1.5 Key success factors In this case, in our opinion, a considerable part of the final success belongs to the principal partner, who was the main driving force in conceiving the strategies and the operations with creativity; in combining experienced enterprising young people with mature professionals with a high level of knowledge and experience; in leadmg all the personnel involved; and in solving the natural conflicts arisen in the process. The second main success factor was the vocation, hope, enthusiasm, enterprising and effort of many young staff and partners. They tried to maintain their jobs and to improve their personal circumstances and they followed the leader without hesitation. And specially the young partners, whose profile were the one of a professional with 10 to 15 years of technical experience working in leading companies as an employee. They tried to find a feeling of economic stability through being partners of the company. And they built their hopes up on the firm soundness because all of them worked previously together with some of the existing partners. So all of them have had a specfiic motivation. And the third success factor was the clever combination of young and very mature professionals (the mature helping and transferring their knowledge to the young people) with a general willingness for the well done work. Company level: conclusions A case in successfully managing company level risks difficult to respond, like the market risk, is presented. Business process re-engineering (BPR), total quality management (TQM), outsourcing, or simultaneous engineering are programs or philosophies that can help the management to confront that risks. But a specific program or philosophy such as the previously alluded to (or any other new to come) will not be the key to success by itself. Successful risk management need to combine different responses, defining the needs for specific generic programs (BPR, TQM, etc.) and, when needed, adapting it to be applicable to the case we deal to. Respondmg risk we need to work with intelligence, common sense, flexibility and almost daily monitoring and control, combined with leadership and just a touch of wholesome ambition. On the other hand, the solutions to respond risks could be simple in case of small sized and even medium companies. Anyway, the project risk will disappear when the project finishes, but the company risk never dlsappear. In this case, the group of companies must know to maintain the situation and to consolidate the new companies, in a possible period of boom. In that kind of period, the motivation that allowed the referred success can decrease, increasing the differences among the partners. To create and launch can be easier than to maintain and consolidate. Any way, this is an example of how a company can fight and win against risk with a proactive view, trying to define the future rather than to adapt to it, going up when market goes down, growing in a crisis environment. 1.6

Risks in small and medium companies

249

2 Part 11: the project level

2.1

Project and project management characteristics

2.1.1 Introduction As previously explained, one of the strategies to confront the risks at the company level was to be apioneer in the sector in achieving the ISO-9.001 certification for the parent company. This second part of the paper will deal with the way to manage risks in that project. At the beginning of the project, the company was already performing d+b contracts, activity to include in the quality certification. In addtion, the board wanted an extremely quick I S 0 certification, as usual, aimed to strengthen the marketing effectiveness. So, for several reasons, they contracted a consultant (at a fixed price). 2.1.2 Project breakdown structure (PBS) Here we include a summarized project breakdown structure [2] (work breakdown structure -WBS- plus organizational breakdown structure -0BS-), with the OBS in brackets:

1. Preliminary works. Analyzing company processes and existing quality documentation. Analyzing the existing company quality system (by the consultant). 2. Trying to find institutional subventions and managing the several steps to obtain it (by the consultant). 3. Certification process: 3.01. Selectmg the cerhfication body -AENOR, TW,Bureau Veritas, Lloyd's- (by the company, with advice of the consultant). Interface relations with the certification body (by the consultant). 3.02. Writing the quality procedures manual (by the company, with advice of the consultant). 3.03. Planning the new quality system implementation -strategies, responsibilities(by the company, with advice of the consultant). 3.04. Meetmgs to inform the personnel (by the company, with advice of the consultant, and with the consultant presence). 3.05. Needed personnel training (by the company, with advice of the consultant). 3.06. Implementing the quality procedures manual (by the company, with advice of the consultant). 3.07. Writing the quality manual (by the company, with advice of the consultant). 3.08. Implementing the quality manual (by the company, with advice of the consultant). 3.09. Quality manual and procedures approval (by the certification body, with the consultant helping the company to solve any problem). 3.10. Audit simulation (to the company by the consultant). 3.11. Pre-au&t visit (by the cedication body, with the consultant helping the company to solve any detected problem). Final audlt (idem). 3.12. Possible pendmg aspects solution (by the company, with advice of the consultant) and obtaining the I S 0 certification.

250 del Cafio et al. 2.1.3 Scheduling and cost aspects With the obvious overlapping between activities, the scheduling sequence for the project was the suggested in the PBS paragraph. The project duration estimated after the preliminary works was twelve months. At the beginning of the project, the followed monitoring system consisted in weekly control meetings with all the main involved personnel. As the quality manager appointment took place almost at the end of the project, the company top manager performed the project management. All the company personnel worked part time in the project, with the help of four external parttime people from the consultant organization. When the project showed a good behavior, and depending on the project phase, the control meetings were convened every two and even every three weeks. That control came back to weekly meetings when incorrect trends were detected. Despite the consultant advice and warning, the company internal costs estimation for the project was optimistically erroneous and it was an overrun in this aspect. It was even an overrun over the internal costs roughly estimated by the consultant, because the company management finally took a more relevant role than they initially conceived. This was caused by periods of excessive company normal work. In that periods, the management decided to assume a higher effort for decrease the effort from project personnel, that also worked in company normal activities. 2.2

Project risk management

2.2.1 Risk management The project risk management fun&on was assumed by the project team in a conscious way but without any documentation covering the process, taking into account the project costs. The main risk factors and responses were:

The extra effort developed by the top manager (risk of internal cost overrun). This risk was identified, assumed and also exploited as an opportunity, as we will see. The quality manager to be appointed (important and delicate decision) was a person who worked in aerospace quality systems, and tried to unnecessarily increase the company quality system requirements (risk of time and costs overrun). The response was, firstly, to postpone the quality manager appointment while persuadmg him about the real initial needs for the certfiication. And secondly, to anticipate an alternative person for the position. In these cases, the better way to avoid a wrong appointment is to assign to the project the possible persons for that position, and choose later the more vocational and motivated person between them, be or not the manager for the I S 0 project. The appointment can take place even when the project is endmg, providing enough time to integrate the several quality aspects implementation, and to assume the responsibility for the system presentation and defense in the final audit. Possible difficulties in obtaining the general commitment. This factor was ident ed and responded in several ways reflected in this text, thanks to the project manager leadership. The specific opposition to the project from one of the oldest partners. This factor was identified and its response is detailed below. The non-realistic company initial time objective for the project (six months). It was

Risks in small and medium companies 251 established a more realistic one (twelve months) after the preliminary andisis. The company optimistic estimation for the internal man-hours necessary for the project. Despite the consultant warning, this factor was underestimated by the company. The period of excessive work for the selected certification body, detected by the consultant and assumed by the company.

And the main success factors were: The highly qualified personnel. The effort developed by the top manager. To practice what one preaches was here, once again, essential. The top manager commitment, determination, perseverance and leadership. The top manager quick and strict decision making in case of conflicts, and specially in responding the opposition to the project from one of the old partners (as we will see below). The hope, enthusiasm, and effort from the young staff and partners. A close monitoring and control during all the project life cycle. To begin the process with the referred existing set of standard engineering designs and specs. This documentation was a key aspect for quickly achieving a positive quality system assessment by the certification body. To build an ISO-9.001 quality system using the previously existmg system. The existing quality system was adapted to the ISO-9.001 normative. Writing the quality manual and procedures by the company helped to produce a realistic documentation easier to implement. Is also important to in situ write the manuals, watching carefully the real processes and reaching a consensus with the personnel, to finally have feasible, ready to use documentation. 2.2.2 Crisis management Probably the worst project risk factor could be the referred opposition to the project. Finally this factor gave rise to a crisis, and the top manager (who was also the CEO, being the principal partner) solved the problem in a really severe way. Only two persons showed opposition to the project: a staff and the referred partner. They were also people with some other added previous problems inside the company. Quickly the partner received a generous offer from the other partners to buy his share, he accepted and abandoned the company. The staff was immehately fired. The other crisis arose at the end of the project as a consequence of a peak period of work in several d+b important contracts. As a result of that, the system implementation was neglected, and the results of the auht simulation made by the consultant weren't as positive as expected in that moment. Again the response was quick, and the top manager immediately organized several crash sessions to tie up the loose ends during the remaining period until the audit by the certification body.

2.3 Main project results ISO-9.001 certification was finally achieved with a slight delay (less than one month), due to the company and certification body peak periods of work referred to in the

252 del Caiio et a1 previous paragraphs. The company is satisfied with the result, mainly because they now enter more easily in bidding to big and multinational companies. So they have the opportunity to increase their project sizes. A summary of the project costs in Spanish currency (take approx. 1US$=140 pts.) is showed in Table 1. Table 1. Summary of project costs (pts.) Cost concept

Initial estimation

Final cost

Consultancy Certfiication body Intemal costs (approx. estimation)

1.100.000 962.500 4.000.000

1.100.000 742.500 5 .OOO.OOO

TOTAL COSTS

6.062.500

6.842.500

Project level: conclusions 2.4 A case in successfully managing project risks is presented. The costs to undertake this kind of projects may be really high for the small and medium companies. It is easy to obtain a certain support from public institutions. The subventions are only dlrected to the external costs but, unfortunately, it will represent a very reduced percentage of those costs, taking into account the large number of companies simultaneously applying for in last years. And that will be an insignificant part of the total costs. But this kind of projects use to be of strategic importance because some of the results are to strengthen the marketing activities and to help in costs reduction. In addition, this kind of projects normally have medlum to high global risk levels. Taking all that aspects into account, it's evident the need for a conscious and efficient risk management in this kind of projects [3]. That risk management has not the need, in these cases, to be a complex process [I]. It is enough with the typical four phases approach [4] (identfiication, analysis, response, documentation), with a minimum documentation covering the process and without the use of sophisticated quantitative risk assessment techniques [I].

3. References 1, de la Cruz, M.P. & del Caiio, A. (1996) Managing risks in small and medlum turn-

key facilities construction projects. A case study. Proceedings of the IPMA'96 World Congress on Project Management, Paris, pp. 457-464 2. del Cafio, A. and de la Cruz, M.P. (1995) Conceptos Bbicos de la Direccion de Proyectos, UNED, Madnd. 3. Chapman, C.B. and Ward, S.C. (1997) Project risk management. Processes, techniques and insights, Wiley, London. 4. Wideman, R.M. (1992) Project andprogram risk management, Project Management Institute, USA.

PART 6

PROJECT RISK MANAGEMENT IN ENGINEERING AND CONSTRUCTION

Constructing reasonably believable edifices: lessons fiom software, implications for construction K.L. HANSEN Complex Product Systems Innovation Centre, Centre for Research in Innovation Management, University of Brighton, Brighton, UK

J.E. MlLLAR Managing Knowledge and Innovation Research Unit, Open University Business School, The Open University, Milton Keynes, UK

Rather than speak of correct software in the unqualified sense, one should rather speak of reasonably believable software. Rather than say software is error free, the most one can usually say is that the conditions under which the next errors will be manifested have not yet arisen [I]. Abstract Notable similarities exist between software development and construction work. For example, both are craft-intensive, exhibit no consensual approach to project management, and are socially distributed. Risk is inherent to both industries. The dominant sources of risk arise from e m r s in requirements specification and lack of COordination within the network of project participants. There are two main reasons for this and together they have sacrificed the integrity of projects. First, relationships between the socially distributed network of groups responsible for development activities are generally adversarial and confrontational. Second, the focus for remedial action has traditionally been on optimising within task performance. This has maintained task fragmentation and separated responsible communities. In software, risk has been associated with problems of communication; in order to manage risk, strategies have been implemented which encourage co-operation among network participants. Through improved co-operation, potential areas of risk can be identified early in product development cycles. This paper examines such strategies as well as risk management approaches typically used in construction. The paper concludes that risk management practices in construction often focus on analysis of risk at the expense of identijication and suggests that valuable lessons can be learned from risk management methods used in software development. Keywords: Construction, network, management, product development, project, risk, software. Managing Risks in Projects, edited by K. KiihkiTnen and K.A. Artto. Published in 1997 by E & FN Spon, 2 6 Boundary Row, London SEl SHN, UK. ISBN: 0 419 22990 6.

256

Hansen and Millar

1 Introduction Notable similarities exist between software development and construction work. For example, both are craft-based, skill intensive and have low capital intensity. This is because both software development and construction activities have been based on techniques of production which are pre-industrial and pre-paradigmatic, in the sense that there is no consensual approach to project management. Despite abundant and sophisticated methodologies, the majority of activities associated with software development and building construction continue to be performed in an ad hoc and chaotic manner and are unrepeatable and unmeasurable. Methods of production are often implicit and few practitioners have had formal training. Surprisingly, software programs, like the built outputs of construction projects, display considerable longevity. Over the course of the product lifecycle, incremental changes may mutate their original designed form and functionality to the extent that they may be unrecognisable. As a result, they can only be effectively maintained if their design and construction have been adequately documented by the original designers. This is particularly rare in software, as documentation is considered a chore and software products have generally been designed under the assumption that they would have a limited economic life span. Further, software development and construction activities are socially distributed across place and time. As with the many project-based businesses, the principal constituent activities involved in software development and construction work are usually performed within a network, populated by different groups (often within distinct organisations) each responsible for various 'stages' of the development process. Relationships between these groups are often strained; historically, conflict, confrontation and adversarialism have characterised the product development process. Both software development and construction projects often suffer excessive cost and time overruns and produce poor quality end products. There are several aspects to poor quality products in software and construction, these include products which are unfit for their purpose, inappropriate to end users needs, unreliable (containing a large number of faults) and those which have poor maintenance and upgrade capabilities. Clearly, clients and end users of software alike face serious uncertainties and risks that the product they anticipate will not be delivered. 1.1 Risk in project-based industries Uncertainty becomes risk when the perceived significance of the consequences of an uncertain event become critical. Therefore, risk can be defined as any uncertain event which has an impact (usually adverse) on the outcome of the project [2]. Some researchers make a slightly different distinction between risk and uncertainty. In their view, risks are those uncertainties which can be identified and quantified [3]. In other words, risk occurs when the outcome of an event or circumstance can be predicted on the basis of statistical probability. For the purposes of this paper, risk is discussed using the former, broader definition: risk involves the likelihood that a system will behave in unpredictable ways, the outcome of which may be undesirable. Risk is endemic to modem society. It is a key feature of economic growth in a period characterised by rapid technological change, the emergence a pattern of innovation based on technology fusion [4] and the transition to a knowledge-intensive

Software development and construction 257 economy [3]. Risk is a precondition for innovation and is intimately connected to learning and change [4]. During innovation, the generative, uncertain and complex activities involved in generating innovative variety are in conflict with the simultaneous requirements for convergence, control, regulation and standardisation [5]. In order to resolve this conflict, a balance needs to be struck between the demands for risk reduction and the need for variation. Risk is particularly associated with project-based businesses such as software development and construction. In these industries, product development depends on co-ordinating the activities of a network of socially distributed (both in terms of their disciplinary base as well as their geographical location) actors, each with their own particular strategic aims and objectives. Concerns over the economic, environmental, and technological hazards connected to such businesses have grown alongside scientific techniques of risk assessment, involving the evaluation of 'proneness to failure' [31, and risk management practices (which are often implemented as mere acts of faith). Networked structures are typical in project-based businesses [8]. In general networks are prejudiced in favour of innovative activities associated with the generation of a variety of new ideas, as distributed groups work independently (often at different locations) on developing aspects of a technological system. This stimulates uncertainty and generates risk in the producttproject environment. These take precedence over the generation of ideas which are linked to standardisation and control [9]. The risk associated with placing the emphasis on generating a variety of ideas in the producttproject environment is compounded by the lack of co-ordination between members of the network. As a result, in the absence of effective risk management practices, networks can often be considered as a source of risk in themselves. One response to this has been to stimulate cultural change in project-based industries in order to introduce synergy among project teams and end the inherent adversarialism that has previously characterised project-based businesses such as software development [lo] and construction [ll]. The aim of this paper is to analyse the implementation of risk management approaches in software development and to examine the lessons that can be learned for transferring such techniques to construction.

1.2 Structure of the paper The paper is structured into four further parts. Part 2 identifies the dominant sources of risk and Part 3 examines risk management practices in both software and construction. Part 4 summarises the lessons that can be learned from software and the implications of applying similar approaches to construction. Conclusions are given in Part 5. 2 Comparable edifices: sources of risk in software and construction Risk is inherent to both software and construction projects. The dominant sources of risk arise from errors in requirement specifications and lack of co-ordination of project participants. These sources of risk are related, as the network of interdependent actors involved in the product development process often have conflicting strategic aims, objectives, understandings of and requirements from the systemic products under development [2]. This conflict tends to generate a variety of possible design alternatives and stimulates uncertainty regarding the desirable features of eventual

258

Hansen and Millar

product design. At the same time it reinforces the cultural distinctions between the various groups which may result in a breakdown of communication and lack of synergy. As a result, in software development projects for example, risk is particularly associated with lack of coherence at the interfaces between software system components on the one hand and between the software system and the business organisation on the other. These problems create further sources of risk as they compound project delays and incur unanticipated and often high levels of cost. This has led to the development of risk management strategies which attempt to achieve certainty of payment through shifting the risks associated with product development. In construction projects, risks are typically shifted from the clients to the contractors through the use of design and build approaches [12][13]. In software projects risks may be shifted from the system development team to the eventual users of the system through encouraging 'end-user' involvement in projects in order to foster ownership of the system under development). Generally, in software development projects, over 56% of errors are due to faults in requirement specifications; correcting these absorbs approximately 82% of maintenance effort [14] and incurs high levels of cost as remedial action may involve substantial system redesign [15]. The majority of errors are those which are the most expensive and require the largest maintenance effort to put right. A detailed analysis of the requirements specification faults which typically contribute to such risks identify them with problems of communication. There are five main sources of difficulty which contribute to these problems of communication [10][15]. The first is due to vast differences in the origins, quality and style of expressions used to express knowledge that is relevant to requirements specification. Second, there is considerable variety in the forms of knowledge which may be drawn on when specifying requirements. Third, conflict is inherent to the requirements specification process, the derivation of requirements therefore relies on conflict management and resolution. As a result, and fourth, the quality of the requirements specification relies heavily on negotiation. Fifth, the fundamental uncertainty and instability of relevant knowledge lends these characteristics to the requirement specification itself. These features draw attention to the significance of achieving effective communication between the network of actors involved in software development projects. Construction also has its share of communication problems. Adversarial relationships have been a long standing issue in construction as have general problems of establishing userlclient needs [I 11. Drawing from the categories listed above, Table 1 highlights some of the types of communication problems which exist in construction.

3 Risk management practices in software and construction In software, risk management emphasises the identification of risk. As previously noted, problems with communication introduce risk. This has lead to the development and use of a range of techniques which enhance communication among project teams. In construction, however, risk management has tended to emphasise risk analysis over risk identification. As discussed in more detail below, the fragmented nature of the project process and historical association of risk with indemnification in construction contribute to the focus on analysis rather than identification.

Software development and construction 259 Table 1. Examples of communication problems in construction Area of difficulty

~~~i~~ examples

Construction examples

Style of expression

Poorly articulated statement of needs from clientlowner Inaccurate interpretation of government codes and regulations Inadequate, incomplete, or erroneous sitdas-built information Varying information media (verbal, written, video, IT) & sources Unanticipated requests from owner for alternatives, feasibility andlor trade studies

Misunderstandings due to differing vocabularies of network members Labour disputes

Variety of input

Conflict resolution

Negotiation

Negotiation of change orders Failure of project partners (owner, architect, engineers, contractor, etc.)

Uncertaintylinstability

Inflation Fluctuations in currency rates of exchange

Defective or incomplete design Clientlarchitect initiated changes Accidentstsafety Disputes over subcontractor performance Poor labour productivity Schedule compression Lack of or untimely payment Negotiation of change orders Delayed disputes Re-negotiation of labour contracts Unknown subsurfacd differing site conditions or groundwater Acts of God Public disorder

3.1 Approaches to risk in software The high potential for error in software requirements specification demonstrates the complexity of the requirements engineering effort and underlines its significance as a major source of risk. As a result, the requirements specification process has been a target for recommendationsof practice change. Procedures and technologies have been implemented in order to reduce risk through optimising within task performance (for example, through the development of automated 'point tools' targeted towards either requirements engineering or software design), or through attempting to integrity among individual software system components (automatic consistency checking). The two main solutions proposed to alleviate these risks are: the application of advanced technology to support or automate risk sensitive aspects of the software development process and stimulating the industrial maturity of the software development process by promising standardisation partly through capital intensification. These approaches have met with little success. This lack of success is because they have dismissed the significance of social communication among the network of groups involved in the development project. In addition, these solutions have restricted attention to the activities of technical groups involved in software development and so failed to tackle sources of risks associated with the lack of integration between the overall system and the business function that it is intended to support.

260

Hansen and Millar

The situation is changing. The identification of risk in software development with communication has led to recognition of the need to enhance communication across the entire network of project participants in order to reduce risk. Through enhancing communication between these distributed actors, it is hoped that networked product development processes will become characterised by openness to new ideas and by access to decision-making processes [7]. It also is intended that this will provide equal infrastructural support both for variety and for standardisation and convergence.

3.2 Approaches to risk in construction Within the business of construction, multiple techniques have been adopted to improve risk management in projects. These include PERT (Programme Evaluation and Review Technique) used to analyse schedule risk, Monte Carlo simulations, cause and effect diagrams, fault trees, and decision trees, etc. (See Table 2 for a list of these techniques). Project management experts advocate the use of these methods. Originally risk management was the domain of insurance companies, where risks are bought and sold. ArchitectuI-al and engineering firms carry errors and omissions insurance policies. Additionally, many owners require surety bonds of their contractors. A surety bond is a financial instrument issued by a third party (surety company) to a first party (owner) which provides a guarantee that a second party (construction firm) will complete a project according to the terms and conditions of a written contract. In the 1980's the surety bonding business experienced several successive years of heavy losses which has lead to the use of innovative approaches such as neural networks as a way of rating new construction bond applicants [16]. However, the approach to risk used by construction firms seldom is based on sophisticated quantitative techniques. In an investigation of strategic decision making in large architectural, engineering, and construction firms, Hansen [17] noted that f m s tend to ignore remote possibilities, look at a few outcomes rather than all alternatives, and focus on opportunities rather than dangers. Firms developed several ways of managing risk by using incremental approaches, performing cost justification exercises, limiting expenditures to those which could be funded from existing projects rather than overhead, and passing risk to vendors and subcontractors through the use of performance clauses in contracts. A study carried out in the UK resulted in a similar finding. In 1992 a survey of expert project management practitioners was undertaken to determine the level of awareness of project risk analysis and management techniques. The sample was drawn from the special interest group concerned with risk of the UK Association of project Managers (APM). Although the 37 practising member sample was small, participants were considered to be expert. As indicated by Table 2, more traditional techniques such as checklists, Monte Carlo simulation, and PERT were favoured [18]. Regardless of the risk analysis technique employed, the focus on remedial action by optimising within task performance has tended to lead to sub-optimisation of the overall project process. This fragmented approach currently is being challenged by sophisticated owners who want more value from their expenditures on constructed products, by project financing vehicles such as the Private Finance Initiative (PFI), and by EC Directives requiring member countries to implement national legislation which demands greater teamwork in the planning and execution of projects (introduced in the UK by the 1994 Construction (Design and Management), or CDM, Regulations) [19].

Software development and construction 261

Table 2. Project risk analysis techniques Use currently

Used in past but not now

Aware of but not used

Have not heard of

76

0

8

4

Controlled Interval & Memory Modelling

8

0

48

32

Decision trees

44

0

48

0

Fuzzy set theory

0

0

64

24

Game theory

8

0

48

24

Influence diagrams

28

0

48

12

Monte Carlo simulation

72

4

16

0

Multiple criteria decision making models

24

0

36

28

PERT

64

4

24

0

Sensitivity analysis

60

4

20

8

4

0

48

36

Technique

Catastrophe theory Checklists

Utility theory -

-

-

Note: % indicates percentage of positive response from 37 participants

Adapted from: J.A. Bowers, 1994

Therefore, Risk Management, as a distinct activity, is gaining attention in construction. Practitioners and researchers alike advocate a two phased approach using assessment and action [2][20]. Figure 1 depicts the usual components of the risk management process.

r Assessment

Identification

I

Analysis Prioritisation

Risk Management Action

-€

Fig. 1. Elements of risk management

Allocation (hold. avoid. reduce. M e r . share) Monitoring & reporting

262

Hansen and Millar

Although techniques for analysis are more robustly developed, the identification of risk is seen as the most critical element of any risk management scheme as risk cannot be managed if it is not identified.

3.3 The changing nature of risk allocation Recent economic conditions have tended to change the nature of risk allocation in construction. In a recessionary period, the number of business failures generally increases, which leads to the desire to share the risk of financial failure and changing economic conditions [21]. Additionally, due to downsizing, many firms do not have diverse portfolios of projects and operations across which to spread risk. These f m s are often interested not in sharing risk but in shifting risk altogether to another party. A recent study on perceptions and trends in risk undertaken in the US compares a survey of ENR s (Engineering News and Record) top 100 US contractors of 1992 with an American Society of Civil Engineers (ASCE) survey conducted in 1979 [21]. The results indicate that certain risks are associated consistently with either contractor or owner. Risks allocated to contractors in both surveys include those involving: labour, equipment, and material availability; labour and equipment productivity; quality of work; safety; labour disputes; and competence. Risks allocated to owners in both surveys include: permits and ordinances; site accesslright of way; defective design (which normally would be transferred to the architectlengineer); changes in work; and changes in government regulations. Apparently, owners and contractors are willing to accept these risks as they consider themselves able to control these risks or take action to curtail or prevent their occurrence. The trend, however, appears to be toward sharing contractuaVlegal risks, which in the earlier survey were borne more by owners [21]. Today many large construction f m s either retain lawyers or employ them in their home offices. Contractors may be more comfortable in negotiations and are therefore more willing to share risks associated with change orders, contmct delay resolution, and indemnification. Additionally, the use of insurance has increased which provides an addition means of avoiding risk. Finally, current interest in design build and private finance initiative (PFI) projects also has focused attention on risk management and on achieving objectives in terms of time, cost, quality, and performance as well as future income stream. In these cases the bidding team is under considerable pressure to ensure that risks are allocated correctly. The management of risk in construction is becoming important as concerns over economic, environmental, and technical hazards have grown alongside scientific techniques of risk analysis. Yet currently available tools for analysis of risk do not seem to have been adopted by the majority of firms. As the next section illustrates, approaches used in software can provide valuable lessons for construction.

4 Lessons from software, implications for construction

A number of collaborative approaches to software development have capitalised on the awareness that risk can be reduced through effective communication. Among these are the socio-technical systems approach to participative systems design, exemplified by the ETHICS [22] method, and the Scandinavian collective resource approach, see [23].

SofhYare development and construction 263 Common to these many variants is prototyping, whereby continual negotiation among members of the project team iteratively evolves the design, refinement and development of the product under development, for example, Rapid Application Development (RAD) in software. RAD techniques for software development involve intensive negotiations among heterogeneous and cross-functional teams of specialists. Each specialist in a RAD team is a representative of one of the various functional groups in the product development network. These specialists coalesce on a temporary basis in order to collaboratively and incrementally evolve new software solutions to business problems. Under certain circumstances, this has been shown to lead to software project success through eliminating misunderstandings in communication and enhancing business members' ownership over the software product [24]. In view of these positive results, a revised risk management scheme for use in construction is proposed. In this enhanced model, risk identification is given a more prominent role and techniques drawn from software, such as RAD, are used to encourage communication and co-operation among members of the project network.

I-

Risk Risk ~ a n a g e m e n tIdentification, (e.g. RAD techniques)

Allocation

Action Monitoring & reporting

Fig. 2. Revised risk management scheme

5

Conclusions

Through enhancing communication between the distributed actors involved over the project lifecycle, it is hoped that networked product development processes will become characterised by openness to new ideas and by access to decision making processes. The by-product of this enhance communication is the early identification of risk associated with the project process. 6 References 1

2. 3. 4.

5.

A. Macro and J. Buxton. (1987) The Craft of Software Engineering. New York: Addison-Wesley. Crossland, Rose, Jon H. Sims and Chris A. McMahon. (1995) 'An ObjectOriented Design Model Incorporating Uncertainty for Early Risk Assessment.' 1995 ASME Design Engineering Conference, Boston, USA. R. F. Fellows. (1996) "The Management of Risk," The Chartered Institute of Building, Ascot 65, 1996. F. Kodama. (1991) Emerging Patterns of Innovation. Boston, Mass.: Haward Business School Press. OECD, "Employment and Growth in the Knowledge-based Economy," . Paris: OECD, 1996.

264

Hansen and Millar

R. Herbold, "Technologies as Social Experiments. The Construction and Implementation of a High-Tech Waste Disposal Site.," in Managing Technology in Society, A. Rip, T . J. Misa, and J. Schot, Eds. London: Pinter, 1995, pp. 185-197. J. Jelsma. (1995) "Learning about Learning in the Development of Biotechnology," in Managing Technology in Society, A. Rip, T. J. Misa, and J. Schot, Eds. London: Pinter, pp. 141-165. M. Hobday. (1996) "Product Complexity, Innovation and Industrial Organisation," Research Policy. D. Foray and M. Gibbons. (1996 ) "Discovery in the Context of Application," Technological Forecasting and Social Change, vol. 53, pp. 263-277. S. Easterbrook. (1991) "Negotiation and the Role of the Requirements Specification," The University of Sussex, Brighton, Cognitive Science Research Reports 197, July 1991. M. Latham. (1994 ) "Constructing the Team," HMSO, London, Final Report of the Govemment/Industry Review of Procurement and Contractual Arrangements in the UK Construction Industry. G. J. Hodgson. (1995 ) "Design and build - effects of contractor design on highway schemes," Institution of Civil Engineers and Civil Engineering 108, May 1995. Thurston, D.L. (1991) 'Design Evaluation of Multiple Attributes under Uncertainty,' International Journal of Systems Automation: Research and Applications, vol. 1, pp. 143-159. T. DeMarco. (1982) Software Systems Development. New York: Yourdon Press. I. Sommerville. (1992) Sofiare Engineering. New York: Addison-Wesley. Kangari, Roozbeh and Moataz T. Bekheet. (1995) 'Risk assessment of construction bonds underwriting using neural network technique,' Integrated Risk Assessmenr: Current Practice and New Directions, R.E. Melchers and M.G. Stewart, eds. A.A. Balkema, Rotterdam, The Netherlands, pp.139-146. Hansen, Karen Lee. (1993) H o r v Strategies Happen: An Investigation of the Decision to Upgrade Computer Aided Design (CAD) in Architectural, Engineering, and Construction Firms. Doctoral Dissertation, Department of Civil Engineering, Stanford University, Palo Alto, California, USA. Bowers, John A. (1994) 'Data for project risk analyses,' Irztemational Joumal of Project Management, vol. 12. no. 1, pp. 9-16. Neale, Brain S. (1994). 'Generic health and safety standards - EC Directives and technical policy implications.' ISARC Proceedings 1994. Elsevier. Boothroyd, Catherine. (1997) 'Managing Risk in Construction,' Managing Value and Risk for the Clients Benefit, Members Report 96-21-S for the Construction Productivity Network, ClRlA, London. Kangari, Roozbeh. (1995) 'Risk Management Perceptions and Trends of U. S. Construction,' Jo~tmulof Construction Engineering and Management, American Society of Civil Engineers, Dec. 1995, vol. 121, no. 4, pp. 422-429. E. Mumford. (1995) Effective Systems Design and requirements Analysis: The ETHICS Approach. London: Macmillan. G. Walsham.( 1993) Interpreting Information Systems in Organizations. New York: John Wiley and Sons. J. E. Millar. (1996 ) "Interactive Learning in Situated Software Practice; Factors Mediating the New Production of Knowledge During iCASE Technology Interchange," in SPRU. Brighton: University of Sussex, pp. 248.

Towards a qualitative risk assessment framework for construction projects J.H.M. TAH School of Construction, South Bank University, Wandsworth Road, London, UK

Abstract In this paper, a hierarchical risk-breakdown structure representation is used to develop a formal model for qualitative risk assessment. A common language for describing risks so as to achieve consistent quantification, including terms for quantifying likelihoods and impacts is presented. The relationships between risk factors, risks, and their consequences are represented on cause and effect diagrams. These diagrams and the concepts of fuzzy association and fuzzy composition are applied to identify relationships between risks sources and the consequences on project performance measures. A methodology for evaluating the risk exposures considering consequences in terms of time, cost, quality, and safety performance measures of a project based on fuzzy estimates of the risk components is presented. Keywords: causality, construction projects, common language, fuzzy logic, project performance, qualitative risk assessment

1 Introduction In this paper, we classify risks using a hierarchical risk-breakdown structure. It allows risks to be separated into those that are related to the management of internal resources and those that are prevalent in the external environment. External risks constitute those due to inflation, currency exchange rate fluctuations, and major accidents or disasters. External risks are relatively non-controllable and there is a need for the continual scanning and forecasting of these risks and a company strategy for managing the effects of external forces. Internal factors are relatively more controllable and vary between projects. Internal risk factors include the level of resource available, experience in the type of work, the location, and the conditions of contract. Some of these risk factors are local to individual work packages within a Managing Risks in Projects, edited by K. KakSnen and K.A. Artto. Published in 1997 by E & FN Spon, 2-45 Boundary Row, London SEl 8HN, UK. ISBN: 0 419 22990 6.

266

Tah

project, whilst the others are global to an individual project and cannot be associated with any particular work package. This hierarchical representation is used to develop a formal model for qualitative risk assessment. The assessment of the level of risk is a complex subject shrouded in uncertainty and vagueness. The vague terms are unavoidable, since project managers find it easier to assess risks in qualitative linguistic terms. In this paper, we present a common language for describing risks so as to achieve consistent quantification, including terms for quantifying likelihoods and impacts. We introduce fuzzy set theory and show how it may be used to represent the heuristic knowledge of project managers. The relationships between risk factors, risks, and their consequences are represented on cause and effect diagrams. These diagrams and the concepts of fuzzy association and fuzzy composition are applied to identify relationships between risks sources and the consequences on project performance measures. A methodology for evaluating the risk exposures considering consequences in terms of time, cost, quality, and safety performance measures of the entire project based on fuzzy estimates of the risk components is presented.

2 Classification of Risks Risk classification is an important step in the risk assessment process, as it attempts to structure the diverse risks that may affect a project. Many approaches have been suggested in the literature for classifying risks. Perry and Hayes [I] give an extensive list of factors assembled from several sources, and classified in terms of risks retainable by contractors, consultants, and clients. Cooper and Chapman [2] classify risks according to their nature and magnitude, grouping risks into the two major groupings of primary and secondary risks. Tah et. al. [3] use a risk-breakdown structure to classify risks according to their origin and to the location of their impact in the project. Wirba et. al. [4] adopt a synergistic combination of the approach of Tah et. al. and that of Copper and Chapman, where the former is used to exhaustively classify all risks and the later is used to segregate risks into primary and secondary risks.

In this paper, we classify risks using the hierarchical risk-breakdown structure of Tah et. al. [3] with minor modifications to the structure with a highly enriched content. A major addition is the inclusion of a dynamic causal network that facilitates the identification and representation of risks into primary and secondary risks. The causal network is necessarily dynamic as the inter-dependencies between risk factors are non-deterministic, depending on the particular scenarios experienced through a project's life. Thus, the risk factors at the leaf nodes of the risk-breakdown structure hierarchy, form a temporal causal network of primary and secondary risks.

Qualitative risk assessment framework

267

OVERALL PROJECT RlSK

t Internal Rlsk

Exlernal Rlsl(

$ = = A Chasges

1 , -

4

b

LOCAL RlSK (Work Package)

GLOBAL RISK

T Labour

Matsrrals

Plant

client

Design

-SubContractor

Sile

Management

Const~c(ion

--Envlronrnental

Contraelual

Locallon

flnanoral

b

Fig. 1. Hierarchical risk-breakdown structure. The hierarchical risk-breakdown structure, depicted in Fig. 1, allows risks to be separated into those that are related to the management of internal resources and those that are prevalent in the external environment. External risks constitute those due to inflation, currency exchange rate fluctuations, and major accidents or disasters. External risks are relatively non-controllable and there is a need for the continual scanning and forecasting of these risks and a company strategy for managing the effects of external forces. Internal factors are relatively more controllable and vary between projects. Internal risk factors include the level of resource available, experience in the type of work, the location, and the conditions of contract. Some of these risk factors are local to individual work packages or categories within a project, whilst the others are global to an individual project and cannot be associated with any particular work package. No two work packages have the same level of risk and should be treated separately. A risk-breakdown structure or categorisation should, therefore, reflect these differences. In the hierarchical risk-breakdown structure (HRBS) shown in Fig. 1, the overall risk is broken down into internal and external risks. The internal risks are further broken down into local and global risks. The local risks cover uncertainties due to labour, plant, material, and sub-contractor resources. These are considered for each work package or section of work. Global risks by their very nature cannot be allocated to individual work packages and are assessed on the

268 Tah project as a whole. This hierarchical representation will be used to develop a formal model for risk assessment. Risks are classified in a hierarchical risk breakdown structure as shown in Fig. 1. the details of the classification are shown in Tablel. The important facets of the classification are "Risk centres", "Risks", and Risk factors. Risk centres are used for aggregating risks so as to focus the attention of the project managers into the areas of the project most at risks. Examples of risk centres are labour, plant, materials, subcontractors, site, construction, management, design, and client. Risks are grouped into risk centres and a risk must belong only to one risk centre. A risk factor can cause many risks and can have one or more sub-factors. Risk factors and sub-factors form a causal network which can be represented in the form of a cause an effect diagram as in Fig. 2 and further discussed in the ensuing section.

3. A Common Language for Describing Construction Project Risks A common language of describing risks is necessary so as to facilitate consistent assessment and quantification of impacts. The hierarchical risk breakdown structure provides the basis for stratified classification of risks and developing a nomenclature for describing project risks. An elaborate common language for describing risks has been developed and a small fragment is presented in Table 1.

Qualitative risk assessmentj?amework

269

4 Characterisationof Risks and Risk Factors Risk factors do not affect project activities directly but through risks. The distinction made here between risks and risk factors allows us to make the assumption that risks are triggered by risk factors. The characteristics of risks and risk factors are important for assessment and analysis purposes. The diagram in Fig. 2 is used to clarify the differences in attributes and the implications for assessment and analysis. The classification above allows us to view the existence of a risks as dependent on the presence of one or more risk factors. The risk due to labour productivity is influenced by factors such as weather, worker moral, trade interference, complexity of work, etc.. The risk assessment process requires the assessment of the probability or likelihood of the risk and the impact. In thinking about the likelihood of a risk, it is easier to think about the likelihood of the presence of the individual influencing factors. This is because the risk factors are more concrete abstractions of the risk and define situations that can be individually assessed with a limited amount of vague information or facts. The key attributes of risk factors are likelihood and severity. The key attribute of risks is severity. Risks are also categorised by the risk centre to which they belong.

Change in duration: Change in cost: Change in quality:

Risk Centre: Labour

Wealher ID: 1

ID: 2

Risk Centre: Slte

Weather ID: 5

ID: 3 Severlly:

Severity:

Fig. 2. Idealisation of some cause and effect relations The diagram in Fig. 2 clearly shows the interdependencies between risk factors, risks , and the effect as changes in the performance measures of the project in terms of cost, time, quality, and duration.

272 Tah This represents the effect of risk factor j on risk i. The total effect of all the risk factors on the risk i is obtained by taking the union of the effects of individual factors, thus

An estimate of the severity of the risk due to the combination of all risk factors can be obtained by selecting the maximum values [5] from the columns of the resulting matrix M i .Let this severity value be denoted by F,' . This induces changes in the work package's performance measures. Next we consider the changes induced in the work package. Let the changes induced by a risk i in the performance measures of a work package be represented by the fuzzy sub-sets q , Ci, Qi, and Si representing time, cost, quality, and safety respectively. Let there exist corresponding apriori relations R; , R,' , R: , and R: which map the severity Fi of a risk i onto the corresponding fuzzy sub-sets I:, Ci, Q,, and Si using fuzzy composition resulting in the following equations:

This relationships are Fuzzy Associative Memories (FAM) that can be obtained from project management experts and can be represented as FAM rules. This relationships when composed with the severity F' of a risk i yield the corresponding fuzzy sub-sets T ' , C: , Q,', and S,' of the actual changes induced in the work package computed from the following equations:

The total effect of all the risks on the work package is obtained by taking the union of the effects of the individual performance measures, thus

Qualitative risk assessmentJi-amework 273 These represent subjective estimates of the changes induced in each performance measure of a work package. The actual linguistic variables describing the changes or crisp values representing the actual change can be obtained by defuzzification [ 5 ] . The ensuing example is used to illustrate the computational process.

6.2 Example The example depicted in Fig. 3 involving selected risk factors and risks influencing an earthworks work package will be used to illustrate the computational process. The fuzzy associative memory (FAM) that represent the causalities between risks and the earthworks work package has been elicited from experienced project managers as shown in Table 4. Note that the ensuing computations have been performed using a computer program developed by the author. Table 4. Subjectively determined Fuzzy Associative Memory for risk consequences and the effects of the performance measures for the earthworks work package. No 1

Description Labour productivity

2

Ground conditions

Consequence Low Medium High Low Medium High

Change in Duration Very Low Low Medium Low Medium High

Change in Cost Very Low Low Medium Low Medium High

Change in Quality Very Low Very Low Very Low Low Low Medium

Change in Safety Very Low Very Low Very Low Low Medium High

Step 1 The first step involves the subjective assessment of the likelihood of occurrence and severity of the individual risk factors as indicated in the leaf nodes in Fig. 3 .

WPID: 1 Task: Earthworks Change in duration: High Change in cost: High Change in quality: Medium

ID: 2

R I E Centre: ~ Site

Risk Centre: Labour

Weather ID: 2

Weather ID: 3

ID: 4 Severity: High

Fig. 3 . Step 1 - Risk factors subjectively assessed.

276 Radujkovic Such trends cause a decrease in investment, and weaken all parties in business. Due to this then, there is a slow down in the growth rate in developing countries and in countries in transition.

2 Transition period

Transition is a process occurring in close to 20 ex-socialist mainly European countries. It involves the global change of their political and economic attributes of existence. The great amount of change that has been occurring in Croatia (and some other countries) is additionally fbeled and complicated by war. In such situations every business system is exposed to concurrent and interactive effects from political changes and economic changes, among which the most influential might be : 1. 2. 3. 4. 5.

Wartime conditions. Change in ownership - privatization. Recession. Reduction of investment. Lack of capital on the market. 6 . Termination of government monetary support in case of loses. The mentioned changes show that the whole industry, including construction, is going through a difficult period. The primary goal for every business system in such a situation is to fight for survival. This is additionally complicated by increased competition on the open market.

+GDP previous year +GDP year 1990=100'%

I ......:..... Construction previous year --k-. Construction 1990=100%

-JltTotal investment 1990=100%

1990

1991

1992

1993

1994

Years of tramition

Fig 1.

Some statistical data for period of transition 1991-1995.

Figures 1 and 2 compare some of the main data which is shown for the transition period in Croatia [6]. The transition changes started in 1991 but the war began the same year. The fact is that construction was fast and strongly influenced by changes. In 1996 and

Risk sources and drivers

277

1997 there are some improvements, because of the war rebuilding process in Croatia. According to the Ministry of reconstruction and development there was intervention on close to 60.000 units for accommodation during the last period [7]. Close to 15.000 houses were rebuilt as a new structure by the government program of post-war reconstruction. The program is still on because of 150.000 damaged houses and other facilities during the war. The reconstruction program supports a stabilization of the construction industry on a level which may be suitable for the future. At the moment it is most important to start some of the capital hture planned investment (railway reconstruction, highway construction,..). It will change and stabilize the relation between the number of business entities and the number of individuals employed in construction. Business entities

1990

1991

1992

1-3

1994

1335

1996

lW7

Year

Fig 2.

Average numbers of people employed and business entities construction

3 Risk in construction projects in countries in transition

Many authors who have been studying risk believe that qualitative analysis is most essential[l]. According to them information about risk source is the first important step. For research into risk sources in construction projects in Croatia [8,9,10], a basic breakdown approach was established in 1994 (shown in Table 1). Croatia is a very good example of a central European country in transition. (Some differences, however, do exist between Croatia and other countries in transition. ) The latest business reports made by several international economic institutions forecast a very dynamic growth in Croatia.

278

Radujkovic

Table 1 . Breakdown of risk sources EXTERNAL SOURCES OF RISK IN PROJECTS 2. POLITICAL 3 .ECONOMIC 4.SOCIAL Local Change Economic Education, - in regulations politics politics culture Permits, Elections Prices, taxes Seasonal work approvals War Financing Strikes Changes in law Treaties conditions Fluctuation in standards Currency value population INTERNAL SOURCES OF RISK IN PROJECTS 6. 7.TECHNICAL 8.PEOPLE 9.SUPPLY MANAGEMEN DOCUMENTS FACTOR AND T LOGISTICS Unrealistic goals Superficiality Productivity Shortages Poor control Inaccuracy Illness Availability Technology Incompleteness Motivation Reliability of Organization Updated Errors equip. documents Insufficient workers 1. LEGAL

5.NATURAL Climate Foundation Fires Earthquakes Floods

10. CONTRACTS

Type of contract Short time frames Unrealistic prices Party relations

The results of previous research which was conducted in 1994195 shows that a significant portion of projects had an internal source of risk (Figure 3) [8]. Unrealistic plan

Fig 3.

Previous research results - rank of factors in risk sources (excluding war) [8]

The most serious consequences we focused on were start-up cost and time overruns. These events are among the worst outcomes which contribute in project failure processes. The mentioned appearances are consequences of risks occurring, so analysis

Risk sources and drivers

279

of a source of risk is very significant for project management. Figure 4 shows the results of a review of close to a hundred construction projects finished in 1996.

0

20

40

h0

8b

100

I 20

Constructionprojects lidshed in 19%.

Fig 4. Time and contract price overruns It has been shown that time and contract price overruns are very frequent, as in some international reports[ll]. Indeed there are just a few construction projects finished on time, according to start up plans. The amount of contract price overmn is significantly less than time overmn. The reason for this may be client orientation to fixed price contracts.

4 Results of the risk source research

The research of risks in construction projects in Croatia is an ongoing action[l2]. The results up to today show that there is a strong influence of internal sources of risk. The value of 58% (Figure 5) indicates an increased responsibility of management. It is obvious that very often projects are started without completed preparation processes and adequate support. The transition period is a time when every business system is in a hurry, trying to get a better position on the market. But sometimes there are more good ideas than are necessary for minimal conditions to be achieved for proper project realization.

280 Radujkovic

Internal sources 58%

Risk sources divided into external and internal - 1996.

Fig 5.

The detailed structure on risk sources shows that in a construction project time and contract price overruns are very much generally influenced by several almost uniformly formed risk source groups. These are namely design, supply and logistics, natural legal - economical conditions, and contract and management (Figure 6).

Cmvad

I I%

Supply and logistics

Lead IZ?.

Political

12% Ecmonric

.I" I

Social

Human Fador 11%

3%

T d c d document. Design

1 40'0

Fig 6.

Risks source breakdown - 1996, 100 construction projects.

Risk sources and drivers

281

Risks source

Fig 7.

Main risk sources with the share and percentage of appearance in total structure - 1996, 100 construction projects.

However, the detailed analysis shows that in 1996 there were five dominant sources. Each of them brought more than 5% share in the total sources identified. Together they carried a 40% share in total sources (Figure 7). Comparing the starting rank (Figure 3) and the one above, it can be concluded that the "climate" influence is rather new and dominant. The "unrealistic plan" and "finance" are still present at high levels. Looking at the data for time overruns (Figure 4) it is clear that short project durations are forced through unrealistic (or too optimistic) plans. "Permit and approvals", as well as "superficiality of design" (technical documentation), are shown as detailed items. The rather new one is "insufficient workers".

5 The project participant attitude regarding risk

Our research has shown that project participant attitudes regarding risk analysis have been changed a little. There is no longer a strong tendency to carry on the analysis by aid of modern techniques. On the contrary in countries in transition, risk in construction projects is often ignored, or is dealt with by simply adding 5% to the total price of the estimates. Some "progress" has been made in relation to transferred risks. Generally it means an approach of putting as many risks on the business partner as possible. The contracting process is oriented in that way. The clients create the policy of risk transferring to contractors by taking advantage of market situations where projects are in a shortage. But transferring risk to other parties is only a partial solution which does not reduce the criticality of risk source. Contractors are under pressure to win tendering processes, and during the contracting process they usually accept unrealistic goals. But in many situations the participant relationships are under pressure from many claims very soon.

282

Radujkovic

The process of claiming damages in court is very long, so the claimant (client) is often better off solving the problem through settlement. The contractors of course know this, so a circle in which no party is satisfied is created. The only solution should be participant joint strategy on risk reduction and after that risk transferring. Our research has shown a very strong correlation between project participant disagreement and risk drivers. There is a general tendency for participants to declare various random events or perhaps some external unknown factors as a risk drivers. However, the structure in Figure 5, shows internal sources of risk make up 58% of total risk in projects. This fact indicates that many drivers are connected to project participants and executives.

6

Conclusion

Risk management is perhaps the most important part of project management[l2]. In construction projects which last long, changes are unavoidable, data is stochastic, and risk is part of the norm. This manner of doing business creates the possibility for numerous deviations fiom project goals. The most frequent consequences of risk occurrence are overruns in start-up cost and time. The construction industry in countries in transition suffers very much from such events[9]. There is much responsibility on the company heads and project managers in dealing with risk and its consequences. From that point, the people that are responsible have to accept methods of managing risk in projects, because those methods guarantee significant advancements in the construction business in countries in transition.

References 1. Raftery J. (1994) Risk Analysis in Project Management, E.F.N. Spoon, London. 2. Thompson P.A., Peny J.G. (1992) Engineering Construction Risks, Thomas Telford, London . 3 . Chapman C.B. (1991) Risk in Investment, Procurement and Performance in Construction, E.F.N. Spoon, London, pp. 259-275. 4. Wideman M. (1986) Risk Management, Project Management Journal, Sept,pp20-26. 5. Perry J.G., Hayes R.W. (1985) Risk and its Management in Construction Projects, Proc. Instn.Civ.Eng., Part 1, 78, pp. 499-521. 6. Katavic M., Djukan P. (1995) Razvitakgraditeljstva i znanstvena istrazivanja u Hwatskoj, Gradjevinar 47 (12) , pp. 761-765 7. Radic J. (1997) Obnova je hrvatski 'new deal', Privredni vjesnik, 4/97 8. Radujkovic M. (1996) Managing Risk in Construction Projects in Countries in Transition, Economic Management of Innovation, Productivity and Quality in Construction, CIB Publication No. 200,7"' International Symposium CIB W55, Zagreb. 9. Radujkovic M. (1996) Risk Management: Maintaing Programmed Construction Time In Economies In Transition, 8th International Symposium The Organization &

Risk sources and drivers

283

Management of Construction : Shaping Theory and Practice, CIB W65, Glasgow, pp. 811 - 819. 10.Radujkovic M. (1994) Project Duration and Risk Programming, Proceedings of INTERNET 94, Dynamic Leadership through Project Management, 1 2 World ~ Congress on Project Management, Oslo, Volume 2, pp. 204-209. 11.World Bank; (1990) Annual Review of Project Performance Results, Operations Evaluation Department, World Bank . 12.BarnesM., Wearne S. (1993) The Future of Major Project Management, International Journal of Project Management, vol. 11, No. 3, pg. 13 5 - 142

The risk of safety regulation changes in transport development projects T . M . WILLIAMS Department of Management Science, Strathclyde University, Glasgow, UK

Abstract Changes to safety regulations forms a major risk to large projects. The effects are systemic, so difficult to quantify and usually under-estimated. As well as general lessons about the risk, this paper describes two transport manufacturing projects that were evaluated post mortem as part of claims procedures, to demonstrate the type of effects caused, and the issues involved in quantification. Traditional tools were inadequate to quantify the effects. The use of System Dynamics is described to demonstrate the project dynamics, to model the inter-relationships between factors and to quantify their combined effect. This technique can be used for many areas of project modelling. Keywords: change control, project risk, safety regulations, system dynamics

1 Introduction The safety regime forms an essential part of the specification of a product to be developed. Changes to this regime during the period of development necessitates a change to the specification and subsequent re-design and re-work. Furthermore, since the changes cause systemic effects, these effects are very difficult to quantify, and are usually grossly under-estimated. This paper will describe two medium-sized manufacturing projects of transport vehicles which have been evaluated post mortem as part of Delay and Disruption claims procedures, to demonstrate the type of effects caused, and the issues involved in quantification. The aims of this paper are thus to: point out the risk of changes to safety-regulations and the need to recognise this risk illustrate how project dynamics operate, specifically in this case showing why the Managing Risks in Projects, edited by K. K%hkirnen and K.A. Artto. Published in 1997 by E & FN Spon, 2 4 Boundary Row, London SEI SHN, UK. ISBN: 0 419 22990 6.

Safety regulation changes 285 effects are larger than intuition would suggest demonstrate a technique for quantification of such systemic effects, which can and has been used for many areas of project modelling, but specifically can be used for modelling this risk, and is useful for prediction, in-project estimation and claims. The two case-studies have been chosen to illustrate different aspects. Case Study 1 was subject to a one-off change to international safety rules, and a simple model was built to demonstrate the overall effects; Case Study 2 was subject to safety rules changing continuously over a time, and a more detailed model was built as part of a formal claims procedure. (In fact, the Case Study 2 was carried out earlier than Case Study 1, and some details have been published previously in the Project Management literature [l]).

2 Changes to safety regulations Change-control has always been an integral part of Project Management, forming a major sub-section to Project Integration Management in the PMI Project Management Book Of Knowledge [2]. This area has increased in importance in recent years as two compounding trends in projects have been seen [3]: Products being developed are becoming more complex (e.g. because of extra functionality, or reduction in physical size, or closer intra-connectivity). Some commentators therefore consider that the projects developing those products are increasing in complexity. Projects have tended to become more time-constrained [4]. There is also an increasing emphasis on tight contracts, often with liquidated damages for lateness. As projects become shorter in duration, this enforces parallelism and concurrency, which by definition increases project complexity further. (The increasing desire to reduce "time to market" times has been partly responsible for the development of Concurrent Engineering, supporting the integrated, concurrent design of products and their related processes [5]). The effects of changes to safety regulations cause particular problems, which will be highlighted by the case-studies described in this paper. These effects combine into feedback-loops and thus all compound and exacerbate each other, and are described in more detail in Williams et al [l]; many These can be swnmarised as follows. Typically, texts on change control [6] distinguish external from internal sources of change, external including such sources as political, legal, economic, social, technological etc.; the point being, of course, that these are not under the control of the project management, and often actions cannot be taken to affect either the timing or requirements of such change-sources (hence the suggestions for an "environmental screening" role within projects). The changes are systemic (within the product), so often a number of project elements must be re-designed simultaneously. As each element is re-worked mid-design, in a

286 Williams design process where design of cross-related parts of the product is occumng in parallel, each activity has to take cognisance of the others, and cross-impacts between elements mean there are secondary re-designs. Most such changes increase complexity, producing increasing cross-relations between parallel activities developing cross-related parts of the product; this implies increasing difficulty in providing a system freeze, since changes in one component will increasingly cross-impact other components, creating a ripple effect across the system. The effect most often not predicted is the lower efficiency of the design-andmanufacture process, due to having to deal with the changes while keeping within either the same, or inadequately adjusted, time-scale. This lower efficiency is due to a number of inter-related effects, for example: - more workers have to be taken on than originally planned, andlor extra shiftpatterns and more overtime have to be worked in order to keep to the schedule; this exacerbates the feedback loops to cause increasing inefficiency (referred to as the "$2,000 hour" by Cooper [7]). - the lack of system freeze, combined with a tight time-constraint, forces management to work on project-elements for which the surrounding system is not yet frozen, and the design of such items will have to be re-worked if there are changes in the as-yet-unfrozen surrounding system; - such work has secondary effects, such as disincentivising the design staff as they work with unclear parameters and knowing that their work may turn out to be nugatory; - when a concurrent Manufacturing phase is considered, there are additional effects, both because design activities finish later and thus increase concurrency, but also because items begin manufacture and are then changed, which leads to retrofit, degradation of manufacture learning [S], but also because the products are no longer Designed For Manufacture (DFM) (or DFA, Designed For Assembly), a key element of Concurrent Engineering [5]. The two case-studies in this paper give examples of such projects in the transport field, which is an obvious area in which products are the object of national and international safety regulations, those regulations are subject to unexpected change (particularly resulting from transport disasters, which affected both of the case-studies below), and are rigorously enforced. Another such area is of course the nuclear field, which is subject to similar regulatory bodies. In the UK, Morris and Hough [9] describe the UK Advanced Gas-Cooled Reactor (AGR) programme up to 1986. In particular, they describe Hinckley Point B station, estimated in 1966 at £96M, which over-spent by E48M (E14M of which was due to inflation): £19M (40%) of the over-spend was ascribed to "modification and development needed to bring the basic plant design to revised standards". However, writing in 1987, they also state that the philosophy of safety-cases adopted by the Nuclear Instillation Inspectorate had led to less "regulatoly ratchetting than in the United States (where the Nuclear Regulatory Commission wrote and promulgated regulations. Canaday [lo] analyses 35 US nuclear power-plan projects, which resulted in up to 400% cost overruns, highlighting increased safety requirements as one of the causes.

Safity regulation changes 287 3 Method: Systems Dynamics

The effects that need to be modelled are systemic. Early project-management methods were based on decomposing the project into its constituent parts in a structured way, in particular PERT, WBS, and CISCSC.; similarly, project risk analysis has been based on decomposing overall effects into individual items on a Project Risk Register [I I]. Legal claims have operated by decomposing projects into individual cost elements or, particularly, individual time elements [12]. However, it is clear that the systemic effects discussed above are not taken account of by such decomposition methods [2]. The modelling method used in the case studies below is System Dynamics (SD). Wolstenholme [13] gives a good overview of the current state of the art; it can be distinguished from discrete-event simulation in that it is concerned with the state of the system and rates of change, it uses pseudo-continuous modelling, and the detail of discrete-events are not included. The modelling approach focuses upon an understanding of feedback and feedforward relationships, and the model construction requires the analyst to construct the relationships between the various state variables and rate variables. A key advantage is that if techniques such as cognitive maps and influence diagrams are used to construct these relationships, then SD is a natural technique to quantify these relationships (as in Case Study 2 below). SD has a track-record since 1964 of use in explaining and modelling the systemic effects in complex projects. It has been used particularly notably by Pugh-Roberts Associates (part of PA Consulting), and a number of successful applications have also been reported at NASA (see a discussion in Rodrigues and Bowers[l4]). Because of its explanatory power, it has had particular application in the post-mortem analysis of projects in litigations such as Delay and Disruption @&D). The first major success was the Ingalls Shipbuilding case against the US Navy in the late 1970's, in which an SD model was used to quantify the cost of disruption stemming from Navy-responsible delays and design changes; the total settlement was finally $447 million, and Cooper [15] claims that the model was the basis for at least $200-300 million of this. Since this major legal precedent, the method has been used on a number of such litigations. The models below were built using the Stella package [16]. There are three types of SD variable. The rectangular tanks represent "stocks" of material, and flows between them are represented by the "rates" (the valve-shaped symbol). All other calculations are undertaken by "auxiliary variables", represented by circles. In a full model, all relationships between the variables have to be shown by lines: it is this explicit representation of the intra-model relationships that makes such models so transparent.

The first case-study was the life extension of an old naval support ship, involving the insertion of an additional mid-section and a complete re-fit. A design office was subcontracted for design services, and the work on the General Arrangement (GA) and composite drawings of services was scheduled to take place over 9 months in 199415. The contract specification required compliance with the regulatory and statutory regulations in force at the date of signature. However, in October 1994 the SOLAS

288 Williams (Safety Of Life At Sea) 92 safety regulations were ratified [17], and shortly afterwards the UK Ministry of Defence (MOD) decided that this ship would be subject to those regulations. SOLAS are international regulations which have to be ratified by national bodies; one important effect was that during the course of the project the UK MSA (Marine Safety Agency) had to consider and interpret the regulations; indeed, at the end of the author's involvement the relevant UK Statutory Instruments had still not been issued; meanwhile, although not relevant to this case-study, the SOLAS Convention is again being amended in response to the Estonia tragedy in which over 900 died [IS] The effect of the changes caused by the SOLAS 92 regulations were many and various. Of particular relevance were two important effects: the air-conditioning (HVAC) system had to be re-designed and enhanced, and subsequent changes caused the HVAC line to be re-routed and related services adjusted round about (HVAC design was subcontracted, as was the design of certain other dependent systems); the deckhead spaces (thus the space available within the ceilings) had to be reduced. These two effects, however are not unrelated: upgrading of the HVAC would have caused deckhead space to be very tight and the routing of services very complex anyway; reducing deckhead spaces exacerbated these problems, and indeed in a few cases made production of the composite drawing infeasible without lowering the ceiling below specification-height. The contractors prepared a claim for the extra work caused directly by the introduction of SOLAS 92, called the "Direct Claim", which covered the above two effects. However, the extra work caused a number of additional effects, exactly those described above in the section on "Changes to safety regulations": all of the GAi'composite work was inter-related: when items had to be re-designed other items had to be re-designed as a consequence, which themselves had the effect of further changing other parts of the system, including within the GAIcomposite work, into the wider project within the design contractor, and to sub-contractors (e.g. on the HVAC); and all of these changes caused secondary effects back on the GAIcomposite work; the design process was less efficient because much more work had to be done while still trying to keep within the schedule in order to avoid delay to the overall ship lifeextension project (e.g. there were more workers, and three-shift working was introduced) the re-design was much more complex than the original design because there was less space to fit in more services, causing extra management attention, and making follow-on work more complex. These effects are interdependent, each exacerbating the others. Thus, the extra timepressure caused less efficient working, which caused more delay, which added to the time-pressure; design feed-backs and cross-impacts produced more re-design work which caused more delays and exacerbated this feed-back loop; and so on. Furthermore, the changes were not immediately well-defined, but time had to be taken by both the

Safety regulation changes 289 project and MSA to consider the full definition of the changes. This also caused delays to the re-design, exacerbating the time pressure and the need for secondary and tertiary re-design etc. Again, these compound each other. The SD model built was fairly small, consisting of just 18 stocks, 18 rates and 29 other variables (a fair number of which were simply book-keeping variables to count up various values), but it was sufficient to demonstrate the effects that were present. The key flow was of work around the basic cycle as follows:

Redesign work

I

3 work Freezing

Designing

Here, work that can be begun (i.e. the surrounding system is sufficiently frozen) is designed as fast as the available manpower and its productivity will allow, and those designs are approved. In the perfect case, that is all that happens (this would represent the project as originally conceived and budgetted for), but in case of changes, work can be extracted from the state of being "Designed and OK'd" and moved back to be reworked. There are two mechanisms controlling this flow. The first is the flow of changes caused by SOLAS, represented by another set of stocks and flows:

Base SOLAS changes

-

ReleaseSOLAS

Changes

ChangesOK

ChangesNotified

I (jq Consideration

l ChangesToBeMade

ChangesDone

ov

RegisteringChanges

StillToBeDone

The SOLAS changes are released at a certain time, then some are delayed while MSA and the design office considered all the implications, then gradually all the changes flow until they are done. This flow of work represented the "Direct Claim". Changes here cause re-design work in the main flow. The second is the management of manpower. A set of auxiliary variables controlled the addition and removal of manpower onto the project, and the transfer onto and off 3 shifts. This was controlled by simple logical rules dependent on the progress of the work compared to the original plan. The other main flows of work showed both base SOLAS changes, and also

290 Williams subsequent changes, impacting upon the wider project and upon sub-contractors. These were needed as, while these changes are being worked upon, they each cause secondary changes back onto the GAIcomposite work. The model was very simple and did not take a number of factors into account, for example, work done out of the proper sequence (as discussed in Case Study 2). However, it did include the two main D&D effects, namely (a) re-designs due to secondary effects and (b) decreased effectiveness in trying to keep to the schedule. The output metric measured was the profile of man-power used over time. Three main runs of the model were carried out: i. The first had no SOLAS changes, so representing the project as initially expected The timescale and man-hours expended was as budgetted, and the work-force followed the budgetted profile. ii. The second introduced SOLAS changes but without D&D effects (a) and (b). The maximum work-force is still on budget, and again only one shift is used; however the time-scale and man-hours were increased by 140% and 220% respectively. iii. The third also included both D&D effects. Here, the workforce rose rapidly, then a three-shift operation had to be started, and operated over a period similar to that in which three shifts were actually used; the time-scale and man-hours were 50% and 340% over budget respectively. Since D&D combines two effects here, it is instructive to look at them individually: If the model included SOLAS changes and D&D factor (b) (decreased effectiveness in trying to keep to the schedule), but with no re-designs due to secondary effects, there was less work than in (iii) above, the project was only 25% late and 275% over the man-hour budget. If the model included SOLAS changes and D&D factor (a) (re-designs due to secondary effects), but with no schedule pressure, here the project was again allowed to continue 140% over the time-budget, with man-hours 240% over budget. The model thus showed a number of indicative results: The model could be used to show the extent of D&D resulting from a Direct SOLAS claim The model could be used to show the additional time that would have been taken on the work had the design office not taken action to reduce the duration and avoid delaying the overall project. The model showed the effects of the various components of D&D; it could also be seen that these individual effects add to well below the total D&D indicated, as is the nature of such systemic effects, so that the D&D has to be evaluated as a whole. Finally, the model's use for additional analyses could be seen; in particular to look at: - the additional management effort caused by the SOLAS changes - the knock-on effects on the wider project; - the effect on other projects in the design office.

Safety regulation changes 291 5 Case study 2

The second case study is similarly of the design and manufacture of a transport vehicle: the Channel Tunnel Shuttle wagons. Eurotunnel had contracted TML to build the Channel Tunnel, and TML had subcontracted a consortium of rolling-stock manufacturers to build the Shuttle Wagons. A number of aspects of the design, construction and operation of the Channel Tunnel required approval from the Intergovernmental Commission (IGC), a body of British and French civil servants; during the development phase of the project, their major focus was on safety, defence, security and environmental issues [19]. It became clear part-way through the project that design changes required by the IGC were not only causing delays, but that work was having to proceed prior to gaining IGC approval, with the subsequent changes and rework when IGC decisions turned out not to be favourable. It is instructive to read a newspaper report of 1991 (the concession had been granted in 1986, UK Parliamentary Approval gained in 1987): "[Eurotunnel] said delays were expected because of changes in the design of fire doors separating rail shuttle wagons to meet strict safety guidelines. The [IGC] has insisted that fire doors between wagons carrying passenger vehicles be widened by at urotunnel] warned yesterday that changes in the least lOcm to allow easier access ....p design of fire doors were likely to lead to a delay of up to 6 months ... Eurotunnel was discussing the possibility of introducing bonus payments to encourage the Shuttle wagon manufacturers to make up any lost time caused by the design change... The [IGC] also warned that the design of semi-open-sided wagons to carry heavy goods vehicles ,would be unacceptable in its present form .... discussions were continuing with the Commission .... The need to complete the project as quickly as possible to start earning revenue to repay bank borrowings meant that design had to be completed and contracts placed before the [IGC] completed its deliberations." [20] The design and manufacture of the Shuttle Wagons was for this reason (and also, the manufacturers claimed, because of delays in approval design documentation) considerably over-spent. The author was part of a team brought in to determine the reasons the D&D caused to the project, and to quantify it with an auditable model, as has already been reported in the Project Management literature [I]. The key technique used to interview managers and subsequently model the explanations given for the various circumstances of the project was "cognitive mapping" [21] using specialist computer software called "Graphics C O P E [22]. This model was developed and validated working in a visual interactive mode with groups of senior members of the project team. The analysis and clustering methods within the software were then used to locate all the positive feedback loops (90 inter-related loops in this case) which formed the basis of understanding the D&D. The elements of the loops were those discussed above ("Changes to safety regulations"), with the added element of client-approval delays. Again, design of crossrelated parts was occurring in parallel; there were tight timescale-constraints, so that after a delay, the project had to become more parallel as delayed activities overlap more with succeeding non-delayed activities. This loop was accelerated by other feedback loops. For example, parallel design of cross-related items increased difficulty in providing a system freeze; this forced work on items for which the surrounding system

292 Williams was not yet frozen, and so on as above, in particular increasing re-work and thus exacerbating delay. Particularly as the supply of trained design manpower began to be exhausted in the geographic region, the "$2,000 hour" effect started to manifest itself. Further loops of course were set up when the concurrent Manufacturing phase was considered, both because design activities finished later and thus increased concurrency (and so on), but also because items began manufacture and were then changed, which led to retrofit, degradation of manufacture learning, increased load on production engineers etc. A key difference between Case Studies 1 and 2 was that in this case the safety regime was ill-defined at the start of the project and only gradually became clarified. This was not only because the environment of the Channel Tunnel was unknown to the safety regulators, but also because the implications of events such as the UK Kings Cross Fire in November 1987 fed into the consideration. This meant firstly that some design parameters were uncertain during the design phase, secondly that safety-driven changes came continuously as a slow trickle rather than as a one-off declaration in Case Study 1, and thirdly that some design approval took longer as safety aspects were considered. The SD modelling is described in the references [1,23], but followed the general pattern of Case Study 1 - with the main difference being that the model was fully calibrated to replicate the project as originally anticipated, the project as completed and also under the various different profiles of client behaviour and liability. This meant that the model was much more sizeable. The model consisted of two inter-related parts, one dealing with Design and the second with Manufacture; in the Design part, 29 stocks, 43 rates and 120 other variables were used. Williams et a1 [23] also give indicative results (although not the actual results, which were confidential): Table 1 of this reference shows how the three main variables compound together: (i) the time take to obtain client approval/comments on design documents, (ii) the proportion of documents commented upon by the client (but without requiring extra-contractual modifications to the product), and (iii) the proportion of project elements on which extra-contractual work was required. Thus, effects on each of these which, in isolation, would have little effect on the project out-turn, have a large impact when combined together. In that Table, when the design changes add 92% to the work-load; extra comments are made which would (on their own) add 11% to the work-load, and approval-delays occur which would (on their own) add only 0.4% to the man-power spent, then the combination of these three effects together adds 225% to the over-all man-power.

6 Conclusions

This paper has, through two case-studies, illustrated the effect that changes to safety regulations can have on a design-and-manufacture project. This risk must be considered at the start of the project, and contractual liability for the risk established. Such changes cause systemic effects which are difficult to quantify, and, because of their systemic nature, are much bigger than intuition would suggest. The System Dynamics method is a proven technique which can and has been used for many areas of project modelling, but specifically can be used for modelling this risk, and is useful for prediction during the

Safety regulation changes

293

risk analysis stage, for estimation to support costing of Variation Orders and for quantification of D&D claims.

References 1. Willia~ns,T.M., Eden, C.L., Ackermann, F.R., and Tait, A. (1995). Vicious circles of parallelism. International Journal of Project Management 13,3, 151-155. 2. Project Management Institute (1996) A Guide to the Project Management Book Of Knowledge", Project Management Institute, Upper Darby, PA, US 3. Williams, T.M. (1995) Holistic methods in project management. Proceedings of INTERNET Symposium, St.Petersburg, Russia, 14-16 September 1995. ISBN 5-871 1501 I-x pages 332-336. 4. Clarke, L. (1994) The essence of change Prentice-Hall, Herts, UK. 5. Syan, C.S. and Menon, U. (eds) (1994) Concurrent Engineering: concepts, implementation andpractice. Chapman and Hall, London 6. Owens, S.D. and Martin, M.D. (1993) Planning for change. In, The A M handbook of project management, P.C.Dinsmore (ed), American Management Association, N.Y., chapter 23. 7. Cooper, K.G. (1994) "The $2,000 hour: how managers influence project performance through the rework cycle". Project Management Journal. 25, March 1994, 1, 11-24 8. Eden, C., Williams, T.M., Tait, A., Ackermann, F. (1994) Dismantling the Learning Curve: the role of learning in understanding disruption. EURO XI11 Conference on O.R., University of Strathclyde, Glasgow 9. Morris, P.W.G. and Hough, G.H. (1987) The Anatomy of Major Projects. John Wiley, Chichester, UK. 10. Canaday, H.T. (1980) quoted in Morris and Hough (ref. 9). 11. Williams, T.M. (1994) Using the risk register to integrate risk management in project definition. International Journal of Project Management .12,1,17-22 12. Scott, S (1993) Dealing with delay claims: a survey. International Journal of Project Management 11,3, 143-154 13. Wolstenholme, E.F. (1990) System enquiry: a system dynamics approach. Wiley. 14. Rodrigues, A. and Bowers, J. (1996) The role of system dynamics in project management. International Journal of Project Management, 14,4,213-220. 15. Cooper, K.G. (1993) "The rework cycle: benchmarks for the project manager" Project Management Journal Vol24 No. 1 16. Stella is a registered trademark of High Performance Systems Inc, Hanover NH, US. 17. Payne, S. (1994) Tightening the grip on passenger ship safety - the evolution of SOLAS. Naval Architect, page E.482 18. Naval Architect (1996) 1995 SOLAS conference amendments. Naval Architect, page 19. 19. Major Projects Association (1992) Beyond 2000: a source book for major projects. Major Projects Association, Oxford, UK. 20. Taylor, A. (1991) Article, Financial Times (London, UK), 9th April 1991, pgs 1,s. 21. Ackermann, F., Eden, C. and Williams, T. (1997) A persuasive approach to Delay and Disruption - using "mixed methods". To appear in Interfaces MarchIApril 1997 22. Graphics COPE is developed and supplied by the Department of Management Science, University of Strathclyde, Glasgow. It runs in the Windows environment. 23. Williams, T.M., Eden, C.L., Ackermann, F.R., and Tait, A. (1995). The effects of design changes and delays on project costs. Joumal of the Operational Research Sociely 46, 7, 809-818

Clients' risks associated with different building procurement methods P. PERNU, J. KIIRAS and T. PELTONEN Helsinki University of Technology, Construction Economics and Management, Espoo, Finland

Abstract Clients can use procurement options both to manage risks and to achieve set project objectives. For that purpose one possible risk treatment method is presented in this paper. The method contains a definition of risk suitable for building procurement, a classification for project objectives, and three categories of risk sources. With the help of this method the client is able to choose appropriate procurement options both to promote positive project outcomes and to hinder negative ones. The basis for this work has been to describe the different procurement options by disjoining the known procurement paths into separate items. Keywords: Building pr'ocurement, risks, client, contractor, design, contract form, supplies, objectives, obstacles, tender. 1 Introduction

The client chooses how to assign tasks, responsibilities and risks in an investment or in a building project. From this point of view the most relevant decision is to choose the procurement paths in the contract. In Finland much effort is made to promote the use of procurement which supports innovation, improves quality, and additionally reduces cost.[l] This paper discusses how procurement influences the responsibilities and the risks amongst the parties in building projects with the focus on the whole procurement procedure. The basis for the treatment of risks is to study the procurement as a combination of separate independent parts (decisions, subsystems) particularly the procurement type, the price mechanism and the way of inviting tenders. The risks are considered to be the possible obstacles to the client's project specific objectives. The primary aim is to Managing Risks in Projects, edited by K. K&kSnen and K.A. Artto. Published in 1997 by E & FN Spon, 2 4 Boundary Row, London SEI SHN, UK. ISBN: 0 419 22990 6.

Building procurement and risks 295

encourage clients to provide more procurement methods and to render these methods more effective. This paper is part of a larger unfinished research project funded by the Technology Development Center (TEKES) and the Confederation of Finnish Construction Industries. The project aims to analyse procurement methods from various points of view and this paper relates the results of that study to the risk aspect. Procurement methods are mainly considered as tools for the clients to utilise the available supply as efficiently as possible. It develops tools for the Finnish clients and helps them to develop their own procurement approaches rather than to offer prepared models or methods. That has been seen as a strategy to promote in-house expertise and, perhaps, also as a source of encouragement for the client. The whole building market could thus benefit from this research work. 1.1 Finnish building procurement approach The Finnish construction market is very much characterised by its small size, in practice meaning that everyone knows each other. This naturally affects the behaviour of the clients relative to other countries. In Finland a single construction contract, between the owner and the main contractor has traditionally been the most widely used procurement method. A consultant prepares completed working drawings for the invitation of tender, and the tenderers have expected to offer a firm fixed price. HVAC- and electrical works are sometimes carried out by separate subcontractors appointed directly by the client. This kind of capacity-oriented main contracting has not encouraged the development in the design documentation nor in the product development. Overlapping design and construction has been impossible, and as a result one instrument to shorten the project duration was not available. To change this situation much research and the promotion of other work have been done to widen the use of alternative procurement options. More problems have, however, arisen due to confhsion regarding deftnitions and liabilities in projects. This paper may assist in part to solve this problem. 2 Procurement methods

Procurement methods are often presented as individual models such as main contractor, design-build, lump sum contract, cost reimbursable contract, separate trades or construction management in the literature. With this point of view less attention is being paid to the fact that there may not be two exact kinds of procurement paths. The vast variation of alternative options stems from the great number of client decisions concerning for example the pricing system, the division of responsibilities, how to obtain the tenders, what kind of and how detailed documents should be used, or the terms for the contract. The subject becomes even more problematic when the interrelationships among these different decisions are analysed. In this paper it is assumed that independent decisions are more significant in describing the situation. In practice, clients tend to be very conservative with their choices and rely on their experience and on their permanent operation mode.

Fig 1. Procurement methods considering the responsibilities for the design and supplies DESIGN ....................................................................................................................................................... Client partly responsible Contractor responsible I Client responsible for i thedesign for the design for design ....................................................................................................................................................... includmg techcal solutions (pilot)

:

quality

i!

value for money

- - - - - , - - , - - - - - - - - - - - - - I

; :- - - price - - - - - I

I

SUPPLIES ....................................................................................................................................................... i Contractor responsible Client partly responsible Client responsible for the supplies i for the supplies for the supplies

1 Project management

contract

contract with I - - - - - - - - - - - I I

separate trades

I , - - - - - - - - - - - I

1 1 - - - - - - - - - - -

, I construction I management

:

I - - - - - - - - - - -

! # management ! I contracting 1

Building procurement and risks 297 2.1 Procurement methods described with design and supply responsibilities In fig. 1. procurement methods are described with the decisions concerning design on the upper level and those of supplies on the lower level. Five paths have been identified.. When the contractor is offering both the design solution and price, the nature of the question is one of a design-build method. Furthermore, the aim in designbuild could be chosen dS?erently.[4] In quality competition the aims of design competition and competitive tendering are combined. The greatest value for money is looked for when price and money are evaluated in the same category with value analysis. If only price has importance, the tender with the lowest price is accepted fiom those exceeding the minimum quality level. One of our institute's research efforts is a pilot-project in which the client is responsible for the architectural design. The contractors, however, can choose openly the technical solutions according to the client's performance and quality requirements. There are diirent possibilities for obtaining the necessary design services. In Finland, client's do not have in-house staff for design, as is the case sometimes for example in the UK or in the USA. Design competition can be useful in architecturally demanding projects; also when the client's requirements are not yet exact. The ideas of the proposals can easily be developed further. Sometimes in the public sector it is even obligatory to invite design tenders but the most usual way is to hire directly suitable consultants. The largest controlling power is achievable with the project management methods. It is typical for these methods always to have a project-specific project management organisation. In other words the principles of management by objectives can be used throughout the project.[5] If the organisation is entirely an outside company at risk, it is called management contracting. Project organisation could be that of a mixture of the client's staff and outside project management services, or totally dominated by the client's personnel resembling the separate trades method.[6] If the client does not want or does not have the necessary resources, a lesser responsibility for the supplies can be taken in the single construction contract and its variations. 2.2 Price The formulation of the contract price starts with the decision as to whether a performance or a cost based method will be used as shown in the fig. 2. In performance based methods, the client pays the agreed contract sum covering risks that may not actually take place. Cost of the variations and extra works are paid separately. With unit prices, the risk of overpricing extra work is managed, and it is not necessary to define the scope of work beforehand. Indexes can be used to avoid external risks due to the length of contract period. If cost basis is chosen, the client has to ensure that the payments are in accordance with the actual cost. A mutual estimate and incentive for savings are achieved through target price compared with cost plus. Reimbursement ceases altogether at the maximum guaranteed price, GMP. There are various arrangements for risk sharing both to compensate the contractor for any savings and to distribute any cost over-runs. Separate payments can concern those parts of the work us&l to reimburse at a fixed price such as for example site machinery cost.

298 Pernu, Kiiras and Peltonen

performancebasis

cost basis

target price

unit prices

f&ed price

cost plus

(guaranteed

w

W

variation and extra work

indexes

deviation from target price

reimbursement

Fig. 2. Decisions associated pricing contracts.

competition

negotiation

el

EVALUATION CRITERIA

I

price, quality, service, scope, financing

preliminary

Fig. 3. Decisions associated with the way of inviting tenders

I

separate Payments

Building procurement and risks

299

2.3 The ways of inviting tenders The ways of inviting tenders can also be described with regard to decisions. Firstly either competition or negotiation is selected as shown in fig. 3. Competition could be open to all interested with a prequalification leading to a restricted competition, or the client directly chooses suitable candidates based on earlier experience for example. A project can be negotiated with one or more contractors, and prequalification is also possible. As evaluation criteria, price (or lie cycle cost), time, quality, service, scope, financing (for example build-own-operate-transfer-methods), or any combination of these items are applicable.

3 Building projects and risks 3.1 Definition of risk In the field's literature, a lot of attention is paid to the management of risks as well as to the description of these risks themselves. In this study risk was defined as possible obstacles with the consequence that the set project objectives or owner's requirements cannot be met. The aim was to analyse those risks connected with building procurement methods. From this point of view, the allocation of risks was considered essential, and for example risks, not under control and normally covered by insurance such as fire or climatic conditions, were not examined. 3.2 Risk treatment Risk treatment is based on the above definition. Procurement methods are first examined as enhancement steps for opportunities and defined as a means to achieve the required results. Secondly, procurement options are discussed as responses to the threats to the decided goals. In other words, if risk could have both positive and negative outcomes (as in gambling), in the same way the responses to risks can work bothways. In fig. 4 the structure of the risk treatment is presented to illustrate the ways the results of this study were obtained.

L

Ipmject objectives

I

obstacles

sources of risks

I 1

procurement methods as means to treatment of risks Fig. 4. The structure of risk treatment used in this study.

300 Pernu, Kiiras and Peltonen

The structure could also be described using the following four questions: 1. What is the proper definition of risk with building project procurement? 2. What possible obstacles to a positive outcome are there? 3. How are the obstacles originated? 4. How can procurement options be utilised on the one hand in reaching the project goals, and in avoiding or controlling risks on the other? 3.3 Project objectives and procurement options This paper identifies six different categories of project objectives. They are schedule, duration cost, budget design quality quality of workmanship scope the characteristics of project management by owner Table 1. (next page) shows how the different procurement options including the documents, the ways of inviting tenders, and the way of defining contract price, are utilised in helping to achieve the set goals. The major categories are split into individual aims. In table 1. there are only some examples of possible contents with the chosen classification. In the last column, the beneficial characteristics of the selected procurement options are identified.

3.4 Sources of risks The sources of risks cause the obstacles to a positive outcome. The following classi6cation of risk sources are assumed based on the authors' earlier experience external market conditions, internal project management skills, and project characteristics. The capacity of the client to deal with project risks must be evaluated for each project as well as for the fill duration of the project with a view in the risk allocation process. 3.5 Risk response development and procurement options In table 2. some examples of risks and their origins, according to the three categories of risk sources, are presented. In the same way as in table I., the chosen procurement options and beneficial characteristics are shown. The responses aim at managing, abating or avoiding the risks. With the procurement, it is more usual to allocate or transfer all or part of the risk to another party or retaining all or part of the risk.[3] This paper points out how procurement options can be used to foster positive events, while at the same time the options can be used to minimise the consequences of negative aspects. The choice of a particular procurement option defines what is the optimal demarcation of responsibilities and risks in any project in question taking into account the client's resources and market conditions. The method is based on emphasisiing prime risks, given that all all risks are interactive and exchangeable during project duration.[2]

Building procurement and risks 301 Tabie 1. Procurement methods and project objectives. Project objectives

Suitable procurement method

Characteristicsuseful as means to reach set aims

Scope of project 'accurate program QO cost of variations and extra works

design-build project management, target price

tenders based on programs design solutions and supplies developed throughout the project

design competition, single construction contract design-build competition, single construction contract

only owner controls the design, alternative solutions alternative solutions, user's representative controls the design

Qualay of worlananship *correspondencewith contract 'correctness

single construction contract, project management cost plus, target price

no need to assess subjective criteria no possibility to gain more profit by lowering quality

Schedule *correspondencewith contract

design-build, project management

d-b: risk is transferred clearly to contractor, pm's control throughout the project overlapping of design and supplies possible

Design quality *aesthetics *functionality

*speed Costs *correspondencewith *budget cost savings

-economical life cycle wsts

Project management *beneficial co-operation project control power

d-b, pm, schedule as one of the evaluation criteria

fixed price target price, project management design-build

project management, target price project management

salternative design solutions design-build

price without variation known before construction starts interest to minitnise costs, pm: effective competition on supplies d-b-contractor can easily take responsibilm of maintenance wsts

mutual benefit of developing design owner manages the project throughout the project design solutions offered

Table 2. Some examples of risks in building projects classified in three categories including risk management with the procurement method Sources of risks

Risks

A choice of a procurement option to treat risks

Characteristics of procurement methods with risk treatment purpose

A. Market conditions *economicstate

recession

design-build, fixed price

boom

project management, design-build cost plus, negotiations, project management design-build, negotiation

short duration possible, increasing supply prices design-builders' responsibility pm: supplies decided at later stage, design-build interest due to falling supply prices cp: owner's cost risk, no competition risk, different parts of works with &rent procurement methods contractors' sites available

'supply

no interest to offer

*site

suitable sites not applicable

B. Building project especial architectural requirements *shortbuilding period .fixedbudget *limitedbudget

C. Project manager or owner *lackof experience *lackof financing resources

no acceptable design solution delays, disturbances extra costs client's requirements not fulfilled, budget overruns

disorders resources overrun, contract annulling

design competition + single construction contract d-b, negotiation, pm fixed price, d-b, single construction contract target price, project management

several design solution easy to be developed further overlapping design and construdion possible price agreed before construction starts excluding variations and extra work mutual interest to develop the design solutions, pm: cost control continues throughout the project

d-b, consultants for making tasks are transferred to design-builder, m c: general main contract contract conditions and document models in Finland financing as an evaluation build-own-aperate-transfermethods applicaple criterium

Building procurement and risks 303 4 References

1. Valtiovarainministeri6n tyoryhmiimuistioita. (1993) Julkisen talonrakentamisen kil'iluttaminen, Helsinki, Pub. 1993:21 2. Project Management Institute Standards Committee. (1996) A Guide to the Project Management Body of hlnowledge, USA. 3. Lowe, J. and Whitworth T. (1996) Risk Management and Major Construction Projects, The Organisation and Management of Construction, CIB W65 Proceeding of the International Symposium 1996 in Glasgow, (ed. D.A. Langford and A. Retik), Vol. 2. pp. 891-9. 4. Pernu P. (1997) Design-build Methods in Finland, Procurement A Key to Innovation. La Maitrise d'ouvrage - Cle de 1'Innovation. CIB W92 Proceeding of the International Symposium 1997 in Montreal. (ed. C.H. Davidson and T.A. Meguid), Pub. 203. pp.615-24 5. Efektia. (1995) Uudet rakenmttamimenetelmiit ja kunnat, Seminaarijullcaisuja 111995, Helsinki. 6. European Communities. (1994) Strategies for the European Construction Sector. A Programme for Chance, A report compiled for the European Commission by W S Atkins International Ltd. Luxembourg.

-

Development of a risk management approach for allowing dependency and uncertainty between activities' duration N.N. DAWOOD School of Science and Technology, The University of Teesside, UK

Abstract Variations in the durations of activities are a common place in the construction industry. This is due to the fact that the construction industry is highly influenced by variations in weather, productivity of labour and plant, and quality of materials. Stochastic network analysis techniques has been used by previous researchers to model variations in activities and produce more effective and reliable project duration estimates. Although these techniques have proven to be useful in modeling variations in activities, dependencies of activities' duration are not considered. This can have a severe impact on realistically modeling projects. In this context, the objective of this research is to develop a risk management methodology that can accurately model activities' dependency and realistically predict project duration using a risk management approach. A simulation model has been developed to encapsulated the methodology and run experimental work.

1 Background

Uncertainity in network analysis has been used by previous researchers in an attempt to model variations in activities' duration more accurately and produce more effective and reliable project duration estimates. Variations of activities duration do occur due to the exposure of construction projects to numerous uncontrollable risk factors. Several probabilistic methods have been developed to solve the problem of Uncertainity in network analysis. Amongst these methods are [1,2]: PERT (Program Evaluation and Review Technique) PNET (Probabilistic Network Evaluation Technique) Managing Risks in Projects, edited by K. KXhkOnen and K.A. Artto. Published in 1997 by E & FN Spon, 2-6 Boundary Row, London SEl 8HN, UK. ISBN: 0 419 22990 6 .

Risk in duration of activities 305 NRA (Narrow Reliability Bounds) MCS (Monte Carlo Simulation)

Diaz and Hadipriono [3] found that PERT is the simplest method and yields the most optimistic results, while MCS produces the most conservative results. They used several types of networks and the evaluation is based on survival function and computer time. Ranasinghe [4] has developed an equation to model the uncertainty in activity duration. From this equation Ranasinghe developed a quantification for uncertainty in project duration. The research in the area of uncertainity in network analysis which has been developed over the last decade has refined the techniques used, however a number of problems still exist. Uncertainity in analysis is applied with survival of the project in mind, rather than applying it to projects with the survival of the company as the basis of the decision. Obviously, before the uncertainties of projects can be combined a good understanding of the uncertainties in each project is needed. Furthermore, the techniques used still need enhancing to produce more accurate models of the interactions between uncertainties and activities variations. In this context it is hypothesised in this research that unless some form of dependency between activities variations exist, accurate modelling of Uncertainty in networks is unattainable. The objective of this research is to explore a methodology, based on risk management approach, that models variations in the duration of activities and their dependency on risk factors. It is hypothesised that such methodology can improve project duration estimates and provide practitioners with a tool for testing several mitigating strategies to counter detrimental events and their iduence on project duration. In order to achieve the objective, the following tasks have been performed: Identiflmg risk factors that cause activity variations using a literature review and conducting interviews with contractors. Model risk factors and activities' duration variations and identify dependency between them. Develop a simulation model to encapsulate and test the new methodology. Run experimental work on case studies to validate the methodology.

2 The developed methodology

In this section the proposed methodology of modelling variations in the duration of activities and their dependency on risk factors is discussed. It is assumed that there are a number of risk factors that might cause variation in activities' duration and their iduence can differ from one activity to another. In general, the following are considered to be the risk factors: type of soil and site condition weather condition material and equipment failure incomplete design scope

306 Dawood defective design design changes fluctuation in labour productivity artificial obstruction sub contractors default land slide Each of the above factors can be modelled using a representative distribution and have a minimum value as (0) and a maximum value as (1). As the case in MCS, random numbers for each risk factor are generated from a particular representative distribution. The type of distribution can vary from one activity to another or can be kept fixed for the project once it has been generated. It is proposed that certain risk factors will have the same influence on the project regardless of time, for example, type of soil and site condition, labour productivity, etc. On the other hand, other risk factors might be changed through time and might have different values from one activity to another, for example, weather conditions, equipment failure, incomplete design, design defect, etc. In this case, random numbers will be generated for each activity or for a particular time in the project calendar. Several distributions are used to model risk factors as shown in Table 1 [5].

incomplete design scope

likely, and the probability of an outcome beyond that

Table 1.

The distributions, their possible use and the parameters required.

The influence of each risk factor on variations of activities' duration should be established. As an example, Table 2 shows a matrix that gives the influence of the risk factors on variations on activities' duration.

Risk in duration of activities 307 RISK FACTOR

Table 2.

Activity/Risk factors matrix

As can be seen above, each risk factor has a certain contribution on activities' variations (risk factor (1) has 20% influence on duration variations in activity A). The total influence of all factors should be 100% on any given activity. In reality the influence of factors will be assessed judgmentally through knowledge elicitation. This will be discussed later in the paper. Once distribution has been allocated (using a combination of historical data and knowledge of distribution theories) to risk factors and the influence matrix is developed, the remaining is the calculation of activities' duration. In order to achieve this, the following equation is developed: Duration of activity A= MinTime + [MaxTme - MinTime] x [(RFl x Random]) + (RF2 x Random2) + (RF3 x Random3) + ... .+(REn x Random,)] where MinTime is the minimum duration that can be assigned to an activity MaxTime is the maximum duration that can be assigned to an activity RF, is the influence of risk factor (n) on a particular activity (from activitylrisk factor matrix) Random, is a random number that should be generated using a representative distribution of risk factor (n). In order to illustrate the above equation, Table 3 shows an example of four runs for activity A.

Table 3 .

An example to illustrate the developed equation

308 Dawood As can be seen in Table 3, in "Run 1" all risk factors have materialised to the very extreme and the duration of the activity is 20 which is maximum. In "Run 2" non of the risk factors have materialised and the duration of the activity is minimum, 10 days. "Run 3" shows a duration of 12.5 days resulted from 50% materialisation of each risk factor. Finally, "Run 4" shows the results of having two risk factors 1 and 2 with 100% materialisation. In order to validate the methodology, a simulation model has been developed using the Turbo-Pascal platform. The model encapsulates risk factors, their distribution and influences on each activity and the logic of a given project. The following section introduces a hypothetical case study to illustrate the proposed methodology.

3 Case study

This section introduces and discusses the proposed methodology developed in the course of this research. The case study is presented by a small civil engineering project as shown in Table 4. The risk factors that affected each activity in the project and their iduence are given in Table 5. The distributions representing the possible outcome of each risk factor are also given in Table 5.

Surface

10

Finishes End

11 12

Table 4.

Logic of the project

Insitu Span PC Span Surface Finishes

Finishes

2

7

End Nil

10

18 0

0

Risk in duration of activities 309

Table 5.

Risk factors influencing the project's activities

A suitable distribution has been allocated to each risk facor using site information and judgement. The quantification of the risk factors has been achieved through selecting a probability distribution which shows the possible outcomes of the variables and the relative likelihood of each possible outcome. Figures 1,2 and 3 show the distributions of weather, soil and reliability of equipment, respectively. Probability

Random N u m b e r

Fig. 1 .

Distribution of Weather

310

Dawood Probability

0 0 0 1 O1O2O2O30.30.40.40.5O5O6O6O7O.7O.8O.8O.9O.91.O

Random Number

Fig. 2.

Distribution of Soil

0 . 0 0 . 1 0.1 0 . 2 0 . 2 0 . 3 0 . 3 0 . 4 0 . 4 0 . 5 0 . 5 0 . 6 0 . 6 0 . 7 0 . 7 0 . 8 0 . 8 0 . 9 0 . 9

1.0

Ranndom Number

Fig. 3.

Distribution for reliability of equipment

The influence of each risk factor on the activity duration is assigned. Obviously, the influence of the risk factors should affect the outcome of the project and a range of experimental work can be designed to investigate the risk factors. It should be mentioned that the objective of this paper is to present the methodology and its operation. Construction managers should be able to use it as a test bench to pinpoint the effect of risk factors on their projects. The distributions that represent the risk factors might differ from project to project and therefore the methodology is designed to accept a wide range of distributions to suit particular applications. 3.1 Analysis of the results Having described and quantified the uncertainty of risk factors, the next stage is to determine the combined effect of uncertainties on the project duration and to identifl the factors which contribute significantly to the total. The results of the runs are compared with Monte Carlo simulation using the Beta distribution to model activities variations. Figure 4 shows the results generated from 1000 iterations of the mode. As can be seen, the minimum duration (optimistic) of the project is 57 days and maximum duration (pessimistic) is 94 days. The mean value of the project duration is 78.7 days with 7.5 standard deviation and -0.115 skewness (i.e. the mean is shifted towards the

Risk in duration of activities 311

pessimistic value). The cumulative density hnction in Figure 5 indicates that around 80% of the results are between 74 and 94 days. In order to identify the influence of the risk factors on the duration of the project, a correlation analysis between the risk factors and project duration is conducted. Figure 6 shows that weather and productivity have a high correlation (0.68 and 0.62 respectively) and this is regarded as a high influence on the project duration compared with other factors. This type of analysis should help project management on focusing on the risk factors that effectively influence the project duration.

,,,,

Probability

1

1

57 59 61 63 65 67 69 71 73 75 77 79 81 63 85 87 69 91 93 95 Possible project duration

Fig. 4. Distribution for the project duration, No of runs: 1000, MinValue: 57 Days, Max Value: 94 Days, Average: 78.7 Days, SD: 7.5, Skewness: -0.115 CDF

57 59 61 63 65 67 69 71 73 75 77 79 81 83 85 87 89 91 93 95 97 Posslbte project durarlon

Fig. 5.

Cumulative distribution for project duration Risk factors

0.00 0.10 0.20 0.30 0.40 0.50 0.60 0.70 0.80 0.90 1.00 Correlation coefficient

Fig. 6.

Correlation of the risk factor with project duration

Dawood

312

In order to compare the results generated from the proposed methodology with the traditional PERT approach, the model was allowed to run the same case study using the Beta distribution. The maximum and minimum values for each activity that were used in the Beta distribution are shown in Table 4. Figures 7 and 8 show the results generated from 1000 iterations of the case study. As can be seen, the results are quite similar to the proposed methodology, however, the PERT solution has provided slightly lower standard deviation (6.9) and higher skewness of (-0.21). The PERT approach has produced an overall expectation of the project duration without any indication regarding the causes of such wide outcomes in the project duration. Probability 0.14

-.

I

61 63 64 66 68 69 71 73 74 76 78 79 81 83 84 86 88 89 91 93 Posslble project duration

Fig. 7.

Distribution for the project using the Beta distribution CDF

61 63 64 66 66 69 71 73 74 76 76 79 81 83 84 86 88 89 91 93 94 Possible project duration

Fig. 8. Cumulative distribution for the project, No of runs: 1000, Min Value: 61 Days, Max Value: 94 Days, Average: 78, STD: 6.9, Skewness: -0.21 3.2 Risk response Having identified the possible outcomes of the project duration, the management is to identify at the possibility of reducing the variations and minimising the pessimistic part of the project duration. The developed methodology is well suited for targeting the detrimental effect of the risk factors and consequently reducing the impact of such factors. In the case study, it was concluded that the weather and productivity risk factors have a high impact on the project duration and the intention is to reduce the

Risk in duration of activities 313

effect of these factors. In order to achieve this, it was suggested that the project used in the case study be constructed over the summer, this way, the effect of weather can be minimised. 1000 iterations were run using the same information presented in Table 4 and changing the mean of the weather distribution to (0.2). Figure 9 and 10 show that the possible project duration has been shifted towards the optimistic part. It can be seen that the mean value is 54 days with skewness of 0.17. More experimental work is under way with the objective of minimising the detrimental effect of the risk factor. From Figures 9 and 10, it can be concluded that the detrimental effect of the risk factors can be minimised and more optimistic duration can be produced. However, the question to be asked is: At what cost can this be achieved? Management should be able to evaluate and determine the costbenefit of each alternative. This subject is being investigated as part of this research. Probabilit 0.12

I

54 56 58 60 62 64 66 68 71 73 75 77 79 81 83 85 87 89 91 93

Possible project duratlon

Fig. 9.

Distribution for the project duration

55 56 58 60 62 64 66 68 71 73 75 77 79 81 83 85 87 89 91 93 95

Possible project duration

Fig. 10. Cumulative distribution for the project duration, No of runs: 1000, Min Value: 54.4 Days, Max Value: 94.661 Days, Average: 72.9 Days, SD: 7.7 Days, Skewness: 0.17

316 Psunder

Fig. 1. A degree of impact on quality during the phases of the project In projects without series products (construction projects) the costs of errors increase approximately 3 times when they are transposed from the conception to the construction phase of the project, then approximately 5 times when transposed from the construction to the implementation phase and additionally 8 times when transposed from the implementation phase to the exploitation phase of the building project. The costs of modifications and the potential savings in individual project phases are presented in Fig. 2.

conception

construction

implementation exploitation

Fig. 2. Modification costs and potential savings in individual project phases

2 Comparison between Europe and Japan

The issue of costs brought about by mistakes and failures in civil projects has not been fully explored by civil engineers. Therefore we shall take an example from the car industry and make a comparison between Japan and Europe.

Quality in civil projects 317

h

number of modifications start of production

.-... .- ....- -

-..,.--',

best of Europe '.*

-24

-20

-I c!sts

-12

-8 -4 increase 30 to 50 trmes

o

-.

>

4

8

duration (month)

Fig. 3. Quantity of reconfiguration for dashboard construction projects in Europe and Japan [I]. The designing phase of a new product in the vehicle dashboard industry lasts approximately one year in Japan. In some cases the first tests are made even in the design phase so that the planning phase of the project and the start of production can begin earlier. The peak of modifications is approximately 4 months before the production starts. The complete developing process of the new product lasts less than three years. In Europe meanwhile the design phase lasts more than two years. The tests are made first at the end of the design phase. When the tests are complete the planing phase begins and when the planning phase is concluded the production can start. The whole developing process lasts up to five years and the peak of reconstruction is a few weeks before the production starts (Fig. 3). In the case of the dashboard industry the costs of a modification rise from 30 to 50 times when it is done 4 weeks before the production starts (as in Europe) instead of 16 weeks before the production starts (as in Japan). In other brands the situation is similar. Even in the civil and construction engineering, modifications are made during the implementation phase of the project. That raises costs and also results in loss of quality.

3 Costs systematisation In order to minimise project costs, a systematised exercise in cost control must be performed. Costs are generally controlled periodically. With the systematised

318 Psunder

percentage of failures

Fig. 4. Costs for quality and costs caused by bad quality. periodical model of cost control, it is easy to locate sources of cost and to assign responsibilities for them. Therefore it is very useful when the costs are divided into the costs for the quality assurance including the quality control (construction, market research, education, control, etc.) and the costs caused by lack of quality (waste, repair, reduced value, warranties, etc.). The goal of the costs systematisation model is to reduce the costs for the quality assurance and to minimise the costs caused by the bad quality to reach the optimum quality level (theoretical optimum, Fig. 4). When the costs are divided into two separate branches (the costs for the quality assurance including quality control and on the costs caused by bad quality), it is easy to plan and to control the costs. Even if the customer expects the so called added quality (by special products or branches) it is easy to define the new optimum for the added quality level (Fig. 4). The theoretical optimum is the best ratio between the total costs and the percentage of failures. A higher quality level decrease the costs caused by bad quality but also increases the costs of quality assurance. Usually the quality level is higher than the theoretical optimum. The difference is called added quality. In some cases it is expected and paid for by a customer, but in most cases it is not. Therefore it contains reserves in costs optimisation.

4 Effects of the quality management The primary aim of the customer is to get the best quality for the lowest price and for the company, the aim is primarily to assure the stability and capital gain of production (Table 1). As is shown in the Table, optimised quality management assures the costs minimisation of the project and the long term successful running of the company through the confidence of the customers, an increased market share and capital gain. Therefore it is very important for the companies which are managing projects to manage the quality of projects as well.

Quality in civil projects 319 Table 1. Effects of quality management EFFECTS OF THE Q.M. FOR THE COMPANY capital gain POSITIVE (QUALITY) market percentage confidence repairs NEGATIVE (UNQUALITY) warranties waste

FOR THE CUSTOMER minimal costs maximal value maximal pleasure upkeeping repairs stovs in exvloitation

5 Conclusion The increased demand for an optimised costlquality ratio of product pushes companies to develop very sophisticated systems for quality management. Some researches has already been done with the aim of automatising quality management, supported by expert systems. With their help it is possible to control projects from beginning to end and to predict possible failure on the basis of expert opinion. This is an additional step to quality management which, will assure an entirely successful product and a project with minimum costs.

6 References 1. Seghezzi H.D., Hansen J.R. [Hrsg.] (1993) Qualitatsstrategien,Carl Hanser Verlag, Miinchen. 2. Jungwirth, D. [Hrsg.] (1996) Qualitatsmanagement im Bauwesen, VDI-Verlag, Diisseldorf. 3. PSunder, I. (1996) Raziskava zagotavljanja kakovosti pri vodenju gradbenih projektov - diplomsko delo, Fakulteta za gradbenigtvo, Maribor.

PART 7

UNDERSTANDING NATURE OF RISK-MODELLING ASPECTS

328 Browne and Keown-McMullan 2.2.4 Results: The reputation and credibiity of NASA, one of the world's premier engineering research and development project management organisations, lay in ruins. Its very survival was under serious threat. The absence of a proficient emergency plan coupled with NASA's handling of the media, its piecemeal approach to explaining the incident and the obvious M i n g of blame between various parties served to underline the inadequacy of management in the eyes of the public. A number of contractors particularly Thiokoh the constructor of the faulty booster rockets, were subjected to similar bad publicity and detailed scrutiny of their policy, ethics, structure, managerial style, responsibility, communications and decision-making procedures.

3 The Management of Projects

To successllly manage projects the project manager should be aware of generic crisis management theory, its application in other sectors and how to transfer this knowledge to the project situation. 3.1 The project A project may be defined as a unique, non-repetitive event, task, contract or item that should normally have specillc and identillable start and finish points and clear deliverables or objectives. Barnes and Wearne [lo] state that " ... the fist task is to establish and define the objectives for the project clearly and in some detail ". Their determination is not only important in setting direction and giving focus to activities, but represents the standard by which those close to the project can measure performance in terms of success or failure. Project risk is therefore concerned with the likelihood of the project objectives or the perceived project benefits not being satisfactorily achieved. A project crisis may be viewed as the ultimate risk facing project managers. Once a crisis has been activated there is no going back - it may be possible to handle the crisis effectively but significant change wiU have taken place and time and money will have been spent on ensuring the project remains on course. As identi6ed in the examination of the crises case histories, the fist stage in the successll management of a crisis is the identscation of early warning signals in the operating environment.

3.2 The project environment The project operating environment is especially complex. Figure Two is an integrative contextual fiamework that illustrates the project's external and internal environment, particularly its complexity. The environment external to the project organisation consists of concentric international, national and local suprasystems, where demand for projects normally emanates. The project organisation has a loosely defined boundary that separates it fiom its environmental suprasystem As the project develops so does its internal environment or subsystems. The client subsystem in responding to demand instigates the project which in itself has specillc and unique characteristics. The project must be properly organised and managed through the use of teams. The prime subsystems of

Proactive project management 329 the internal environment are therefore: the client; the project; the project management subsystem and the project teamlmulti-organisation. The project manager should continually scan the environment for any significant change, issue or event which could possibly trigger a crisis. Project crises have been triggered by events such as war, and large scale movement of capital across country borders in the international environment; factors such as changes of govemment and legislation, and interest rate fluctuations at national level and by natural disasters, civil disorder, community pressure etc. at local level. Change within the internal project systems may also precipitate a crisis. The client body may become hancially unsound, a key decision maker may die or the company may face major litigation. There may be inherent problems with the project, for example its objectives may have been overly ambitious, or its geographic location inappropriate. Problems may also arise with support organisations or the project management system eg., poor team spirit or contlict; communication f a h e ; or poor problem sohring and decision making.

The external environment - National

Figure Two: The Project Environment

330 Browne and Keown-McMullan

Sigmficant change within any of the sub-systems of the project environment may trigger a crisis. Therefore it is vital that project managers cany out extensive environmental scanning to ensure detection of the early warning signals which usually precipitate a crisis.

4 Project Environment Scanning

Crisis triggers may be categorised into those caused by internal forces and those caused by external forces and by technical/economic failure or humadorganisational/social failure. Project managers must set in place a system or routine which facilitates regular, accurate checks for early warning signals. In order to structure this environmental scanning it is suggested that a generic matrix, based on the work of Shrivastava and Mitroff [l 11, should be used. Technical/Economic .Technical Errors .Iack of Resources .Inaccurate Costings .System Failure .Accidents .Insolvacy

pGFl

.Economic Shifts .Changesm Govemrnent/Policy/LawlTax .Resource Shortages -CompetitorActivity .New T&ologylInformatim .Natural Disasiers

m l l

Internal

External .Communication Breakdown Sabotage (Intntemal) .Lack of Competmcy .Removal of Key Persormel .Shift m Objectives/Core Valus -Ova ambitious Objedivs &&a

.Wadcivil UnrestlTerrd Attack .Negaive Media Coverage or Public Relations .Public Pressure .Shift m social ~ d e s / v a l u s / d y n a m i c s Sabotage (External)

Figure Three: Project Crisis Trigger Matrix The Project Crisis Trigger Matrix (Figure Three) will focus attention on key areas but this generic model may in turn be used by project managers to develop their own individual project matrix.

Proactive project management 331 5 Conclusion To avoid crisis the Project Manager could adopt the following proactive strategy.

5.1 Draw up a Project Crisis Trigger Matrix - as shown above but adapted to highlight potential crisis triggers for the individual project; 5.2 Develop systems and initiatives to aid project environment scanning. For the above matrix (Figure Three) the following suggestions are made: 5.2.1 Cell One - Internal Technical/Economic Triggers Technical errors - establish a comprehensive, regular maintenance routine for all equipmentlmachinery employed, establish a procedure to be followed when a fault or suspected fault is identified by operative staff; ensure that personnel specifications detail appropriate level of technical skills and competencies; Lack of Resources - plan work in detail and schedule resources; negotiate an appropriate purchasing contract with suppliers to guarantee supply of materials for the duration of the project; monitor international commodity markets to detect likely shortages; Inaccurate Costings - ensure calculations are double checked; put in place policies and procedures to establish a uniform approach to costings; System Failure - regular maintenance and a system for fault reporting should be in place; fast response to faults should be a key contract consideration; Accidents - appropriate safety training should be provided; an accident record book should compiled - this will help i d e n t e vulnerable areas; safety audits should be carried out at regular intervals; Insolvency - accurate budgeting and regular progress meetings should help detect problems before they reach crisis point. 5.2.2 Cell Two - Internal Human/Organisational/Social Triggers Communication Breakdown - conduct regular meetings to report on project progress and ensure accurate minutes are recorded; use informal contacts to i d e n t e potential problems; Sabotage fiom within - recruitment and selection procedures should help recruit appropriate staff; appropriate security and working arrangements should be imposed and any deviation reported via established channels; Lack of Competency - team members must be caremy selected and goals established for each member of the team. Regular monitoring of progress should i d e n t e problems before they escalate; Removal of Key Personnel - establish contracts for the duration of the project; develop incentives to encourage staff loyalty; Shift in objectivedcore values - monitoring of all company publications and internal communication; monitoring of local and national press, especially following a new appointment; compile a written mission statement and aims and objectives for the project; utilise informal channels of communication; Over ambitious objectives - employ group decision making and realistic strategic plans; Inertia - hold regular team meetings to increase motivation; focus on targets and monitor progress. - -

332 Browne and Keown-McMullan 5.2.3 Cell Three - External Economic/Technical Triggers

Economic Shifts - daily monitoring of financial markets; Changes in Govemment/Policy/Law/Tax - structured, regular scanning of govemment reports and the quality press; Resource Shortages - regular monitoring of commodity markets and trade press; Competitor Activity - awareness of new developments through trade press; media and formal and informal professional/industrialcontacts; New Technology/Information - regular contact with specialist suppliers; monitoring of trade press; Natural Disasters - environmental auditlrisk assessment prior to commencement of project. 5.2.4 Cell Four - External Human/Organisational/SocialTriggers WarICivil UnrestITe~~orist Attack - monitoring of media reports; established security routines; recording of security incidents; Negative Media Coverage or Public Relations - scanning of local, national and international media; monitoring of local govemment reportdmeetings; Public Pressure - establish contacts with key local groups; invohe key pressure groups in some elements of project planning; Sabotage fiom external source - established security routines; appropriate security systems. 5.3 Develop a detailed crisis management plan. 5.4 Proceed to scan/monitor the environment.

5.5 If a trigger is identified take immediate action to avoidlmitigate the situation. Early identification of warning signals of potential crises may enable the project manager to shift the possible crisis to a risk which can then be managed. 6 References

1. Shrivastava, P, and M~troff,1.1. (1987) Strategic Management of Corporate Crises Columbia Journal of World Business, Spring, pp.5-11. 2. Barton, L. and Hardigree, D. (1995) Risk and Crisis Management in Facilities. Facilities, Vo1.13, N0.9110, p.12. 3. Adapted from: Keown-McMullan, C. (1997) Crisis: when does a mole h l l become a mountain? Dismter Prevention and Management, Vo1.6, No. 1. p.10. 4. BSI, 1996, Guide to Project Management. BS 6079, HMSO, 1.3.16. 5. BSI, 1996, Guide to Project Management. BS 6079, HMSO, 1.3.16. 6. Fink, S. (1986) Crisis Management. New York: AMACOM, American Management Association. 7. The material for this case study is drawn from: Lacey, R. (1996) How now mad cow. Viva Guides, Guide 3, Viva. 8. Shenhar A. (1992) Project Management Style and the Space Shuttle Program (Part 2). Project Management Journal, March, pp.32-37. 9. Morris P.W.G. (1994) The Management ofProjects. Thomas Telford, London. lO.Barnes, N. M. L. and Wearne, S. H. (1993) The Future for Major Project Management International Journal of Project Management Vol. 11, No 3, pp. 135-141. 11. Shrivastava, P. and Mitroff, 1.1. (1987) Strategic Management of Corporate Crises, Columbia Journal of World Business, Spring, pp.5-11.

Coping with environmental uncertainty in projects J.T. KARLSEN and B.O. ELVENES Norwegian University of Science and Technology, Trondheim, Norway

Abstract The problem in focus in this article is how to cope with environmental uncertainty in projects. Projects are viewed as partially open and adapting systems, where the external environment becomes a source of both threats and opportunities that affect the project performance. Within this fiamework projects usually experience a high degree of environmental uncertainty. The article focus especially on coping with time bounded uncertainty, which can only be reduced over time through a learning process where the project enacts the environment. Keywords: project environment, systems theory, systems boundaries, relationships, environmental uncertainty, uncertainty reduction, learning.

1 Introduction

The purpose of this article is to present and discuss some ideas and concepts regarding coping with environmental uncertainty in a project setting. Projects usually experience a higher degree of as well as a more fluctuating uncertainty than the traditional line organization [I]. When the project enters into a dynamic interaction with its environment, a network of temporarily relationships are created between the project and actors in the environment. These relationships can take many different forms and can change during the project period. However, environmental uncertainty is generated when there is a lack information about the environment. It can be lack of information about how the actors in the environment perceive information, how they react to information and how this reaction will affect the project. Every person and organization involved in project oriented work have to manage in a context of uncertainty which are Managing R i s k in Projects, edited by K. Kahk6nen and K.A. Adlo. Published in 1997 by E & FN Spon, 2 6 Boundary Row, London SEI 8HN, UK. ISBN: 0 419 22990 6.

336 Karlsen and Elvenes

Fig. 2. The subsystems network The links between actors in the systems network can take many different forms, dependent upon the situation as well as the actors experience and trust with the other actors. In figure 3, four alternatives are depicted. Traditional analytical approaches and techniques have usually treated the project as a task isolated from an ever changing environment. The project must be protected from hostile and unpredictable environments by building walls or boundaries keeping them from interfering with project processes. This situation is illustrated by alt. 1. in figure 3 . An example of this alternative is the classical market situation with sellers and customers. However, this approach does not eliminate the environmental uncertainty, it defines it mainly outside the boundary and might thereby even enhance it. By acting this way, the project does not exploit the possibilities to interact and influence the environment to the benefit of both parties. Even though the systems boundaries are closed and there might not be any direct relationship between the project and actors in the environment, they can interact with each other through a third party. This boundary spanner can be a person or an organization. This might be the case when there is a legal problem between the actors. In figure 3, alt. 2 depicts this situation. However, an interactive relationship is possible between the project and actors in the environment. When the project is boundary-crossing, it is a recognition of the need for building constructive working relationships with other actors. These projects are also more flexible in the sense that they could easily change and adapt to ever changing environments. Even more positive results can be obtained by attempting to influence and change it. We will describe these relationships to be characterized by both stability and change. Alternative 3 in figure 3 shows this situation. An example of this alternative can be a project steering committee, where the actors meet and discuss problems and solutions. Development towards interorganizational structures (e.g. integrated teams) have to a certain degree changed, erased or made the system boundaries between the project and actors in the environment invisible. There is created a temporarily dependency relationship on both sides, and the actors are working very close together. This situations is illustrated by alt. 4, in figure 3.

Environmental uncertainty 337

Alt 1

Alt 3

0 0 0-0 0% 0 Alt. 2

Alt. 4

Fig. 3. System boundaries 3 Environmental uncertainty

Galbraith introduces the concept of uncertainty as the key factor in analyzing the project environment [5].But what is this term uncertainty? Many have difficulties explaining what uncertainty is, even though we all have experienced it. Perhaps the most common definition of the term uncertainty is an inability to predict and control future events. From an information-processing perspective, Galbraith defines uncertainty as the difference between the amount of information required to perform the task and the amount of information already possessed by the organization. [5]. However, it is important to recognize that uncertainty is individually based. When a project team member enacts the environment, individual stereotypies based on knowledge, experience, interests, viewpoints, norms and expectations will influence what the person perceive and his reconstructed image of the situation. In this article we will define environmental uncertainty as imperfect conditions for rational behavior generated by the environment. The greater the environmental uncertainty, the more difficult it is for the project manager to program and routinize activities by preplanning in response. This require modes of organizations that attempt to cope with rather than avoid uncertainty and interdependence. Project managers can no longer work as if they are isolated from the environment. Actors in the project systems network have to recognize their dependencies on one another, and ensure that they exploit the possibilities to interact and influence the environment to the benefit of both parties. A variety of environmental dimensions have been introduced into the organizational literature, each of which could account for a noticeable portion of variance in the environmental uncertainty. We will emphasize the following environmental dimensions which contribute to explaining the uncertainty. Complexity. This dimension refers to the heterogeneity, range and number of actors or activities of the environment which are relevant to the project's operation[6] [7]. Routineness. This dimension refers to the extent to which relations with environmental actors are formalized, and reactions to changes initiated by other actors.

340

Karlsen and Elvenes

Fig. 4. The project control loop To increase the capability to cope with environmental uncertainty, it is required to change in direction toward a different way of learning, called double-loop learning [13]. Double-loop learning, by contrast, is characterized by the search for and generation of new alternative practices. It allow the project to challenge operating assumptions and norms which are embedded in the project tradition, in a most hndamental way. It involves how project managers think, how they perceive information, and how they reasoning and implement their action. By removing the barriers which may inhibit deutero-learning or learning to learn, project managers develop an ability to reflect and inquire into previous contexts for learning or failure to learn and can question and evaluate the appropriateness of their actions [ 101. We will argue that it is misleading to equate learning only with adaptation to environmental changes. To the contrary, we will emphasize double-loop learning as a proactive process. It is the process by which knowledge is used offensively to understand and improve the interrelationships between the subsystems both inside the project and between the project and actors in the environment. Such learning is evolutionary; it challenges the existing structures. This argument is in accordance with Hedberg who claims that the purpose of learning is to improve performance and master the environment [9]. In this way learning is a proactive process where the project enacts and attempts to influence and change the environment. To relate this discussion to figure 3, we will argue that the potential and the efficiency of this process depends on the boundaries and relationships between the project and actors in the environment, which can take many different forms. The ability to learn from and influence the environment is higher when there is a close interaction between the parties (e.g. integrated teamwork), compared to a situation where the project is isolated from the environment. However, there are several major barriers which can make this learning process difficult. Since the process of learning often introduce experimental acts, it can create a temporarily higher degree of uncertainty. From this view learning becomes a trade off This can cause some resistance against double-loop learning, especially from involved actors in the environment. Second, there is the problem of bureaucratizing [14]. From a bureaucratic approach project team members are not really encouraged to think for themselves and be creative.

Environmental uncertainty 341 Instead, project team members are expected to work within operating norms, procedures, rules and practices which have been institutionalized as the common way of doing projects. According to Morgan a third major problem is the use of single-loop learning system to control the project team members work. This may prevent double-loop learning from occurring [ 141. A fourth major barrier to overcome stems from the project reward (or career) system. This problem is often associated with accountability. To the extent that project team members are held responsible for their performance and decisions within a system that rewards success and punishes failure, they have an incentive to protect themselves and keep a retreat open. Thus they ofien tend to find ways of obscuring problems that will place them in a bad light. A fifih barrier which may inhibit double-loop learning is shortage of time. In almost every project time is a critical factor or resource. Since time is a critical factor, the focus of the project manager will be directed towards completion of the project rather than learning to learn. Similarly a crisis in a project will be solved and not analyzed for learning possibilities, because time is seldom allocated to evaluation activities. Mostly they do not have a capacity or an ability to challenge operating assumption embedded in the project system.

5 Conclusion

In this article an attempt has been made to review and discuss the problem of coping with environmental uncertainty in projects. This, however, implies several challenges. First, we will argue that the project managers have to put environmental uncertainty on the agenda. Second, they have to realize that learning is necessary to cope with external dynamic uncertainty, and the challenge is to move from reactive to proactive learning. We will emphasize the creation of a continuous learning process to enhance and develop the ability to adapt to as well as influence and control the external environment. We will argue that often it is project managers who have most difficulty in learning, because they misunderstand what learning is and how to bring it about. Developing a learning project, however, requires creating room and arenas for learning. There must be time for communication and reflection, and arenas for challenging assumptions and experience based stereotypies. Further, there must be room for unlearning, experimentation and possible failures. Successfbl learning, to cope with environmental uncertainty hinges on constructing an understanding of the concept external uncertainty, both its source, form and content. We will emphasize that it is necessary to develop an understanding of the project system network, its dynamics and complexity between elements of uncertainty and other elements in the environment. This also include an understanding of the relationships between these elements and their relations to the project, both as tasks and processes. In order to meet these challenges, more effort should be put forward to develop theories, models and tools to understand and cope with the dynamic relationship between the project and the environment. Within this context project managers are able

342 Karlsen and Elvenes

to learn to learn, and use their experience to initiate creative double-loop learning. This will provide new and improved arenas for coping with environmental uncertainty.

6 References

Stinchcombe, A.L. and Heimer, C. A. (1985) Organization Theory and Project Management: Administrating Uncertainty in Norwegian Offshore Oil. Norwegian University Press, Oslo. Draft, R.L. (1983) Organization Theory and Design. West Publishing Company, St. Paul, MN. Dill, W.R. (1958) Environment as an Influence on Managerial Autonomy. Administrative Science Quarterly, Vol. 2. pp. 409-43. Emery, F.E. and Trist, E.L. (1965) The Causal Texture of Organizational Environments. Human Relations, Vol. 18. pp. 21-32. Galbraith, J.R. (1977) Organizational Design, Addison-Wesley, Reading, MA. Child, J. and Mansfield, R. (1972) Technology, Size and Organizational Structure. Sociology, Vol. 6. pp. 369-93. Thompson, J.D. (1967) Organizations in Action, McGraw-Hill, New York. Pfeffer, J. and Salancik, G.R. (1978) The External Control of Organizations: A Resource Dependence Perspective. Harper & Row, New York. Hedberg, B. (1981) How organizations learn and unlearn, in Handbook of Organizational Design, (ed. Nystrom, P.C. and Starbuck, W.H.), Oxford University Press, Oxford. West, P. (1994) The Learning Organization: Losing the Luggage in Transit? Journal of European Industrial Training, No. 1 1. pp. 30-38. Anderson, John R. (1995) Learning and Memory: An Integreated Approach. John Wiley & Sons, New York. Senge, P.M. (1990) The Fifth Discipline: The Art and Practice of the Learning Organization. Century Business, London. Argyris, C. and Schon, D. (1978) Organizational Learning: A Theory of Action Perspective. Addison-Wesley, Reading, MA. Morgan, G. (1986) Images of Organization. Sage, New York.

Project risk: systemicity, cause mapping and a scenario approach T.M. WILLIAMS, F.R. ACKERMANN and C.L. EDEN Department of Management Science, Strathclyde University, Glasgow, UK

Abstract The approach to managing risk in complex projects in recent years has been centred around the Project Risk Register (PRR). Some project managers assemble a PRR and say "so what?" Others use it for analysis and planning; however, the escalating intracomplexity of projects means that project risks are becoming more inter-related, and the impacts of risks more systemic. In these circumstances, simple treatment of individual items in the PRR is flawed. The approach discussed here took a PRR and reassembled it into a "cause map" to capture the inter-relationships between risk items and help towards a deeper understanding of the causality. Use of appropriate software provided useful analysis tools which form clusters of relatively independent "scenarios". The process also suggested that "cognitive mapping" used prior to cause mapping would be an efficient and effective way of developing a structured PRR; and a Group Decision Support System (perhaps networked) would enable aggregation of knowledge from diverse sources. Finally, the structure of the cause map developed in the case study described, suggested that the scenario approach would be a useful analysis and planning tool allowing action options to be tested against a number of possible alternative futures. The whole process could be a powerful first step in risk evaluation. Keywords: risk register; cause mapping; scenarios

1 Risk analysis and Management in MOD

Concern about starting major defence (mainly aviation) development projects prompted the setting up in 1958 of the Committee on the Management and Control of Research and Development. The resulting Zuckerman Report recommended that "project st~~dies" should be carried out for all major projects before a development Managing Risks in Projects, edited by K. K2hkOnen and K.A. Artto. Published in 1997 by E & FN Spon, 2 4 Boundary Row, London SEl SHN, UK. ISBN: 0 419 22990 6.

344 Williams, Ackermann and Eden contract was placed. This idea came to its full fruition with the crucial Downey Report [1,2] which fully defined the concept of a Project Definition (PD) study phase, gave it its strategic parameters and made detailed proposals on procedural changes. PD studies are now mandatory for large UK Ministry of Defence (MOD) projects. However, problems continued because of the high-risk nature of defence development. The Downey work was therefore extended by the JordanfLee/Cawsey Report [3]. This endorsed the Downey procedures, established the PD phase as a risk-reduction phase, and also called for MOD resources for technical scrutiny of proposals, particularly assessing the degree of technical risk at each project phase [4]. Risk assessment now plays a vital role when MOD look at tenders [5]. Similar developments have occurred in the US.

2. The Project Risk Register Such risk assessments are usually based around a Project Risk Register (PRR). This is a document kept under configuration control, usually within a data-base containing a list of adverse events that might occur. It should be a list of binary ("0-1" or "flip-flop") events that will or will not occur, with a specific disbenefit to the project if they do; however, risks often need to be described by a distribution (e.g. X might be overweight but the extent might be anythmg from 0 to 10 tons). Schafer [6] defines two types of probability: aleatoric, relating to intrinsically uncertain situations (Latin alea, dice), and epistemic, relating to a measure of belief, or more generally to a lack of complete knowledge (see [7]; see also Ackoff and Emery [8], who discuss belief structures). The PRR must contain all of the important episternic risks, as it reflects the lack of knowledge at the start of the project and the gradual resolution of those uncertainties. The major aleatoric uncertainties should also be held in the PRR. The run-of-the-mill aleatoric uncertainties are taken as read, and only come in when risk analyses are carried out. Thus, the epistemic risk that a new type of casting proves unsuccessful should be in the PRR; the fact that time to cany out a known casting varies by +lo% (aleatoric uncertainty) will be taken into account in risk analyses, but need not be in the PRR unless it is likely to be an important project-success determinant whch will alter management actions. Four sets of details are given for each risk: Event. A description of the risk, its estimated likelihood of occurrence (often initially classified as "High", "Medium" and "Low", becoming more quantitative as the analyses proceed), and its "owner" (the body who will feel the effect of the risk and who is responsible for its removal or amelioration (not always the same). Impact. The project objective on which the risk impacts (time, cost or a performance measure), the estimated severity of its impact (again often initially classified as "High", "Medium" and "Low"), and the project items affected (PERT activities or Work Breakdown Structure (WBS) items). Actions. Both risk-reduction actions and contingency plans. Secondary risks (following these actions) are also recorded. Contractual. How the risk will be treated contractually, including the degree of risk transfer that can take place.

Cause mapping and scenarios 345 3. Use of the PRR

The PRR has two main roles. The first is that of a repository of a corpus of knowledge. In major projects, few project members have a good project overview. Indeed, many large projects are undertaken not by individual companies but by consortia, with for example, in a defence project, one company manufacturing the vehicle body, one the motive power and a third the weapons-set. Often engineers involved in one aspect of the manufacture will have a surprisingly hazy view of the issues involved in other aspects, and many of the major problems of recent defence projects stem from the interfaces between (inter) aspects rather than within (intra) them. So a formal repository of projectrisk knowledge is useful; indeed the risk manager rapidly comes to the position of being one of the few in the project with a good overview (although he is not "on the ground" monitoring events). The PRR has proved effective to a degree in this role, although the representation within the PRR strictly limits the knowledge that can be contained, and this will discussed further in this paper. At this point, many companies stop. They have created the PRR, and perhaps included it in their bid, but they see no other use for it, merely it is a contractual formality. This is particularly true for companies who are fulfilling an Invitation to Tender requirement by a client, but are otherwise simply erecting a facade of risk management with no substance behind it. Other companies take the PRR into its second and more substantive role. This is as the foundation for the analysis and management that flows from a knowledge of the risk. Williams [9] describes a whole structure of project risk analysis and management based on the PRR, as used in a major defence project, including: analyses of cost, time and technical risk (using also the standard project deterministic (and sometimes aleatoric) data-bases); risk reduction and contingency planning, and decision-making on the best use of resources for such planning; contract planning, both ensuring that all risks are allocated in the contract, and making decisions on the best level of risk transfer. However, all of the above is predicated on the assumption that risks in the PRR are independent (as well as all-inclusive). This former is nearly always not so - some risks will be directly implied by other risks (and indeed there might be whole cascades of implied risks), and some risks will be more subtly inter-connected (e.g. the risk of an unsuccessful engine development and that of an unsuccessful gearbox development might both depend on the risk of an inadequate definition phase). The impacts that some risks have might compound the impact of others - so the effect of two risks might be more than the sum of the two individual effects thus reflecting systemicity [lo]. Some inter-connections between risks might lead to feedback loops, either negative (so some risks are balanced out by reductions in others) or positive (leading to vicious circles [lo] (or occasionally virtuous circles where the concepts include actions bringing positive benefits)). In practice, of course, when carrying out a risk analysis these effects are (or should be!) taken into account - but in the past these have had to be researched as a separate exercise.

346

Williams, Ackermann and Eden

Thus the PRR is inadequate and needs to be taken fiuther, because it does not contain the inter-relationships between risks and the systematic structure within the rislts. This makes it firstly an inadequate tool for the capture and representation of risks, so that it does not fulfil its first role adequately and thus often fails to perform a useful function (and is seen as such). It also makes it inadequate for its second role, acting as the basis of analysis and decision making, because it lacks knowledge of the systemic relationships.

4. The case study and cause mapping. This paper arose fiom a major BOO (Build, Own and Operate) bid to MODin which a PRR had been assembled. The question posed by the client "now what do we do with it to get the most out of it?' . It was clear to the authors that there was systemicity within the Register, so it was felt that it might be useful to investigate the risks in the form of a cause map, specifically using special purpose software ("Decision Explorer" [Ill). Cause mapping typically follows fiom the use of cognitive mapping of the kind developed by Eden and colleagues [12,13], which structures the way in which humans construe and make sense of their experiences by developing maps consisting of elements ("constructs") joined by links showing relationships between elements. Cause mapping extends the idea by aggregating cognitive maps into a cause map which is amenable to analysis as if it were an influence diagram. Cause mapping was immediately applicable in this case as the initial constructs had already been defined in the PRR. These constructs were entered into Decision Explorer, and a manager guided through the concepts, discussing the inter-item relationships, causal effects and consequences of items. This facilitated uncovering of systemicity and also added value through increasing understanding by giving a holistic view; but it also led to a whole range of other benefits, either realised at this point or having potential for future usage, as described in the following section.

5

Benefits of cause mapping.

Four sets of benefits can be drawn fiom the use of cause mapping to represent a PRR. (i) Use of appropriate techniques and software The use of a cause mapping techniques by an experienced facilitator, aided by a software tool such as Decision Explorer, is a powerful means of drawing out laowledge of project risk fiom a manager. For example: it enhances clarity of thought as duplications, contradictions and inconsistencies are revealed or highlighted; it allows investigation of the interactions between risks; it helps to "spark off' new thoughts on risks and their relationships; it promotes analysis of the map, suggesting potential danger-spots; it helps to identify actions which can address more than one risk and hence find synergy.

Cause mapping and scenarios 347 The visual interactive nature of the software enhances these benefits as the relationships and structures can be visualised and their representation modified as the implications of the visualised structure are thought through. (ii) Group facilitation The use of risk-analysts to question and draw out risk-items is well-established; Bartlett [14] for example gathers sub-groups within a project team and questions them on risk; sometimes an analyst works with a top-level Risk Management Committee [15]. However, the use of a well-defined, methodologically sound facilitation process by a trained facilitator, particularly when using visualisation software as in (i): brings out interactions between the managers (productively managing social as well as content issues), helps to surface cultural differences, and helps different people to contribute different knowledge, thus giving rise to a richer set of knowledge (i.e. both deeper and a wider range) than that gathered from each individual separately, as ideas and questions are developed and extended. It also aids organisational learning [16,17] both within the project and also between projects, as a cause map can act as an aide memoire for later projects. (iii) Information contained. The resulting cause map has started to satisfy the inadequacy in the PRR as it now coiltains knowledge about systemicity, showing related items, causal effects, common-cause effects etc. (while the detailed information contained in the PRR is not lost, as mapping software has facilities to attach memo-fields to concepts). But in addition, the display functions in the software enable concepts to be shown in different colours and shapes, categorised for example by uncertainty-level, or impact-level (or some combined measure). Or, the dispersion of the risk can be explored by categorising risks for the different elements of the project visually, particularly between sections of the project where inter-section (or even intercompany where a consortium is involved) implications are not well-understood. This in itself can be a useful visual aid in seeing where the major risk lies - although we can't show the usefulness in this black and white paper! (Another possible classification could be by risk-transferability [9]). Indeed, it gives the ability to see both the "big picture" and the detail - the former providing an overview of the structure and the latter the various risks. It should be noted that, while PRRs have generally been only of the order of I00 or so items, cause maps can in fact be as large as 1000 items; perhaps the limiting factor on PRRs has been the difficulty of dealing with a larger degree of complexity; the use if cause-mapping allows the complexity to be managed rather than reduced and thus overcomes this restriction. (iv) Analysis. There are further benefits, that surprised the first author (an experienced risk analyst used to "hard" quantitative methods). These come from the powerful analysis capabilities of the Decision Explorer software, and include: identification of loops, which can help explicate project dynamics (this latter is particularly true of nested loops) [18];

348 Williams, Ackermann and Eden identification of "heads", concepts which have no out-going links: these should be critical project failure modes, otherwise there are still links not yet identified; identification of subsets of risks disconnected from (thus independent of) the remainder; exploration of chains of argument, thus illustrating knock-on effects; analysis of the effects that preventative and corrective actions might have on the whole project (and thus also identification of which have greatest benefits); ailalysis of boundaries between contractors or departments to explore the number or impact of cross-party risk relationships; analysis of the "busyness" of the risks: those which are "busy" (i.e. have many in- and'out- links) are elaborated more, suggesting either that more is known about them, or that they are considered more risky; but risks with low busyness need to be looked at also, in case they need to be elaborated more or researched; selecting high-risk items and exploring them shows areas of most concern. As the map is analysed in this qualitative fashion (and by further methods [19]), a greater understanding is gained of the nature of the risks and their systemicity. These analyses used only the pre-defined functions of Decision Explorer; the software is customisable, so further study might look at the tailored analysis possibilities, such as exploring busyness while analysing impact and probability Of course, the idea of transforming a pre-prepared register-style PRR into this map format suggests the use of cognitive mapping techniques to produce the PRR in the first place rather than simply mapping a register which might be faulty or may "bound" participants' vision. Recent developments of networked Group Decision Support Systems [20] have aimed at facilitation of drawing out and organising knowledge from a (perhaps heterogeneous) group of managers, and the most recent technological developments enable this process to be carried out without the managers being present either at the same place or even at the same time [21], making coverage more effective and efficient. Speaking from long experience, the first author has found that developing a PRR is a difficult, often methodologically suspect, process, as a risk analyst has to struggle with not only technical engineering issues but also corporate politics and issues of bias (managerial, expert and cognitive bias 1221). Clearly, well-developed Cognitive Mapping techniques for collecting a structured cause map can provide not only a more efficient process, but also make the output more complete as well as more consistent. This is because participants are encouraged to reason out the concepts and links and .justify statements. Thus conclusions are drawn in a more participative process, and insights emerge from the mapping process rather than by leaps of intuition. Furthermore, a PRR developed using these techniques will significantly enhance the on-going learning and understanding of the risks. The PRR map can be used during the project to continue to develop understanding, and to check the continued existence of the effects modelled (perhaps particularly useful in "State of the Art" projects, where there is a high level of unknowns at the start of the project). Cause mapping is carried out using "natural" language, so is understandable and accessible to all; the resulting model is therefore a useful repository for future PRRs and can be augmented or refined as time

Cause mapping and scenarios 349 elapses. Moreover, if there are multiple companies working on a project their input can be combined into the model, providing a useful device for enhancing communication on risk, an important requirement in such projects [23]. And of course communication is required with the project client, and the PRR map could be a useful device to help to manage dealings about risk with the client.

6. Planning for the future: scenarios

In the case study, the authors were provided with a PRR consisting of about 60 items. Exploration and rationalisation of these, working with one of the managers, resulted in an initial map consisting of about 50 concepts. Figure 1 shows the 25 key concepts (details have been changed for reasons of confidentiality, and the display style has been modified to suit black-and-white reproduction - in fact, the five oval concepts were coloured so as to stand out brightly). It can be seen that failure of the project was driven by five key concepts (the oval shapes), described in 0-1 or "flip-flop" terms. This is precisely the conditions under which scenario-generation techniques are appropriate. Eden and Ackermann [25] describe these techniques thus: "In the complex and turbulent environment of today, traditional forecasting methods, such as trend extrapolation and regression, are seen to be too dependent upon a projection of the past into the hture to be useful for anticipating changes. Similarly they suggest a single view of the future (albeit with attached uncertainties). ...... In contrast, scenario planning suggests a number of distinctly different alternative futures, each of which are possible. Scenarios focus 'less on predicting outcomes and more on understanding the forces that would eventually compel an outcome; less on figures and more on insight' (Wack [24]). They are more concerned with understanding the discontinuities in creating altemative futures by recognising that the structure of the environment may change.". These techniques look at the alternatives of "flip-flop" events. Thus, one Boolean event and its consequences are considered ("if this happens, then so what?')), then the consequences of its consequences, and so on. Splitting the events (i.e. looking at the "flip" and the "flop" separately) may also give rise to scenarios. Further consideration can be prompted by taking a number of events and building up a "story" in which events unfold about them. Using such techniques can reveal inconsistencies in assumptions, counter-intuitive results (sometimes surprising insights), and positive and negative feedback loops. As a trivial example, suppose the threat of an accident led to a call for less nuclear power stations, this might lead to more burning of oil and gas, more co2 produced, more weather problems, more likelihood of accidents similar to Piper Alpha, and a call for more nuclear power stations: a balancing negative loop. Real practical examples of the use of such techniques are discussed in [25]. Once an initial map has been produced, we can focus on our five scenario events and consider what would happen if each resulted (this may give rise to 10 or more interrelated scenarios). This will help to:

350 Williams, Ackermann and Eden explore what might happen: secondary and consequential risks, and the implications of risks in the map; highlight strategically important events; explore what management could do about the primary and consequential risks, thus enabling coherent contingency and risk-reduction planning (rather than planning for each risk in the PRR separately). test different options against possible future condition to consider different sets of actions and their implications (e.g. how robust are they?). As in cause mapping, the technique has particular value when used with a group of managers. It has been found to enhance learning and creativity (and highlights new options). It also gives a better appreciation of the overview, helping participants to spot significant events quickly. Thus rather than simply listing the risks (as in the PRR), or mapping them (as in cause-mapping, which enhanced the PRR), the use of scenario techniques not only enhances the benefits that cause-mapping brings, but also gives a basis for considering the planning against the risks, providing the basis for taking the knowledge learned and using it to improve the execution of the project (forming part of an iterative process). As it is used during the course of the project, it also assists in managing the environmental uncertainty and turbulence as management has thought through the consequences of changes and is prepared.

7,

Conclusion

The PRR as it is currently assembled is inadequate. While for some it is used as an (inadequate) analysis tool, for others it simply poses the question: "so what?" neither really capitalises on the potential. This paper has discussed the PRR's inability to capture laowledge about systemicity, and shown the extra benefits that can be gained when it is turned into a cause map and explored with appropriate software. Indeed the use of cognitive mapping techniques to produce a risk map in the first place is both more efficient and more effective than current rather haphazard methods. As well as gaining greater understanding of the risk structure, the use of scenario planning for the possible future exploration and facilitates coherent planning for the possible future scenario. We believe this should give a good foundation for risk evaluation.

Cause mapping and scenarios 351 References 1. Ministry of Technology (1969) Report of the Steering Group on Development Cost Estimating (The Downey Report). HMSO, London. 2. Bryson, Admiral L. (1982) Large scale project management Proceedings of the Institute of Electrical Engineers Vol 129A, pp. 625-633 3 Jordan, G., Lee, I. and Cawsey G. (1988) Learningfrom experience: a report on the arrangements for munagzng major projects in the Procurement Executive. Report to the Ministry of State for Defence Procurement. Ministry of Defence, London 4. Humphries, D.E. (1989) Risk Management in MOD, in Proceedings of a Conference ofproject Risk Analysis in the Aerospace Industry. 8th March 1989. Royal Aerospace, Society, London 5. Hull, J. K. (1990) Application of risk analysis techniques in proposal assessment International Journal of Project Management Vol. 8, No. 3, pp. 152-1 57. 6. Shafer, G. A. (1976) Mathematical Theory ofEvidence Princeton University Press, US. 7. Oakes, M. (1986) Statistical Inference: A Commentary for the Social and Behavroural Sciences Wiley. 8. Ackoff, R. and Emery, F. (1972) On PurposeJirlSystems.Tavistock, London. 9. Williams, T.M. (1994). Using the risk register to integrate risk management in project defmition international Journal of Project Management Vol 12, pp. 17-22. 10. Williams, T.M., Eden, C.L., Ackermann, F.R., and Tait, A. (1995). The effects of design changes and delays on project costs. Journal of the Operational Research Sociev Vol. 46, no. 7, pp. 809-818. 1 1. Decision Explorer is supplied by Banxia Software, Glasgow. It runs in the Windows environment 12. Eden, C., Sim, D. and Jones, S. (1979) Thinking in Organisations London: Macmillan 13. Eden, C. (1988) Cognitive mapping: a review European Journal of Operational Research. Vol. 36 No. 1 pgs 1-13. 14. Bartlett, I. and La Bouchardiere, D. (1994) Invest in a fm foundation to manage risk throughout a project. Proceedings of the INTERNET 12th World Congress on Project Management, Oslo, June 1994, Vol. 2, pg 187-196. 15. Williams, T.M. (1994) Managing risk in development and initial production. International Journal of Production Research Vol. 32, No. 7, pp. 1591-1597. 16. P.M.Senge (1990) Thefifh discipline: the art and practise of the learning organization Doubleday Currency, New York. 17. Morecroft, J.D.W. and Sterman, J.D. (Eds) (1992) Special issue: modelling for learning. European Journal of Operational Research Vol. 59, No. 1 18. Ackermann, F., Eden, C. and Williams, T. (1997) A persuasive approach to Delay and Disruption using "mixed methods". Interfaces Vol. 27, No. 2, pp 48-65. 19. Eden, C., Ackermann F. and Cropper S. (1992) The analysis of cause maps Journal of Management Studies vol29, pp. 309-324 20. Eden, C.L. and Ackermann, F.R. (1992) Strategy development and implementation - the role of a Group Decision Support System, in, R. Bostrom, R. Watson And S. K i e y (eds) Computer Augmented Teamwork - A Guided Tour, Van Nostrand Remhold, New York 2 1. Ackermann, F. (1996) Working with groups using groupware: electronic problem structuring and project management support for face to face and dispersed organisational groups. In: B.Glasson et a1 (eds) Information Systems and Technology in the International Ofice of the Future. Chapman and Hall, London. 22. Merkhover, M.W. (1987) Quantifying judgemental uncertainty: methodology, experiences and insights Institute of Electrical and Electronic Engineers Transactions in Systems, Man and Cybernetics Vol. 17, No. 5, pp. 741-752. 23. Williams, T.M. (1993). Risk Management Infrastructures International Journal of Project Management, Vol 11, pp. 5-10 24. Wack, P. (1985) Scenarios, uncharted waters ahead. Harvard Business Review, SeptIOct. 25. Eden, C. and Ackermann, F. (1998) The Journey ofstrategic Change Sage, Chichester. (forthcoming)

Focusing on risk response development and risk measures to be taken - can risk estimating even be skipped in an RM application? K.A. ARTTO Helsinki University of Technology, Finland

Abstract The paper discusses an approach to project risk management with a basic assumption that risks are affected by risk responses only. This might imply that finally only risk response execution is important, and risk estimation would not be necessary in atl risk management applications. Although risk management applications discussed in literature mostly tend to have an emphasis on the risk identification and risk estimating or quantification stages as necessary prerequisites to responses, empirical applications exist that almost ignore applying risk analysis. Thus, applications have features that cause a strong orientation to response planning and an action plan development without going via any specific risk analysis stage. Rationales and potential solutions for a tentative risk management approach is discussed where the major effort is directed to risk response development and risk response execution rather than to risk estimation. Keywords: Project management, risk management, risk analysis, identification, estimating, quantification, response planning, response execution, risk control project failures, risk knowledge base

1. Introduction A risk management (RM) approach is discussed where the major effort is directed to a risk response development and a risk response execution rather than to a risk estimation. An idea is presented that in some applications very insignificant - or in some cases even none - emphasis could be put to estimating the magnitude of risk. The traditional general sequence associated with risk management consists of identification, analysis, estimating, quantification, response planning, response execution Managing R i s b in Projects, edited by K. Kakonen and K.A. Artto. Published in 1997 by E & FN Spon, 2-6 Boundary Row, London SEl SHN, UK. ISBN: 0 419 22990 6 .

354 Artto

and risk control. When developing the approach and features of such an overall risk management system with the focus described above, it is necessary to understand rationales of implementing the system with remarkably less - if any - effort on analyzing, estimating, or quantifying risks. Understanding the response oriented approach requires understanding of risks and risk management in wider contexts. As our basic aim is a successful project management with larger profit for the company, it is necessary to adopt a viewpoint of discussing the role of risk management in context of an overall project management discipline.

-

2. What is RM the traditional perspective Risk management content is generally defined as stages or processes including risk identification, risk estimation - or quantification, risk response development, and risk control (see e.g. [I] and [ 2 ] ) .In this paper the terms risk estimation and quantification are used interchangeably. Some concrete areas of traditional RM tools are listed in the following to provide a somewhat deeper insight to what a project risk management can be considered to be in practice: team based analysis solutions for identifying and estimating risks checklists for identification stage risk identification, risk mapping according to various criteria, influence diagramming 'unfavourable events' analysis concepts for worst case scenarios and important strategic issues 'continuous impact ranges' and range estimates concept for a successful project management at operational level contract management applications; using contracts as risk management vehicles risk lists and response plans For more discussion about RM content, see also [3]. 3. Estimating risks

3.1.

Criticism concerning quantitative approaches

There is some criticism associated with employing quantitative risk estimates in empirical risk analysis applications. The criticism usually concerns either the difficulty of determining probabilities or magnitudes of risk impacts on a subjective basis, or deficiencies in the reliability of the risk estimates finally got as an end result of the quantification process. Both arguments criticizing risk estimation are justified. The following considerations are associated with the critisism. First, as far as the estimating difficulty aspect is concerned, to estimate probabilities is a difficult procedure. One solution for the problem could be to employ range estimates - e.g. three point estimates - which enable avoidance of directly expressing probabilities but, however, which still enable the of a probalistic interpretation of the estimates expressed. Second, as far as the reliability issue is concerned, an argument might be justified according to which

Response development and risk measures 355 accurate quantitative risk results are not necessarily the most important requirement for measuring the quality of a quantification process. Instead, as risk response planning and creating team work with risk reduction as a result might be the ultimate goals, the quantification process might be considered to serve as a communication vehicle for just support setting of the right direction in terms of risk responses. 3.2.

Estimating risks contributes to response planning

Despite the idea presented above that RM might in some cases even be skipped before planning responses, it is worth noting that quantitative approaches can be used indirectly for promoting communication, team work, and risk response planning among project personnel. Quantitative methods can be used for enabling team work and the use of people's and organization's experience and knowledge when planning risk management and risk responses. It is appropriate to list some advantages of risk quantification in the following that at least partly contribute to risk response planning and execution: a common means of enabling a change of opinions and communication about the situation and measures to be taken cost effects are considered. Sources of risk and reasons for cost effects are described significant problems and risks are highlighted requiring for responses additional in-depth analyses may be recognized to be indispensable quantitative information is provided to support decisions in: choosing between alternatives transferring risks by contracts setting cost targets and contingency probability distribution of total cost shows how likely it is to achieve the base estimate risk structure is described to show the main areas where control effort should be concentrated it is shown to the project personnel that there is a range of possible outcomes depending on the measures taken by them

4. Deriving risk responses from experience Risks are affected by risk responses only. This might imply that finally only risk response execution is important, and risk estimation would not be a necessary stage to be applied in all risk management applications. The discussion above refers to a principle that risk estimating as such could in some contexts be considered only an intermediate phase, the purpose of which is to determine appropriate responses. However, when the responses are related to determining appropriate quantitative contingency levels and e.g. to pricing decisions, the quantitative risk treatment cannot be dismissed out of hand. Otherwise, if quantification is only used to support risk response planning, there might be other appropriate solutions for response planning that perhaps enable to skip the quantification process and to move directly to response planning and execution. Such a solution could be e.g. the application of risk knowledge bases that do not

356 Artto comprise only the description of risks occurred or observed, to be used as check list items, but there might be suggestions about responses to be applied directly, whatever the exact magnitude of the risk. Such risk knowledge bases are used as organizational memories providing quidelines about measures to be taken. In this context, the discussion later in this paper of the learn of project failures is most relevant: Project failures as well as potential or observed unfavourable risk outcomes could be recorded into a database with suggestions of appropriate risk responses. And when relevant, risk responses can in some cases be directly applied without estimating the magnitude of the risk. When appropriate risk responses are based on experience in such a database derived also from previous or parallel projects, skipping of proper risk estimation procedure before determining the appropriate responses is made possible. A question is raised if in such a procedure response development is satisfactory enough with no more need to estimate risks before determining responses. Could such approaches be applied in the case of projects with totally new technology with uncertainty inherent.

5. The learn of project failures Studies on project failures can be seen as a remarkable contribution to project risk management. Several examples of project failures exist. In principle, to record unfavourable outcomes is rather straightforward because of the clear objective statements typical for projects and project oriented work. Basically, the failures may concern problems in achieving the basic and interrelated objectives of scopelperformance,time, or cost. Whereas the traceability of unfavourable events or their impacts in serial production processes may disappear in the net variation caused by various factors, projects will always have a clear start and end with clear traceability of achieving project objectives. Thus, in the world of projects there is objective information available associated with the achievement of project objectives of scopelperformance, time and cost. The knowledge accumulated from project failures or unfavourable events in projects can be used for creating an understanding of unfavourable outcomes, their reasons and responses required. The basic idea is to learn from experiences and to introduce experience-based solutions of how risks could be (or could have been) avoided. One new growing application area in the field of project risk management is development of risk knowledge bases serving as organizational memories. Risks as well as project failures and risk responses can be recorded in such a risk knowledge database for future use. Knowledge bases developed can be seen as sophisticated extensions to traditional risk check lists and questionnaires. The nature and magnitude of risks are application area or industry specific, and so is the case with the overall risk management concept and the risk responses accordingly. In the area of information technology and software projects, the Standish Group study [4] shows that in American companies: 31.3% of projects are cancelled before they get completed 52.7% of projects will cost 189% of their original estimates projects have only ca. 42% of the originally-proposed features and functions Reasons for such unfavourable project outcomes were:

Response development and risk measures 357 there is no clear definition about objectives or scope an incomplete or lacking follow-up and control no user involvement, no management support For discussion about software project risk management, see e.g. [5] [6] [7] and [8]. An extensive discussion about project failures by introducing project cases was provided already in the 80's by Kharbanda and Stallworthy [9]. A study concerning the major risk factors in construction projects was made by Artto [lo]. Recently, there has been a growing discussion about unfavourable project outcomes and how such outcomes could be avoided, see e.g. [ l 11 [12] [13] and [14]. Many studies about unfavourable project outcomes report project failures in the construction or.the traditional engineering areas. Software projects referred above are a new and growing field of application. Also change or re-engineering as well as research and development projects are relevant arenas for specific risk management procedures and applications. Problems and failures in change, or re-engineering, projects are specific to that project type. Success factors and problems in case of change projects - or factors causing project failures - are reported by Salminen et. al. [15] with an indirect implication for both risk management and overall project management focus areas. Sallklinen et. al. report the following major risks in change projects: top management support participation communication resources goal setting problem area specific skills

6. Widening project risk management perspective Construction and engineering industries perhaps have the longest experience in using a systematic project risk management methodology. The first empirical industrial applications were mainly used in context of investment projects in the energy field. The development of project-oriented working methods in organizations is a relevant issue in any industry. Today, there are new industries and project types, e.g. as environmental technology related projects is a growing field of risk management application, as well as projects in growing industries such as in telecommunications business. It is suggested above that in some contexts risk estimation could even be skipped and a more proactive and response planning oriented risk management could be applied. Responses could be based on experience and knowledge derived from previous projects. Such a response oriented and experience-based risk management without any specific analyses incorporated might slightly shift toward the other knowledge areas of project management. The phenomenon of widening the scope is explained in the following by taking change project management as a hypothetical example. Managing change or re-engineering as well as research and development projects are important new arenas for specific risk management procedures and applications. Risks associated with change projects were listed above. Communication is one specific risk

358 Artto item which is likely to affect success or failure of a change project. However, it might be found difficult or unfruitful to try to quantify potential risk impacts for the communication. Thus, the conclusion might be that we skip the generic stage of risk estimation. But it might be most appropriate to apply specific and concrete responses which by experience are known to reduce the communication risk. Taking the risk management perspective as a standpoint, we have come into applying essential responses for risk reduction for e.g. managing project communications better. Now we come to a question of what is risk management and what is project management? We have probably widened the scope of risk management and partly moved into the knowledge area usually known as communications management. Fig. 1 shows an illustration of the project management knowlegde areas according to PMBOK [I] with e.g. risk management and communications management areas included. Also recent documentation for the project management quality guideline [2] makes a distinction between risk related and communication related processes, see Fig. 2. We can conclude from the above discussion that the risk management goes across other project management knowledge areas or processes - including the communication area used above as an example. However, the definition of risk management in relation to project management in general is not clear, which might provide room for different definitions of the risk management content, depending on the empirical application.

Fig. 1 Project management knowledge areas (according to PMBOK [I])

Response development and risk measures 359

--

Strategic Process Interdependency Management Processes -

h>j,jpitlnildon andRo~eclPlan Owelopmat lnl-t~ln managema! Change a d Cmfipuradon Mana~enrnt

-

Closure

-

Resource Related Processes -

Personnel Related Processes -

-

Scope Related Pmesses -

-

Coneepl Developmea Scope tkvelopmenl and Control Anwily Defirubon Anivily C o n M

Time Related Processes -

-

-

Aawily Dependency Plamhg Dura6on Emmanon Schedule Development ScheddeCmtml

Cost Related Processes -

-

Cmt E d m u n n Budgebng Cmlcunml

Rcwurce Planning Resmrce Conml

-

Organilaocn Slmmre Defirution Scdf Alloation ROcess Team Developme*

Communication Related Operational Processes -

-

-

Commurucdon Planrunp Informadon Managemen1 CnmmurucmonComol

Risk Related Processes -

-

Risk ldentif~caaon Risk E~bmatlon k s k Respmse Developmenr Risk Contml

Purchasing Related Processes -

-

Purchamng Planntng andCDntml RequirementsD~.umntanon SukonrraclorEvaluahon Suboncacting C m m t Control

Fig. 2 Project management processes [2]

7. Conclusion Rationales and potential solutions for a tentative risk management approach is discussed where the major effort is directed to risk response development and risk response execution rather than to risk estimation. When developing the approach and features of such an overall risk management system with the focus described above, it is necessary to understand rationales of implementing the system with remarkably less - if any - effort on analyzing, estimating, or quantifying risks. Understanding the response oriented approach requires an understanding of risks and risk management in wider contexts. There is some criticism associated with employing quantitative risk estimates in empirical risk analysis applications. However, it is worth noting that quantitative approaches can be indirectly used for promoting communication, team work, and risk response planning among the project personnel. Risks are affected by risk responses only. There might be other appropriate solutions for response planning that perhaps enable us to skip the quantification process and directly to move to response planning and execution. Such a solution could be e.g. application of risk knowledge bases that comprise risks and suggestions about responses to be applied directly, whatever the exact magnitude of the risk might be. Such risk knowledge bases are used as organizational memories providing quidelines for measures to be taken. In this context, the discussion later in this paper of the learn of project failures is most relevant.

360 Artto Studies on project failures can be regarded as a remarkable contribution to the project risk management. The knowledge accumulated from project failures or unfavourable events in projects can be used for creating an understanding of unfavourable outcomes, their reasons and responses required. The basic idea is to learn from experiences and introduce experience-based solutions of how risks could be avoided. A hypothetical example was provided according to which it might be comsidered difficult or unfruitful to try to quantify potential risk impacts for the communication in a change project. Thus, it might be appropriate that we skip risk estimation and move directly to response planning. One conclusion was that risk management goes across other project management knowledge areas or processes. The definition of risk management in relation to project management in general is not clear; thus, risk management might take different definitions depending on the purpose and empirical application area.

8. References PMBOK, 1996. A Guide to the Project Management Body of Knowledge, Project Management Institute Standards Committee, Project Management Institute PMI, Upper Darby, PA, USA (and PMBOK Exposure Draft - August 1994) I S 0 10006, 1996. Guidelines to Quality in Project Management, ISOIDIS 10006, Document 176-2-8-N160. Artto K. A., 1997. Fifteen years of Project Risk Management Applications Where are we going? in KWonen K., Artto K. A. (eds.): Managing Risks in Projects, E & FN Spon, London, United Kingdom Standish Group, 1995. Chaos - Study on Software Project Failures, http://www.standishgroup.corn/chaos.html Down A., Coleman M., Absolon P., 1994. Risk Manangement for Software Projects, McGraw-Hill, London, United Kingdom Boehm B. W., DeMarco T, 1997. Software Risk Management, IEEE Software, Vol. 14., NO. 3., 1997, pp. 17-19 Williams R. C., Walker J. A., Dorofee A. J., 1997. Putting Risk Management into Practice, IEEE Software, Vol. 14., No. 3., 1997, pp. 75-82 Conrow E. H., Shishido P. S., 1997. Implementing Risk Management on Software Intensive Projects, IEEE Software, Vol. 14., No. 3., 1997, pp. 83-89 Kharbanda 0 . P., Stallworthy E. A. , 1983. How to Learn from Project Disasters -True-life Stories with a Moral for Management, Gower Publishing Company, Hampshire, United Kingdom Artto, K. A., 1986. Major Risk Factors in Construction Projects, Ninth International Cost Engineering Congress 1986, NACPE. International Cost Engineering Council, Oslo Kharbanda 0 . P., Pinto J. K. , 1996. What Made Gertie Gallop? Lessons from Project Failures, Van Nostrand Reinhold, USA, New York, USA ~ W i j n e nK., 1997. How to Learn from Project Failures, Projektitoiminta (Finnish Project Management Journal), Vol. XX, No. 1, pp. 17-19, in Finnish

Response development and risk measures 361 13. 14. 15.

Artto, K. A., 1997. The Anatomy of Project Risk Management, Projektitoiminta (Finnish Project Management Journal), Vol. XX, No. 2, in Finnish Pinto J. K., 1997. Twelve Ways to Get the Least from Yourself and Your Project, PM Network, Vol. 11, No. 5, pp. 29-31 Salminen A. K., Lanning H. C., Roiha M. J., 1997. Risks in Change Project Management. in Kiihkonen K., Artto K. A. (eds.): Managing Risks in Projects, E & FN Spon, London, United Kingdom

Deciding which risks are important S.C. WARD School of Management, University of Southampton, Southampton, UK

Abstract A common problem in project risk management processes is the need to determine the relative significance of different sources of risk so as to guide subsequent risk management effort and ensure it remains cost effective. A common approach is to use some form of 'probability impact grid' to identify sources of risk which will receive the most attention. This paper examines the shortcomings of such techniques in identifying important sources of risk and considers the information needed for a proper assessment of importance. In particular it is desirable to distinguish between the size of impacts and probability of impacts occurring, the range of feasible responses, and the time available for responses. The paper offers some practical suggestions for dealing with this problem. Key words: Probability-impact grids, major risks, responses 1 Introduction For many busy managers with problems on all sides, perhaps one of the hardest tasks is deciding which problems to work on first. In a Harvard Business Review article entitled "How senior managers think", Isenberg quotes one manager's description of this difficulty [I]:

"I have to sort through so many issues at once. There are ten times too many. I use a number of defence mechanisms to deal with this overload - I use delaying actions, I deny the existence of problems, or Iput problems in a mental queue of sorts. This is an uncomfortable process for me."

Managing Risk in Projects, edited by K. Kahktinen and K.A. Artto. Published in 1997 by E & FN Spon, 2-6 Boundary Row, London SEl SHN, UK. ISBN: 0 419 22990 6.

Evaluating risks 363 Deciding the relative importance of problems might well be regarded as a key test of managerial competence. Certainly it is reasonable to suppose that a manager is judged not by the number of problems he or she solves, but by the impact of solutions on the performance of the manager's organisation. The project risk manager's situation is no different. With limited time and resources, any effort expended on analysis and management of project risks must be cost effective. Faced with a potentially large number of sources of risk, the risk manager needs to know which risk to concentrate on, both during the initial analysis of risks and subsequently in actively managing risks as the associated project progresses. A concern for cost-effectiveness has encouraged a tendency towards what might be termed 'quick and dirty' approaches to assessing and managing project risks. One common approach involves the use of a risk register. Typically the risk register surnrnarises identified risks in tabular form with other pertinent information such as size of impact, proposed responses, and the individuals responsible. The purpose of the risk register is to help the project team monitor and manage project risks on a regular basis throughout the project. A tabular form of risk register has the attraction of simplicity and convenience, but has a number of shortcomings, particularly if unsupported by other backup documentation. These shortcomings include:

1. individual risk drivers may not be described in sufficient detail to avoid ambiguity and misunderstandings about what risk is being described; 2 . important inter-dependencies between risks are not readily highlighted; 3. a table of risk drivers, particularly a long one, provides limited guidance on the relative importance of individual risk drivers. These three shortcomings are linked in that shortcoming 1 contributes to shortcoming 2, and shortcoming 2 in turn, contributes to shortcoming 3. Most tabular risk registers provide some information which is intended to indicate something about the relative size or importance of individual risks. However, this information is usually rather limited and can be of little value at best, and very misleading at worst.

2 Probability impact grids

2.1 Risk ratings A very common approach to ranking risks involves the use of probability impact grids. Typically such grids require individual sources of risk to be characterised as risk events with a probability of occurrence and a degree of impact, which then allows each risk to be characterised by a single 'risk rating'. The higher the risk rating the more important the risk, in some sense. Sometimes probabilities and impacts are assessed qualitatively using labels like "High" (H), "Medium" (M) or "Low" (L). Figure 1 illustrates such a grid where cells labelled 3, 2 and 1 indicate risks with the highest, intermediate and lowest importance respectively.

364 Ward

Probability

Impact

Low

Medium

High

1

1

2

Medium

1

2

3

High

2

3

3

Fig. 1 Qualitative scoring in a probability impact grid Sometimes numerical scales are used to 'score' each risk in terms of impact and probability of occurrence. Figure 2 gives an example of such a grid. With this format, each cell has an associated risk rating which is calculated as the product of the two scores: Risk rating = (Impact score) x (Probability score) This simple formula is appealing because it takes a similar form to the calculation of unconditional expected impact = (impact x probability). A crude way to order sources of cost risk in descending order of importance is to place them in descending order of expected cost as determined by: Expected cost = (expected impact) x (probability of occurrence) However, the use of numerical scores is essentially equivalent to using qualitative labels. Any calculations involving these scores will be entirely spurious and the product (impact score x probability score) cannot be interpreted as a meaningful calculation of expected cost. For example, in Figure 2 it would be inappropriate to conclude that a risk rated 100 is more than one hundred times more important than a risk rated 1, or twice as important as a risk rated 50 etc.. Clearly, for rating purposes there is no need to calculate ratings using an explicit formula which is a function of impact and probability scores, or even to use a numerical rating scale at all. Probability

Impact

Fig. 2 Numerical scoring in a probability impact grid

Evaluating risks 365

Another fundamental problem with scoring schema is that they are open to different interpretations by different people. Requiring a consistent approach implies a need to set clear guidelines for scoring impacts and probabilities of occurrence to facilitate greater consistency in allocating scores. The perceptions incorporated in different scores should be apparent to all the personnel that make use of this information. This is particularly important if personnel change on a project and if perceptions and experiences on different projects are to be compared. 2.2 Quantified categories A logical improvement on qualitative scores is to define different levels of impact and probability of occurrence in terms of numerical ranges. For example, assuming cost risk is the concern, a three-way classification convention might take the following form:

"Low" impact: "Medium" impact: "High" impact:

EOk < Impact < E10k E10k < Impact < E100k E100k < Impact

Although only illustrative, this example shows that any such attempt to define categories needs some thought. In particular, definition of categories might reasonably be influenced by past experience of impacts, future targets for risk control, size and the nature of projects the classification is to be applied to. This example also highlights the question of how impact from a given risk is to be described in order to allocate it to a given classification. In reality impact associated with a particular risk can take a range of values, so unless the range falls wholly into one of the chosen classification ranges, there is a question of which range to allocate the impact. The typical approach is to ignore the possibility of a range of impacts and think (implicitly) in terms of a single level of impact. If impact is to be assessed in terms of cost or time as a single figure, then the expected (mean) value of the impact should be estimated rather than the most likely, or other value, and this expected value used to classify impact on the appropriate scale. Clearly this process involves discarding potentially useful information about the spread of possible impacts. Similar comments apply to classifying probabilities of a risk occurring. For example, a three-way classification would be defined in terms of specified ranges of probabilities corresponding to "high", "medium" and "low" probability of occurrence. Figure 3 illustrates a grid which uses four well defined ranges for impact in terms of expected cost (given that the risk occurs), and three well defined ranges for the probability the risk occurs. (In general the number of rows and columns defined is, of course, arbitrary and there is no reason why the number of ranges for impact and probability have to be the same.) Each cell shows the implied range of unconditional expected cost for each pair of impact and probability categories. It is immediately obvious that the ranges in different cells overlap substantially. This will be the case in general, although the precise extent of overlaps will depend on the ranges chosen to categorise probability and impact.

366 Ward Probability

< 10%

10% - 20%

20% - 100%

(072)

@,lo)

0 - 10

Impact (Ek)

10 - 100

(0,lO)

(1,20)

(2.5,lOO)

100 - 500

(0,50)

(10,100)

(20,500)

O