Risk identification

combining the tools to deliver the goods

Conference Paper Risk Management 25 May 2003

Piney, Crispin

How to cite this article:

Piney, C. (2003). Risk identification: combining the tools to deliver the goods. Paper presented at PMI® Global Congress 2003—EMEA, The Hague, South Holland, The Netherlands. Newtown Square, PA: Project Management Institute.

Manage Risk Proactively

This webinar demonstrates key failures of traditional risk management and stakeholder management practices in projects with "extreme unknown unknowns," and identifies the remedy.

View the Webinar

Acknowledgements

I would like to thank Kees Vonk for a critical review and valuable suggestions to this paper, and for agreeing to present it at the PMI Global Congress, Europe.

Introduction

The risk identification lifecycle

Whereas the PMBOK^® Guide presents a clear methodology for managing risks – from identification, through analysis to monitoring and control – the actual process of identification as described lacks any internal structure. Given the number and complexity of the tools specified for this function, the practitioner can encounter considerable difficulty in deciding which tool to use, why and how, at various points in the process.

The contribution of this paper is to provide a logic that adds a structural overlay to the tools and techniques listed in the PMBOK^® Guide and define, in effect, a practical “Risk Identification Lifecycle” (Exhibit 1). The activities in each phase of the lifecycle are explained in the body of the document. As with any lifecycle, the idea is to invest only as much effort as necessary in any phase – in case the decision is made not to progress to the next phase.

Note also that “statement finalisation” can be delayed until after the Risk Analysis phases, if the initial risk statement is sufficiently detailed for the analysis; the PMBOK^® Guide does in fact state that the one output of the Analysis process is “risks for additional work”: statement finalization is typical of this “additional work”.

Exhibit 1: The six phases of the Risk Identification Lifecycle

The process that precedes risk identification is risk management planning. The output of this process is the “risk management plan”, which should provide one key input to the identification lifecycle: a template for a fully specified risk statement (Exhibit 2).

The risk statement

In the same way that one key characteristic of project management is the progressive elaboration of the resultant deliverables, the completeness of the list of risks and the plans for responding to them also need to be elaborated progressively.

One key point to note for effective risk identification is the following: it is not only the list of risks that needs to be elaborated progressively, the same holds for the full description of each risk: a fully specified risk statement has to describe not only what may happen, but also why, when and to what effect (for a fuller description of this see Hillson 2000). The most effective way of ensuring that this is carried out consistently by the project team is to define, in the Risk Management Plan, a standard template for all risk statements. One typical template is given in Exhibit 2: The expressions in italics inside the square brackets need to be specified in order to describe any risk completely.

Exhibit 2: A typical Template for a fully specified risk statement

People, naturally, do not think in terms of fully specified risk-statements: when you ask for potential risks, you will initially obtain a mixture of

