loops within each stage. Primary feedback involves costs, but should be cost- effective if limited and therefore welcome. ‘Secondary’ and ‘tertiary’ feedback loops indicate more costly feedback, to be avoided if possible. The execute stage A go decision in the allocate stage initiates the main body of the project—the execute stage. The start of this stage signals the start of order-of-magnitude increases in effort and expenditure. The planning is over; the action begins. During execution, the essential process threat is that co-ordination and control procedures prove inadequate. A common perceived threat in the execute stage is the introduction of design changes, but these may be earlier sources of uncer- tainty coming home to roost, including opportunities that should have been spotted earlier to take full advantage of them. Consequent adjustments to pro- duction plans, costs, and payments to affected contractors ought to be based on an assessment of how project uncertainty is affected by the changes and the extent to which revised risk management plans are needed. For most projects, repeated iteration will be necessary through the steps within the execute stage. Exceptionally, loops back to earlier stages may be necessary. Big surprises, including major opportunities missed earlier, could take some aspects of the project right back to the concept stage or lead to a no-go decision, including project abortion. Both nasty and pleasant surprises are realized sources of uncertainty from earlier stages that were not identified, in- dicating a failure of the risk management process in earlier stages. The rationale for separate deliver, review, and support stages The project ‘termination phase’ of Table 2.1 involves three distinct aspects, captured in the deliver, review, and support stages, each encompassing different risk management concerns. The rationale for their separation, and no further separation, has the same form as the argument for separ ation of the design, plan, and allocate stages. However, argua bly the case for separation is even stronger in terms of the very different nature of these stages. The deliver stage The deliver stage involves commissioning and handover. Again the issues are different from previous stages. The ‘basic deliverable verification’ step involves verifying what the product of the project will do in practice—its actual perform- ance as distinct from its designed performance. An important threat is that the deliverable fails to meet expected performance criteria. Modification of product performance may be achievable, but modification of performance criteria or Eight stages 23 influencing stakeholder expectations and perceptions may be necessary. However, unless they were explicitly anticipated these are not sources of process uncertainty in this stage, they are a realization of earlier unmanaged sources of uncertainty. ‘Delivery evaluation’ focuses on the need for quality assessment and modification loops, including compensating for unanticipated weaknesses by developing unanticipated strengths. Loops back to the concept stage or a no-go abort decision are still possible. The basic process threat is being unable to ‘make the best of a bad job’. The basic process oppor tunity is making the best of ‘delighting the customer’. The review stage The review stage involves a documented audit of the project management process after delivery of the product. Some lessons will be obvious—the ‘basic review’ starting point. But allocating resources to systematic study to draw out lessons that were not obvious—‘review development’—is important. Missing important lessons means the same mistakes will be made again—the key source of process uncertainty in this stage. Not having such a stage explicitly identified almost guarantees the realization of this source of uncertainty. Hind- sight may suggest some actions were successful, or not, for unanticipated reasons. Such occurrenc es ought to be noted for future reference. An important aspect of the review should be documentation of the manner in which perform- ance and other criteria relevant to each project stage developed—in particular the rationale for any changes. ‘Review evaluation’ involves evaluating the likely relevance and usefulness of review data for informing future project management practice. Unlike evaluation steps in previous stages, the review stage as conceived here is not concerned with the possibility of aborting the project or loops back to earlier stages. As indicated in Figure 2.1, the purpose of review evaluation is to inform practice on other projects. A positive, ‘opportunity management’ approach to the review stage is important, with the emphasis on capturing good practice and rewarding the deserving, not highlighting bad practice and punishing the guilty. The support stage The support stage involves living with the product—the ongoing legacy of apparent project ‘completion’, possibly in a passive ‘endure’ mode—until the product of the project is discarded, decommissioned, or otherw ise disposed of. ‘Basic maintenance and liability perception’ is the starting point when the project is complete in the handover sense, noting that handover may be an internal matter in organizational terms. ‘Development of support criteria’ and associated ‘support perception development’ leads to ‘support evaluation’, which may be repeated periodically. The focus of this evaluation may be a within-stage loop 24 The project life cycle back to development of perceptions or a limited loop back to the deliver stage. Exceptionally, the outcome could be a no-go decision involving product with- drawal or other explicit withdrawal of support for the project’s product. Again, surprises are not sources of uncertainty inherent in this stage, but sources of process uncertainty in earlier stages realized in this stage. Elaborations to the eight stage framework Despite the number of steps in Table 2.1, and the possibility of iteration at each evaluation step, our description of the PLC is still a simple one by comparison with the complexities of real projects. Nevertheless, it is a useful basic framework that can be built on in various ways, illustrated by the following elaborations. Separable project dimensions In practice, projects are planned and executed in several dimensions that are separable to some extent: physical scope, functionality, technology, location, timing, economics, financing, environmental, and so on. This means that each step in Table 2.1 could be viewed as multidimensional, with each step consider- ing each dimension in parallel or in an iterative sequence. In this latter case, the PLC might be visualized as a spiral of activities moving forward through time, where each completed circle of the spiral represents one step in Table 2.1 completed and each spir al represents sequential consideration of the various project dimensions. Charette (1993) uses similar notions in a related context. Parallel components Many projects, especially large ones, may be ma naged as a set of component projects running in parallel. The steps in Table 2.1 can still be used to describe the progress of each component project, although there is no necessity for the component life cycles to remain in phase at all times. ‘Fast-tracking’ is a simple example of this, where completion of the parent project can be expedited by overlapping project design, plan, allocate, and execute stages. This implies that some components of the parent project can be designed and planned, and allocation and execution commenced for these components, before designing and planning is complete for other components. As is widely recognized, such staggered execution is only low risk to the extent that the design of components first executed is not dependent on the design of subsequent components. Plans that involve an element of ‘fast tracking’ should be supported by an appropriate RMP, with a focus on feedback from more advanced components into the life cycle steps of following components. Elaborations to the eight stage framework 25 Objectives not easily defined For many projects objectives and related performance criteria can be refined progressively through the conceive, design, plan, and allocate stages of the PLC. However, in some projects (e.g., information systems or software develop- ment projects), it may not be practicable to ensure that all project objectives are well defined or crystallized prior to the execute stage. This becomes apparent in earlier stages, where go decisions acknowledge the situation. In this scenario ‘control evaluation’, undertaken each time a milestone is achieved, ought to include a ‘configuration review’ (Turner, 1992; Turner and Cochrane, 1993) of objectives currently achievable with the project. If these are unsatisfactory, further stages of design and plan may be necessary. Contracting When allocation of tasks in the allocate stage involves the employment of con- tractors, the tendering and subsequent production work of the contractor can be regarded as a component project in its own right. For the contractor, all the steps in Table 2.1 are passed through on becoming involved in the parent project. What the client regards as the allocate stage is regarded by the contractor as the conceive, design, plan, and allocate stages. In the case wher e the contractor has a major responsibility for de sign (as in turnkey or design-and-build contracts), the client will move quickly throug h the conceive, design, and plan stage s, perhaps considering these stages only in general outline terms. Then the contractor carries out more detailed work corresponding to these stages. For the contractor’s project, the ‘trigger’ involves both a need and an opportunity to tender for work, usually managed at a high level in the contracting organization. The conceive stage corresponds to a preliminary assessment of the bidding opportunity and a decision to tender or not (Ward and Chapman, 1988). This is followed by costing design specifications and plans provided in more or less detail by the client, perhaps some additional design-and-plan development, evaluation of the tender- ing opportunity, price setting, and submission of a bid. For the contractor’s project, the allocate stage involves further allocation of tasks, perhaps via sub- contracting, detailed design work and produc tion scheduling as indicated above. Incomplete definition of methods In some projects, such as product development projects, it may not be practic- able to define completely the nature or sequence of activities required prior to commencing the execution phase (Turner and Cochrane, 1993). In such cases management expects design, plan, allocate, and execute stages to take place alternately on a rolling basis, with achievement of one milestone triggering detailed design, plan, allocate, and execute stage s of the next part of the 26 The project life cycle project deliverable. In this scenario, previous go decisions in the design, plan, and allocate stages are made on the understanding that subsequent control evaluation steps will send the process through further design, plan, and allocate stages as necessary when the appropriate milestone has been achieved. In effect, the design, plan, allocate, and execute stages are managed as a sequence of miniprojects. Prototyping is a special case of this scenario and a natural approach where the intention is to mass-produce a product, but the product involves novel designs or new technology. For the production project, the PLC conceive and design stages are managed as a prototype project (with its own PLC). On completion of the prototype, the production PLC proceeds from the plan stage through to the support stage in Table 2.1. The value of a detailed stage–step structure The value of a basic PLC structure at the level of detail used in Table 2.1 might be questioned on three grounds: 1. these steps and stages will be difficult to distinguish cleanly in practice; 2. in practice some of these steps may not be necessary; 3. this level of detail adds complexity, when what is required to be useful in practice is simplification. For example, it might be argued that some of the later evaluation steps may be regarded as non-existent in practice because the decis ion to proceed is not usually an issue beyond a certain point. However, we would argue that it is worth identifying such steps beforehand, given their potential significance in managing sources of process uncertainty. Many of the really serious sources of project uncertainty are late realizations of unmanaged uncertainty fro m earlier project stages. The detailed stage and step structure of Table 2.1 and the associated Figure 2.1 hel p to make this clear. In many projects there is a failure to give sufficient attention to go/no- go/maybe decisions. Such decision s should involve careful evaluation of uncertainty, both to appreciate the sources of uncertainty inherent in a go decision and the rewards forgone in a no-go decision. Equally important is the need to recognize when a go/no-go or maybe choice should be on the agenda. Many projects appear to involve just one go/no-go decision—at the end of the conceive stage. Yet the large number of projects that run into major problems of cost escalation, time overruns, and quality compromises suggests that explicit go/ no-go/maybe decision points in later stages would often have been worthwhile. A further reason for the detailed step structure is to highlight the process of objectives formation and its significance for project risk management. As noted in The value of a detailed stage–step structure 27 Chapter 1, risk is measured in terms of uncertainty about the attainment of project objectives. In the PLC, objectives and performance criteria are often initially vague for good reasons, but they must be progressively clarified and refined during the conceive, design, plan, and allocate stages. This process needs to be recognized and the implications understood. A situation where the objectives of a project change imprecisely during the project without proper recognition of the new situation implied is particularly risky. From a risk manage- ment viewpoint, any changes in objectives and performance criteria at any stage of the PLC need to be carefully evaluated for risk implications. Beyond a single-project perspective As well as recognizing the detailed internal structure of individual project life cycles, it is also important to recognize the role of a project as part of a larger, corporate picture. Projects are invariably embedded in a wider context, which involves other projects. Three basic context structures are the chain configura- tion, the parallel configuration, and the project hierarchy. Figure 2.2 illustrates these configurations. In the chain configuration a sequence of component projects follow one another over time to complete an overarching, primary project. In the parallel configuration a number of component projects run in parallel, perhaps with interdependencies, to complete an overarching, primary project. In either case the ‘primary project’ may be thought of by senior management, in terms that go beyond that associated with individual component projects, as a strategy or long- term programme, using ‘programme’ in the ‘portfolio of proj ects’ sense, with links between the component projects defined by shared objectives, resources, or other issues. The discipline and techniques of project management may be considered of limited use in managing strategy or programmes in this sense, leading to a 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 risk management of component projects being treated separately from consideration of strategic risk. 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 configura- tions. 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). 28 The project life cycle In a project hierarchy the ‘primary project’ is broken down by management into a hierarchy of component projects. The project hierarchy shown in Figure 2.2 is a simple example with embedded parallel and chain configurations. Much more complex configurations involving a combination of these three configura- tion types exist in most organizations. Large engineering or construction projects are invariably managed as project hierarchies. As noted earlier, large projects may be managed as a set of com- ponent projects running in parallel, with each parallel component comprising a hierarchy of component projects. Management of the ‘pr imary project’ can be Beyond a single-project perspective 29 Figure 2.2—Configuration of project systems 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 make sure the component projects fit together as a whole. To achieve this they need to pay special attention to how the six Ws of each of the various component projects fit together, with obvious implications for managing risk. More generally, a project hierarchy can be thought of as a hierarchy of an organization’s long-, medium-, and short-term planning activity. In a top-down approach, long-term strategy leads to the development and implementation of medium-term projects. These may be achieved by a programme of short-term projects or may otherwise constrain 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 potential impacts on their projects from both short-term and long-term issues. Example 2.1 Planning projects at different levels in an electric utility An electric utility, providing electricity to a set of private and corporate consumers, might start with a corporate level assessment of annual profit P t , equal to annual revenue R t , less annual costs C t , for t ¼ 1, 2, , n,up to the chosen long-term planning horizon. Revenue might be a key source of uncertainty, worthy of major risk management effort. Forecast demand might be important here, but existing competing utilities, possible new competitors, market regulators, and other political players may be important parties to consider. Cost might also be important. At the corporate level, cost may be 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 an operational level, management is concerned with the 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. Sudden failure of an existing unit may trigger a need to bring plans forward. Political events may alter the need for a planned unit significantly, perhaps even eliminate the need for a unit, possibly doing so when construction of the unit is already under way. 30 The project life cycle 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 he or she is responsible for and ensure that the sources of uncertainty other members of the organization are responsible for are managed in a supportive manner. Motivation to unde rtake risk analysis in a top-down strategic manner needs to come from the organization’s board level managers. This involves issues beyond the scope of this book, but discussed elsewhere (Chapman and Ward, 2002, chap. 11, develops Example 2.1). However, even if a project manager’s organ- ization chooses to ignore such issues completely, a competent project risk manager should not do so. At the very least, it is important to identify the complete set of corporate risks that impact on the project manager’s project and may require responses from the project manager or other parties. For some purposes and from some perspectives, it can be important to distinguish project management and programme management, to see whether uncertainty is an issue or not. For example, see CCTA (1995a, b, and 1999). We will not develop this distinction for risk manageme nt pu rposes in either/or terms, but treat programmes as the strategic end of a strategy–tactic or programme– project dimension that characterizes projects in an important way for RMP purposes—a driver that should shape the nature of the RMP used, directly comparable in this sense with the stage in the PLC. Conclusion To be fully effective, risk management needs to address the whole PLC rather than selected stages, guiding and informing each and every stage of the PLC. The scope and depth of analysis should increase as the project progresses toward the execute stage. Prior to each stage a preliminary risk analysis should guide the first step, but as more details and options are considered in subsequent steps, further risk analysis should be performed with increasing detail and precision to continuously guide and inform the project management process. Risk manage- ment should be an integral part of project management at each stage of the PLC, designed to accommodate the focus of each stage in an integrated, holistic manner. Taking a wider perspective, any designated project is but a particular refer- ence point in a larger sys tem, affected by the wider system, and with potential to affect the wider system in turn. A key management issue, with risk management implications, is the degree of interdependency between (component) projects. The desirability of an approach to risk management that addresses the overall system increases dramatically as the interdependency between projects increases. Conclusion 31 [...]... formal risk management processes joint management, as addressed later and further explained in Chapman and Ward (20 02) Further, risk efficiency in this multiple attribute sense links project risk management to project value management, project quality management, and so on project management in toto The objective is jointly optimizing the design associated with a project, the duration of the project, ... proportionate increase in the expected cost of all projects In these terms an aggressive approach to risk taking at a project level is part of a risk efficient approach to corporate level risk management IBM UK developed project risk management in the early 1990s to facilitate taking more risk, not less, to exploit this perception of corporate risk management, and both authors of this book were involved in a linked... cost risk Later work with IBM UK made it clear that in the context of an ongoing portfolio of projects, choosing between D, E , F , and G is better viewed as a matter of corporate level risk efficiency, as distinct from the project level of risk efficiency involved in defining these plans That is, corporate risk efficiency means never reducing risk for a project by increasing expected cost when the risk involved... documentation can clarify the initial thinking process If people have to set down their thinking in writing, this forces clarification of what is involved 2 Clearer communications Documentation can provide an unambiguous vehicle for communication at any given point in time If people explain what they mean in terms of designs and activities, sources of uncertainty and responses, and in writing in detail, the scope... scope for opportunity management in the context of uncertainty that includes ambiguity is fully realized Project risk management is about doing the right things in every sense, as well as doing them the right way—effectiveness as well as efficiency in general terms Risk efficiency in a multiple attribute sense embraces all of this in a holistic and integrated manner Trade-offs between risk and expected performance... later uncertainty, risk, and overall expected cost, but more fundamental lateral thinking may be key Example 1 .2, turning a threat into an opportunity by managing potential delays in a way that improved the project s cash flow, is a good example If a project s plans are not risk efficient, any lack of effectiveness and efficiency in general terms will reveal itself as risk inefficiency Diagnosis of potential... Reactive crisis management is not eliminated but is reduced to a tolerable level For years we have suggested to seminar audiences that good formal risk analysis processes are 52 Motives for formal risk management processes not inhibiting, that they are not about ‘doom and gloom’, but they are about creative thinking, seizing opportunities, and having fun The acid test of a good risk management process... proactive risk management that in the event proves unlucky The general cultural issue is concerned with distinguishing between good luck and good management, bad luck and bad management, in order to persuade people to take the right risks and avoid the wrong ones, in risk efficiency and risk/ expected performance trade-off terms Particularly at middle and lower levels of management involving decisions that risk. .. definition of risk, the key to the difference is treating opportunities and threats—or events, conditions, and circumstances—as sources of uncertainty that cause risk, rather than as risk in themselves A holistic and integrated approach to risk management requires this perspective, and risk management without it is severely crippled, be it project risk management, safety management, or any other form of risk. .. knowledge in a manner useful for subsequent similar project teams If the kernel of the thinking behind one project is available in a readily accessible form for those doing the next project, the value of this information can be very great For contracting organizations this information can amount to a competitive advantage over rival firms Such information can also be the basis of ongoing training as well . running in parallel, with each parallel component comprising a hierarchy of component projects. Management of the ‘pr imary project can be Beyond a single -project perspective 29 Figure 2. 2—Configuration. may be worth pursuing in their own right: 1. Clearer thinking. A focus on documentation can clarify the initial thinking process. If people have to set down their thinking in writing, this forces clarification. developed briefly at various points in later chapters, and in more detail in Chapman and Ward (20 02) . Risk efficiency A central reason for employing formal risk management is the pursuit of risk efficiency’.