How to Manage Project Opportunity and Risk: Why Uncertainty Management can be a Much Better Approach than Risk Management

Part I

Setting the scene

Part I sets the scene, introducing key concepts used throughout the rest of the book in Chapters 1–4.

Chapter 1 considers the nature of uncertainty in and around projects. It begins by considering the nature of projects, and the relationship between project management, strategic management and operations management. It then considers the implications of the project lifecycle, using a nominal 12-stage framework which can be adapted to any organization’s preferred structure. This helps to clarify the context in which project uncertainty management operates and a range of project management issues that uncertainty management needs to address. For example, the nature of the process used to manage project uncertainty should be driven by when in the lifecycle it is used. Within this project lifecycle structure, the seven Ws are considered: ‘who’ (parties involved), ‘why’ (motives), ‘what’ (design of the product of the project), ‘whichway’ (plans for relationships and contracts, business case purposes, operations and activities), ‘wherewithal’ (resources for operations and activities), ‘when’ (integration of all timing questions) and ‘where’ (the location of the project and wider context issues). The role of inherent variability, ambiguity and systemic relationships in addition to events is then explored briefly, followed by an introduction to the use of a ‘performance lens’ and a ‘knowledge lens’ to view uncertainty for different purposes, and a final linking conceptual framework to prepare for Chapter 2.

Chapter 2 uses all the basic definitions and linking conceptual frameworks from Chapter 1 to explore the nature of uncertainty in terms of its relationship with opportunity and risk. It first introduces a ‘minimum clarity’ approach to quantifying uncertainty. This practical tool is also an important conceptual framework. It is used to explain the distinction between targets, expected outcomes and commitments. The linked ‘opportunity/risk datum’ concept is then introduced and its subjective and ambiguous nature is explored. In this framework a ‘clarity efficiency’ concept is introduced, concerned with maximizing insight which can be communicated for any given level of analysis effort and cost, and choosing an appropriate level of clarity. This framework is then used to consider a generalization of Markowitz’s ‘risk efficiency’ concept, the conceptual basis of ‘risk’ used in this book. A linked ‘opportunity efficiency’ concept is also introduced, a key conceptual framework.

Chapter 3 describes the key motives for formal ‘performance uncertainty management processes’ (PUMPs). These include the benefits of documentation, the value of quantitative analysis which facilitates distinguishing between targets, expectations and commitments, the pursuit of risk efficient ways of carrying out a project, generalization of risk efficiency to ‘opportunity efficiency’, and related culture changes. Effective exploitation of opportunity efficiency implies proactive uncertainty management which takes an integrated and holistic approach to opportunity and threat management with respect to all seven Ws in all relevant stages of the project lifecycle for all projects in an organization’s portfolio of projects.

Chapter 4 outlines the basic PUMP – a seven-phase generic framework central to this book. This basic PUMP framework plus associated processes defining a ‘PUMP pack’ is compared with a number of other published frameworks, as a basis for understanding the transferable nature of the concepts developed in the rest of this book for users of alternative frameworks, and as a basis for understanding the choices available when developing uncertainty, opportunity and risk management frameworks for particular organizations.

Chapter 1

Uncertainty in and around projects

I keep six honest serving men, they taught me all I knew; their names are what and why and when and how and where and who.

—Rudyard Kipling

Uncertainty management as addressed in this book is concerned with clarifying all relevant aspects of opportunity, uncertainty and risk in all projects. In a plain English sense at a basic level:

‘uncertainty’ means ‘lack of certainty’,

‘risk’ means ‘possible unfavourable outcomes’,

‘opportunity’ means ‘possible favourable outcomes’.

These three definitions are both basic and general, in the sense that they are consistent with all definitions in widely used dictionaries (Oxford Concise, 1995, for example). They are nominal definitions in the sense that readers can use their own comparable plain English alternatives if they wish – we do not want to open a book with counterintuitive definitions that inhibit colloquial use of words. More specifically, we do not want to inhibit richer or more specific colloquial interpretations, such as ‘an opportunity is usefully seen as an occasion when it is relatively easy to achieve what you want’, and ‘risk is usually associated with problems and danger’. However, it is crucial to avoid the morass soon encountered if simple common practice technical definitions are used. The three definitions provided above are basic default definitions, in the sense that they will serve if the reader is unclear about an unrestrictive basic plain English interpretation.

These nominal/default definitions, or any comparable alternatives the reader may prefer, provide sufficient clarity for our purposes without the need for more restrictive formal definitions. This is because we will introduce explicit working assumptions as needed.

Managing opportunity is our top priority, and the identification and pursuit of opportunity are usually the starting points in terms of enhancing corporate performance. Risk may not be relevant provided it is understood and acceptable. However, uncertainty needs to be understood and managed to clarify both opportunity and risk, and that is why exploring the scope for uncertainty in and around projects is a useful place to start to understand how effective uncertainty management can enhance corporate performance.

An appreciation of the potential for uncertainty management in projects has to be informed by three somewhat different views of ‘projects’. One is projects as those concerned with ‘operations management’ see them. A second is projects as those concerned with ‘project management’ see them. A third is projects as those concerned with ‘corporate management’ see them. All three perspectives need a common framework and language for communication.

This three-part perspective requires a clear understanding of the scope of decision making involved in project management and the nature of linked concepts. One key concept is the project lifecycle which forms part of the lifecycle of the asset or change created by a project. This lifecycle is a natural framework for examining decisions and associated uncertainty. A structured view of this lifecycle is also important to provide a framework for looking ahead for sources of uncertainty that can be seeded by decisions in earlier stages of the lifecycle. Further, a structured view of this lifecycle is central to understanding how the ‘performance uncertainty management processes’ (PUMPs) of central interest in this book ought to change as the lifecycle of the project unfolds and the priorities of associated project management objectives change.

