Post processes the Project Risk Analysis and Management PRAM Guide

In the mid-1990s the APM (Association for Project Management) started to develop the Project Risk Analysis and Management (PRAM) Guide (Simon et al., 1997). PRAM is a core contributor to the heritage of the SHAMPU process. The PRAM process description was drafted by Chapman, as chap. 3 of the PRAM Guide. It was a distillation of the experience of a large number of UK organizations that had used RMPs successfully for a number of years, as understood by a working party of more than 20 people drawn from an APM Specific Interest Group on Project Risk Management of more than 100 who reviewed working party drafts and provided feedback. The draft PRAM process was based on a synthesis of designed and evolved processes using a nine-phase structure similar to Table 4.1. The SHAMPU harness phase was called the planning phase, and this and several other phases were interpreted less precisely, but there were no other significant differences in terms of phase structure.

The PRAM process used nine phases from an early stage in its development, rather than the four of the SCERT process (Chapman, 1979), or the various three to six phase structures used by other SIG members, because of the need to seek a 'common basis'. There was a clear need to make sure everyone involved could map their process onto the agreed PRAM process, to ensure collective ownership, if possible. This required more divisions than might otherwise seem sensible and suggested phase divisions as defined by Table 4.1. It was clear that if people could not see how the process they used currently mapped onto what was proposed, they were not going to buy into it. Nine phases as defined by Table 4.1 was the simplest structure that came close to achieving this 'common basis' criterion. Any process defined via synthesis involving a group of people and organizations faces a range of similar issues, and how these issues are managed is important.

The key reason Chapman was soon convinced that this nine-phase structure was appropriate in operational terms was the separability (but not the independence) of the phases in terms of different purposes, deliverables, and tasks. This suggested each phase could be thought of as a project in its own right, and all nine-phases could be regarded as a programme (portfolio of nine projects). This in turn suggested that everything we know about good programme and project management could be applied to managing the RMP. As for any programme or project, alternative structures are feasible, but this nine phase structure seemed robust and effective at a generic level at the time, and experience since confirms this. Much of the structure was tested operationally prior to the PRAM synthesis, in a SCERT context and in the context of other RMPs that contributed to its form.

Between agreeing the nine-phase structure portrayed by Table 4.1 and the publication of the PRAM Guide, editing to link chaps 2 and 3 of the PRAM Guide resulted in recasting the nine phases as six phases with four subphases, as indicated in Table 4.3. A new assessment phase was defined, incorporating structure, ownership, estimate and evaluate as subphases. This phase/subphase distinction is not an issue of importance, and the alignment between the PRAM and SHAMPU processes is clear. Indeed, Table 4.3 is a useful illustration of differences between process descriptions that should matter very little in practice. However, the merit of an assessment phase that aggregates the structure, ownership, estimate and evaluate phases as subphases is debatable. It is usefully interpreted as an illustration of the pressure within the PRAM working party to 'keep it simple' in terms of well-loved familiar structures. Such pressure is understandable, but when it is useful to simplify the recommended nine phase structure of Table 4.1, our preference is for the structures of Table 4.2 for a number of reasons that should become clear by the end of this book.

Some process insights

To the authors of this book, chapter 3 of the PRAM Guide provided four very important insights relating to process, in addition to useful advice on a range of other topics in other chapters.

Table 4.3—Aligning SHAMPU with PRAM

the nine phase portrayal of the SHAMPU

PRAM phases and subphases from the PRAM

process of Table 4.1

Guide (Simon et al, 1997)

define the project

define project

focus the process

focus PRAM

identify the issues

identification

structure the issues

assessment—structure

clarify ownership

—ownership

estimate sources of variability

—estimate

evaluate overall implications

—evaluate

harness the plans

planning

manage implementation

management

First, 'planning the project' in risk management terms and 'planning the planning of the project' in risk management terms are well worth separation, in the define and focus phases respectively, to clarify the basis of analysis. A separate focus phase formally acknowledges that there is no one best way to undertake an RMP for all projects. Deciding how to proceed in a given context is a particularly difficult process to conceptualize and make operational; so, recognizing the need for this phase is crucial. To some extent the focus phase is home territory for skilled consultants, in intuitive if not formal terms, but it is virgin territory for planners or estimators who do not have a sophisticated understanding of RMPs or other decision support processes. If no explicit focus phase is involved in an RMP, the process is seriously defective in ways naive users may not even recognize, using 'naive' in Hillson's (1997) risk maturity sense (discussed later in Part III). PRAM working party discussions about the relative value of different approaches in different contexts, looking for a systematic explanation of different practices, served as a trigger for the insight that a focus phase is essential.

Second, both the define and focus phases have to be part of an ongoing iterative framework, not part of a one-shot 'start-up' or 'initiation' phase. The importance of an iterative approach was recognized early in the development of PERT and CPA/CPM, although this insight has been lost along the way by some. It is particularly important with respect to initial assumptions including framing assumptions.

Third, ownership of risk is so important that it deserves separable attention in its own phase (or subphase), as a part of an ongoing iterative process. Isolating it from the iterative loops in a one-shot 'start-up' or 'initiation' phase is not appropriate, and it is usefully conceived as a final part of qualitative analysis in SHAMPU terms. PRAM was the first RMP to have a separate explicit ownership phase.

Fourth, the PRAM planning and management phases as defined by Table 4.3—the basis of the SHAMPU harness and manage phases—are important parts of the RMP. SCERT did not include these aspects of the RMP. Other RMPs did so in part in various ways. In particular, phases with these labels were part of the MoD (1991) RMP, and there was a rapid and clear agreement to include them in the PRAM process, acknowledging this heritage. However, there were competing views as to what these labels should imply, and what they involved was not agreed as clearly as might have been the case.

