Project Risk Management best practices

project risk management exam questions and answers pdf and project risk management notes and project risk management roles and responsibilities pdf free download
Dr.MattWood Profile Pic
Dr.MattWood,United States,Teacher
Published Date:25-07-2017
Your Website URL(Optional)
Comment
Uncertainty, risk, and their 1 management 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 as a central feature of effective project management The need to manage uncertainty is inherent in most projects that require formal project management, using ‘uncertainty’ in the plain English ‘lack of certainty’ sense. Consider the following illustrative definition of a project: an endeavour in which human, material and financial resources are organised 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 (1992). This definition highlights the change-inducing nature of projects, the need to organize a variety of resources under significant constraints, and the central role of objectives in project definition. It also suggests inherent uncertainty related to novel organization and a unique scope of work, which requires attention as a central part of effective project management. Much good project management practice can be thought of as effective un- certainty management. For example, good practice in planning, co-ordination, setting milestones, and change control procedures seeks to manage uncertainty directly. However, most texts on project management do not consider the way uncertainty management should be integrated with project management more generally, in terms of a wide view of what a co-ordinated approach to proactive and reactive uncertainty management can achieve. Threats and opportunities A simplistic focus on project success and uncertainty about achieving it can lead to uncertainty and risk being defined in terms of ‘threats to success’ in a purely4 Uncertainty, risk, and their management negative sense. For example, suppose success for a project is measured solely in terms of realized cost relative to some target or commitment. Then both ‘un- certainty’ and ‘risk’ might be defined in terms of the threat to success posed by a given plan in terms of the size of possible cost overruns and their likelihood. From this perspective it can be a natural step to regard risk management as essentially about removing or reducing the possibility of underperformance. This is extremely unfortunate, because it results in a very limited appreciation of project uncertainty and the potential benefits of project risk management. Often it can be just as important to appreciate the positive side of uncertainty, which may present opportunities rather than threats. Two examples may help to illustrate this point. Example 1.1 Capturing the benefits of ‘fair weather’ North Sea offshore pipe laying involves significant uncertainty associated with weather. Relative to expected (average) performance, long periods of bad weather can have significant sustained impact. It is important to recog- nize and deal with this ‘threat’. It is also very important to recognize that the weather may be exceptionally kind, providing a counterbalancing op- portunity. Making sure supplies of pipe can cope with very rapid pipe laying is essential, for obvious reasons. Also important is the need to shift following activities forward, if possible, if the whole pipeline is fin- ished early. If this is not done, ‘swings and roundabouts’ are just ‘swings’: the bad luck is accumulated, but the good luck is wasted, a ratchet effect inducing significant unanticipated delay as a project progresses. Example 1.2 A threat resolved creates an opportunity The team responsible for a UK combined cycle gas turbine electricity project were concerned about the threat to their project’s completion time associated with various approvals processes that involved important novel issues. Gas was to be provided on a take-or-pay contract in which gas supply would be guaranteed from an agreed date, but gas not required from that date would have to be paid for anyway. This made any delay relative to the commitment operating date very expensive, the cost of such unused gas being in effect a project cost. The only response identified was to move the whole project forward three months in time (starting three months earlier and finishing three months earlier) and arrange for standard British Gas supplies for testing purposes if the project actually finished three months early. Using British Gas supplies for testing was a non- trivial change, because its gas composition was different, requiring different testing procedures and gas turbine contract differences. This response would deal with planning delays, the motivation for first suggesting it,Threats and opportunities 5 but it would also deal with any other reasons for delay, including those not identified. Further, it provided a very high degree of confidence that the combined cycle gas turbine plant would be operational very shortly after the main gas supply initiation date. But, of special importance here, this response made it practical to maintain the strategy of using British Gas supplies for testing, but move the whole project (this time including the main gas supply availability date) back in time (starting and finishing later) in order to time the take-or-pay contract date to coincide directly with the beginning of the peak winter demand period, improving the corporate cash flow position. The opportunity to improve the cash flow position in this way, while maintaining confidence with respect to the take-or-pay contract for gas, was deemed to be a key impact of the risk management process. The search for a way to resolve a threat was extended to the identification of a related but separate opportunity, and the opportunity was the key benefit of the process. These two examples illustrate the importance of opportunities as well as threats, the first in cost terms at an activity level, the second in cost and revenue terms at a project level. In the first example, if the implications of good luck are not seized and only bad luck is captured, the accumulated effect is reasonably obvious once the mechanism is understood, and it should be clear that this applies to all activities in all projects. The second example illustrates the benefits of creative, positive thinking, which looks beyond merely overcoming or neutral- izing a problem to associated opportunities. This aspect of problem solving is more subtle and is not widely understood, but it can be very important, in direct terms and from a morale point of view. High morale is as central to good risk management as it is to the management of teams in general. If a project team becomes immersed in nothing but attempting to neutralize threats, the ensuing doom and gloom can destroy the project. Systematic searches for opportunities, and a management team willing to respond to opportunities identified by those working for them at all levels (which may have implications well beyond the remit of the discoverer), can provide the basis for systematic building of morale. In any given decision situation both threats and opportunities are usually involved, and both should be managed. A focus on one should never be allowed to eliminate concern for the other. Moreover, opportunities and threats can sometimes be treated separately, but they are seldom independent, just as two sides of the same coin can only be examined one at a time, but they are not independent when it comes to tossing the coin. Courses of action are often available that reduce or neutralize potential threats and simultaneously offer opportunities for positive improvements in performance. It is rarely advisable to concentrate on reducing threats without considering associated opportunities, just as it is inadvisable to pursue opportunities without regard for the associated threats.6 Uncertainty, risk, and their management Recognizing this, guides published by the US Project Management Institute (PMI) and the UK Association for Project Management (APM) have adopted a broad view of risk in terms of threats and opportunities. Their definitions of risk are very similar, as follows: Risk—an uncertain event or condition that, if it occurs, has a positive or negative effect on a project objective—PMI (2000, p. 127). Risk—an uncertain event or set of circumstances that, should it occur, will have an effect on the achievement of the project’s objectives—APM (1997, p. 16). These widely used definitions embrace both welcome upside and unwelcome downside effects. In spite of this, there is still a tendency for practitioners to think of risk management in largely downside, threat management terms (a tendency that the authors are not always able to resist). It is important to keep ‘beating the drum’ to remind ourselves that we are dealing with the upside as well as the downside of uncertainty, with a balance appropriate to context. Even in a safety- critical context, when the downside has clear priority, it is a serious mistake to forget about the upside. Hillson (2002a) explores alternative definitions of risk with a focus on this issue, and Hillson (2002b) explores the trend toward a greater focus on opportunity management. Uncertainty about anything that matters as a starting point While we warmly endorsed the PMI and APM definitions with respect to their breadth in terms of threats and opportunities, we strongly resist the very re- stricted and limiting focus on ‘events’, ‘conditions,’ or ‘circumstances’, which cause effects on the achievement of project objectives. Rather than a focus on the occurrence or not of an event, condition, or set of circumstances, it is important to take uncertainty about anything that matters as the starting point for risk management purposes, defining uncertainty in a simple ‘lack of certainty’ sense. Uncertainty management is not just about managing perceived threats, opportunities, and their implications; it is about identifying and managing all the many sources of uncertainty that give rise to and shape our perceptions of threats and opportunities. It implies exploring and understanding the origins of project uncertainty before seeking to manage it, with no preconceptions about what is desirable or undesirable. Key concerns are understanding where and why uncertainty is important in a given project context, and where it is not. This is a significant change in emphasis compared with most project risk management processes.Uncertainty in projects 7 It could be argued that this starting point means we are talking about ‘risk and uncertainty management’ or just ‘uncertainty management’ (including risk management), not ‘risk management’. That is the direction we are taking (Chapman and Ward, 2002; Ward and Chapman, 2003), but the term ‘project risk management’ is too well established to be replaced widely in the near term and is retained for this book. Our publisher was understandably reluctant to change the title of a second edition while the first edition (Chapman and Ward, 1997) had sales that were very healthy and stable, one example of the inertia involved. But increasing the emphasis on opportunity management in an uncertainty management context is a key feature of this edition relative to the first. Uncertainty in projects The scope for uncertainty in any project is considerable, and most project management activities are concerned with managing uncertainty from the earliest stages of the Project Life Cycle (PLC), clarifying what can be done, deciding what is to be done, and ensuring that it gets done. Uncertainty is in part about ‘variability’ in relation to performance measures like cost, duration, or ‘quality’. It is also about ‘ambiguity’ associated with lack of clarity because of the behav- iour of relevant project players, lack of data, lack of detail, lack of structure to consider issues, working and framing assumptions being used to consider the issues, known and unknown sources of bias, and ignorance about how much effort it is worth expending to clarify the situation. In a project context these aspects of uncertainty can be present throughout the PLC, but they are particularly evident in the pre-execution stages, when they contribute to uncertainty in five areas: 1. variability associated with estimates; 2. uncertainty about the basis of estimates; 3. uncertainty about design and logistics; 4. uncertainty about objectives and priorities; 5. uncertainty about fundamental relationships between project parties. All these areas of uncertainty are important, but generally they become more fundamentally important to project performance as we go down the list. Potential for variability is the dominant issue at the top of the list, but ambiguity becomes the dominant underlying issue toward the bottom of the list. Uncertainty about variability associated with estimates involves the other four areas: each of them involving dependencies on later areas in this list.8 Uncertainty, risk, and their management Variability associated with estimates An obvious area of uncertainty is the size of project parameters such as time, cost, and quality related to particular activities. For example, we may not know how much time and effort will be required to complete a particular activity. The causes of this uncertainty might include one or more of the following: . lack of a clear specification of what is required; . novelty or lack of experience of this particular activity; . complexity in terms of the number of influencing factors and the number of interdependencies; . limited analysis of the processes involved in the activity; . possible occurrence of particular events or conditions that might affect the activity. Only the last of these items is directly related to specific events or conditions as referred to in the PMI (2000) and APM (1997) definitions of ‘risk’. The other sources of uncertainty arise from a lack of understanding of what is involved. Because they are less obviously described as threats or opportunities, they may be missed unless a broad view of uncertainty management is adopted. Uncertainty about the basis of estimates The quality of estimates depends on: who produced them, what form they are in; why, how, and when they were produced; from what resources and experience base; and what assumptions underpin them. The need to note assumptions about resources, choices, and methods of working is well understood if not always fully operationalized. Most of the time estimates ignore, or assume away, the existence of uncertainty that relates to three basic sources: ‘known unknowns’, ‘unknown unknowns’, and ‘bias’ (Chapman and Ward, 2002). All three of these sources of uncertainty can have a very substantial impact on estimates, and this needs to be recognized and managed. Uncertainty about design and logistics In the conception stage of the PLC the nature of the project deliverable and the process for producing it are fundamental uncertainties. In principle, much of this uncertainty is removed in pre-execution stages of the PLC by attempting to specify what is to be done, how, when, and by whom, and at what cost. In practice, a significant amount of this uncertainty may remain unresolved through much of the PLC. The nature of design and logistics assumptions and associated uncertainty may drive some of the uncertainty about the basis of estimates.Uncertainty in projects 9 Uncertainty about objectives and priorities Major difficulties arise in projects if there is uncertainty about project objectives, the relative priorities between objectives, and acceptable trade-offs. These diffi- culties are compounded if this uncertainty extends to the objectives and motives of the different project parties and the trade-offs parties are prepared to make between their objectives. A key issue is: ‘do all parties understand their respon- sibilities and the expectations of other parties in clearly defined terms, which link objectives to planned activities?’ ‘Value management’ has been introduced to encompass this (Green, 2001). The need to do so is perhaps indicative of a perceived failure of risk management practices. However approached, risk man- agement and value management need joint integration into project management. Uncertainty about fundamental relationships between project parties The relationships between the various parties may be complex, even if they look quite simple. The involvement of multiple parties in a project introduces un- certainty arising from ambiguity in respect of (Ward, 1999): . specification of responsibilities; . perceptions of roles and responsibilities; . communication across interfaces; . the capability of parties; . formal contractual conditions and their effects; . informal understandings on top of, or instead of, formal contracts; . mechanisms for co-ordination and control. Ambiguity about roles and responsibilities for bearing and managing project- related uncertainty can be crucial. This ambiguity ought to be systematically addressed in any project, not just in those involving formal contracts between different organizations. Contractor organizations are often more aware of this source of ambiguity than their clients, although the full scope of the threats and opportunities that this ambiguity generates for each party in any contract (e.g., via claims) may not always be fully appreciated until rather late in the day. For example, interpretations of risk apportionment implied by standard contract clauses may differ between contracting parties (Hartman and Snelgrove, 1996; Hartman et al., 1997). The nature of assumptions about contractual relationships and associated uncertainty may drive uncertainty about objectives and priorities with further knock-on effects. If a ‘fair weather partnership’ cracks when the going gets tough, everything else comes apart, and lost opportunities may be the biggest casualty.10 Uncertainty, risk, and their management The six Ws framework for the roots of uncertainty In the authors’ experience the initial motivation for applying formal risk manage- ment usually arises because of concerns about design and logistics issues in major projects that involve the large-scale use of new and untried technology. However, the most important issues that risk management helps to resolve are usually related to objectives and relationships between project parties. For example, a common issue in most projects is: ‘do we know what we are trying to achieve in clearly defined terms, which link objectives to planned activities?’ It is important to understand why this situation arises and to respond effectively in any project context. A convenient starting point is consideration of the project definition process portrayed in Figure 1.1. There are six basic questions that need to be addressed: 1. who who are the parties ultimately involved? (parties); 2. why what do the parties want to achieve? (motives); 3. what what is it the parties are interested in? (design); 4. whichway how is it to be done? (activities); 5. wherewithal what resources are required? (resources); 6. when when does it have to be done? (timetable). For convenience we refer to these question areas as ‘the six Ws’, using the designations in parentheses as well as the W labels for clarity when appropriate. While somewhat contrived, this terminology helps to remind us of the need to consider all six aspects of a project, reinforced by the Rudyard Kipling quote used to open this chapter. The flow lines in Figure 1.1 show the influences on project definition that are the roots of uncertainty. In the context of roots of uncertainty, these arrows can be interpreted as indicating the knock-on effects of uncertainty in each entity. As Figure 1.1 shows, the roots of uncertainty may extend back to the basic purpose of the project and even the identity of the relevant parties. Any uncertainty associated with entities earlier in the cycles portrayed by the diagram are of fundamental importance later. In the earliest stage of a project, during concep- tion, uncertainty is at its greatest. The purpose for which the project is required and the parties who will be involved may not be clear. As indicated in Figure 1.1, ‘project initiators’ are a subset of the who, the ‘project parties ultimately involved’. Project initiators kick the whole process off. One or more project initiators first identify the basic purpose of the project, or intended benefit from it, the why or motives for the project. These motives will usually include profit, involving revenue and cost, along with ‘other motives’. Initially, the nature of these motives will be defined, but they will not be quantified as objectives. That is, in terms of the mission–goals–objectives hierarchy often used to move from an overall mission statement to quantifiedThe six Ws framework for the roots of uncertainty 11 Figure 1.1—The project definition process objectives, the initial focus of the why may be on mission and broadly defined goals. Why, in terms of the initial conception of purpose, drives the initial what, the design. The design—be it a building, other physical product, service, or process—drives the initial activity-based plans, associated plan-based resource allocations, and plan-based timetable, the initial whichway, wherewithal, and when. Subsequently, there is significant feedforward and feedback along the whichway–wherewithal–when dimensions and some feedback to the what.The whichway–wherewithal–when entities then feed back into quantification of cost, possibly revenue and other motives, and why in terms of a more developed, measured definition. These considerations may relate to capital cost only or more complex, through-life performance criteria. This can involve related feedback to the who, with changes of a still more fundamental nature involving the project12 Uncertainty, risk, and their management initiators, ‘later players’, and ‘other interested parties’. As the project evolves it may be appropriate to bring in further later players, enlarging the who (e.g., to banks for resource reasons). It may also become appropriate to consider other interested parties who are not direct players (e.g., regulators). In each case the feedback loops result in subsequent feedforward, which may result in fundamental changes to the what, whichway, wherewithal,or when. This brief description of the project definition process in terms of the six Ws involved is an oversimplification for many projects, but it is sufficiently complex to highlight the nature of important roots of uncertainty in projects. In particular, if we recognize that the what, whichway, and wherewithal together describe the quality of a project and ignore revenue and other motives, then the lower part of Figure 1.1 corresponds to the well-known cost–time–quality triad. The limited perspective inherent in the simple cost–time–quality triad is then apparent from the expansion of this triad by Figure 1.1. Further, Figure 1.1 provides a useful operational basis for addressing cost–time–quality trade-offs. The scope of project risk management Efficient and effective project management requires appropriate management of all the sources of uncertainty outlined above. Risk Management Processes (RMPs) that adopt a simplistic focus on threats will not address many of these sources of uncertainty. RMPs concerned with threats and opportunities using the APM (1997) or PMI (2000) definitions of ‘risk’ will do better, but will still tend to be focused on uncertain events, conditions,or circumstances. This does not facilitate consideration of aspects of variability that are driven by underlying ambiguity. To address uncertainty in both variability and ambiguity terms we need to adopt a more explicit focus on uncertainty management. Uncertainty about anything that matters has to be the starting point for holistic and integrated project risk management. To this end it is useful to define ‘risk’ as an uncertain effect on project performance rather than as a cause of an (uncertain) effect on project perform- ance. Such a definition of project ‘risk’ is ‘the implications of uncertainty about the level of project performance achievable’. However, this definition on its own is not an effective operational alternative to those provided by the PMI or APM. We provide it here as a short form of a more complete operational definition provided in Chapter 3. What this short-form definition attempts to clarify now is that managing project risk must start with managing sources of project uncer- tainty about achievable performance that matter. Opportunities and threats are part of the sources of uncertainty that matter, but they are not risk per se in our terms. Similarly, uncertain events, conditions, or circumstances that may have an effect (positive or negative) on project objectives are part of the sources of uncertainty that matter, but they are not risk per se in our terms. Why uncertainty matters is not a simple issue, but Chapter 3 outlines key aspects of what isThe scope of project risk management 13 involved; the rest of this book illustrates what is involved in more detail, and Chapman and Ward (2002) elaborate further. To realize in practical terms the advantages of this wider perspective, it is essential to see project risk management as an important extension of conven- tional project planning, with the potential to influence project design as well as activity-based plans on a routine basis, occasionally influencing very basic issues like the nature of the project parties and their objectives for the project. There are many ways to classify ‘plans’. In general we will associate ‘plans’ with all six Ws, sometimes identifying ‘activity-based plans’, ‘plan-based resource allocations’, and so on, as indicated in Figure 1.1. For the present purposes it is useful to distinguish ‘base’ plans and ‘contingency’ plans. ‘Base plans’ are target scenarios, a portrayal of how we would like a project to go, incorporating proactive responses to uncertainty identified by proactive RMP planning. Base plans provide a basis for project preparation, execution, and control. Underlying the base plan in activity terms is a design, which may be worth identifying as a ‘base design’ if changes are anticipated. Base plans in activity terms imply base plans in resource allocation terms and associated base plan timetables. It may be useful to associate the who and why with base plans explicitly too, if changes are anticipated. Control involves responding to threats and opportunities, and revising per- formance targets where appropriate. ‘Contingency plans’ are a second level of plan, a portrayal of how we would like to respond to threats or opportunities associated with a base plan, incorporating reactive responses to uncertainty identified by proactive RMP planning. Where uncertainty presents potential future threats or opportunities, risk management seeks to modify the future incidence and quality of threats or opportunities and their possible impact on project performance via proactive planning in terms of base plans and con- tingency plans. This does not mean that reactive planning will not be necessary or that all possible out-turns will have been predicted. It means that proactive planning will have been carried out to an extent that allows reactive planning to cope without nasty surprises most of the time. Reactive risk management, responding to the control function, sometimes without contingency plans in place, should be reasonably panic-free, without a need for crisis management most of the time. A degree of crisis management may be essential even in the context of very effective and comprehensive risk management, but relatively few crises should come totally ‘out of the blue’. To illustrate these points, consider another example, building on Example 1.1. Example 1.3 Effective contingency planning for a pipe-laying problem Offshore oil or gas pipe laying in the North Sea in the 1970s involved a number of serious sources of uncertainty. If no proactive planning had14 Uncertainty, risk, and their management been undertaken, the potential for overwhelming crisis management was obvious. The pipes laid in the North Sea at this time were constructed from sections of rigid steel pipe coated with concrete, welded to the pipeline on the lay barge, then eased over the stern of the barge by taking up the tension on sets of bow anchors, maintaining a smooth S shape of pipe between the barge and the ocean floor. As bow anchors approached the lay barge, they were picked up by tugs, carried ahead, and reset. Improperly controlled lowering of new pipeline sections could result in a pipe buckle—a key pipe-laying threat. Excessive waves greatly increased this threat. Barges were classified or designated to indicate maximum safe wave heights for working (e.g., 3 metre or 1.6 metre). In the face of excessive wave heights the operators would put a ‘cap’ on the open end of the pipe and lower it to the ocean floor, retrieving it when the waves reduced. These lowering and lifting operations could themselves lead to buckles. The base plan for laying pipe assumed no major sources of uncertainty (opportunities or threats) would be realized, only minor day-to-day varia- tions in performance that could be expected to average out. The potential opportunity provided by unusually good weather and the potential threat posed by unusually bad weather were assessed by direct reference to historical weather records. Control was exercised by monitor- ing progress relative to the base plan, aggregating all reasons for being early or late, until a significant departure from the base plan was identified. A control response could be triggered by an accumulation of minor diffi- culties or the realization of a major threat like a pipe buckle. Once the need for a control response had been identified and an appropriate response selected reflecting the nature of the realized threats or opportunities, the associated response became part of the revised base plan. Effective comprehensive contingency planning ensured that the most crucial prior actions necessary to implement the preferred revisions to the base plan would be in place if it was cost-effective to put them in place. The implications of not putting them in place were understood when making a decision not to do so. Should a pipe buckle occur, there would be a potential need for addi- tional pipe. This had to be ordered well in advance of starting the pipe laying if a delay associated with awaiting delivery were to be avoided. Effective contingency planning needed to ensure that enough pipe was available most of the time. However, it would not have been cost-effective to ensure buckles never led to a shortage of pipe. Nor would it have been cost-effective to undertake detailed planning to deal with all the knock-on effects of a pipe buckle.The scope of project risk management 15 Proactive risk management needs to be embedded in both base plans and con- tingency plans. Further, proactive and reactive planning are not alternatives, they are complementary aspects of planning as a whole, with proactive contingency planning supporting reactive contingency planning when this is cost-effective. Similarly, crisis management is not an alternative to risk management; it is a consequence of risk management failure. Nevertheless, even the most effective risk management must fail on occasions if it is to remain cost-effective on the average. Only if risk management fails completely, or is simply not addressed, will crisis management become the dominant management mode. Project risk management is usually associated with the development and evaluation of contingency plans supporting activity-based plans, but effective project risk management will be instrumental in the development of base plans and contingency plans for all six Ws. Really effective risk management will strongly influence design and may significantly influence motives and parties. It will certainly influence basic timing and resource allocation plans. Planning and risk management in this sense are integrated and holistic. Treating project management and project risk management as closely coupled processes is central to the approach taken in this book. In practice, some sep- aration may be essential because different people and organizations may be involved, and other differences are important. However, the separability should be limited, to avoid imposing constraints that can prove very expensive. This is another key aspect of an integrated and holistic approach.2 The project life cycle The moving finger writes; and, having writ, moves on: nor all thy piety nor wit shall lure it back to cancel half a line, nor all thy tears wash out a word of it.—Edward Fitzgerald Introduction An appreciation of the potential for risk management in projects has to be grounded on a clear understanding of the nature and scope of decision making involved in project management. A natural framework for examining these decisions is the project life cycle (PLC). A structured view of the PLC is also important to provide a framework for looking ahead for sources of uncer- tainty that are seeded earlier and for understanding how the risk management process (RMP) ought to change as the PLC unfolds. In order to focus on the structure of the PLC, much of this chapter will consider a single project in isolation, but it ends with a short discussion of the implications of a multiproject environment. Eight stages The PLC is a convenient way of conceptualizing the generic structure of projects over time. It is often described in terms of four phases, using terms like con- ceptualization, planning, execution, and termination (Adams and Barndt, 1988). Alternative phraseology may be used, such as formation, build-up, main pro- gramme, and phase-out (Thamhain and Wileman, 1975), but the underlying phases identified are essentially the same. These phases are commonly described in a manner emphasizing the extent to which they differ in terms of 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 life of the project. Useful recent references to the PLC literature include Bonnai et al. (2002) and Tummala and Burchett (1999). A similar argument applies to sources of uncertainty and their management. However, an appreciation of the scope for risk management and how to approach it requires consideration of the differences between phases of the PLC in a greater level of detail than the typical four phase structure. Table 2.118 The project life cycle Table 2.1—Phases, stages, and steps in the project life cycle (PLC) Phases Stages Steps conceptualization conceive trigger event the product concept capture clarification of purpose concept elaboration concept evaluation planning design basic design the product development of performance criteria strategically design development design evaluation plan basic activity and resource-based plans the execution development of targets and milestones strategically plan development plan evaluation allocate basic design and activity-based plan detail resources development of resource allocation criteria tactically allocation development allocation evaluation execution execute co-ordinate and control production monitor progress modification of targets and milestones allocation modification control evaluation termination deliver basic deliverable verification the product deliverable modification modification of performance criteria deliver evaluation review basic review the process review development review evaluation support basic maintenance and liability perception the product development of support criteria support perception development support evaluation breaks down the typical four phase characterization of the PLC into eight stages. We use the term ‘stage’ rather than ‘phase’ to emphasize the difference and to reserve the word ‘phase’ for the decomposition of the RMP. Table 2.1 also breaks each stage into steps. The breakdown into eight stages goes some way toward highlighting sources of uncertainty and facilitating their management. However, the still more detailed description of the PLC provided by steps is useful toEight stages 19 underline where particular sources of uncertainty arise in the PLC and how risk management might be most effective. In the early stages these steps imply a process of gradually increasing detail and a focus on the nature of a product or service deliverable, as distinct from the later focus on its delivery and then its operation. The conceive stage It is useful to think of the conceive stage as part of an innovation process and draw on ideas from Lemaitre and Stenier’s description of the innovation process (Lemaitre and Stenier, 1988), although the scope of our conceive stage is some- what different. The conceive stage involves identifying a deliverable to be pro- duced and the benefits expected from the deliverable. It begins with a ‘trigger event’ (Lyles, 1981), when a member of an initiating organization perceives an opportunity or need. 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’ involving the identification of relevant perform- ance objectives and their relative importance is another key step in the conceive stage. 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. Objectives at this stage are likely to be ill defined or developed as aspirational constraints (e.g., latest completion date, minimum levels of functionality, maximum cost, and so on). Before the concept can be developed further, in a ‘concept elaboration’ step, 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 stake- holders may become involved. Support at this stage may be passive, merely allowing conceptualization to proceed, rather than an expression of positive approval of the project. The focus of this stage is early cycles through the six Ws’s framework of Figure 1.1. Eventually, an evaluation of the project concept and objectives as defined to date becomes necessary—the ‘concept evaluation’ step in Table 2.1. Evaluation here (and later) is not simply a go/no-go decision, but a go/no-go/maybe deci- sion. A go decision takes the process into the the next stage. A no-go decision causes it to stop. A maybe decision involves iteration through one or more previous steps. The basic process threat in this stage is moving on to design before the project concept and objectives have crystallized, and before effective concept evaluation. Underlying this threat is a failure to foresee ‘concept killer’ threats that reveal themselves later in the process and ‘concept maker’ opportu- nities that may be lost without trace. The basic process opportunity in this stage is finding all the concept maker opportunities for the projects that otherwise might not be proceeded with and all the concept killer threats for projects best rejected.20 The project life cycle The design stage A go decision in the conceive stage initiates a ‘basic design’ at a strategic level in the first step of the design stage, giving form to the deliverable of the project. The focus of this stage is giving substance to the what entity, although loops through the other five Ws will be involved. This usually requires a step increase in the effort or resources involved. ‘Development of performance criteria’ builds on the basic design and project objectives. For many projects this involves refining project objectives, but it may involve the identification of additional objectives and further negotiation where pluralistic views persist. This step influences ‘design development’, which leads to ‘design evaluation’ using the developed performance criteria to assess the current design in go/no-go/maybe terms. As in the concept stage, no-go will end the process. A maybe evaluation is most likely to lead to iteration through one or more development steps, but if fundamental difficulties not anticipated in the concept stage are encountered, the loop may go back to the concept stage. Go takes the process on to the plan stage. The basic process threat at this stage is moving on to the plan stage before effective design development and evaluation at a strategic level is complete. Underlying this risk is a failure to foresee ‘design breaker’ threats that might be designed out and that reveal themselves later in the process, and ‘design maker’ opportunities that may be lost and never found. The basic process opportunity in this stage is finding and resolving all the design breaker threats and finding and capturing all the design maker opportunities. Decomposition of the Table 2.1 ‘planning phase’ into design, plan, and allocate stages serves to focus the management of this and related subsequent threats and opportunities. The plan stage A go decision in the design stage initiates formal capture and development of basic activity and resource based plans at a strategic level, indicating how the design will be executed (whichway), what resources are required in broad terms (wherewithal), and how long it will take (when). The focus of this stage is these three Ws, but loops through the other three will be involved. Yet more indi- viduals and organizations may become involved. ‘Development of targets and milestones’ involves determining specific targets for producing the project deliverable, typically in terms of cost and time, but sometimes in terms of resource usage or other considerations as well. ‘Plan development’ follows and leads to ‘plan evaluation’ in go/no-go/maybe terms. A maybe decision may require further development of targets and milestones within the plan stage, but more fundamental difficulties may take the process back to design develop- ment or even concept elaboration. The basic process threat at this stage is moving on to the allocate stage before effective development and evaluation of the plans in terms of all six Ws at a strategic level, and both ‘maker’ andEight stages 21 ‘breaker’ threats at a strategic planning level underlie this. The basic process opportunity is avoiding the breakers and capturing the makers. The allocate stage A go decision in the plan stage takes the process on to the allocate stage and a detailed allocation of internal resources and contracts to achieve the plan. The allocate stage is a significant task involving decisions about project organization, identification of appropriate participants, and allocation of tasks between them. Resource allocation with a view to project implementation requires much more detail than earlier stages needed. The detail of the what (design) drives the detail of the whichway (activities), which drives the detail of the wherewithal (resources), which drives the detail of the when (timing), with iterative, inter- active loops. The who may also require redefinition. Either implicitly or explicitly the allocation stage involves the allocation of execution uncertainty and risk between participants. Risk and uncertainty alloca- tion is an important source of process uncertainty because it can significantly influence the behaviour of participants and hence impact on project perform- ance, and how best to do it is itself very uncertain. In particular, allocation of execution and termination phase uncertainty influences the extent and manner in which such uncertainties are managed. This warrants careful consideration of the basis for allocating tasks, uncertainty, and risk in the ‘development of resource allocation criteria’ step. ‘Allocation 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. Contracts and subcontractual structures may require development. Again, the nature of the issues changes with the change of stage, and the level of effort may escalate. As in the earlier project stages, development during this stage is followed by ‘allocation evaluation’. A maybe decision that goes back to the plan, design, or even conceive stage is 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 evaluation steps will be seen to have failed at this stage. The basic process threats and opportunities revolve around augmenting effective strategic plans with the detail essential to make execution a success. The rationale for separate design, plan, and allocate stages Possible arguments against decomposition of the Table 2.1 ‘planning phase’ into design, plan, and allocate stages is their interdependent nature and the need to iterate within this phase. We believe that the importance of this dependence and the process threats and opportunities it generates is highlighted by their separa-

Advise: Why You Wasting Money in Costly SEO Tools, Use World's Best Free SEO Tool Ubersuggest.