An appreciation of uncertainty also has to draw on Kipling’s ‘six honest serving men’ as identified in the opening quote for this chapter – plus a linked ‘resources’ concept – for convenience referred to as the seven Ws: ‘who’, ‘why’, ‘what’, ‘whichway’ (how), ‘wherewithal’ (using what resources), ‘when; and ‘where’. That is, to clarify in more detail where and how we need to look for uncertainty that needs managing, project uncertainty management has to be informed by seven basic questions associated with these seven Ws.

Exploring the lifecycle structure and the seven Ws is the central task of this chapter. However, our focus on performance uncertainty management needs to be linked to other aspects of uncertainty management, and it has to ensure that all aspects of uncertainty are addressed in a holistic manner. Such concerns are addressed in an introductory manner at the end of this chapter.

Begin by considering a standard definition of a ‘project’ and the ‘asset/change’ concepts that underlie it.

Projects and the associated ‘asset/change’ concepts

Turner (1992) provides a useful illustrative definition of a project:

an endeavour in which human, material and financial resources are organized in a novel way, to undertake a unique scope of work of given specification, within constraints of cost and time, so as to achieve unitary, beneficial change, through the delivery of quantified and qualitative objectives.

Turner’s definition covers a very wide variety of projects where the ‘beneficial change’ to be delivered is a tangible asset of some kind that will subsequently be made use of in an operating mode – such as a building, aeroplane or computer system. It also includes the creation of less tangible assets – such as incremental improvements in operating systems, new ways of working, new knowledge acquisition or a new image creation – that have value beyond the delivery of tangible changes. Further, the acquisition of both tangible and intangible assets may be usefully viewed as changes for some purposes. The term ‘asset/change’ is sometimes a useful reminder that:

projects may involve the creation of a physical asset, but it may be useful to view them in terms of the change to the organization or system in which the asset operates; projects may involve changing organizational processes, but it may be useful to view these changes in asset creation terms;

most projects benefit from both perspectives – simple traditional asset creation terms are convenient sometimes, but management of change terms can be more relevant at other times.

A flexible approach to all terminology can be useful, adapting to the context. For example, a culture change project may be approached in change management terms for most purposes, but the initial concept evaluation of that project needs to value the culture change as an asset to justify the effort and expenditure involved. A new electricity generation power station project may be approached in asset creation terms for most purposes, but the initial concept evaluation of the project needs to value the power station in terms of all related changes to the electric utility’s portfolio of assets, cost of capital, operating costs, reliability, plus other changes in terms of all relevant objectives, such as a green (environmentally friendly) image. Table 1.1 lists a sample of example projects in conjunction with the asset/change delivered to illustrate the variety of organizational changes and assets that may be associated with projects.

Table 1.1 Examples of projects and associated asset/change

Turner’s definition highlights the change-inducing nature of projects requiring formal management, the need to organize a variety of resources under significant constraints, and the central role of the objectives to be achieved. It also suggests inherent uncertainty related to a novel organization and a unique scope of work. In our plain English terms this uncertainty may imply risk, but it may not. In our terms this uncertainty always implies potential opportunity – projects without possible ‘beneficial change’ should be rejected, if ‘beneficial change’ is sensibly defined. As a central part of effective project management, all relevant uncertainty requires attention to clarify opportunity and risk, and enhance performance.

Much good basic project management practice might be thought of as uncertainty resolution by clarifying what can be done, deciding what has to be done, and ensuring that it gets done. For example, good practice in planning, coordination, setting milestones, and change control procedures seeks to progressively resolve and reduce uncertainty as a project progresses. However, uncertainty management is not just about uncertainty reduction – increasing project uncertainty and risk to seize opportunities or to reduce corporate bankruptcy risk may sometimes be the only rational option – and increasing uncertainty and risk when the rewards are worth it is always important. Uncertainty management as discussed in this book is about recognizing uncertainty wherever it matters, and taking appropriate, timely, decisions in the face of this uncertainty. Most texts on project management or project risk management do not take a sufficiently wide view of project related uncertainty, and most do not explore what a coordinated approach to proactive and reactive uncertainty management can achieve in terms of improved performance from a corporate perspective for the project owner.

Part of understanding where uncertainty matters involves appreciating the context within which a project takes place, and the extent to which this context both affects and is affected by the project. The relevant organizational and environmental contexts and the extent of interactions with a project will obviously vary substantially depending on the nature of a project and its scope of work. Sometimes projects can be viewed in very simple terms as largely independent operations. However, sometimes very complex interactions need attention. To deal with all possibilities we must have a sophisticated view which can be simplified in the most appropriate manner for each practical situation.

Operations, corporate and project-related uncertainty

To put projects and project management in context it is useful to consider the overall task of managing organizations in terms of three basic aspects:

operations management – managing for ‘business as usual’;

corporate management – deciding what changes to make at a corporate strategy level, providing appropriate resources and corporate capability, and ensuring appropriate governance;

project management – designing and creating specific changes or assets.

In common with other ways of characterizing the task of managing, these three aspects should be seen as intimately related – not as separate ‘silos’. Corporate management decisions are influenced by current and desired future operational capability; project management is driven by corporate decisions; and future operations are facilitated by project management that maintains or enhances operational capability. All three aspects involve uncertainty and associated challenges of complexity and novelty. In particular, all three aspects are influenced and affected in related ways by the wider environmental conditions prevailing, and by perceptions about the future operating environment.

Operations management

Operations management – managing existing assets for ‘business as usual’ – is sometimes seen as a relatively low level of management involving limited novelty. However, depending on the organization, high levels of complexity can be involved because of the need to manage the day-to-day behaviour of operating systems in great detail. Operations issues can be a major driver of strategic change, and major opportunities are often first identified by the people ‘at the coal face’ in operations management terms. ‘Intelligent control’ (Leitch, 2008) and intelligent organization and careful deployment of assets are usually crucial. Uncertainty, and the extent of its consequences, is typically minimized by frequent or continuous adjustments to operating processes in a control sense. Necessary or efficient specialization encourages a silo approach to various sources of operational uncertainty often involving a number of specialist functions focused on different aspects of control. However, the implications often ripple through the whole organization–as with approaches to health and safety, for example.

