Once risk planning has been completed, the next stage is to start the process of risk identification. Figure 11.2 shows the inputs, tools and techniques and the sole output for the risk identification process. As in the production of the risk management plan, the task of identifying the project risks is predominately conducted by the project manager, key stakeholders, the sponsor and the project team. Extra assistance can also be gained from subject matter experts, although everyone should be encouraged to identify risks when they are seen. The first iteration of the risk identification process cannot start until the project scope statement and WBS have been created, but a good starting point could be the risks identified within the preliminary project scope statement generated by the sponsor. The whole process does not stop with the production of the initial risk register. Work continues to constantly review and revise the identified risks, because updating the risk register is an iterative process. Always try to involve the project team with the regular risk reviews, because this will encourage a level of ownership and responsibility towards the risks and their associated responses. As you move through the project's lifecycle, more risks may be identified, while others noted may disappear in time.
Figure 11.2. The risk identification process
The risk register is the foundation of managing risks effectively. It contains both known knowns and known unknowns, but any risk not in the register is in effect an unknown unknown, the most dangerous kind of risk. It is vital that all risks identified go into the risk register. The tools and techniques are explained in the text. Adapted from PMBOK Guide (p.246)
The first set of tools and techniques used to identify project risk is a full review of the project's plans and documents. This should present the risks covered by the project charter and preliminary project scope statement, together with documents included within the project management plan. The other details to consider, which in some way can be of more importance, are those elements missing from this documentation. All of these documents play their part in the planning and execution of the project, but differences or inconsistencies between the plans and the project requirements could provide signs of risk to the project manager. Risks experienced from other projects could also prove useful as a guide or prompt.
Information gathering techniques
There are a series of basic techniques used to gather information from many sources. The standard approaches used to identify possible risks associated with the project are described in the following paragraphs.
Brainstorming is a collaborative environment to encourage free association among the project members. Individuals can either call out their ideas spontaneously, or take turns to offer ideas on project risk. The principle of using this technique with stakeholders and team members is to get people to input their ideas on risk, and to feed off points raised by others. A facilitator is best used to control the session, but can also be used to scribe each risk as it is suggested. The initial part of the brainstorming session can be broad, but the risk breakdown structure may be used as a good starting point to target thoughts on specific risk areas. The next stage of brainstorming could involve expanding the identified risks and the definitions linked to them.
The purpose of the Delphi technique is to obtain information and judgements from experts to come up eventually with an overall consensus. The process does not physically bring the contributors together, but information about risks and their responses is exchanged via mail, fax or e-mail. This technique is designed to take advantage of the experts' creativity, as well as combining the effects of group involvement and interaction. By keeping the group apart during the review process, no one person will have greater influence on the final outcome. If the e-mail system is used to recirculate the anonymous responses on project risk, a consensus can usually be reached within about five days.
The process of interviewing stakeholders and experts to identify project risk remains an important approach. The task of conducting the interview will fall to the project manager, or their team, but time spent gathering risks from subject matter experts and stakeholders could pay dividends in the longer term.
Root cause analysis
Once the task of identifying all possible risks has been completed, analysis of the information may link a single cause to a series of risk outcomes. Further analysis of the identified cause could then uncover more risks to the project. From a proactive approach, if you are able to eliminate the specific cause to some of the risks, effort can then be focused on the remaining project issues.
Strengths, weaknesses, opportunities and threats analysis (SWOT)
The aim of SWOT analysis at this stage should be to isolate the key risks that could have an impact on the success of the project. By identifying the main strengths of the project, this in turn produces specific threats towards its progress. It is also essential to spell out the assumptions made prior to starting the analysis process.
The first step for the project manager is to select the required information gathering techniques to identify and specify the risks involved. Once this process has been completed, the checklist can then be considered as a mechanism to double-check your thinking so far. Using the checklist as a final confirmatory test gives the project manager the confidence that all the risk categories have been addressed, although it is impossible to say that every risk has been covered. The checklist can be amended throughout the project's lifecycle, but the final update should occur during project closure to reflect the risks experienced. An improvement to the checklist will prove beneficial for future projects.
A series of assumptions are made at various stages of the project's progress with the information available at the time. Analysis of these assumptions could identify errors or inconsistencies that pose further risk to the project. Assuming good weather conditions in early spring for a building project would certainly increase the level of risk, but also allow justification to challenge the validity of the assumption.
These techniques can be used in the analysis of quality issues when identifying risks. Root cause analysis has already been mentioned for identifying possible causes of risk, but other techniques such as fishbone diagrams, flowcharts and influencing diagrams are useful tools. Looking at the project from a different angle can develop ideas, as well as coming up with other possible risks.
Output of risk identification risk register
The key output from risk identification, after using some or all of the techniques listed, is contained in the risk register. Once the list of identified risks has been drawn up, a list of potential responses may be produced and fed in to the risk response planning process. New risk categories identified and developed during the risk management process can then be added to the RBS. The risk register is also vital at project closure because the information contained in its pages will be useful to other projects, therefore the need to retain the updated register for the project's historical records must be remembered. The importance of the new categories included in the revised checklist may not help you, but it could assist project managers in the future.
Top of Page