effects (e.g. “the customer does not really know what they want”)
causes (e.g. the external influences on bidding successfully for a contract)
impacts (e.g. “we could have to pay penalties”)
areas of risk (e.g. “I'm really worried about our delivery process”)
and events (e.g. “we could fail the acceptance test”)

This is not initially a problem once you understand how to use the various tools in order to elaborate, progressively, the complete list of fully specified risk statements.

One additional point to bear in mind is that “risks”, as they occur in projects and as defined in the PMBOK^® Guide, are uncertain events which can have a positive or negative effect on the objectives of the project. Positive risks are generally known as opportunities, negative risks as threats. In the identification process, you need to identify and specify all of these potential threats and opportunities.

The structure of the paper

The paper will follow describe each phase of the risk identification lifecycle in turn, with its tools and techniques. In order to explain each of the risk identification concepts and the use of the corresponding tool, these will be applied to the Sample Project defined below (see Exhibit 3). Additional details and constraints relative to this project will then become apparent as the risk identification process progresses.

Exhibit 3: The Stated Objective for the Sample Project

The First Step – Basic Identification

The first step in any project is to ask two questions:

Why (or why not) us?
Where have we seen this before?

The first question corresponds to a SWOT analysis, whereas the second can be answered by use of “lessons learned” or other sources of analogy with known projects (Exhibit 4).

Exhibit 4: The tools in the Basic Identification phase

SWOT Analysis

The four letters that make up the acronym SWOT stand for “Strengths”, “Weaknesses”, “Opportunities” and “Threats” (Bradford 1999). The first two (SW) correspond to internal capacities of the organisation, whereas the last two (OT) refer to factors impacting or impacted by the external environment. For the Sample project,

A Strength: we have a product that works and we understand
A Weakness: we do not have experience in delivering in some of the countries mentioned
An Opportunity: we have a good name in the market-place
A Threat: there are some start-up companies that will be able to under-bid us

Analogy

The approach is to learn from previous experience (see also Pritchard 1997). In this case it is very important to select a project or set of projects that are really similar to the current one. For the Sample project, when we came up against one of these competitors before, we lost the bid because of their political lobbying

The Second Step – Detailed Identification

The risks identified in the first step will serve as a trigger the thinking in more depth. There are five main techniques described in the PMBOK^® Guide for this (Exhibit 5).

Exhibit 5: The tools in the Detailed Identification phase

Interviewing

In order to obtain the best results from an interview, it should be run as a project in its own right: define the objectives and desired outcome. Select the correct people and brief them (interviewers and interviewees). Allocate time and resources. Develop relevant questions. For more details, see Pritchard 1997.

For the Sample project, they decided to interview their Chief Financial Officer to identify the financial risks in the case of winning the bid, losing the bid and choosing not to bid.

Assumptions Analysis

A number of project decisions are based on (conscious or unconscious) assumptions. Since each assumption could be wrong, each is a potential risk. One challenge in assumptions analysis is to try to make the unconscious assumptions visible.

For the Sample project, one assumption is that the customer does in fact want to buy the product or service described in the RFP. This could be false (they may have decided to create it themselves and are just looking for additional information or justification for this). This is clearly a threat.

Document Reviews

All of the project documents provide details that can indicate areas of risk. Some risks may come from faulty project process, whereas others may be inherent in the project approach or constraints.

For the Sample Project, the RFP states that in case of satisfactory delivery by the chosen contractor, the contractor may be requested to provide ongoing support and operations for the service. This is an opportunity to be considered.

Delphi Technique

This technique is especially useful when the views of a large number of distributed people are required. It can be seen as remote interviewing with group feedback (Meredith & Mantel 1995).

A document is sent to each participant explaining the situation and asking a specific question or set of questions. The responses are then analysed and assembled into a standardised form, destined to ensure a consistent and objective structure to each statement. The full list is then circulated to all participants with a follow-on question such as “what is the relative correctness and importance of each statement, and does this list suggest any additional points to you”. These responses are once again collated and a final list circulated for approval.

For the Sample project, the leaders of each functional entity were solicited in this way and differing views on the types and levels of risk were brought to light:

Sales saw the size of the initial order as a major opportunity whereas
Manufacturing saw it as a threat to its current commitments due to capacity limitations

Brainstorming

The basic concept of brainstorming is to encourage creative thinking by allowing all participants to propose ideas with no fear of criticism or negative judgement (Meredith & Mantel 1995). This can lead to considerable synergy and unexpected ideas.

There are two main approaches:

purely verbal (the “classic approach”)
partly written (“nominal group technique”).

The classic approach

In this case, the facilitator writes down each of the suggestions – normally on a flip chart or similar. The facilitator ensures that there is no analysis or criticism of any ideas. The only discussion allowed is for clarification. The facilitator consolidates the list once the session is over. The success of this technique depends on the ability of the facilitator to ensure that everyone gets a fair chance to express themselves.

Nominal Group Technique

In this case the participants start of by writing their ideas on stick-on notes, one idea per note. The facilitator then gets each participant in turn to read out one idea; the note is then stuck on the wall. Once again, the facilitator ensures that there is no analysis or criticism of any ideas. Participants can create additional notes as ideas come to them while this process is going on and read them out as their turn comes back. This technique is more structured than the classic approach and allows people more time to prepare their thoughts. It ensures that each participant can express themselves.

The Third Step – Expand the List

By now you already have a fairly extensive set of risks. However, this is almost entirely based on knowledge and ideas from within the project team. The next step is to evaluate whether there is any relevant information available beyond the project (Exhibit 6).

Exhibit 6: The tools in the External Cross-check phase

Checklists

Risk checklists are normally aimed at a specific market or technology area. They consist of a list of typical risks with their causes and typical impacts (see Appendix in Pritchard 1997). They will often also propose typical responses. They should only be used once the initial list has been developed because they tend to stifle creativity if used prematurely.

The Fourth Step – Validate against the scope

However well the list has been produced, it is always important to verify that it does correspond exactly to the defined scope (Exhibit 8). It is at this point therefore that the Work Breakdown Structure (WBS) should be used, since the WBS provides a hierarchical breakdown of all of the work planned for the project (Kerzner 1998).

Exhibit 8: Use of the WBS in the Internal Cross-check phase

Mapping to the WBS

For each item from the risk list, identify which elements of the WBS correspond to it, add this information to the risk list and flag the corresponding elements of the WBS accordingly. This will make planning the response more straightforward, as well as assigning a person responsible for managing that risk.

Checking the WBS

This is carried out after mapping to the WBS: you should check each of the WBS elements – and especially those that are not flagged as having an associated risk – to see whether they suggest any specific risks. If no risks are identified for any elements, it is recommended to flag those elements as “risk-free”.

After the Fourth Step – What's Next?

At this point, you will have a list of risks, which, as mentioned at the start, will be a mixture of causes, impacts, areas and events. What is finally required is to fill in any missing element in each fully specified risks statement (Exhibit 2). There are specific tools for determining each missing element. (Exhibit 9)

Exhibit 9: The tools in the Statement Finalization phase

Flowcharting

A flowchart can show the activities and decisions as well as the flow of control and data through a specific area or process (Dale 1999). In order to determine the risks associated with the area or process in question, each action and decision-point has to be investigated from the point of view of threats and opportunities that it might represent (Exhibit 10).

Exhibit 10: Flowchart for Sample Project delivery process

Fishbone diagram

This technique is best known in the Quality Management area and is also known as a “cause-and-effect diagram” (e.g. Dale 1999): it provides a pictorial method of breaking down the potential causes of a given situation hierarchically into more and more detail: the “head” of the fish is the situation and the “backbone” links all potential causes – which are the main fish bones. For each bone, the same breakdown into potential cause is carried out, to produce an added level of fishbone, and so on to the required level of analysis (Exhibit 11).

Exhibit 11: Fishbone Diagram for Sample Project to analyse why the customer may not know what they want

Influence diagram

An influence diagram is a way of showing the relationship between actions – in their chronological order – and potential causes. In this way the full set of risk scenarios can be shown. All that then remains is to read the various scenarios off the diagram by following the influence relationships (Exhibit 12).

Exhibit 12: Influence Diagram for Sample Project showing the various influences and their effects on the bid

Conclusion

A “good” risk list satisfies the following criteria:

Each statement complies with specified template for a fully specified risk statement (Exhibit 2)
Each risk statement corresponds to one or more elements in the WBS and these have been identified accordingly.

The fully specified statements are developed progressively across the Risk identification lifecycle. An integrated view of the lifecycle is shown in Exhibit 13. This table allows immediate selection of the correct tool to use at any point.

The components of the statements support all of the risk management processes that depend on risk identification:

The Cause: pre-emptive action can then be taken to prevent or reduce the probability or impact
The Event: knowing the event allows you to determine symptoms and recognise when it occurs, so as to take any planned – or unplanned – action necessary
The Time Window: this allows the project team to focus their efforts most effectively
The Impact: this allows an evaluation of the effect and potential size
The Project Objective: this shows which aspect of the project is impacted – and, therefore, who should take ownership

Exhibit 13: The tools and their use within the Risk Identification Lifecycle

References

Bradford, Robert W. (1999). Simplified Strategic Planning. Worcester, MA, USA: Chandler House Press.

Dale, Barry G. (1999). Managing Quality. Malden Mass, USA: Blackwell Publishers.

Hillson, David (2000). Project Risks - identifying causes, risks and effects. PM Network, Project Management Institute, 14(9), 48-51.

Hillson, David (2002). The Risk Breakdown Structure (RBS) as an Aid to Effective Risk Management. PMI European Conference, Cannes, France.

Kerzner, Harold (1998, June). Project Management. A systems Approach to Planning, Scheduling and Controlling. NY, USA: John Wiley & Sons, Inc.

Pritchard, Carl L (1997). Managing Risk – Concepts and Guidance. Arlington, VA, USA: ESI International.

Project Management Institute (2000). A Guide to the Project Management Body of Knowledge. Newtown Square, PA:Project Management Institute.

Turner, J.R. (1993). The Handbook of Project-based Management (pp.247-248). London, UK, McGraw-Hill.

This material has been reproduced with the permission of the copyright owner. Unauthorized reproduction of this material is strictly prohibited. For permission to reproduce this material, please contact PMI or any listed author.

PMI Global Congress 2003-Europe 25-26 May, 2003