Sources of uncertainty can be internal to an operation, associated with the behaviour of employees and other assets, and their interactions, including communications and the provision and use of information. External sources of uncertainty are virtually infinite, but those that can materially affect operational performance are usually the only issues of interest. Further narrowing of attention is possible if only a short-term view of the future operating environment is taken. However, the choice of an appropriate operating horizon depends upon perspective and capability, shaped by the responsibility for making desirable adjustments. At a low level of operations management, horizons may be very short, even hours or minutes, and processes are largely routine, based on extensive experience and perhaps trial and error adjustments. At higher levels of operations management attention is on progressively more aggregated operations, which involves a wider set of contextual factors and related uncertainties, and usually longer planning horizons.

In most organizations, operational interdependencies between assets are significant. Shared objectives, shared supporting resources and common sources of uncertainty may be involved. Further, creating new assets may impact other assets, with goodwill and important relationships being particularly exposed if such effects are overlooked. Consequently, at almost any level in an operations hierarchy, concerns about managing uncertainty can have wider implications for other parts of the organization or strategic implications for the organization as a whole. These strategic implications might relate to the capability of current operational capacity and assets, and their ability to perform into the future. Any strategy formulation process needs to understand this capability, and the nature of all the major sources of uncertainty that can impact on future operational performance, whether these sources are internal or external to the organization. Operational uncertainty, be it short or long term, should be a key driver of strategy.

Corporate management

The uncertainty that must be addressed as part of corporate strategy management includes all significant sources related to operations just discussed. It also includes all significant uncertainty related to necessary resources and corporate capability. Further, it includes all significant uncertainty about the ambitions and aspirations of senior management and key stakeholders, and in relation to the interpretation of the organization’s mission and key objectives. The scope of possible future ventures may be very uncertain, their desirability may be uncertain, and the extent to which these ventures need to be related to existing operations and assets may also be unclear. Part of the challenge of strategic management is to identify potential investment options that are suitable, feasible and acceptable in a very uncertain environment (Johnson et al., 2005). Strategy formulation involves developing a coherent and effective set of future investment options that will deliver specified benefits over some future time period. Part of the context is an existing portfolio of assets, current operations, future plans and commitments. Another part of the context is an uncertain environment.

In a top-down approach, long-term corporate strategy leads to the development of a hierarchy of projects reflecting long, medium and short-term planning. Long-term strategy is implemented via a programme of medium-term projects. These in turn may be achieved by a programme of linked, short-term projects, potentially constrained by short-term operations. Scope for managing sources of uncertainty exists at each level, reflecting the corresponding key issues at each level. However, management at each level also needs to be aware of potential impacts from adjacent levels. In particular, managers of medium-term projects need to take into account the potential impacts on their projects from both short-term and long-term issues.

Project management

It can also be important to appreciate and manage how a given project relates to other concurrent projects. For example, a project may be one part of a larger project, part of a portfolio of largely separate projects, part of a sequence of projects, or may itself be managed as a set of sub-projects. Figure 1.1 illustrates three basic interconnected project structures: the chain configuration, the parallel configuration and the project hierarchy.

Figure 1.1 Example configurations of project systems

In the chain configuration a sequence of component projects follows one another over time to complete a ‘primary project’ which overarches ‘component projects’, which are ‘secondary’. In the parallel configuration a number of component projects run simultaneously, perhaps with interdependencies, to complete an overarching, primary project. In a project hierarchy the primary project is broken down by management into a hierarchy of component projects. The project hierarchy shown in Figure 1.1(c) is a simple example with embedded parallel and chain configurations. Much more complex configurations involving a combination of these three configuration types are employed in most organizations. In slightly different language, one person’s project may be an activity in someone else’s higher level project – different levels of decomposition may serve the needs of different levels of management.

Large engineering or construction projects are invariably managed as project hierarchies. Large projects may be managed as a set of component projects running in parallel, with each parallel component comprising a hierarchy of component projects. Management of the ‘primary project’ can be tackled as a complex version of project management and is typically managed at a more senior level than management of the component projects. As a practical matter, managers of primary projects may not be interested in the ‘nuts and bolts’ of individual component projects, but they will have to understand them well enough to ensure that the component projects fit together as a whole.

The primary project may be thought of by senior management in terms which go beyond that associated with individual component projects – that is, as a strategy or long-term programme, using ‘programme’ in a ‘portfolio of projects’ sense, with links between the component projects defined by shared objectives, resources or other factors. For some purposes ‘programmes’ and ‘portfolios’ can be usefully distinguished from each other and from ‘projects’, but this book uses ‘projects’ in a generic sense which includes programmes and portfolios. It follows that we have to address a spectrum of project complexity, from very strategic projects that are usefully seen as portfolios of programmes for some purposes, to very tactical projects that are usefully seen as single activities or tasks for some purposes.

We shall not engage directly with alternative approaches to ‘complexity’ or alternative views of ‘project’, ‘programme’ or ‘portfolio’ distinctions, but we will address common concerns from an uncertainty management perspective using an inclusive ‘project’ concept. Readers may interpret what we are saying in ‘programme’ or ‘other portfolio of projects’ terms when such distinctions are appropriate. This issue is revisited briefly at the end of Chapter 12.

The following example illustrates some of the interconnectedness between the management of uncertainty in corporate, operations and portfolio/programme/project management.

Ontario Hydro example

At the beginning of the 1990s Ontario Hydro in Canada developed a 25-year strategic plan which included ten new nuclear power stations. They sought Ontario government permission to proceed with the whole plan. The approval process involved official ‘interveners’ making a case to receive funding from Ontario Hydro to challenge the basis of the plans. The Independent Power Producers Society of Ontario (IPPSO), representing all non-government power producers, received funding for a critical report on Ontario Hydro’s approach to strategic planning prepared by Chris Chapman (1992a).

