Writing a critical review of two journal articles about project risk Management
Pergamon International Journal of Project Management Vol. 15, No. 5, pp. 273-281, 1997
© 1997 Elsevier Science Ltd and IPMA. All rights reserved Printed in Great Britain
0263-7863/97 $17.00 + 0.00
PII: S0263-7863(96)00079-8
Project risk analysis and management-- PRAM the generic process
Chris Chapman School of Management, University o f Southampton, Southampton S017 1B J, UK
This paper provides an overview of a project risk management process developed b y a w o r k i n g p a r t y o f the Association of Project M a n a g e r s . I t is a synthesis o f methods developed b y a n u m b e r o f individuals and organizations over an extended p e r i o d . All a s p e c t s o f it have been tested and developed in the context o f successful practice (and difficulties associated with achieving success). The process of synthesis has provided a n u m b e r o f n e w insights. These include: a more detailed phase structure based on objectives, t a s k s a n d deliverables; a more f o r m a l process of defining the project to b e assessed; treating the risk management p r o c e s s as a project in its own r i g h t ; a n d treating the r e s o l u t i o n o f o w n e r s h i p - c o n t r a c t u a l issues as a p r o j e c t in its own right. © 1997 E l s e v i e r Science Ltd and I P M A
Keywords: risk analysis, risk management, generic processor
This paper describes a project risk management process initially drafted for the Association o f Project Managers (APM, now Association for Project Management) Project Risk Analysis and Management (PRAM) Guide. 1 It uses a development o f this draft for another book. 2
As indicated in the acknowledgements, the basis o f this paper is the experience o f a large number o f organizations which have used risk management processes (RMPs) successfully for a number o f years, as understood b y a working party o f 20 drawn f r o m an A P M Specific Interest G r o u p (SIG) o f m o r e than 100 who represent a very broad spectrum o f organizations in the UK. The structure o f the process it provides is likely to b e c o m e a standard because o f this wide authorship and support, and it works well as a f r a m e w o r k for discussion. All o f those who contributed to it know it works well in practice, although we previously described it in different terms, with different emphasis, and the process o f synthesis has provided useful new insights.
A formal risk management process (RMP) should be applied at all stages in the project life cycle, b y clients (project owners) and contractors (other parties associated with a project). It is most easily explained, and applied for the first time, when implemented in a comprehensive manner on behalf o f a client at a sanction stage. This p a p e r assumes that this is the perspective and stage o f interest initially, revisiting these assumptions later.
Most specific RMPs are described in terms o f phases (stages) which are decomposed in a variety o f ways, some related to tasks (activities), some related to deliverables (outputs/products). The nine-phase structure used here is m o r e detailed than most specific methods. A consequence o f the additional detail provided b y nine phases is clari-
fication o f the relative importance and role o f aspects o f the process which other specific R M P descriptions emphasise in varying degrees. This includes making explicit several very important aspects which none o f the earlier descriptions addresses directly.
The methodology described here is comprehensive, encompassing all important aspects o f all methods familiar to all the A P M SIG authors. Shortcuts are possible, and m o r e sophisticated processes are also possible within the f r a m e w o r k provided. Both are addressed in Chapman and W a r d . 2 Illustrative case studies and other supporting material is provided in the forthcoming A P M Guide.I
The nine phases are discussed in a start-to-start precedence sequence. Once started all phases proceed in parallel, with intermittent bursts o f activity defined by an iterative process interlinking the phases. Each phase is associated with broadly defined deliverables. Each deliverable is discussed in terms o f its purpose and the tasks required to produce it. Significant changes in purpose underlie the boundaries between phases.
Table 1 summarizes the phase/deliverable structure. Figure 1 indicates in linked bar chart f o r m the way effort expended in each phase might be focused o v e r the life cycle o f a typical RMP, and Figure 2 summarizes the phase structure in flow chart format.
Other specific R M P descriptions can be mapped onto the nine phase description provided here. F o r example, the four phase S C E R T (Synergistic Contingency Evaluation and Response Technique) description 3 and the slightly different four phase structure plus an Initiation phase used b y the U K Ministry o f Defence 4 align as indicated in Table 2. Part o f the purpose o f the A P M SIG PRAM Guide
273
P r o j e c t risk analysis a n d m a n a g e m e n t : C C h a p m a n
Table 1 A generic risk management process structure (client perspective/plan stage initiation)
Phases Purposes Deliverables (may be targets not achieved initially)
Define Consolidate relevant existing information about the A clear, unambiguous, shared understanding of all relevant key aspects of the project project documented, verified and reported
Focus
Identify
Structure
Ownership
Estimate
Fill in any gaps uncovered in the consolidation process Scope and provide a strategic plan for the RMP Plan the RMP at an operational level Identify where risk might arise Identify what we might do about this risk, in proactive and reactive response terms Identify what might go wrong with our responses Testing simplifying assumptions Providing more complex structure when appropriate Client-contractor allocation of ownership and management of risks and responses Allocations of client risks to named individuals Approval of contractor allocations Identify areas of clear significant uncertainty Identify areas of possible significant uncertainty
Evaluate
Plan
Manage
Synthesis and evaluation of the results of the estimate phase
Project plan ready for implementation and associated risk management plan
Monitoring Control Developing plans for immediate implementation
A clear, unambiguous shared understanding of all relevant key aspects of the RMP, documented, verified and reported All key risks and responses identified, both threats and opportunities, classified, characterized, documented, verified and reported
A clear understanding of the implications of any important simplifying assumptions about relationships between risks, responses and base plan activities Clear ownership and management allocations, effectively and efficiently defined, legally enforceable in practice where appropriate
A basis for understanding which risks and responses are important Estimates of likelihood and impact in scenario or numeric terms, the latter including identification of assumptions or conditions, sometimes with a focus on 'showstoppers' Diagnosis of all important difficulties and comparative analysis of the implications of responses to these difficulties, with specific deliverables like a prioritized list of risks, or a comparison of base plan and contingency plans with possible difficulties and revised plans 1. Base plans in activity terms at the detailed level required for implementation,
with timing, precedence, ownership and associated resource usage-contractual terms where appropriate clearly specified, including milestones initiating payments, other events or processes defining expenditure, and an associated base plan expenditure profile
2. Risk assessment in terms of threats and opportunities, prioritized, assessed in terms of impact given no response is feasible and potentially desirable, along with assessment of alternative potential reactive and proactive responses
3. Recommended proactive and reactive contingency plans in activity terms, with timing, precedence, ownership and associated resource usage-contractual terms where appropriate clearly specified, including trigger points initiating reactive contingency responses and impact assessment
Diagnosis of a need to revisit earlier plans, and initiation of replanning as appropriate, including on a regular basis specific deliverables like the monitoring of achieved performance in relation to planned progress, and prioritized lists of risk-response issues Exception (change) reporting after significant events, and associated replanning A rolling horizon of detailed plans for implementation (base and contingency)
p r o j e c t w a s t h e p r o v i s i o n o f a s t a n d a r d p r o c e s s d e s c r i p t i o n a n d t e r m i n o l o g y to a v o i d t h e u n n e c e s s a r y c o n f u s i o n g e n e r - a t e d b y s l i g h t l y d i f f e r e n t d e s c r i p t i o n s o f c o m m o n c o n c e p t s .
Define the project for risk management purposes: the define phase
A l l s p e c i f i c R M P s h a v e a D e f i n e p h a s e , b u t m u c h o f it is u s u a l l y i m p l i c i t . I t s p u r p o s e is to d e f i n e p r o j e c t e f f o r t to d a t e i n a f o r m a p p r o p r i a t e f o r t h e R M P , to:
• c o n s o l i d a t e i n a s u i t a b l e f o r m r e l e v a n t e x i s t i n g i n f o r - m a t i o n a b o u t t h e p r o j e c t w h i c h t h e R M P a d d r e s s e s - - f o r e x a m p l e , p r o j e c t o b j e c t i v e s s h o u l d b e c l e a r l y s t a t e d , p r o j e c t s c o p e ( i n c l u d i n g b r e a d t h a n d t i m e f r a m e ) a n d s t r a t e g y n e e d to b e d e f i n e d , a c t i v i t y p l a n s n e e d to b e d e f i n e d at a n a p p r o p r i a t e s i m p l e o v e r v i e w l e v e l , a s s o c i - a t e d t i m i n g a n d r e s o u r c e u s a g e i m p l i c a t i o n s s p e c i f i e d , u n d e r l y i n g i s s u e s l i k e d e s i g n d e s c r i b e d , a n d s t a k e h o l d e r ' s i n t e r e s t s d e f i n e d ; a n d
• u n d e r t a k e p r o j e c t m a n a g e m e n t a c t i v i t i e s to fill i n a n y g a p s u n c o v e r e d i n t h e c o n s o l i d a t i o n p r o c e s s - - i n p r i n c i p l e s u c h g a p s s h o u l d n o t e x i s t , b u t i n p r a c t i c e t h i s is a c r u c i a l a s p e c t o f t h e R M P , a f o r m o f r i s k a s s e s s m e n t o f
t h e p r o j e c t m a n a g e m e n t p r o c e s s to d a t e , a n d r e s p o n s e to a n y c o n c e r n s .
A c h i e v i n g b o t h p u r p o s e s o f t h e D e f i n e p h a s e is e s s e n t i a l , a b a s i c f o u n d a t i o n f o r w h a t f o l l o w s .
T h e d e l i v e r a b l e s p r o v i d e d b y t h e D e f i n e p h a s e m a y b e a s i n g l e d o c u m e n t o r p a r t s o f s e v e r a l d o c u m e n t s . W h a t e v e r t h e i r f o r m , a c o m p r e h e n s i v e a n d c o m p l e t e D e f i n e p h a s e s h o u l d c l a r i f y all r e l e v a n t k e y a s p e c t s o f t h e p r o j e c t w h i c h t h e R M P a d d r e s s e s , i n a m a n n e r a c c e s s i b l e to a l l r e l e v a n t c l i e n t staff. T h e t a r g e t d e l i v e r a b l e is this c l e a r , u n a m b i g u o u s , s h a r e d u n d e r s t a n d i n g o f t h e p r o j e c t .
T a s k s r e q u i r e d to p r o v i d e t h i s d e l i v e r a b l e i n c l u d e :
u c o n s o l i d a t e : g a t h e r a n d s u m m a r i z e i n a s u i t a b l e f o r m r e l e v a n t e x i s t i n g i n f o r m a t i o n ;
n e l a b o r a t e : fill i n t h e g a p s , c r e a t i n g n e w i n f o r m a t i o n ; n d o c u m e n t : r e c o r d i n text w i t h d i a g r a m s as a p p r o p r i a t e ; n v e r i f y : e n s u r e a l l p r o v i d e r s o f i n f o r m a t i o n a g r e e as f a r
as p o s s i b l e , i m p o r t a n t d i f f e r e n c e s i n o p i n i o n a r e h i g h - l i g h t e d i f t h e y c a n n o t b e r e s o l v e d , a n d a l l r e l e v a n t p r o v i d e r s a r e r e f e r r e d to;
n a s s e s s : v a l u e t h e a n a l y s i s to d a t e i n c o n t e x t , to e n s u r e it is ' f i t f o r t h e p u r p o s e ' g i v e n t h e c u r r e n t s t a t u s o f t h e r i s k m a n a g e m e n t p r o c e s s ;
2 7 4
Project risk analysis and management: C Chapman
R M P RMP start phase ~
Define
Focus i
Identify
Structure
Ownership
Estimate
Evaluate
Plan
Manage
First complete cycle
i
II
Sub- cycle
Second complete cycle
Project execution /
Third complete cycle /
l " 1
, : i
k C . , h . . . . I ~
i 0 i
: Z
Intense activity ~ Ongoing activity ~ Intermittent activity
Figure 1 An example risk management process (RMP) over time
• report: release verified documents, presenting if appro- priate.
i
F o c u s t h e r i s k m a n a g e m e n t p r o c e s s : t h e f o c u s p h a s e
The first two o f these tasks are specific to the Define phase. The last four are common to all phases.
Because aspects o f the project may not be clearly defined when the RMP begins, and may take some time to be clearly defined, important and central aspects o f the Define phase may be ongoing. However, the initial concern o f the RMP should be making as much progress as possible with the Define phase before moving on to later phases. The greater the level o f unfinished business from the Define phase, the lower the efficiency and effectiveness o f the following phases. Figure 1 indicates the way effort expended on the Define phase might be timed in a typical RMP, with the bulk o f the effort at the outset, but further bursts o f effort at the start o f subsequent cycles through the process, three complete cycles being illustrated in Figure 1 by way o f example. Ongoing Define phase activity through- out the process is another way Figure 1 might portray this phase.
Development o f this phase in Chapman and Ward 2 is structured around Figure 3, which uses an influence diagram to explore the relationships between 'the six W s'. The importance o f ensuring all six, and their relationships, are fully understood, is an insight o f great importance. It allows recognition, for example, that the best way to deal with some risks may be to abandon activities generating the risks and achieve objectives some other way, in the limit perhaps redefining success.
All specific RMPs have a Focus phase, although it may be given other titles. Its purpose is:
• to define RMP scope and strategy as distinct from the strategy o f the project the RMP addresses; and
• to plan the RMP in operational terms as a project in its own right.
F o r example, i f RMP is being applied to test the viability o f a new project, a purely qualitative approach may be appropriate, but i f RMP is being used to assess budgets or bid prices, a fully quantitative (probabilistic) approach may be required, these differences having important specific method and resource requirement implications.
Achieving both purposes o f this phase is essential, as basic to what follows as the Define phase. Some specific RMPs make more o f this phase than others. For example, the Mo D Risk Strategy Plan 4 requires more formalization o f both aspects o f this phase than most. The deliverables provided by the Focus phase may be a single document or parts o f several documents. Whatever their form, a comprehensive and complete Focus phase should clarify all relevant key aspects o f the RMP as a project in its own right in a manner accessible to all relevant client staff. The target deliverable is this clear, unambiguous shared understanding o f the RMP.
Tasks required to provide this deliverable include:
275
Project risk analysis and management: C Chapman
D e f i n e
F o c u s
Identify
I Structure
I Ownership I
I Estimate I ¢
Evaluate [
I Plan
M a n a g e
Figure 2 Risk management process (RMP) phase structure flow chart
1. Scope the process. This task addresses issues like who is doing the analysis for whom, why is the formal project risk management process being undertaken (what benefits must be achieved), and what is the scope o f the relevant risk.
2. Plan the process. This task addresses issues like using what resources over what timeframe, using what models and methods (techniques), what software and so
Table 2 Risk management process (RMP) phase structure comparisons A P M (used here) UK MoD (1991) SCERT (Chapman, 1979)
Define ) Initiation l Focus Scope Identify Identification Structure t Structure Ownership Analysis Parameter Estimate Evaluate ) Plan Planning Manipulatmn Manage Management and interpretation
WHO
I Proje~ Later [Other I ~ r s l , ~ s ~ d p . . . .
.1 I WHAT Design
IT*' i . . . . . . . . . . . . . . . . . . . , I H Actxvlty based p ans Plan b a s e d r e s o u r c e P a n b a s e d t metab e
[ ~ ' * ~ all . . . . . . . . ~ = ~
1 ii ............. " WHY
Motives Profit
Other
Revenue i Cost m o t i v e s i
tl Mare feedforward/feedback loops
...... -, Initial influence Figure 3 The six Ws
on, and culminates in a 'tactical' plan for the risk man- agement process, to make the process operational.
The repetitive common tasks (document, verify, assess and report) are also involved, with some specific assess tasks.
The Focus phase may be largely concurrent with the Define phase, but updating RMP plans will necessarily be ongoing. Figure 1 indicates the way effort expended on the Focus phase might be timed in a typical RMP, assuming bursts o f activity linked to the Define phase, and some additional ongoing activity.
The Define phase and the Focus phase may be thought o f jointly as a higher level Initiation phase as indicated for the UK MoD process in Table 2. The Define and Focus phases are part o f the even larger 'scope' phase in the SCERT process, as indicated in Table 2. They are separated here because they are concerned with very different deliver- ables, both o f which are essential to what follows.
Separation facilitates viewing the Focus phase as a project in its own right, and applying all we know about good project management to this phase.
I d e n t i f y t h e r i s k s a n d r e s p o n s e s : t h e i d e n t i f y p h a s e
All specific RMPs have an explicit Identify phase, some using this designation, the UK MoD 4 for example (omitting to worry about the identify-identification distinction). We cannot manage risk if we do not understand:
• where it is coming from, in terms o f what detrimental effects might be experienced, and the mechanisms under- lying these effects;
276
• what we might do about it, in proactive and reactive response terms; and
• what might go wrong with our responses, i.e. secondary risks.
All RMP methods emphasize a need to identify sources o f risk at the outset o f the process. Some specific RMPs concentrate initially on impact or effects o f these risk sources, leaving root causes or root sources until later. Some specific RMPs which defer the issue o f root causes until later also defer the related issue o f responses (to effects and root causes), and then only consider alternatives in relation to major risks. However, at least one response, even if it is 'do nothing and accept the risk' (which may not be feasable) must be identified and assumed in order to understand the impact o f a risk later in the first pass (iteration) through the process. The RMP is iterative, with frequent loops back, so specific RMPs which in theory do things in different orders can prove much the same in practice.
Identifying risks and responses involves two specific tasks:
1. Search: for sources o f risk and responses, employing a range o f techniques such as pondering, interviewing, brainstorming and checklists;
2. Classify: to provide a suitable structure for defining risks and responses, aggregating/disaggregating variables as appropriate;
plus the four common tasks document, verify, assess and report).
The deliverables provided by the identification phase should include a risk list (log or register), indicating at least one assumed response, a generic 'do nothing' being one option. The immediate deliverables may include a preli- minary assessment o f response options associated with these risks, but more detailed lists o f response options may be deferred. The key deliverable is a clear common under- standing o f threats and opportunities facing the project. Opportunities (upside risks and more effective ways o f proceeding in general) and associated responses need to be identified and managed with the same resolve as threats. Often RMPs are particularly successful because the process o f generating and reviewing responses leads to the identification o f important opportunities with implications well beyond the risks which led to their identification.
Figure I indicates the way Identify phase effort might be focused in a typical RMP, assuming significant preliminary assessment o f responses at the outset o f this phase, renewed response option identification effort later in areas where risks remain a concern.
Develop the analysis structure: the structure phase
It is useful to decompose the UK MoD 'analysis' phase into four phases (structure, ownership, estimate and evaluate), because they each have different deliverables serving different purposes.
All RMPs have a Structure phase, usually part o f another phase, like the UK MoD 'analysis' phase. Some aspects are necessarily integrated with earlier phases, like the structure implied by the lists o f activity risks and responses. Other aspects are necessarily left until now, or later. In some specific RMPs structure is implicit, assuming a simple standard structure by default. In general we want the structure used for a RMP to be as simple as possible, but
Project risk analysis and management: C Chapman
not misleadingly so. The purpose o f the Structure phase is testing simplifying assumptions, and providing a more complex structure when necessary. Failure to structure can also lead to lost opportunities. F o r example, some responses (general responses) to particular risks can in practice deal with sets o f risks, possibly all risks up to that point in a project. It is important to recognize the oppor- tunities provided by such general responses.
Structuring involves three specific tasks:
1. Refine classifications. This involves the review and dev- elopment (where appropriate) o f existing classifications, in the sense that a 'new' response may be defined because the understanding associated with an 'old' one may be refined, and in the sense that a new classification structure may be introduced, distinguishing between specific and general responses, for example.
2. Explore interactions. This involves reviewing and exploring possible interdependencies or links between project activities, risks and responses, and seeking to understand the reasons for these interdependencies.
3. Develop orderings. This involves possible revisions to the precedence relationships for project activities assumed in the Define phase. An ordering for risks is also needed for several purposes, including priorities for project and process planning, and for expository (presentation) purposes. In addition, this step involves developing a priority ordering o f responses which takes impacts into account, including secondary risks.
In terms o f documentation, the Structure phase involves completing the generation o f a set o f pictures or graphs, and defining associated mathematical models where appropriate, which capture all the key relationships in terms which are as simple as possible.
The key deliverable o f the Structure phase is a clear understanding, on the part o f the analysts and all users o f the analysis, o f the implications o f any important simplify- ing assumptions about the relationships between risks, responses, base plan activities and all others Ws.
Clarify ownership issues: the ownership phase
All RMPs have an Ownership phase, with three purposes:
• to distinguish the risks and associated responses that the client is prepared to own and manage from those the client wants other organizations (such as contractors) to own or manage;
• to allocate responsibility for managing risks and responses owned by the client to named individuals; and
• to approve, if appropriate, ownership-management allocations controlled by contractors and third parties.
The first o f these three purposes should be achieved before moving on to the following phase o f the RMP. Some organizations will consider this first purpose as a part o f project strategy, which the Define phase will identify. Deferring achievement o f the other purposes until later is usually appropriate, as indicated by Figure 1. This suggests modest effort initially, increasing in subsequent cycles as the first purpose is replaced by the second and third.
The deliverables provided by the Ownership phase are clear ownership and allocations o f management responsi- bility, efficiently and effectively defined, and legally en- forceable as far as practicable. The tasks required to provide this deliverable may be very simple or extremely complex,
277
Project risk analysis and management: C Chapman
depending upon contract strategy. F o r expository purposes assume no fixed corporate contracting policy. In these circumstances the Ownership phase involves two specific tasks:
1. Scope the policy. This task addresses issues like what are the objectives o f the ownership strategy (the why), which parties are being considered (the who), and what kinds o f risk require allocation (the what). This task culminates in a policy for risk allocation issues.
2. Plan the allocation. This task considers the details o f the approach (the which way), the instruments (the wherewithal, and the timing (the when). This task trans- forms risk ownership policy into operational contracts.
Separate identification o f this phase facilitates treating it as a project in its own right, and applying to it all we know about good project management.
Estimate in terms o f scenarios and numbers: the estimate phase
All RMPs have an Estimate phase, concerned with cost, time and other appropriate performance measures, although it may be given an alternative designation like the ' p a r a m e t e r ' phase o f the S C E R T process as indicated in Table 2, or embedded in a broader phase, like the U K M o D ' a n a l y s i s ' phase o f Table 2. It should have two purposes, which are related but important to distinguish:
• to identify areas o f the project 'reference plan' which m a y involve significant uncertainty, which need m o r e attention in terms o f data acquisition and analysis; and
• to identify areas o f the project reference plan which clearly involve significant uncertainty, which require careful decisions and judgements by the client team.
A single pass to achieve the second purpose is not usually a cost-effective approach to analysis. W e want to minimize the time spent on relatively minor risks and risks with simple response options, to use the time on major problems involving complex response options. To do this a first pass with a focus on the first purpose can be used, looping back until the second purpose can be achieved with confidence. Initial loops back can involve just the estimate and evaluate phases, illustrated in Figure I by one such loop (sub-cycle) within each o f the two complete loops back to the Define phase. Later m o r e complete loops will be effective, providing m o r e attention to detail and some revisions in relation to all the previous phase outputs in those areas where unresolved risk issues suggest it is worth applying m o r e effort. Attempting to achieve all the required outputs via a single pass process is not effective, because it will involve attention to detail which proves unnecessary in some areas, as well as skimped effort in areas where m o r e effort would be very productive. Part o f the process o f managing the R M P as a project in its own right is con- cerned with responding to those areas where risk (in threat or opportunity terms) is identified and better solutions are required. The R M P has a clearly defined formal structure, but it cannot be applied in a mechanical manner. Most experienced risk analysts understand this, but many formal statements o f R M P methodology do not make this very important point clearly enough.
The deliverables provided by the estimate phase are estimates o f likelihood and impact in terms o f cost, duration, o r other project criteria for risks identified earlier. Some
specific R M P methods suggest numeric probability dis- tributions from the outset. Some suggest likelihood and criteria ranges associated with labels like High (H), Medium (M) and L o w (L) initially, numeric measures later i f appropriate. Most methods recognize that assessment o f some risks may be best handled by identifying them as conditions, associated with assumptions, deliberately avoid- ing estimation in the usual sense. Most methods recognise that estimation in the usual numeric (or H / M / L label) terms m a y be a waste o f time, best eliminated, on occasion: for example, if on a first pass the concern is identifying and then managing any ' s h o w stoppers', 'estimation' reduces to looking for show stoppers.
The key deliverable o f the Estimate phase is the provision o f a basis for understanding which risks and responses are important. Three specific tasks are required to provide this deliverable, as follows:
1. Select an appropriate risk. As the basis o f a process o f successive estimation o f a set o f risks, select an appro- priate place to start, and each successive risk, in terms o f initial estimates and refinement o f those estimates.
2. Scope the uncertainty. Provide a simple numeric subjective probability estimate, based on the current perceptions o f the individual or group with the most appropriate knowledge, to ' s i z e ' the risk.
3. Refine earlier estimates. I f the impact o f the risk being estimated given chosen responses warrants, or the sensi- tivity o f associated response decisions warrants, refine the initial scoping estimate. This m a y be undertaken in conjunction with refining the response-related decision analysis.
Evaluate the numbers and scenarios: the evaluate phase
All RMPs have an Evaluate phase, although it m a y be coupled with the estimate phase and embedded in a broader analysis phase, like the U K M o D 'analysis' phase, or it m a y be coupled with planning and management, as in the S C E R T process description. Its purpose is synthesis and evaluation o f the results o f the estimate phase, with a view to client assessment o f decisions and judgements.
The deliverables will depend upon the depth o f the preceding phases achieved to this point, looping back to earlier phases before proceeding further being a key and frequent decision at this stage. F o r example, an important early deliverable will be a prioritized list o f risks, while a later deliverable might be a diagnosed potential problem associated with a specific aspect o f the base plan or contin- gency plans, and suggested revisions to these plans to resolve the problem. Specific loops back to earlier phases are not indicated on Figure 2, because they could be to any phase. The key deliverable is diagnosis o f any and all important difficulties, and comparative analysis o f the im- plications o f responses to these difficulties. Generic tasks other than the three c o m m o n tasks cannot be usefully defined at the level o f generality used here, but specific tasks are discussed and illustrated in Chapman and Ward. 2 The Evaluate phase should be used to drive the distinction between the two purposes o f the Estimate phase indicated earlier. That is, a first pass can be used to portray overall uncertainty and the relative size o f all contributing factors, and further passes can be used to explore and confirm the importance o f the key risks, obtaining additional data and undertaking further analysis o f risks where appropriate,
278
before moving on to consideration o f project decisions and judgements. However, to make these judgements as part o f the Evaluate phase, careful consideration has to be given to such judgements in the Estimate phase, to capture both un- certainty 'in nature' (inherent in the project) and uncertainty related to our understanding o f this inherent uncertainty.
Plan the project and the management o f its risk: the plan phase All RMPs have a Plan phase. It may be called that, as indicated for the UK MoD process in Table 2, or coupled with ongoing risk management, as for the SCERT process description. The Plan phase uses all preceding RMP effort to produce a project base plan ready for implementation and associated risk management plans (actions) for the project management process. Ensuring these plans are complete and appropriate is the purpose o f this phase. The plans are the deliverables. The specific tasks are reasonably obvious in relation to the specific deliverables. Some o f the key specific deliverables any RMP Plan phase should provide are:
• base plans in activity terms, at the detailed level required for implementation, with timing, precedence, ownership and associated resource usage-contractual terms where appropriate clearly specified, including milestones initiating payments, other events or processes defining expenditure, and an associated base plan expenditure profile;
• risk assessment in terms o f threats and opportunities, prioritized, assessed in terms o f impact given no response if feasible and potentially desirable, along with an assessment o f alternative potential proactive and reactive responses; and
• recommended proactive and reactive contingency plans in activity terms, with timing, precedence, ownership and associated resource usage--contractual terms where appropriate clearly specified, including trigger points (decision rules) initiating reactive contingency responses, and impact assessment.
Proactive responses will be built into the base plans, and reactive responses will be built into the associated contin- gency plans, when they become part o f the overall project plans. All phases o f the RMP should be closely coupled with project planning in general, but the need for this coupling is perhaps particularly obvious in this phase.
Most experienced risk analysts argue in favour of reaching the Plan phase for the first time early in the RMP, much o f the RMP time then being spent in iterative loops concerned with the development o f project plans. Figure 1 assumes this is the case, the illustrative three complete cycles being used to revise and reassess developing plans as well as refining analysis o f risks and responses where this seems worth while. In practice early completion o f the first pass may not be achievable, but the benefits o f the RMP will be reduced as a direct consequence.
Some specific methods suggest a formal separation between base plans (which are owned by the project planning function) and the risk management plans (which are owned by the risk management function). This can be required by organizational constraints, but it is not desirable. It high- lights the practical need to separate project management and risk management in some organizations, but the general desirability o f seeing risk management as an integral part o f project management.
Project risk analysis and management: C Chapman
Manage the project and its risk: the Manage phase
All RMPs have a Manage phase, ongoing once the project is implemented, concerned with monitoring actual progress with the project and the associated risk management plans, responding to any departures from these plans, and dev- eloping more detailed plans for the immediate future. One key deliverable is diagnosis o f a need to revisit earlier plans, the basis o f control, and initiation o f replanning as necessary. Another is rolling development o f plans ready for implementation. The specific tasks relate to the specific deliverables as in the Evaluate and Plan phases. Some o f the key deliverables any RMP Manage phase should provide on a regular cycle (monthly for example) include measures o f achieved performance in relation to planned progress, a short prioritized list o f r i s k - r e s p o n s e issues requiring ongoing management attention, with recent changes in priority emphasized and trends assessed, plus related lower level more detailed reports drawing appropriate manage- ment attention to all issues requiring action. In addition to reports on a regular cycle, significant events should initiate appropriate replanning and exception/change reporting.
A r i s k management process earlier or later in the project life cycle
Guidelines associated with the impact o f using a RMP earlier or later in the project life cycle raise very complex issues, and only a few overview comments can be offered here.
Implementing a RMP earlier in the project life cycle is in general more difficult, because the project is more fluid, and less well defined. A more fluid project means more degrees o f freedom, more alternatives to consider, including alternatives which may be eliminated as the project matures for reasons unrelated to the RMP. A less well-defined project means appropriate documentation is harder to come by, and alternative interpretations o f what is involved may not be resolvable. At a very early stage in a project's life cycle, just after conception, RMP can be like attempting to nail jelly to the wall.
That said, implementing a RMP earlier in the project life cycle is in general much more useful i f it is done effec- tively. There is scope for much more fundamental improve- ments in the project plans, perhaps including a risk driven redesign or initial design o f the product o f the project. The opportunity aspects o f RMP can be particularly important for early RMP implementation. It can be particularly important to be very clear about project objectives, in the limit decomposing project objectives and formally mapping their relationships with project activities, because pre- emptive responses to risks need to facilitate lateral thinking which addresses entirely new ways o f achieving objectives.
Some broad general features o f RMP earlier in the project life cycle include characteristics like it is usually less quantitative, less formal, less tactical, more strategic, more creative, and more concerned with the identification and capture o f opportunities.
Implementing a RMP later in a project life cycle gives rise to somewhat different difficulties, without any compen- sating benefits. Contracts are in place, equipment has been purchased, commitments are in place, reputations are on the line, and managing change is comparatively difficult and unrewarding. A RMP can and should encompass routine reappraisal o f a project's viability. In this context early warnings are preferable to late recognition that targets
279
Project risk analysis and management: C Chapman
are incompatible or unachievable. That said, better late than never.
As a general rule, the earlier the better, but organizations which want to introduce a R M P which have some choice about when in the context o f a range o f possible projects to use as test cases would do well to start with a project which has been well managed to the project approval stage. Being thrown into the deep end m a y prove an effective way to learn to swim, but there are preferable alternatives.
Alternative perspectives Guidance associated with alternative perspectives and associated approaches to contracting are beyond the scope o f this paper, but it m a y be useful to make the following points:
• if risk ownership is not clearly defined, a client's risks can be a c o n t r a c t o r ' s opportunities;
• clients and contractors necessarily have different objec- tives, but a contract which leads to confrontation is perhaps the biggest single risk most projects encounter, a contract which seeks congruence in objectives being absolutely critical;
• clients and contractors both need to undertake separate RMPs, but they need to establish a constructive dialogue involving input to each others' RMPs, and 'fixed' price contracts mitigating against this;
• the trend towards ' p a r t n e r i n g ' and other forms o f contracting which facilitate cooperative working is a trend to follow, but not blindly, when developing a comprehensive procurement strategy; and
• a carefully and thoughtfully executed R M P should address all the really difficult and sometimes obscure questions, like how should contracts be structured and defined, as well as the comparatively obvious ones like how much will the project cost, if for no other reason than the fact that the answers to the simple questions usually depend upon the assumptions about the difficult ones.
Selecting shortcuts The comprehensive RMP outlined here should be under- stood as a cohesive, internally consistent, integrated process in full before attempting the shortcuts and modifications which are essential in most practical applications. Practical projects require shortcuts, but explaining how shortcuts should be selected is not a simple matter.
Conclusions The R M P outlined in this p a p e r is comprehensive in the sense that it is designed to include all specific methods in current use the authors o f the A P M Guide were familiar with, to give the reader an overview. Separate chapters for each section o f this paper in Chapman and W a r d 2 give this overview m o r e operational content, and clarify its nature with examples. The A P M P R A M Guide ~ elaborates in a different manner, including the use o f case studies.
Several key issues should be clear f r o m the overview provided here:
• RMPs are highly structured, but they do not imply a rigid 'painting-by-numbers' approach. Creativity, lateral thinking and imagination are stimulated b y the process, not discouraged.
• RMPs are in many important respects largely a formaliz- ation o f the c o m m o n sense project managers have applied for centuries. The RMP described here is not a new way o f thinking, or the engine o f an intellectual revolution, which requires a significant change in mind set to be appreciated.
• The formalisation involved in RMPs is central to cap- turing the benefit o f RMPs, as part o f the communication processes involved. The level and kind o f communi- cation R M P can generate can lead to significant culture changes within organizations. These changes can be quite fundamental, and they can be very complex.
• Because RMPs can be concerned with very complex issues, it is very important to see ' k e e p it simple' as a guiding principle, adding complication only when benefit from doing so is perceived.
• The iterative nature o f the R M P is central to 'keeping it s i m p l e ' , using early passes o f the process to identify the areas that need m o r e detailed assessment in later passes.
• A particularly useful insight which the Focus phase o f the A P M process captures is the need to 'plan and manage the planning' as a project in its own right, using everything we know about 'planning and managing'. The distinction between 'planning' and 'planning the planning' is important, and making it explicit is very useful.
• A particularly useful insight which the Ownership phase o f the APM process captures is the need to manage relationships as a project in its own right.
• An exciting aspect o f the direction this R M P definition and development is taking is its 'strategic' flavour, moving away from 'tactical' planning. It is driving project ' o w n e r s ' towards seeing project risk management as benefit management o f selected projects, and under- standing the connections between individual project benefits and requirements as an output o f a p r o g r a m m e management approach to project management. Further, they are seeing p r o g r a m m e management as a basis for strategic management. Finally, to close the loop,* they are seeing project selection as an output o f strategic management.
Acknowledgements Members o f the A P M SIG on Project Risk Management who were involved in the working party which contributed to the generic process definition described in this paper (and their organisations) are: Paul Best (Frazer-Nash), Adrian Cowderoy (City University, Business Computing), Valerie Evans (Ministry o f Defence Procurement Executive), Ron Gerdes (British Maritime Technology Reliability Consultants Ltd), Keith G r a y (British Aerospace (Dynamics)), Steve Grey (ICL), Heather Groom (British Aerospace (Dynamics)), Ross Hayes (University o f Birmingham, Civil Engineering), David Hillson (HVR Consulting Services Ltd), Paul Jobling (Mouchel Management Ltd), M a r k Latham (BAe(British Aerospace)SEMA), Martin Mays (BAeSEMA), Ken Newland (Quintec Associates Ltd), Catriona Norris (TBV Schal), G r a h a m e Owen (IBM(UK) Ltd), Philip Rawlings (Eurolog), Francis Scarff (CCTA, The Government Centre for Information Systems), Peter Simon (PMP, Project Management Professional Services Ltd), Martin Thomas (4D Management Consultancy), and David Vose (DVRA, David Vose Risk Analysis). We would all particularly like to thank Peter Simon (chair o f the working party and editor o f the P R A M Guide) and David Hillson (secretary to the
280
P r o j e c t risk analysis a n d m a n a g e m e n t : C C h a p m a n
w o r k i n g p a r t y ) . N a t i o n a l W e s t m i n s t e r B a n k c o l l e a g u e s s u g g e s t e d the p a r t i c u l a r l y u s e f u l c l o s u r e o f the l o o p - - s e e a s t e r i s k in l a s t p o i n t o f C o n c l u s i o n s . S t e p h e n W a r d d e c l i n e d h a v i n g his n a m e o n this p a p e r b e c a u s e so m a n y o t h e r s h a d c o n t r i b u t e d as n o t e d a b o v e , b u t h e p l a y e d a s i g n i f i c a n t r o l e in s h a p i n g it. J o h n W i l e y a n d S o n s k i n d l y a g r e e d to the d i r e c t u s e o f m a t e r i a l f r o m C h a p m a n a n d W a r d 2 w h i c h m a k e s u p m u c h o f this p a p e r . T w o a n o n y - m o u s r e f e r e e s p r o v i d e d a n u m b e r o f u s e f u l c o m m e n t s .
References
1. Association for Project Management (APM), Project Risk Analysis and Management (PRAM) Guide (in preparation).
2. Chapman, C. B. and Ward, S. C., Project Risk Management: Processes, Techniques and Insights. John Wiley & Sons, Chichester, 1997.
3. Chapman, C. B., Large engineering project risk analysis. 1EEE Transactions on Engineering Management, 1979, EM-26, 78-86; or s e e Chapman, C. B., A risk engineering approach to project risk management. International Journal o f Project Management, 1990, 8(1) 5-16
4. MOD(PE)-DPP(PM), Risk Management in Defence Procurement, Reference D/PPP (PM) 2/1/12, published by and obtainable from
the Ministry of Defence, Procurement Executive, Directorate of Procurement Policy (Project Management) Room 6302, Main Building, Whitehall, London, SWlA 2HB, 1991.
Chris Chapman is Professor o f management science and Director o f the School o f Management at the University o f Southampton. For about 20 years his consulting and research have centred on the man- agement o f risk. Most o f his con- sulting has been concerned with large energy projects in the UK, USA and Canada, but other concerns have included computer hardware and software systems, aircra)2 production, warship building, financial asset and commodity broking portfolio manage- ment. He was the founding chairman o f the APM Specific Interest Group (SIG) on Project Risk Management, and is a past president o f the Operational Research Society. He holds a BSc in industrial engineering (Toronto), an MSc in operational research (Birmingham) and a PhD in economics and econometrics (Southampton).
281