100,99 €
Mehr erfahren.
- Herausgeber: John Wiley & Sons
- Kategorie: Fachliteratur
- Sprache: Englisch
Managing the Unknown offers a new way of looking at the problem of managing projects in novel and unknown environments. From Europe's leading business school, this book shows how to manage two fundamental approaches that, in combination, offer the possibility of coping with unforeseen influences that inevitably arise in novel projects: * Trial-and-Error Learning allows for redefining the plan and the project as the project unfolds * Selectionism pursues multiple, independent trials in order to pick the best one at the end Managing the Unknown offers expert guidelines to the specific project mindsets, infrastructures, and management methods required to use these project management approaches and achieve success in spite of unforeseen obstacles. This book equips readers with: * Causal explanations of why unforeseeable factors in novel projects make traditional project planning and project risk management insufficient * Directly applicable management tools that help managers to guide novel and high-uncertainty projects * Real-world case studies of both successful and unsuccessful approaches to managing high uncertainty in novel projects
Sie lesen das E-Book in den Legimi-Apps auf:
Seitenzahl: 539
Veröffentlichungsjahr: 2011
Ähnliche
Table of Contents
Cover
Contents
Title Page
Copyright
Foreword
Introduction
Project Management and Project Risk Management (PRM)
Operational Risk Management and PRM
Contribution and Plan of the Book
PART I: A New Look at Project Risk Management
1 PRM Best Practice: The PCNet Project
1.1 Background
1.2 Risk Identification
1.3 Risk Assessment and Prioritization
1.4 Risk Monitoring and Management
1.5 Managing Residual Risks
The Risk Management Office
1.6 Learning and Sharing Across Projects
1.7 PRM as a Method and as a Mind-Set
1.8 Summary and Conclusion
2 The Limits of Established PRM: The Circored Project
2.1 Early Design of the Circored Technology
2.2 Joint Venture and Business Plan
2.3 The Construction Phase, May 1996–April 1999
2.4 The Startup Phase, May 1999–Summer 2000
2.5 A Management and Design Change
2.6 Market Turmoil
2.7 The Limit of PRM: Unforeseeable Uncertainty
2.8 Summary and Conclusion
3 A Broader Look at Project Risk Management
3.1 Understanding the Fundamental Types of Uncertainty
3.2 Foreseeable Uncertainty and Residual Risk
3.3 Complexity
3.4 Unknown Unknowns
3.5 Expanding the Toolbox: Fundamental Approaches to Project Uncertainty
PART II: Managing the Unknown
4 Diagnosing Complexity and Uncertainty
4.1 Diagnosing the Unforeseeable at Escend Technologies
4.2 Diagnosing Complexity
4.3 A Process for Diagnosing Uncertainty and Complexity at the Outset
4.4 Evolve the Complexity and Uncertainty Profile
4.5 Conclusion
5 Learning in Projects
5.1 Learning at Escend Technologies
5.2 Types of Project Learning
5.3 Back to Escend: Drawing the Lessons
6 Multiple Parallel Trials: Selectionism
6.1 Selectionism at Option International
6.2 Explaining the Principles of Selectionism
6.3 What Makes Selectionism Work?
6.4 Conclusion
7 Selectionism and Learning in Projects
7.1 Selectionism and Learning at Molecular Diagnostics
7.2 Choosing and Combining Selectionism and Learning
7.3 Reexamining the Circored Project with This New Framework
7.4 Conclusion
PART III: Putting Selectionism and Learning into Practice
8 Establishing the Project Mind-Set
8.1 Open-Mindedness: Expecting the Unexpected
8.2 Project Vision, or a “Map” of Unknown Terrain
8.3 Robust-Mindedness: The Ability to Cope
8.4 Summary: How to Foster an Unk Unk Mind-Set
9 Putting the Infrastructure in Place: Management Systems
9.1 Managerial Systems in Project Risk Management
9.2 The Management Systems of Learning (Sub) Projects
9.3 The Management Systems of Selectionist (Sub) Projects
9.4 Integrating Learning and Selectionist Pieces into the Overall Project
10 Managing Unk Unks with Partners
10.1 The Dangers of Project Contracts
10.2 A Problem-Solving Process in the Face of Unk Unks
10.3 Summary: A Process of Partner Relationship Management
11 Managing Stakeholders
11.1 The Project of the Flying Car
11.2 How Informal Stakeholders May Hold Up a Project
11.3 Lessons: Map the Decision Influence Levels to Sell the Project
PART IV: Managing the Unknown: The Role of Senior Management
12 The Role of Senior Management in Novel Projects
12.1 Choosing the Project Scope
12.2 Building Organizational Capabilities
12.3 Sponsoring Novel Projects
12.4 Conclusion
References
Index
End User License Agreement
List of Illustrations
Chapter 01: PRM Best Practice: The PCNet Project
Figure 1.1 The PCNet project
Figure 1.2 The PCNet project key milestones
Figure 1.3 HR risk list in the PCNet project
Figure 1.4 The PCNet project outcome distribution
Figure 1.5 The Metal Resources Co. IT merger project prioritization
Figure 1.6 Aggregate deployment progress monitoring tool
Figure 1.7 PRM process enhanced by residual risk management
Figure 1.8 Communication document for operating company compliance
Figure 1.9 The critical path versus PRM mind-sets
Chapter 02: The Limits of Established PRM: The Circored Project
Figure 2.1 Simplified Circored process diagram
Figure 2.2 CAL risk lists and business scenarios
Figure 2.3 The CAL Circored facility in Point Lisas, Trinidad
Figure 2.4 Project timeline and delays
Chapter 03: A Broader Look at Project Risk Management
Figure 3.1 The fundamental sources of project risk
Figure 3.2 A network flow diagram of a project schedule
Figure 3.3 Histograms, or distributions, of the project duration
Figure 3.4 A project plan with project buffer
Figure 3.5 A network flow diagram of a project schedule with rework loop
Figure 3.6 Project durations with and without rework loop
Figure 3.7 Decision tree of a central nervous system drug
5
Figure 3.8 Generic risk list (template) of a pharmaceutical development project
Figure 3.9 The control-and-fast-response mind-set
Figure 3.10 Contract types and risk allocation among the parties
Figure 3.11 The eight key business levers in the contract
Figure 3.12 Three fundamental PRM approaches in face of uncertainty
Figure 3.13 A framework of the sources of uncertainty in project management
Chapter 04: Diagnosing Complexity and Uncertainty
Figure 4.1 Example of a design structure matrix, DSM
Figure 4.2 Interactions in three domains in a system development project
Figure 4.3 A project diagnosis process
Figure 4.4 Uncertainty and complexity profiles: Prioritization tool
Figure 4.5 Evolution of complexity and uncertainty profile
Chapter 05: Learning in Projects
Figure 5.1 Escend Technologies’ initial view of the extended sales organization
Figure 5.2 The evolution of Escend’s business model before 2003
Figure 5.3 Escend’s description of the industry network, spring 2004
Figure 5.4 Trial-and-error learning as a Plan-Do-Check-Act cycle
Figure 5.5 The trade-off between variation (learning potential) and progress
Figure 5.6 An experimental learning process
Chapter 06: Multiple Parallel Trials: Selectionism
Figure 6.1 Selectionist searches in configuration parameter space
Chapter 07: Selectionism and Learning in Projects
Figure 7.1 Four canonical examples of learning and selectionism
Figure 7.2 Learning and selectionism in simple and complex landscapes
Figure 7.3 Selectionism with unk unks in a simple and a complex project
Figure 7.4 Value comparison of learning and selectionism with complexity and relative cost differences
Figure 7.5 Task dependency matrices for integrated, sequential, and modular project architectures
Figure 7.6 Possible learning and selectionism in the Circored subprojects
Chapter 08: Establishing the Project Mind-Set
Figure 8.1 A map for a rapid technologies development project
Chapter 09: Putting the Infrastructure in Place: Management Systems
Figure 9.1 Plan the experimental cycle
Figure 9.2 Monitoring system assuming foreseeable uncertainty
Figure 9.3 Organization and fast execution of the experimental cycle
Figure 9.4 High-level “plan” for the turnaround project at Escend Technologies
Figure 9.5 Formats of preliminary information
Chapter 10: Managing Unk Unks with Partners
Figure 10.1 Tunnel architecture
Figure 10.2 Tunnel depth profile
7
Figure 10.3 Overall project schedule and planning
Figure 10.4 The actors in the Eurotunnel project and their interests
Figure 10.5 Path difference between successful and failed projects
41
Figure 10.6 Steps of partner management in novel projects
Chapter 11: Managing Stakeholders
Figure 11.1 The discontinued selectionist trials: FlyBike and SkyScooter
2
Figure 11.2 The DuoSport prototype
3
Figure 11.3 The final verdict on the DuoSport.
Figure 11.4 Four levels of influences on a novel project
Figure 11.5 Network connectivity of the Vol de Nuit team
Part I: A New Look at Project Risk Management
Figure I.1 Conceptual steps of the PRM process
List of Tables
Chapter 03: A Broader Look at Project Risk Management
Table 3.1: Definition of the Key Drivers of a Contract Business Deal
Chapter 04: Diagnosing Complexity and Uncertainty
Table 4.1: Problem Areas with Uncertainty Type
Table 4.2: Examples of Interaction Types in Three Domains
Chapter 05: Learning in Projects
Table 5.1: Project Stages of a New Venture Project Reaching IPO
Table 5.2: Probing Questions to Query Assumptions
Chapter 09: Putting the Infrastructure in Place: Management Systems
Table 9.1: Infrastructure for Planned, Learning, and Selectionist Projects
Table 9.2: Monitoring Table for Areas with Potential Unk Unks at Escend, Status October 2003
Table 9.3: Process Versus Upward Incentives in Projects with Unk Unks
Guide
Cover
Contents
Start Reading
Pages
iii
iv
xi
xii
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
261
262
263
264
265
266
267
268
269
270
271
273
274
275
276
277
278
279
280
281
282
283
285
286
287
288
289
290
291
292
Managing the Unknown
A New Approach to Managing High Uncertainty and Risk in Projects
Christoph H. Loch
Arnoud De Meyer
Michael T. Pich
Copyright © 2006 by John Wiley & Sons, Inc. All rights reserved
Published by John Wiley & Sons, Inc., Hoboken, New Jersey
Published simultaneously in Canada
No part of this publication may be reproduced, stored in a retrieval system, or transmitted in any form or by any means, electronic, mechanical, photocopying, recording, scanning, or otherwise, except as permitted under Section 107 or 108 of the 1976 United States Copyright Act, without either the prior written permission of the Publisher, or authorization through payment of the appropriate per-copy fee to the Copyright Clearance Center, 222 Rosewood Drive, Danvers, MA 01923, (978) 750-8400, fax (978) 646-8600, or on the web at www.copyright.com. Requests to the Publisher for permission should be addressed to the Permissions Department, John Wiley & Sons, Inc., 111 River Street, Hoboken, NJ 07030, (201) 748-6011, fax (201) 748-6008, or online at http://www.wiley.com/go/permissions.
Limit of Liability/Disclaimer of Warranty: While the publisher and the author have used their best efforts in preparing this book, they make no representations or warranties with respect to the accuracy or completeness of the contents of this book and specifically disclaim any implied warranties of merchantability or fitness for a particular purpose. No warranty may be created or extended by sales representatives or written sales materials. The advice and strategies contained herein may not be suitable for your situation. You should consult with a professional where appropriate. Neither the publisher nor the author shall be liable for any loss of profit or any other commercial damages, including but not limited to special, incidental, consequential, or other damages.
For general information about our other products and services, please contact our Customer Care Department within the United States at (800) 762-2974, outside the United States at (317) 572-3993 or fax (317) 572-4002.
Wiley also publishes its books in a variety of electronic formats. Some content that appears in print may not be available in electronic books. For more information about Wiley products, visit our web site at www.wiley.com.
Library of Congress Cataloging-in-Publication Data:
Loch, C. (Christoph)
Managing the unknown: a new approach to managing high uncertainty and
risk in projects / Christoph H. Loch, Arnoud De Meyer, Michael T. Pich.
p. cm.
Includes bibliographical references and index.
ISBN-10: 0-471-69305-7 (cloth)
ISBN-13: 978-0-471-69305-5 (cloth)
ISBN-13: 978-1-118-27673-0 (epdf)
ISBN-13: 978-1-118-27682-2 (epub)
ISBN-13: 978-1-118-27668-6 (mobi)
1. Project management. 2. Risk management. I. Meyer, Arnoud De.
II. Pich, Michael T. III. Title.
HD69.P75L62 2006
658.4’04—dc22
2005019102
Foreword
Project management, as an important part of our disciplinary background, has been close to our interests for a long time and has been part of our professional experience as consultants, program directors, and, in one case, dean at INSEAD. The research on which this book is based began in 1996, when we became interested in project risk management and, in particular, methods that might help project managers to deal with novel projects.
We first explored real options and contingent decision-making in projects, a “new” method from the finance discipline that was widely discussed in the mid-1990s. This turned out to be a dead end, as the powerful analytical methods from finance did not sufficiently carry over to project management, an environment where much less information is available than in financial markets. In project management, these methods were wonderful in theory but required too many assumptions to apply in practice.
As we worked with project managers and wrote cases about the projects we analyzed, we began to realize that our concerns with managing novel projects were not so much with the existing project risk management (PRM) methods per se—as these methods were quite well developed over many years—but with the very concept of risk itself. We felt that the concept of risk, as discussed in PRM, was not entirely appropriate for novel projects. The first practical lessons we learned from these project managers were summarized in a Sloan Management Review paper in 2001. But we also understood that we needed a conceptual framework to help us understand how seasoned project managers of novel projects dealt with uncertainty and risk, and how a project team might in principle deal with it.
We realized that a key reason many projects fail is because organizations do not recognize the fundamental difference between project novelty and project risk. This thinking led to a publication in Management Science (2002), in which we examined the key difference between project risk and project novelty. We defined two critical characteristics of novel projects: unforeseeable uncertainty and complexity. We also identified two fundamental approaches that were, in principle, possible in the presence of unforeseeable uncertainty and complexity. We referred to these new approaches as selectionism and learning.
These theoretical considerations gave us a “roadmap,” a lens through which we could gather evidence and examine the projects with which we worked. We discovered that, while selectionism and learning had, of course, been discussed before, a complete approach to managing novel projects was missing. How should organizations and project management teams approach novel projects? How do they diagnose the level of project novelty, how do they build the organizational capabilities to deal with novel projects, and finally, how do they go about managing these projects?
This, then, is the new thinking and the contribution of this book. Selectionism and learning can be viewed as a powerful arsenal of weapons in the face of high novelty and unforeseeable uncertainty in projects, an arsenal in addition to established project risk management methods. The book explores the nature of unforeseeable uncertainty, of “unk unks” and explains the concept of selectionism and learning. Then, most of the book tries to develop operational and actionable methods and tools that managers can use to evaluate selectionism and learning and to put them in practice. This book may be interesting for academics, but we are addressing an audience of practicing managers, and we hope they find it useful.
We are indebted to the many project managers with whom we have worked and from whom we have learned—in our case research and in our management seminars at INSEAD, where the participants learn from us, but where we also learn invaluable insights from them.
We also thank our colleagues, notably Christian Terwiesch and Svenja Sommer, the collaboration with whom has helped us think through many issues. We are indebted to Jean Cropper, who helped us turn our clumsy language into readable English.
If this book makes a small contribution to the project management profession, we feel proud, and the tremendous effort was worthwhile.
Fontainebleau and Singapore, May 2005
Christoph LochArnoud De MeyerMichael T. Pich
Introduction
Project Management and Project Risk Management (PRM)
Nearly all managers engage in project management. The rapid change in the competitive climate, the internationalization of the economic environment, and the rise in customer power have rendered business activities less repetitive. Today, all managerial tasks contain elements of project management. In older textbooks, project management was often identified in the context of industrial activities, such as construction, product development, or the introduction of new technologies. The most important challenge in these projects was often to handle myriad tasks and relationships, and the focus of project management methods was on complexity. But today’s projects are much broader, encompassing, among other activities, internal or external consulting, launching market campaigns, developing software, or implementing mergers or acquisitions. These new projects are often less complex than the traditional ones, but they also often break new ground and are therefore confronted with more uncertainty. This book is about highly novel projects that have to cope with a high level of uncertainty.
What is a project? A project can be defined as a sequence of activities undertaken to accomplish a temporary endeavor (with a defined completion date) to create a unique product or service.1 Projects represent an organizational tool to respond to risks. They are made up of temporary structures, they use flexible methods, and they are dismantled after the work is done. Each project is unique in some respect: It can be a new project, meaning that the tasks have not been done before, or there can be spatial separation, indicating that the resources are assembled at a separate place. Each project is thus managed slightly differently from other projects or ongoing repetitive processes. In short, projects are temporary structures and management methods that allow companies to be flexible and to respond to risks.
The ability of an organization to use temporary structures to flexibly respond to risks has gained in relevance in many business contexts. While projects and project management methods have historically been relegated to the R&D, infrastructure, IT, and defense-related industries, projects and the language of projects have now become ubiquitous in a wide variety of industries, organizations, and functional areas. Projects are now seen as an important strategy to manage change in organizations. This reflects an increase in uncertainty and velocity in many industries, which has prompted prediction in the popular press that “the old organizations and career tracks will be obliterated in the future.”2
This has brought about a critical look at projects, starting with empirical evidence of the prevalence of project failure. The Project Management Institute (PMI) states that over 70 percent of projects in large organizations fail to meet their stated objectives. A study of large engineering projects by Miller and Lessard found that only 45 percent of these projects met most of their stated objectives, while 19 percent met only a subset of their objectives, 16 percent had to be significantly restructured, and fully 20 percent were abandoned. The picture is no better for startup venture projects. Before the 1997–2001 bubble, nearly 50 percent of the value created by venture capital firms was a result of the 6.8 percent of their investments that actually achieved a return of 10 times or more. Battery Ventures reported that of 153 companies it backed, 25 went public, while 43 were acquired—and 25 companies went out of business.3
Many reasons are given for this rather poor record of project success, ranging from technical or market uncertainty, poor leadership, and multiple stakeholders with differing interests. Too often, these failures to meet stated project objectives are interpreted by organizations as failures on the part of the project management team, negatively affecting promotions and bonuses. While each of these reasons may be present in various projects, we will argue that the main reason for project failure is that organizations do not recognize the fundamental difference between project novelty and project risk.
An understanding of project risk and project risk management (PRM) has been around for a very long time. Project risk management has become an integral part of project management and is an established, formalized, and widely used project management method. This is reflected by a steady stream of technical books on the topic.4
Project risk is often defined as the product of the probability of an event’s occurrence and the extent of its impact. In other words, what is the probability that an event will occur, and what is the extent of impact of this event on the project, as planned, if it does occur? PRM techniques have thus been developed to help organizations to identify possible uncertain events, assess their potential impact (positive or negative) on the project plan, prioritize these events for action, and develop preventive, mitigating, and contingent actions in response to these foreseen events. PRM even goes so far as to foresee that not all events can, or will, be predicted, and that organizations must be prepared to quickly improvise a response to this “residual risk” to get the project back on track. Issues of project leadership, stakeholder management, and supplier relationships are all dealt with in an attempt to create a project infrastructure and environment that can flexibly respond to events in order to bring the project back under control, should events, both foreseen and unforeseen, arise.
But project novelty is not the same as project risk, and novel projects pose fundamentally different challenges than do risky projects. Novel projects, by definition, cannot be planned. In novel projects, there are either too many “unknown unknowns” (unk unks) or there is too much complexity, or both. There is no “real” project plan around which to apply standard PRM techniques. Contingency planning makes little sense, as the major risks are unknown. In this context, complexity means that even if events could be foreseen, the interaction of events is so complex that contingency plans would be impossible to draw up. Novel projects pose unforeseeable uncertainty and are complex in nature, and this is necessarily so because only such projects offer sustainable rents. Simple projects are easily copied and their rents competed away. Increasing industry dynamics and sophistication force project managers to push the envelope in seeking new markets and new technologies.
The fundamental logic of the PRM mind-set does not address novel projects. PRM preplans contingencies and flexibility around a project plan and then “triggers” them as events unfold. This approach works fine as long as all risks are identified, or as long as residual risks are simply events that temporarily take the project off its planned course. The basic backbone of PRM is that there is a real project plan, one that can be implemented, albeit with some contingent or mitigating actions thrown in. When unforeseen events arise, the project team can improvise its way back to the basic project plan because it is never too far away from it.
Serious problems arise when the PRM mind-set and toolbox are applied to novel projects. Because one cannot have a project without a plan, a project plan will inevitably be drawn up for the novel project. As the project is “novel,” rigorous PRM techniques will be applied to ensure that all potential risks are identified, assessed, and prioritized, and that preventive, mitigating, and contingent actions are developed. Solid, experienced project leadership will be allocated to the project, supplier relationships will be considered, and good project governance will be installed, all around the idea that when unforeseen events arise, the project team, its suppliers, and its stakeholders will all be prepared to improvise a “solution” to these unforeseen events and bring the project back on plan. But, of course, there is no project plan. The plan is but a starting point, an illusion, a simple sketch. The basic backbone of PRM, the project plan, does not really exist.
This creates tremendous problems for the project team. All the PRM efforts provide a level of comfort to all the parties involved that the project, as planned, is feasible. The team is convinced that their job is to implement the plan, without properly appreciating the challenges that lie ahead. As unforeseen events arise, they try to improvise their way “back” to the project plan. But the project, as planned, may not have been feasible, and this leads to two common stages of behavior. In the first stage, the project team makes promises that the project will be back on track after some degree of effort. The improvisational effort is undertaken, and the project is still not back on track. This cycle continues for a while until the second-stage behavior manifests itself: The team suddenly realizes that the project plan was simply stakes in a desert, and they wonder how they got out there themselves. All their effort had been concentrated on following the stakes in the ground, instead of doing what they really should have done: discovering where the stakes should be going.
Operational Risk Management and PRM
Before we explain how this book starts from PRM and then turns to managing unforeseeable uncertainty, we must distinguish project risk from the term “(enterprise) risk management,” which has been prominently discussed in the business press since the banking and accounting fraud scandals of the late 1990s. In both finance and strategy literatures, one can find other definitions of operational risk than the one we will use with respect to projects.
With the Asian crisis and the bursting of the financial markets bubble in 2000, attention has focused on market risks, credit risks, liquidity risks, and legal/regulatory risks. Then, in the wake of corporate governance and fraud scandals, such as Enron, Tyco, Ahold, Parmalat, and Arthur Andersen, the interest conflicts between stock market analysts and investment bankers within large, universal banks, and many others turned attention to what the financial community began to call “operational risk”: the risk of direct or indirect loss resulting from inadequate or failed internal processes, people, and systems or from external events, the latter also being called “operational strategic risk.”5
In the context of business strategy, strategic risk is defined as “an unexpected event or set of conditions that significantly reduces the ability of managers to implement their intended business strategy.”6 Strategic risk comprises operations risk, asset impairment risk, and competitive risk. Operations risk results from the consequences of a breakdown in a core operating, manufacturing, or processing capability. Any operational error that impedes the flow of high-quality products or services has the potential to expose the firm to loss and liability. At the aggregate business level, there have also been recent attempts to cover property, product liability, employee crime, and exchange risks with integrated insurance policies. Overall, however, operational risk is not as well understood as market or credit risk (in particular, mathematical models are not as fully developed), and many financial institutions manage operational risk on an ad hoc basis.7
There are important differences between “operational risk management,” as seen by strategy and financial services, and PRM. PRM is more focused than operational risk management because it looks at projects only. At the same time, it is more general because it considers any possible event that may change the execution of the project plan or the plan itself, over the course of the project. PRM is more operational than operational risk management because it is directly concerned with the work of the project team—namely, what they need to do and how flexible they must be in responding to stochastic events. Finally, the notion of “risk” is more general in PRM: In contrast to operational risk, project risk may represent not only a downside (such as adverse events that threaten the project) but also an opportunity, or upside (such as an unexpected application of a project result). PRM should include both guarding against unpleasant surprises and taking advantage of opportunities.
Contribution and Plan of the Book
In this book, we make two main contributions. First, we begin by discussing project risk management (PRM), because novel projects have a lot to do with risk and PRM is the best toolbox available to handle them. Then we explore the implications of unforeseeable uncertainty in novel projects, and we demonstrate that they render PRM methods insufficient and require fundamental modifications in the logic of project management itself. Thus, we offer a different way of looking at the problem of managing novel projects: Rather than working harder, straining to consider more possibilities in planning and formal risk management, we propose that one must recognize that project novelty fundamentally renders planning approaches inadequate. In such cases, project managers must make use of two fundamentally different approaches: learning, or a flexible adjustment of the project approach as one learns more about the project, its environment, and their interactions (as opposed to a contingent approach that utilizes planned “trigger points”), and selectionism, or pursuing multiple approaches, independently of one another, and picking the best one ex post.
Second, these approaches must be managed differently from each other and from the traditional planning approach; they require different project mind-sets, different project infrastructures, and different supplier and stakeholder relationships. Project sponsors must be aware of these differences if they are to help build the organizational capabilities critical to managing novel projects and to properly support these novel projects within a possibly hostile organization.
While the important events and courses of actions cannot be foreseen in novel and complex projects, the project team, more often than not, has a good feel for the complexity of the project and for the limitations of its own knowledge, thus preventing it from falling victim to unk unks. The team can, at the outset, put in place the competencies, infrastructure, and relationships appropriate to the challenge at hand. This is what we propose in this book, and for which we offer tools. These tools are not as quantitative and precise as traditional PRM tools, reflecting the more difficult nature of the challenges that confront novel projects. Yet we set out to convince the reader that they can make an enormous difference to the project.
In Part I of this book, we present two contrasting examples of current PRM practice and then propose an extended view of PRM. Chapter 1 describes a PRM best practice example, while Chapter 2 illustrates the limitations of PRM practice in novel projects. Chapter 3 proposes a broader view of PRM and demonstrates that, in the presence of unk unks, project management itself must follow an extended logic. We distinguish fundamental sources of uncertainty and expand the PRM toolbox in order to address uncertainty from all these sources.
Part II is the conceptual heart of the book, where we explain what a project can do in the face of unforeseeable uncertainty, not only in terms of PRM but by changing the project management approach itself. Chapter 4 offers a diagnosis tool for recognizing the type of uncertainty at the outset of a project and outlines the two fundamental approaches to unk unks, selectionism and trial-and-error learning. Chapters 5 and 6 explain and give examples of learning projects and selectionist projects, respectively. Chapter 7 develops tools for choosing between the two and for combining them and the strengths of each.
Part III develops tools for managing learning and selectionist projects facing unforeseeable uncertainty on three fundamental dimensions. Chapter 8 defines the culture and mind-set that are necessary to be successful in the face of unk unks, a mind-set of experimentation and learning rather than of executing planned tasks and achieving established targets. Without such a mind-set, tools will not be successful. We also discuss what this means for the profile of the members of the project team. Chapter 9 describes the required project infrastructure, the systems that need to be put in place for planning, monitoring, coordinating, evaluating, and exchanging information. These management systems must vary according to what fundamental project management approach is chosen.
Chapter 10 discusses the collaboration with partners, an increasingly important way of organizing large projects with wide-ranging technologies. Managing partners becomes more challenging in the presence of unk unks, as unexpected surprises tend to unbalance the interests of the players involved (even if they were perfectly aligned at the outset), which produces an often irresistible temptation to behave opportunistically in order to safeguard one’s own interests. The chapter describes how flexible project governance with limits of acceptable behavior can be achieved using a collection of contracts, informal agreements, mutual stakes and ownership, repeated interactions (into the future), experience, and personal relationships that are necessary in order to withstand the pressures of unexpected surprises.
Chapter 11 addresses the project stakeholders. Stakeholders are parties that are not formally involved in the project (as opposed to the partners in Chapter 10) but are affected by the project, interested in it, and can influence it through formal means and informal means and the application of power. The presence of unk unks renders an appeal to rational interests insufficient—interests may change along with the content of the project over time, as unk unks emerge.
Finally, Part IV elevates the discussion from project management to senior management. While project management must execute the project and deal with the unk unks, senior management shapes the project’s environment and is responsible for enabling the project team to respond to unexpected events. Thus, senior management has a significant responsibility in making novel projects successful. Chapter 12 outlines three areas of responsibility that senior management should keep in mind.
This book is meant as a resource for project teams that have to deal with novel projects. We offer a number of tools and ideas for your inspiration, but even then, we realize that this does not make managing novel projects trivial. Dealing with unknown unknowns is inevitably uncomfortable and dangerous. We hope this book provides some guidance or red thread in the chaos of dealing with the many unexpected and hard-to-interpret events that will inevitably arise in novel projects.
Endnotes
1.
This is a standard definition; see, for example, Meredith and Mantel 2003, p. 8.
2.
An increase in velocity, and thus the need for project management, has been observed by a number of researchers, for example, Kloppenborg and Opfer 2002, Pinto 2002, and Kerzner 2003. The conclusion that career tracks will be obliterated can be found, for example, in Stewart 1995. This latter conclusion is premature.
3.
See Sahlman 1990. He reports that of the 383 companies studied between 1969 and 1985, 34.4 percent experienced a partial or total loss of invested capital, 49.8 percent returned between 0 and 5x, and 9.8 percent returned between 5 and 10x. While the Internet bubble for a while promised spectacular returns, VCs are now back to the times before 1997 and have actually begun to focus more on incremental projects.
4.
For example, Wideman 1992, PMI 1996, Chapman and Ward 1997, the Department of Defense (2001), or Smith and Merritt 2002.
5.
The focus on market, credit, liquidity, and legal risks is observed in Crouhy
et al.
2000, p. 35. The term “operational strategic risk” is coined ibid, p. 479. The focus on inadequate or failed internal processes, people, and systems or on external events is described in Basel Committee Publications 1998, and Harmantzis 2003.
6.
See Simons 1999.
7.
Integrated insurance policies are described in Meulbroek 2001. The diagnosis that operational risk is often managed ad hoc is in Crouhy et al. 2000, p. 484.
PART I:A New Look at Project Risk Management
Imagine you are planning a climbing expedition up the Matterhorn, one of the most spectacular mountains in the Alps. As a project management expert, you produce a detailed plan and specify routes, expected distance travel times, budgets for equipment, shelter and food, and so on. In addition, you have to worry about what might go wrong: A storm may move in, for example. For such an eventuality, you need to build buffers into the plan: extra time and/or extra equipment (perhaps an emergency tent or ice picks). You also need to plan decision points; for example, if the storm moves in before noon, we turn around, and if it catches us at 4:00 P.M., we take refuge in an emergency shelter. This exercise of anticipating risks is the essence of project risk management (PRM).
Project risk management can be defined as the “art and science of identifying and responding to project risk throughout the life of a project and in the best interest of its objectives.” PRM extends project planning by identifying, appraising, and managing project-related risks. Risk, in turn, is defined as “the implications of the existence of significant uncertainty about the level of project performance achievable” and is seen as having two components: first, the probability of occurrence, and second, the consequences or impacts of occurrence.1
PRM has become an established, formalized, and widely used project management method.2 This method offers a powerful set of tools that help companies to keep downside risks under control and to take advantage of upside opportunities. In some industries, such as engineering, construction, or pharmaceuticals, anticipating and managing downside risks is essential to remain in business. In other industries, the ability to seize opportunities can greatly enhance profitability. For example, the manager of one power generation engineering company told us, “Thinking proactively through risks enables us to fill the ‘white spaces’ in our contracts to our advantage. We proactively interpret undefined events in our favor. ‘User training costs money? Well, that was not specified, so it’s clear that you must pay it.’ This protects us from the customer interpreting the event in his favor, and sometimes, we even manage to seize an opportunity and sell it to the client for additional profit.”
PRM, then, is concerned with achieving the stated project goals in spite of risks (see Smith and Merritt 2002), although it ideally includes influencing the “base plan” and even the project design, and revising the targets when necessary.3 While the details differ, authors agree that PRM consists of four conceptual steps (see Figure I.1): Identify risks beforehand; classify and prioritize them according to probability and impact; manage them with a collection of preventive, mitigating, and contingent actions that are triggered by risk occurrence; and embed these actions into a system of documentation and knowledge transfer to other projects.
Figure I.1 Conceptual steps of the PRM process
In Part I of this book, we present two examples of project risk management. The first example, the PCNet project, describes one of the many IT integration projects undertaken as part of the takeover of RBD, Inc. by the diversified resources company Metal Resources Co. from July 2001 to September 2002. We consider this to be an excellent example of how solid application of PRM techniques in the appropriate project environment can produce good results.
The second example, the Circored project, describes the design and construction of a plant in Trinidad to produce direct-reduced iron (DRI), as part of a joint venture between Cleveland Cliffs, one of the largest iron ore suppliers to blast furnace integrated steelmakers in the United States, Lurgi Metallurgie GmbH, a metallurgical process engineering company, and LTV Steel, who wanted to use DRI in a mini-mill they were building in Alabama. We consider this to be an excellent example of what happens when standard PRM techniques are applied to novel, first-of-a-kind projects. As is often seen in such cases, the project ran into unexpected problems that delayed completion for several months, it ran over budget, and it was eventually blindsided by an unexpected turn in the market.
In Chapter 3, we draw the lessons from the two examples and characterize the types of uncertainty that require PRM. Based on this classification, we outline under what circumstances which of the various methods of PRM are appropriate. In addition, we extend the PRM toolbox by discussing additional methods that are relevant but have not been presented in the same context. Control-and-fast-response is a method of dealing with high task complexity, and project contracts are used to coordinate multiple stakeholders in the presence of relationship complexity. Finally, we introduce two approaches to unforeseeable uncertainty, both of which can extend PRM: trial-and-error learning, or the repeated redefinition of the project over time, and selectionism, or the use of parallel candidate trials, the best of which is chosen ex post. These will be further discussed in Part II of the book.
Endnotes
1.
The definition of PRM can be found in Chapman and Ward 1997, p. 10; see also Wideman 1992. The definition of risk is in Chapman and Ward 1997, p. 7. The components of risk are described in DoD 2001, p. 5.
2.
See, for example, Wideman 1992, PMI Standards Committee 1996, Chapman and Ward 1997, Council of Standards Australia 1999, DoD 2001, or Smith and Merritt 2002.
3.
See Chapman and Ward 1997, p. 10.
1PRM Best Practice: The PCNet Project1
1.1 Background
In 2002, the first-tier diversified resource company, Metal Resources Co., headquartered in Austin, Texas, announced a cash offer for the Winnipeg-based metals company, RBD, Inc. The offer was recommended by the RBD board to its shareholders and then swiftly executed. The combined companies formed the second largest mining and resources company in the world. In 2004, Metal Resources Co. had activities in 28 countries, with $29 billion in sales, 40,000 employees, and leadership positions in aluminum, nickel, copper, uranium, gold, carbon steel metals, diamonds, manganese, and various specialty metals used in steel production.
The acquisition execution placed heavy emphasis on synergies, that is, on gross annual cost savings. Five top-level integration areas were put in place to capture the savings: IT infrastructure, HR systems and processes, financial systems and processes, operational integration, and organizational integration. The total synergy target amounted to $1.9 billion in annual gross operating cost savings.
One of the important merger activities was a consolidation of the IT systems of the two companies, a huge undertaking involving 900 IT employees throughout the combined company. Not only had the IT integration achieved its own target of $210 million in savings, but it also critically enabled the other merger areas by providing a transparent, integrated, and reliable application platform. Max Schmeling, the enterprise CIO, was responsible for executing the IT integration.
A pre-integration team planned the integration project in detail over a period of nine months, up to October 2002. The team started from an overall target (“get $210 million in annual savings by consolidating the IT structure”) and successively broke this target down to more and more detailed tasks. Within each consolidation area, large projects were defined, then subprojects, and then detailed tasks that could be assigned. In total, 110 projects were to be executed in parallel by project managers and subproject managers, supported by a central project office. The projects would have to be carefully coordinated, as some of them served as enablers for others, and all competed for the same scarce staff time.
In September 2002, Max Schmeling pulled his direct reports and operating company CIOs into one room (about a dozen people). He presented them with the work breakdown structure that the planning team had produced. He said, “Nobody leaves this room before every one of the 110 savings opportunities has a name on it.” The first outcome of this two-day marathon meeting was a project structure that clearly assigned project accountabilities, as well as a corporate sponsor for each project, to help them drive change through the organization. The key projects within the IT integration were “General” (mainframe decommissioning, Unix integration, and office consolidation at the various sites of the previous companies), knowledge management (including the consolidation of portals, intranets, yellow pages, instant messaging, collaboration tools, and publishing), the ERP program (moving to an enterprisewide SAP installation encompassing HR systems and financial reporting across both companies), the Web applications center, IT strategy (which was to connect the IT changes to head counts and reengineered processes, and strategic IT sourcing), and the PCNet project, on which our project risk management (PRM) example focuses.
The last piece, not producing bankable savings but critical nonethe-less, was the “Time Zero” project: The IT systems were changed while simultaneously running the business. Critical systems, such as e-mails, global address lists, help desks, and all business applications (but not, for example, cross-unit calendar lookup), had to work on day one. Without this minimal functionality, the business damage would have been too great, and resistance would have prevented a successful execution of the migration.
The second outcome of the marathon meeting was a “Gantt Chart from Hell,” which filled an entire wall. This was a preliminary plan showing how the 110 projects would be sequenced, and when they would reach their critical milestones and, ultimately, completion. In addition to encompassing a large number of tasks, the planning job was made even harder because the 110 projects had to be coordinated with the other synergy projects and with the activities of the operating companies, who were responsible for carrying out numerous activities.
1.1.1 The PCNet Project
The PCNet project encompassed four network infrastructure migration areas (see Figure 1.1): (1) worldwide standard desktop environment, mostly the exchange of the 40,000 companywide desktops, standardizing on Windows XP desktops (HP) and laptops (IBM); (2) a global communications network, consolidating the corporate network (which had previously been centered on the bottlenecks in California and Texas) around six hubs, with added bandwidth to the rest of the network and further internal redundancy; (3) a standard network server infrastructure using Windows 2000, with a greatly reduced number of network routers; and (4) an enterprise security and directory system, going from multiple directories, security systems, and firewalls down to one each. Multiple directories caused headaches when, for example, executives were reassigned and stopped receiving their e-mails until the IT staff had located the directory in which they had been filed.
Figure 1.1 The PCNet project
The business case called for a total savings net present value (NPV) of $115 million, with a project budget of $149 million. This was based on direct savings from infrastructure costs alone, but the project was the key enabler of the whole merger, not just the IT integration. It enabled additional savings, including cutting 130 different applications in the Finance area alone, and it later made the transition to an enterprisewide ERP system much faster and smoother.
The network integration included the reconciliation of outsourcing decisions that had been made differently in the previous companies. For example, Metal Resources had outsourced mainframe, telecom, and the help desk to EDS, while RBD had outsourced the server environment and the help desk to IBM. To move fast, IT management decided to move the entire package to EDS (the provider who already had the bigger share) and to take some server services back in-house.
The PCNet project organization included a project management office, a group for implementation and operations, and a planning group comprising several analysts who compiled business cases and risk analyses, and maintained the tracking tools. Embedded in the master plan for IT integration, the PCNet planning group developed and maintained its own plan and milestones (Figure 1.2). Much of the actual work (such as physically installing routers in basements and desktops in offices) was performed by local staff in the operating companies; the central project organization coordinated, standardized, oversaw time plans, and centrally sourced the standardized components.
Figure 1.2 The PCNet project key milestones
1.2 Risk Identification
Risk identification is concerned with recognizing, at the outset, the factors that may make the project plan obsolete or suboptimal. Thus, risk identification is an important part of project planning. It represents a thorough homework exercise that allows the project organization to be prepared when adverse events strike, offering ready-made (rough-cut) solutions, based on which a team can respond quickly.
In the PCNet project, risk planning was a formal part of all project plans. The main risk areas were seen as Operating Company acceptance (they had to perform, and pay for, a lot of the detailed implementation work, and they resented the distraction from their pressing priorities); “staying focused,” meaning dealing with too many activities with the same scarce resources; security breaches during the transition; and a change in business climate that would threaten the availability of funds to complete the merger.
This aggregate list rested on many lower-level risk identification efforts, one of which is shown in Figure 1.3, focusing on HR and personnel retention risks. The list showed where the risk’s impact would lie (e.g., in achieving synergies); whether the impact was financial, on the schedule, or on solution quality; and how high the impact would be financially. Finally, the list estimated the risk probability and indicated the impacted parties and the “owner,” i.e., the party responsible for responding to the risk.
Figure 1.3 HR risk list in the PCNet project
The lower-level risk lists (such as the one illustrated in Figure 1.3) were produced by the project management office in collaboration with the operating divisions that performed much of the work. The project management office produced a draft list based on experience from previous projects, and the execution teams added risks, based on the detailed tasks, systematically asking what could possibly go wrong. In other words, the risk lists combined knowledge and experience with project-specific planning.
1.3 Risk Assessment and Prioritization
1.3.1 Impact Assessment: The Project Outcome Is a Distribution, Not a Number
After risks have been identified, their impact should be estimated, in order to prioritize them. For the large IT merger projects (from around $10 million), Max Schmeling built on the identified risk factors, and their possible values, to develop a probabilistic distribution of the project outcome. This was done with a scenario business plan with respect to the ultimate success measure, the NPV of savings (see Figure 1.4 for the PCNet project): “With only 10 percent probability, we will fail to deliver savings of at least $90 million; with 50 percent probability, we will not reach $135 million; and with 90 percent probability, we will not be able to deliver as much as $180 million in this project” (in other words, a pessimistic, medium, and optimistic scenario). The scenarios, connected to a value-distribution curve, were called P10, P50, and P90 (a method and terminology that come from mining and oil engineering). In the curve (Figure 1.4), the failure probability increases from left to right as the target increases. The value distribution for the PCNet project rested on similar curves for the four major subprojects.
Figure 1.4 The PCNet project outcome distribution
The project value distribution curve in Figure 1.4 offers two benefits. First, it forces the team and management to acknowledge that the outcome cannot be planned exactly, as a number, but that many outcomes are possible with varying degrees of probability. In other words, the team cannot offer a fixed target, but only a confidence level (the probability of achieving $115 million in savings is 90 percent). Confidence levels offer a better understanding of the overall project riskiness than simplified project buffers that are used in other companies.
Second, the value distribution curve offers a different dimension of priority for the key value drivers: The value distribution is influenced by the variance of the risk factors, and the distribution represents a “model” of how that variance impacts the project’s value. This method is finer-grained than the expected impact that we have discussed above: Uncertain events often do not simply “occur or not occur” but have a continuum of possible values. For example, for the desktop migration subproject, the dominant risk lay in the prices set by the PC vendors. These prices had possible ranges, and the variance of the ranges defined the importance of the risk, both on the upside and the downside.
1.3.2 Risk Prioritization
Based on the impact assessment, risks are usually prioritized in order to allow the project team to focus attention on the most important ones. Typically, this prioritization is based on an “expected impact” of the risk, that is, size of impact, if possible in monetary terms, times probability of occurrence. However, one should not rely on this expected impact metric alone—a risk may have a moderate expected impact because it has a low probability; but at the same time, it may represent serious damage (a “showstopper”) if it occurs. It may be advisable to pay keen attention to preventive or mitigating actions against such a risk.
In the PCNet project, hundreds of distinct risks were identified and listed in the risk planning process. They had to be prioritized in order to maintain focus (which was one of the main identified risks itself!) and efficiency. Rather than classifying the hundreds of risks themselves, the merger team chose to classify the subprojects in a type of ABC analysis according to their value (that is, the amount at stake when a risk occurred) and the probability of failure (aggregated from individual risks affecting that project). The logic of this analysis is shown in Figure 1.5. The project management team aggressively intervened in high-priority projects (high value and high risk), whereas projects with high risk but low value were delegated to the Operating Companies, with an offer to help if requested. The well-running projects were either watched (high value) or let run (monitored only on a routine basis).
Figure 1.5 The Metal Resources Co. IT merger project prioritization
1.4 Risk Monitoring and Management
Risk identification and assessment form the basis on which the project can proactively influence the risks and monitor them, responding quickly if they occur. The Metal Resources Co. IT merger illustrates this.
1.4.1 Proactive Influencing of Risk Factors
The identification of the most important risk drivers by the value distribution curves (Figure 1.4) allowed the project team to manage them proactively. For the PC prices, the dominant risk for the desktop migration, a team of project managers visited the vendors and aggressively negotiated in order to lock in prices at a low level. Not only did this reduce the savings variance (guaranteed prices for all countries were obtained), but the centralized negotiation also achieved prices that were even lower than hoped for, creating additional savings. Thus, the pricing risk turned from a downside potential into a substantial upside opportunity, which was successfully utilized.
A second example relates to the considerable schedule risk of actually delivering all the desktops into all countries on time for the “new” system to start. Metal Resources Co. operated in countries such as Angola, Congo, or Armenia, where fighting might disrupt delivery, and where “gatekeepers,” “consultants,” or bureaucrats could block every move until permission is requested. Or sometimes they merely wanted to be shown attention and respect. In the aggregate, the schedule risk became large in such countries, or deployment might even be endangered entirely. So, for each country with significant bureaucratic restrictions, a plan was devised with countermeasures, emergency procedures, and appropriate buffers to allow for disruptions, and a deployment was not started until the remaining uncertainty had been reduced to a high confidence level such that the deployment could be carried out within the buffers allowed.
1.4.2 Monitoring and Reporting
Risk supervision concentrated on areas of high exposure. For example, the PCNet project came out as high priority from the classification in Figure 1.5: The desktop and server subprojects were in the upper right quadrant (high value and high risk), and the network project, while not directly of high value, was of high strategic importance and classified as high risk. The project team could not complain about a lack of attention from upper management.
In October 2002, work started in earnest, hitting multiple fronts at the same time: Telecom lines were rented and connected, network equipment was installed, security policies and software and directories were set up, and PCs were exchanged. Control of the large projects was paramount to keeping the integration on track and to producing the savings. An integration management office was set up for the merger as a whole (the “Integration Management Committee,” of which Max Schmeling was a member), and the IT merger had its own integration office, the Project Management Office.
In monthly meetings, progress was tracked using the “Deployment Progress” monitoring tool (Figure 1.6). This reported on the progress status of PC deployment (for example, in January 2003, 1,428 of the 40,000 PCs had been migrated), sites with upgraded networks, reduced Internet access points to the global network, and reduced standard applications. The tool also showed the current budget status and offered comments on current events in the various regions of deployment.
Figure 1.6 Aggregate deployment progress monitoring tool
In addition to the progress tool, which focused on operational figures, budgets and, of course, the financial synergies (or savings) were reported. The savings data were urgent: Only when they had been achieved and documented could they be incorporated into the accounting and bookkeeping systems, and then reported to external financial analysts. Being able to report booked synergies is very important for a CEO after an acquisition.