The report’s argument was in two parts. First, confidence bands on Ontario Hydro’s load forecast should have been several times wider; other uncertainties were similarly underestimated and, as a consequence of these uncertainties, the Ontario Hydro approach to strategic decision making was not fit for the intended purpose. Second, a very different planning approach, outlined in some detail, was needed. The mathematical optimization approach adopted by Ontario Hydro was flawed because the optimization did not consider uncertainty. But the common practice of addressing uncertainty via scenario robustness tests was not ‘risk efficient’ in a basic ‘portfolio theory’ sense, and Ontario Hydro’s search for optimality was sound in principle if not in practice.

The applied research funded by the report writing exercise was an opportunity to integrate the thinking underlying this book’s advocated approach to project uncertainty management with strategic uncertainty management and operations uncertainty management. About two weeks before Chris Chapman was to appear as an expert witness, demand fell outside Ontario Hydro’s confidence band, and the strategic plan was withdrawn. This was clearly very lucky for IPPSO. The first part of Chris Chapman’s report was validated in traditional empirical terms. The second part remains debatable, but the basic approach to integrating strategy, operations and projects outlined in Chapman (1992a) and developed in Chapman and Ward (2002, chapter 11) illustrates how to approach the management of the interdependencies between operations, strategy and ‘projects’ defined to include programmes and portfolios of projects.

We will return to this example in Part III, and draw on it occasionally in the interim. Of immediate interest are two points. First, an approach to corporate and operations management compatible with this book’s approach to project uncertainty management was needed as a starting point for operational development. Second, the way a utility such as Ontario Hydro has to approach the operations–corporate–projects spectrum illustrates the nature of these interdependences when a top-down strategic perspective is adopted.

Viewing Ontario Hydro’s uncertainty structure might start with a corporate level assessment of annual profit, Pt, equal to annual revenue, Rt, less annual costs, Ct, for t 1= 1, 2, . . ., n, up to the chosen long-term planning horizon, n = 25 years, for example.

Revenue is a key source of uncertainty, worthy of a major uncertainty management effort. Forecast demand will be central here, in terms of consumer demand and industrial demand, with considerable underlying complexity and interactions in both cases. Also important are existing competing utilities, possible new competitors, market regulators, and political players concerned with relevant conservation and environmental issues.

Cost is also important. At the corporate level, cost is driven by long-term strategic planning decisions: What mix of sources of power should be aimed for 25 years hence? What proportion of nuclear, gas-fired, coal-fired units should be planned for? and so on. Through-life costs will be important, including fuel costs, the effects of environmental legislation or technology development, and liability for pollution or accidents.

At a basic operational level, management is concerned with cost effective day-to-day utilization of existing units. At an intermediate level, an important management concern is the timing of decisions to start building new power-generating units. Such decisions may be coupled to both short-term operational issues and longer-term strategic issues. The sudden failure of an existing unit may trigger a need to bring plans forward. Political events may significantly alter the need for a planned unit; or perhaps even eliminate the need for a unit; possibly doing so when construction of the unit is already underway.

The project manager for the construction of such a unit clearly needs to manage the project in a way that deals effectively with the sources of uncertainty for which he or she is responsible, and ensure that the sources of uncertainty for which other members of the organization are responsible are managed in a supportive manner. The director to whom the project manager reports, and all the directors responsible for the way the project fits into the corporate portfolio of projects, also need to understand and manage all important relationships across the operations–corporate–projects spectrum.

Most project managers have comparable concerns, but the relationship between their project and the rest of the organization may be more ambiguous, and a source of uncertainty needing attention. Most directors of organizations with a direct interest in projects also have comparable concerns, often with greater complexity and ambiguity.

Ontario Hydro had a lot of uncertainty to deal with. It is a useful example for the present purposes because its structure is intuitively obvious to most people, and an approach flexible enough to deal with all relevant uncertainty for this kind of utility can be adapted by most other organizations. At the same time, its uncertainty is easily structured by comparison to some organizations. It has only one product – electricity – and the assets are tangible and relatively inflexible. It will also be a useful example to build on later, especially in Part III.

Operations, project and corporate aspects of a single asset

All projects should originate from some level of corporate strategy formulation in the project sponsoring organization. This is usually the case for projects involving substantial investment in the delivery of an asset involving significant corporate change, but it may not be so apparent with projects involving smaller levels of investment or corporate change. Similarly, all projects, whatever their size or impact, ought to involve consideration of any relevant sources of uncertainty that affect both the creation of an asset and its subsequent operational performance, and any corporate change implications. This consideration should include the complete set of corporate sources of uncertainty that impact on an individual project and may require responses from the project manager or other parties. Motivation to undertake this uncertainty analysis in a top-down strategic manner needs to come from the organization’s board level managers. Ideally this will be undertaken using an approach comparable to a suitable adaptation of that outlined for Ontario Hydro in Chapman (1992a), its generalization in Chapman and Ward (2002, ch. 11) and its brief treatment in Part III. However, even if a project manager’s organization chooses to ignore such issues completely, a competent manager of project uncertainty should not do so.

The focus of this section is projects associated with a single asset. Putting aside the issues noted in the preceding paragraph, linkages between operations, corporate and project management perspectives also exist within the context of a single (primary) project and the associated asset/change lifecycle. Table 1.2 portrays a traditional view of the relationship between the three basic aspects of management and a generic asset lifecycle characterized as four basic stages: conceptualization, planning, execution and delivery, and utilization.

Table 1.2 A traditional four stage view of the asset lifecycle and dominant management aspects

The conceptualization stage encapsulates concept development and the development of a business case for investing in the asset concept. It may be initiated bottom-up to meet operations needs, or top-down to meet corporate level strategic needs, but corporate management considerations usually dominate the end of the conceptualization stage and the beginning of the planning stage. The planning stage encapsulates a complex and potentially lengthy process that begins at a strategic level and progressively refines the design of the asset, an understanding of intended benefits from the asset, how it will be used, how it will be created, what resources will be needed, and when and how it is to be delivered. The execution and delivery stage encapsulates the implementation of plans for the creation and delivery of the asset, with project management preparing for this during much of the planning stage. The utilization stage encapsulates the operation of the asset throughout its operating life to eventual termination of use, with operations staff building on their earlier contribution to the planning stage, assuming they were involved earlier.