In summary, from our perspective the four SCERT phases (Chapman, 1979) formed the starting point for the SHAMPU/PRAM define, identify, structure, estimate, and evaluate phases, augmented by ideas from other processes, most of which have define, identify, estimate, and evaluate equivalents. The SHAMPU/ PRAM harness (planning) and manage phases were borrowed from the MoD (1991) RMP in a form modified by ideas stimulated by the PRAM working party. The SHAMPU/PRAM focus and ownership phases were entirely new concepts as separate formal phases, triggered by PRAM working party discussions. The iterative nature of the process as a whole, including the basis of analysis phases, was endorsed by the PRAM working party as a very important feature of the process.

Some important differences between the PRAM and SHAMPU frameworks

The first edition of this book (Chapman and Ward, 1997) was profoundly influenced by drafting chapter 3 of the PRAM Guide. It used the nine phase PRAM structure directly, employing the same dependent chapter structure used in this edition. It was published prior to the PRAM Guide, and it did not allude to the Table 4.3 differences or any other differences, presenting itself as a direct elaboration of a PRAM process. However, this elaboration was based on a SCERT and 'risk engineering' perspective, and revisiting the PRAM Guide to revise Chapman and Ward (1997) has crystallized differences that need clarification here.

The first difference concerns the central importance of risk efficiency as developed in the SCERT process (Chapman, 1979). The PRAM Guide does not mention risk efficiency, because Chapman was unable to convince the PRAM working party that this is a central issue. In the SCERT process the pursuit of risk efficiency and associated risk balance issues (risk efficiency at a corporate level) are explicit steps in the equivalent of the evaluate phase, and this aspect of SCERT is reflected in Chapters 3 and 11 of this book. This different view of what risk management is about at a fundamental level has important implications, which are explored later.

A second difference is Ward's development of the six W s framework, as outlined in Chapter 1, which is central to our thinking. This framework is not mentioned in the PRAM Guide, because it was not fully developed at the time chap. 3 of the PRAM Guide was developed. An operational define phase that is holistic and integrated requires a six Ws structure equivalent. In addition, Ward's development of the PLC structure (Ward and Chapman, 1995b), as outlined in Chapter 2, is central to our thinking, but its use in the PRAM Guide is limited to describing risk management in the plan stage of the PLC. The role of the PLC as a driver of the focus phase was clear at the time chap. 3 of the PRAM Guide was developed, but its use as a basis for the define phase was not developed at that time. Like the six Ws, it is crucial to a holistic and integrated define phase. A holistic define phase needs to consider the cash flow and associated multiple criteria models that integrate the six Ws and the PLC. This issue was not addressed by the PRAM working party.

A third difference relates to the harness phase. As described in this book, the harness phase is broadly equivalent to the planning phase of the PRAM framework. However, the PRAM Guides section 2.6 description of the planning phase embraces aspects of risk response development (seeking risk efficiency in our terms) that we associate with the shape phases, and it omits the initiation of detailed planning for implementation within an action horizon determined by lead times that we believe should be deferred until looping back to earlier phases is largely over. Figure 4.1 shows two important loops back from the evaluate phase, but no loops back from the harness phase. The harness phase is about using the results of previous analysis to gain approval for a project strategy shaped by the earlier iterative process and then preparing a detailed project base plan and contingency plans for implementation. This process is outside the earlier iterative looping structure of Figure 4.1. Figure 4.1 is as used in the first edition of this book and submitted for PRAM in terms of this looping iteration structure, but the PRAM Guide version of Figure 4.1 was altered to show feedback from the planning phase. Moving tasks from one phase to another may not be particularly important and reordering tasks in the context of an iterative process may have little effect in practice, but the additional content of the harness phase as we define it is important. Also important is the removal of feedback from the harness phase to the define phase, as this allows the shape phases to work at a relatively high 'strategic' level. This has important ramifications (developed in Chapter 12), as well as implications for Chapters 5 to 11. In brief, the development of responses in order to achieve risk efficiency and balance has to start at a strategic level, then progress to a tactical level, with a simple, possibly deterministic, approach to the most detailed plans required for implementation.

A fourth difference is that the PRAM Guide does not adequately reflect the recent shift in emphasis from project risk in the downside risk sense to project uncertainty, involving upside and downside issues. Jordanger (1998) reported Stat Oil's use of the term uncertainty management at the beginning of the period when this shift in perception occurred, and Stat Oil deserves considerable credit for initiating this shift in emphasis, which is central to Chapman and Ward (2002).

It has been picked up by many other authors (e.g., Hillson, 2002b). However, full consideration of the implications of uncertainty management demands a risk efficiency perspective and a related simplicity efficiency approach to analysis, which Hillson does not adopt.

If the reader wishes to embed the SHAMPU phase structure of Table 4.1 and the ideas developed in the rest of this book in a process defined by the PRAM Guide, three things need attention:

1. Expand the define phase scope to embrace the six Ws and the PLC, integrating cash flow and multiple criteria models. Make associated adjustments to all following phases.

2. Adopt the risk efficiency concept and the associated primary definition of risk (as outlined in Chapter 3) and use these changes to fully embrace the management of good luck as well as bad luck. Embed the wider scope this gives risk management in all the phases, driven by a search for risk efficiency and simplicity efficiency in an evaluate phase that is served by all preceding phases.

3. Associate this use of the evaluate phase and all preceding phases with the PRAM Guide's chapter 2 concept of planning risk responses, distinguish this from the PRAM Guide's chapter 3 concept of the planning phase, and revise the manage phase to reflect the rolling nature of detailed action plans developed in Chapter 13 of this book.

Was this article helpful?

0 0

Post a comment