This portrayal of the lifecycle uses the term ‘stage’ rather than the common alternative ‘phase’ to reserve ‘phase’ for discussions on related processes. A range of labels similar to those used for Table 1.2 stages may be found in the literature behind this simple four-stage structure, along with alternative views of why such a structure is useful. The asset lifecycle is a convenient way of conceptualizing the generic structure of projects over time for a wide range of purposes. An alternative terminology example is ‘formation’, ‘build-up’, ‘main programme’ and ‘phase-out’ (Thamhain and Wileman, 1975), but the underlying structure is essentially the same. Whatever the stage terminology, these stages are commonly described in terms of the extent to which they differ in the level of resources employed (Adams and Barndt, 1988), the degree of definition, the level of conflict (Thamhain and Wileman, 1975), the rate of expenditure, and so on. This can help to show how management attention to the factor being considered needs to vary over the lifecycle. More recent references in the project lifecycle literature include Tummala and Burchett (1999), and Bonnai et al. (2002).

The way the traditional dominant management aspect pattern portrayed in Table 1.2 changes over time, and the lack of real separability between these management aspects, encourages a wide range of different and more detailed project lifecycle structures in different project contexts to ensure that who does what, when and how, in an orderly manner, is clearly defined. For example, the UK rail industry has developed an eight-stage investment lifecycle as part of its GRIP (Guide to Railway Investment Projects) process (Network Rail, 2007) which is widely cited.

Looking at Table 1.2 from an uncertainty management perspective, responsibility for each stage in the lifecycle is clearly important, but the dominant issue is ensuring that all uncertainty associated with different stages of the lifecycle receives appropriate and timely attention. Maximizing the opportunities presented by the creation of proposed assets warrants careful attention to all stages of the asset lifecycle, taken together as a whole, as well as attention to the role the asset will play in the context of the asset owner’s other investments and operations.

Taking a traditional corporate management perspective, the basic form, timing, cost and envisaged benefits from the proposed asset are a central concern. From this perspective the prospective asset owner will be considering the need for the proposed investment and the opportunity it represents in the context of an existing portfolio of assets, current operations and the future shape of both. Deliberations can be challenging due to high levels of uncertainty about what is desirable, possible and affordable, future operating conditions, and how the proposed asset will perform as part of a portfolio of existing and future assets. This warrants early consideration of later stages in the asset lifecycle. For example, in projects that involve the large-scale use of new and untried technology, design and future operating issues can be a very early focus in preparing a business case.

With a conventional project management perspective, the central concern is determining how to create the proposed asset once conceptualization and planning have reached a sufficiently well-defined point. Project management in these terms often begins with more detailed design planning and working to create and deliver the required asset at a detailed planning level. Approaches to project management have become increasingly sophisticated, particularly in respect of the design and construction of large physical assets such as infrastructure, buildings, processing plants, transport vehicles, etc. This has led to the development and formalization of the processes involved. Such formalization has encouraged the ‘projectification’ of all kinds of organizational initiatives in the hope or expectation that the application of project management techniques will bring about a more timely, beneficial and cost effective delivery of initiatives in an organization.

However, critics of conventional project management argue that the focus of project management has been much too narrow, with an overemphasis on execution and delivery of given asset specifications. Conventional project management techniques may help to deliver efficiently well-defined prespecified assets within a well-defined, relatively stable environment, but, critics argue, where asset design and construction is more fluid or uncertain, a wider perspective of associated uncertainty is needed. Further, in some contexts conditioning on (assuming fixed) cost and time, and treating performance as variable, may be more practical than conditioning on performance and treating time and cost as variables. In addition, critics argue that project management should encompass the ‘front end’ project definition phase – that is both the conceptualization and planning stages in Table 1.2 – and in particular that project management should include a concern for the operational benefits to be derived from a created asset, not just performance of execution and delivery. Morris (2009, p. 60) puts the argument as follows:

. . . shaping and delivering projects requires that directions be established, value optimized and opportunities created. Projects need to produce business value as well as deliver predictable outcomes. Both are needed. But whereas most project managers are happy to see themselves as efficient execution tacticians, the prize is for project managers to begin thinking about how the project, as it is developed, can enhance the value of the sponsor’s strategic position.

When considering the management of uncertainty from an asset lifecycle perspective, this wider view of projects and project management seems entirely appropriate, and even essential. In this sense the discipline and techniques of common practice project management may be considered of limited use in managing strategy or programmes, leading to excessive separation of strategy (primary project or programme) management and project management of the component projects. This separation may be formalized by organizational structures, and may increase the chances of the uncertainty management of component projects being treated separately from the consideration of strategic uncertainty, risk and opportunity. An obvious example is a contracting organization where the ongoing business involves tendering for individual contracts. Each contract won is treated as a project, and these contracts form a mixture of the chain and parallel configurations in Figure 1.1. Interdependencies exist between contracts to the extent that they utilize common corporate knowledge, skills and other resources. An important task for senior management is to manage the (often implicit) primary project – the organization’s short and long-term strategy. Unless this is managed explicitly at ‘the top’, strategy is likely to emerge ad hoc and ‘bottom-up’ in an unintended rather than deliberate manner (Mintzberg, 1978).

A lifecycle stage structure with a ‘purpose’ focus

Characterization of the asset lifecycle as four sequential stages starts to indicate the scope of the basic tasks involved from operations, corporate and project management perspectives and the associated scope of uncertainty that warrants attention. However, a more detailed consideration of the four basic stages of conceptualization, planning, execution and delivery, and utilization with a purpose focus as portrayed by Table 1.3 provides deeper insight into the scope of decisions involved in different parts of the lifecycle: the goals being addressed; the identity of the main players; and the extent and nature of the uncertainty involved. In particular, elaborating Table 1.2 as Table 1.3, suggests three areas of concern.

Table 1.3 A 12-stage nominal project (asset/change) lifecycle with a purpose focus

First, it is important to distinguish between strategic planning for operations, project execution and corporate strategy purposes. They are related but involve different purposes – a different ‘why’ in Kipling’s terms, with implications for the ‘who’.

Second, it is important to distinguish between strategic and tactical planning for all purposes, and to ensure that all strategic planning precedes all tactical planning. Strategic and tactical planning also serve different purposes and often involve different people. In our terms ‘strategic planning’ must include detailed design and detailed planning to test strategy when appropriate, but detailed design and planning for execution, delivery, operations and termination purposes is associate with ‘tactical planning’. It is often useful to recognize an important boundary after the strategy gateway stage, when ‘strategy shaping’ ends and strategy implementation begins with ‘tactics shaping’, especially if a contractor responsible for execution and delivery is also given responsibility for detailed planning for execution and delivery purposes. Separating detailed planning to test strategy when appropriate, and detailed planning to implement strategy, helps to facilitate clarity about this boundary.

Third, it is important to understand the difference between ‘evaluation’ for corporate governance approval purposes and ‘evaluation’ for internal control of a management process designed to be iterative – again a different ‘why’ and ‘who’ are involved.

The second column of Table 1.3 breaks down the basic four-stage characterization of the asset lifecycle. It uses eight stages with traditional lifecycle stage functions. It also uses four ‘gateway’ processes involving consolidation of plans to date and associated governance, usefully treated as if they were stages. This makes 12 stages in total. It does so in a way that explains the key objectives or ‘purpose’ of these 12 component stages – the ‘why’. The reason more divisions than the traditional basic four are useful is that greater clarity about the purpose of each stage leads to simpler and more effective processes. Simple and effective processes are goals that matter.

For simplicity we will often refer to ‘the project lifecycle’ or just ‘the lifecycle’, with the default meaning ‘the project (asset/change) lifecycle of Figure 1.3’ – all 12 notional stages or some comparable equivalent. However, sometimes we will use ‘asset lifecycle’ to emphasize that we are talking about the whole lifecycle from a client’s corporate perspective. Further, sometimes it is important to recognize that some people may use a ‘project lifecycle’ that starts much later and ends much sooner – for example, a contractor hired to complete a task within one or two stages of a broader client’s perspective of ‘the project’ is working with different lifecycle and project concepts.

Figure 1.3 The role of the performance lens and the knowledge lens to visualize uncertainty

The third column of Table 1.3 breaks each stage into ‘steps’. The breakdown into stages goes some way towards highlighting important sources of uncertainty and facilitating their management as well as clarifying different purposes. However, the more detailed description of the lifecycle provided by the steps in Table 1.3 is useful to underline where particular sources of uncertainty arise in the lifecycle and how uncertainty management might be most effective. In the early lifecycle stages these steps imply a process of gradually increasing detail and a focus on the nature of the deliverable asset. Later steps focus on delivery and operation of the asset followed by termination in the sense of decommissioning or selling an asset.

For reference purposes the column two ‘stage purpose’ descriptions are abbreviated to lifecycle stage ‘labels’ in column four. There is a good argument for adding the word ‘strategic’ to all the labels for the first five stages – they are all focused on strategy, and a constant reminder can be useful in some contexts. There is also a good case for using ‘overall strategy gateway’ as the label for the sixth stage. Further, the design and operations management perspective of the DOT-shaping stage versus the more traditional project management perspective of the E&D-shaping stage may need emphasis sometimes. Finally, the DOT label does not have its common USA interpretation ‘Department of Transportation’ – an illustration of the virtually impossible task of always using uniquely identified acronyms. However, the labels adopted here are as simple as possible while avoiding obvious ambiguity. They are nominal in the sense that if additional words or alternative labels will make communication clearer, such adaptation is clearly desirable and should be used. This notion applies to much of our recommended terminology – there is no need to be dogmatic about terminology provided everyone understands what is being said – it is the concepts that really matter. Using minimal labels when the meaning is clear, but adding additional words for clarity whenever this might be useful, is a policy adopted throughout this book. It is also a policy which is highly recommended as a corporate strategy. In our experience simple ‘handles’ are a form of jargon practitioners need for efficient communication when they all understand each other, but such jargon can seriously impede effective communication when they do not, and effectiveness can be the key.

The lifecycle structure of Table 1.3 is also nominal in the sense that alternatives can be used whenever appropriate, but effective uncertainty management should not oversimplify any of the distinctions that matter.

Any organization adopting the uncertainty management approach advocated in this book may wish to preserve features of lifecycle structure variants from Table 1.3 for a range of corporate reasons which go beyond the purposes of project uncertainty management. However, this book assumes that the features of the Table 1.3 nominal structure will be preserved, in the sense that compatible expansion of the components may be involved for other purposes, but not a collapse of components which would lead to confusion. An agreed synthesis of Table 1.3 or equivalents, with appropriate simple labels for all stages, is an essential aspect of full integration of project uncertainty management with all other aspects of project management, including integration with operations and strategic concerns. Table 1.3 is a nominal framework because it may need simplification or elaboration according to the context in which it is used.

Concept shaping

The concept shaping stage involves strategic planning from a corporate perspective, although it may be initiated top-down or bottom-up. Top-down is often assumed, but bottom-up is often a more important source of strategic initiatives – a marketing department sees new market opportunities, a research and development department sees new product opportunities, a production department sees new manufacturing process possibilities, and so on. This stage involves identifying a deliverable asset to be produced by a project and the benefits expected from the deliverable. In essence, this involves an innovation process that begins with a ‘trigger event’ (Lyles, 1981), when a member of an initiating organization perceives an opportunity or need for a new asset or an organizational change. At this point the project deliverable may be only a vague idea, and some initial development may be associated with the ‘concept capture’ step. ‘Clarification of purpose of the possible asset’ should involve the identification of operational performance objectives and their relative importance to relevant stakeholders, and associated design and delivery criteria. This step may be problematic to the extent that different views about the appropriate objectives are held by influential stakeholders who try to negotiate mutually acceptable objectives. At this stage objectives are likely to be ill-defined or developed as aspirations expressed as constraints (for example: latest completion date, minimum levels of functionality, maximum capital cost, and so on).

Before the concept can be developed further, in ‘concept elaboration’ and ‘business case development’ steps, sufficient political support for the idea must be obtained and resources allocated to allow the idea to be refined and made more explicit. Other individuals, organizations or potential stakeholders may become involved. At this stage support from stakeholders may be passive, merely allowing conceptualization to proceed, rather than an expression of positive approval of the project.

Eventually an evaluation of the asset concept, objectives and business case, as defined to date, becomes necessary. The last step for the concept shaping stage is an internal evaluation by the team responsible for concept shaping at this point. It purpose is iteration control. Evaluation for iteration control purposes here (and in later stages) is not simply a ‘yes/no’ or ‘go/no-go’ decision – a ‘maybe’ possibility is very likely and should be anticipated for early iterations, when a ‘maybe’ decision involves a planned iteration through one or more previous steps. For reasons explored later, it is not cost effective to manage uncertainty using a single-pass process. Early passes are about sizing uncertainty, asking ‘Does it matter?’ Later passes are about ‘Where it matters most, what would be the best way to approach managing it?’ A ‘go’ decision takes the process on to the next stage. A ‘no-go’ decision causes further investment in the project to stop, possibly subject to governance confirmation, or possibly a pause in the project’s evolution rather than its elimination.

Concept gateway

It is useful to separate the concept gateway stage because it serves a very different purpose from concept shaping. The parties initiating and controlling the concept shaping stage should be taking a corporate perspective, but they are likely to have views of what matters most which are rooted in particular parts of the organization. The concept gateway is about consolidating the plans as shaped in the first stage for communication outside the concept stage team followed by appropriate governance – ensuring that a balanced overall corporate perspective decides whether more money and effort should be invested in developing plans for the asset or not. A ‘maybe’ decision is a possibility, but a resulting iteration is unplanned and usually unwelcome. A ‘no-go’ decision may be the appropriate choice, and no loss of reputation for anyone involved may be appropriate. A ‘go’ decision takes the lifecycle on to the next stage.

Design, operations and termination (DOT) shaping

DOT shaping initiates design, operations and termination strategy formulation, beginning with design and operations strategy capture from the corporate strategy of the concept shaping stage. This usually requires a step increase in the effort and resources involved. The sequence of the words ‘design’ and ‘operations’ reflects the usual precedence ordering, but future operation of the proposed asset or corporate changes might be addressed before design to emphasize the importance of future operations at this stage in the lifecycle, with step titles indicating that design is operations-led in practice.

‘Development of lifecycle performance criteria’ builds on the basic design and operations objectives from the first stage. For many projects this involves refining such objectives, but it may involve the identification of additional objectives and further negotiation where pluralistic views persist among relevant stakeholders. This step influences an ‘integrated development of design, operations and termination’ that leads to ‘integrated evaluation of design, operations and termination’ using the developed performance criteria to assess the current asset design in ‘go/no-go/maybe’ terms.

As in the concept stage, a ‘no-go’ evaluation should kill the project or put it on hold. A ‘maybe’ evaluation is most likely to lead to iteration through one or more development steps, and such loops should be expected planned iterations, because this is the most effective way to manage uncertainty. If fundamental difficulties that were not anticipated in the concept stage are encountered, the concept stage may be revisited, but this is an unplanned iteration. A ‘go’ decision takes the lifecycle on to the next governance gateway stage.

Building any relevant termination considerations into the design and operations strategy needs attention in this stage if this was not addressed earlier.

Design, operations and termination (DOT) gateway

The DOT gateway is a consolidation process followed by a governance process with the same role as the concept gateway – deciding whether more money and effort should be spent on proceeding to planning for execution and delivery from a balanced perspective considering overall corporate strategy. A ‘maybe’ decision is a possibility, but a resulting iteration is unplanned and usually unwelcome. A ‘no-go’ decision may be the appropriate choice, with possible loss of reputation issues if the first gateway ‘go’ was a clear mistake. A ‘go’ decision takes the lifecycle on to the next stage.

Execution and delivery (E&D) shaping

The E&D shaping stage initiates formal capture and development of activity and resource use plans at a strategic level, indicating how the asset design will be executed and delivered, and the resources that will be required by these activities in broad terms. ‘Development of delivery targets and milestones’ involves reconciling how long execution and delivery should take and how long various parties would like it to take. Even more individuals and organizations may become involved. ‘Strategic plan development for execution and delivery’ follows. This leads to ‘evaluation of execution and delivery strategy’ in ‘go/no-go/maybe’ terms.

A ‘maybe’ decision may require further development of strategic plans, including targets and milestones within the E&D-shaping stage, as part of a process planned to be iterative because this is the most effective way to manage uncertainty. More fundamental difficulties may take the process back to asset design and operations strategy development, or even to concept development, but this would be an unplanned iteration. A ‘no-go’ decision kills the project or puts it on hold, usually subject to gateway approval. A ‘go’ decision takes the lifecycle on to the next gateway stage.

Strategy gateway

The strategy gateway is a consolidation process followed by a governance process with the same role as the earlier gateways – deciding whether more money and effort should be spent on the project from a balanced perspective considering overall corporate strategy. However, this time the ‘overall strategy gateway’ can be a useful label extension because all relevant aspects of strategy are involved. This includes E&D strategy as shaped by the preceding stage plus updates to asset design, operations and termination strategy as defined at the DOT gateway. It also includes updates to the overall concept and business case strategy as initially defined at the concept gateway and possibly updated at the DOT gateway. Further, the overall strategy gateway is a significant ‘watershed’, a stage where turning around later means significant extra effort, because expenditure on the project grows at an increasing rate from now on if it progresses. A ‘maybe’ decision is a possibility, but a resulting iteration is unplanned and unwelcome. A ‘no-go’ decision may be the appropriate choice, with possible loss of reputation issues if either of the first two gateway ‘go’ decisions were a clear mistake. A ‘go’ decision takes the lifecycle on to the next stage, but later ‘no-go’ or ‘maybe’ decisions could be severely ‘career limiting’.

Tactics shaping

Tactics shaping involves an important shift in perspective – to the implementation of a strategy which is assumed to be robust and viable. ‘Shifting the perspective to implementation’ is a useful first step to ensure that everyone involved appreciates this transition.

Separate tactics shaping is needed for asset design, execution, delivery, operations and support, then termination – in that order of priority. Operations tactics shaping might be delayed for some time – provided the design strategy does not need to be revisited – and does not need to be completed until the O&S stage is about to begin. Termination tactics shaping can be deferred until needed for the termination phase. A detailed allocation of resources and contracts to achieve the design and implement the execution activities is part of the initial priorities. But it is useful to begin with the ‘development of detailed design and plan criteria’. This includes issues such as clarifying the level of detail needed, and the extent to which those executing the project can be left to ‘plan as they go’ as part of execution. Subsequent ‘detailed plan development’ has to build on this basis.

The tactics shaping stage is a significant task involving decisions about execution and delivery organization, identification of appropriate participants and allocation of tasks between them. Resource allocation and associated contracting with a view to project execution requires much more detail than earlier stages.

Either implicitly or explicitly, the tactics shaping stage involves the allocation of execution uncertainty and associated risk and opportunity between participants unless this has been done earlier. Risk and opportunity allocation is an important source of project uncertainty because it can significantly influence the behaviour of participants and hence impact on project performance – and how best to do it is itself often very uncertain. In particular, allocation of execution and later stage uncertainty influences the extent and manner in which such uncertainty is managed. This warrants careful consideration of the basis for allocating tasks, uncertainty, risk and opportunity in the ‘development of resource allocation and contracting criteria’ step.

‘Detailed plan development’ necessarily involves revising detailed design and planning in order to allocate tasks unless this whole stage is contracted out along with the balance of the project. Contract and subcontract structures may require development. Indeed, in some cases ‘tactics shaping including contracting’ would be a better label for this stage, unless contracting was addressed earlier – as in design and build or design, build and operate contracts (with or without a ‘transfer’ stage), which should be addressed initially in the concept-shaping stage.

The nature of the issues changes with the change of stage as with all earlier stage transitions, and the level of effort escalates as noted earlier.

As in the earlier lifecycle stages, development during this stage is followed by a ‘detailed design and plan evaluation’. A ‘maybe’ decision which requires revisions to aspects of detailed designs or plans should be seen as part of the iterative process of shaping details effectively and efficiently – a planned iteration. A ‘maybe’ decision which involves changes at a strategic level to execution and delivery plans, design and operations strategy, or concept strategy, is usually extremely unwelcome, and a ‘no-go’ decision will be seen as a serious disaster in many cases. If the ‘devil is in the detail’, earlier shaping and governance evaluation steps will be seen to have failed unless the environment in which the organization operates has changed to an extent that even risk efficient and robust planning could not have anticipated.

Tactics gateways and a start of execution gateway

Tactics gateways for various aspects of detailed designs and plans provide a pre-execution consolidation of plans and a governance check on internal evaluations used initially for iteration control. They have to assess detail in the context of corporate, operations and project strategy when appropriate. A ‘start of execution’ gateway can be a useful summary concept for all details gateways relevant to a ‘start of execution’ decision – a recommended enhancement of the nominal Table 1.3 structure.

Separation of consolidation and governance in the four gateway stages

Separation of the four gateway stages from the shaping processes leading to them has benefits which will become clear when the details are considered later, if they are not clear now. One key benefit is distinguishing between planned iterations, which are an inherent aspect of effective uncertainty management, and unplanned iterations due to earlier shaping and governance evaluation failures. Other aspects include distinguishing the responsible party and the purpose of the exercise, the processes used, and the outcomes of the processes. There is a growing concern about the effectiveness of common practice governance processes. One key issue worth noting now is that governance should test the validity of all plans and associated decisions as well as the processes used to develop the plans and make the decisions. Put slightly differently, it should consider all relevant assumptions – working assumptions and framing assumptions.

Separation of three aspects of strategic planning and all tactical planning

The decomposition of the Table 1.2 ‘planning stage’ into six stages helps to distinguish the very different management purposes and attendant issues in all eight of the stages considered above. A possible argument against this decomposition is the interdependent nature of the eight stages, and the need to iterate between them. However, the importance of this dependence, and the process threats and opportunities it generates, is highlighted by their separation. Each stage involves quite different tasks, different goals and end products, different levels of detail in some cases, and different sources of process uncertainty. The importance of decisions to move from each stage to the next increases with each successive stage, because the costs of going back a stage or more escalates. This makes it important to treat the planning stages as separable, while recognizing important interdependencies between them.

There is a very strong case for a clear boundary between the overall strategy gateway and tactics shaping, provided strategy is effectively tested by detailed planning on a selective basis when appropriate. Given this proviso, there is a good case for allowing tactics shaping and associated gateways to overlap execution in those areas where this will not lead to delay. For example, shaping tactical plans for the operations stage or the termination stage can wait until they are needed, and some areas of detailed design or tactics shaping for execution may overlap the execution stage.

Assuming a strict boundary can simplify the nominal lifecycle structure. Its relaxation may be important in practice, but the resulting risk needs to be understood.

Execution

The start of the execution stage initiates the main work of the project from the project manager’s perspective. The start of this stage signals the start of order-of-magnitude increases in effort and expenditure. The planning is over, the action begins. The four individual steps in this stage are obviously basic project management; they are not worth detailed development here, other than noting that all plan revisions can be supported by a variant of the steps used earlier.

During execution, the essential process threat is that coordination and control procedures prove inadequate. A common perceived threat in the execute stage is