introduction
Identify Risks is the process of determining which risks may affect the project and documenting their characteristics.
The key benefit of this process is the documentation of existing risks and the knowledge and ability it provides to the project team to anticipate events.
Purposes of Identify Risks Process
Purposes of Identify Risks Process
A risk cannot be managed unless it is identified.
The purpose of risk identification is to identify the maximum extent to which the risk is practicable.
It is good to be as comprehensive as possible while identifying the risks in the project. All identifiable risks to the project objectives need to be recognized.
The process of risk identification is not merely restricted to the planning phase of the project,
but it should be made an ongoing and iterative process, throughout the project lifecycle.
When a risk is first identified, the potential responses may also be identified at the same time.
Likewise, the person who identifies the risk on the project could be the right one to recommend a potential solution to mitigate that risk.
This risk should be recorded and considered for immediate action if appropriate.
Who participate in identify Risk ?
the following entities can participate in identify Risk :
- project manager
- project team
- risk management team if assigned
- subject matter expert SME
- risk expert
- other project manager in other projects
- end user
- stakeholder
- customer
Risk Register
Risk Register is created in this process and develop during ALL project phases
Risk Register include :
- list of risk : risk name
- risk response : although risk response plan will be detailed later, but this is initial risk response
- root cause of risk
- updated risk category
Success Factors of Identify Risk
Identify Risk Success Factors
identification is early identification.
- Risks should be identified right from the beginning of the project. The earlier the detection of risk, the sooner is the decision regarding risk response made.
- The responses which are taken early usually cost lesser than the ones that are implemented later on.
iterative identification.
- In practice, all the risks cannot be identified at the initial stage of the project.
- The process of risk identification should be carried out throughout the project.
- To make this effective, define the periodicity in terms of frequency or milestone of the project.
- The frequency typically depends on the size and the complexity of the project. During the initial stages of the project, the frequency of risk meetings should be high.
emergent Identification.
- Emergent identification means that, in addition to following the identify risks process as defined in the project plan, the risks should be identified at any time during the course of the project.
- You need not wait for the risk management or status meeting to work on identifying the risks.
comprehensive identification.
- It is recommended to be as comprehensive as possible while identifying risks on the project.
- Comprehensive identification ensures that you find all the possible sources from where risks can be identified. These sources can be internal, external, technical, or project management related risks.
explicit identification of opportunities.
- It is not just the threats that need to be identified, but also the opportunities on the project.
- Explicit identification ensures that opportunities are properly explored.
multiple perspectives.
- It is always better to get multiple perspectives on a particular risk. It is purely based on the stakeholder expectation, interest, environment, and appetite.
- The risk identification process should be carried out by considering the input received from a broad range of stakeholders.
- This ensures that all perspectives are represented and considered. If you are restricting risk identification to the immediate project team, then there are high chances of missing some of the identifiable risks.
link risks to project objectives.
- Identified risks are either an opportunity or a threat to the project objective.
- These risks should be linked to project objectives like time, cost, scope, quality, etc.
- Sometimes, these risks can be linked to a single or multiple objectives.
- For example, unavailability of software license on time delays the project completion date, while squeezing the activities or using the fast tracking compression technique to deliver the project on time affects the quality.
- The fast tracking compression technique refers to the process of conducting activities in parallel instead of performing them in a sequence.
complete risk statement.
- It is always good to capture risk in the form of a complete risk statement.
- For example, due to change in the weather, the machine might malfunction which results in a delay on the project.
- The weather change is considered as the cause here. The malfunctioning of the machine is the risk, and the delay in the project is the effect.
- The risk identified should be clear and unambiguous.
- Detailed risk descriptions with the description of uncertainty, and its causes and effects should be mentioned as early as possible in the project lifecycle.
Ownership and level of details.
- The need to identify risks and respond appropriately is not the ownership of the project manager alone.
- The ownership also lies with other responsible people in the project. Risks should be identified at a number of levels of details.
- A high-level description of risk makes it difficult to understand and develop response.
- , the level should be good enough to assign to people who can take the accountability and responsibility of identifying and managing the risk.
- Triggers should be identified wherever possible and appropriate.
objectivity.
- The risk identification process needs human intervention which can result in bias as a result of conflict of interest and judgmental factors.
- This also occurs because people apply heuristics.
- This should be recognized and addressed during risk identification process. The sources of bias should be exposed wherever possible and their effect on the risk process should be managed proactively.
- The aim is to minimize subjectivity and allow open and honest identification of as many risks to the project as possible.
process inputs - techniques - outputs
Inputs
- risk management plan
- cost management plan
- schedule management plan
- quality management plan
- HR management plan
- scope baseline
- activity cost estimate
- activity duration estimate
- stakeholder register
- project documents
- procurement documents
- OPA
- EEF
Techniques
- documentation review
- information gathering techniques
- checklist analysis
- assumption analysis
- diagramming techniques (quality management tools)
- SWOT analysis (strength wake opportunities threat)
- expert judgment
Outputs
- risk register
- risk report
- update project documents
process inputs
Identify Risks: Inputs
Project Management Plan
The components of the overall project management plan that are inputs to this process include:
- Requirements management plan–the requirements management plan may indicate which project objectives that are particularly at risk
- Schedule management plan–the schedule management plan may identify areas that are subject to uncertainty or ambiguity with respect to the schedule. Note: activities on the critical path will automatically be of higher risk to the project, as any delay in their execution will result in a delay in the final deadline of the project.
- Cost management plan–the cost management plan may identify areas that are subject to uncertainty or ambiguity with respect to the budget.
- Quality management plan–the quality management plan may identify areas that are subject to uncertainty or ambiguity, or where key assumptions with regards to quality have been made that might give rise to risk.
- Resource management plan–the resource management plan may identify areas that are subject to uncertainty or ambiguity, or where key assumptions with regards to critical resources have been made that might give rise to risk.
- Risk management plan–includes the following elements relevant to this process: like Lists risk and Indicates as well as Describes categories of risk
- Scope baseline–indicates deliverables in the scope statement which might give rise to risk. The WBS can be used as a framework for identifying individual risks.
- Schedule baseline–May be used to identify milestones and deliverable due dates that are subject to uncertainty or ambiguity, or where key assumptions with regards to the schedule have been made that might give rise to risk.
- Cost baseline–May be used to identify costs or funding requirements that are subject to uncertainty or ambiguity, or where key assumptions with regards to costs have been made that might give rise to risk.
Project Documents
- Assumption log–assumptions and constraints recorded in the assumption log may give rise to individual project risks and may also influence the level of overall project risk.
- Cost estimation–cost estimates provide quantitative assessments of project costs, ideally expressed as a range, indicating the degree of risk, where a structured review of the documents may indicate that the current estimate is insufficient and poses a risk to the project.
- Duration estimation–duration estimates provide quantitative assessments of project durations, ideally expressed as a range, indicating the degree of risk, where a structured review of the documents may indicate that the current estimate is insufficient and poses a risk to the project.
- Issue log–issues recorded in the issue log may give rise to individual project risks and may also influence the level of overall project risk.
- Lessons learned register–this is where lessons learned during the process of risk identification will be recorded and reviewed in later processes of the project to determine whether similar risks might recur during the remainder of the project.
- Requirements documentation–the project requirements should be analyzed during this process to identify those that could be at risk.
- Resource requirements–resource requirements provide quantitative assessments of project resource requirements, ideally expressed as a range, indicating the degree of risk, where a structured review of the documents may indicate that the current estimate is insufficient and poses a risk to the project.
- Stakeholder register–Indicates which individuals or groups might participate in identifying risks to the project. It also details those individuals who are available to act as risk owners.
Agreements
- If the project requires the external procurement of resources, the agreements may have information such as milestone dates, delivery dates, contract type, acceptance criteria, and awards and penalties that can present threats or opportunities.
Procurement Documentation
- If the project requires the external procurement of resources, the initial procurement documentation should be reviewed, because procuring goods and services from outside the organization may increase or decrease overall project risk and introduce additional individual project risks
Enterprise Environmental Factors
- Published material, including commercial risk databases or checklists
- Benchmarking results
- Industry studies of similar projects
Organizational Process Assets
- Project files, including actual data and checklists, from previous similar projects
- Risk statement formats
- Organizational and project process controls for risk
process - techniques
Expert Judgment
- Experts should be consulted who have expertise in individual project risks and those stakeholders with a grasp of risk management who can weigh in on the overall project risks based on their expertise in the field.
Data Gathering
There are many ways of gathering data regarding risk:
- Brainstorming–ideas are generated under the guidance of a facilitator either in a free-form fashion or by using more structured techniques. A particular useful starting point for these discussions is the Risk Breakdown Structure, which categorizes risk by its potential source.
- Checklists–this is using lists of potential risks that were developed based on previous similar projects. Of course, even if a previous project was similar, care must be taken to account for the differences by going over all risks on the checklist to make sure they actually apply in the current project.
- Interviews–conversations with stakeholders and subject matter experts in the field of risk management can be used to get contributions to the list of potential risks on the project.
Data Analysis
- Root cause analysis–just as root cause analysis can be used to discover the underlying causes that lead to an actual problem (a defect), it can also be used to identify the causes of a potential problem. You start with the potential problem, such as cost overruns and schedule delays, and go back to find out those factors which might lead to this problem.
- Assumption and constraint analysis–a project is conceived with a set of assumptions and within a series of constraints (schedule, cost, quality, scope, etc.).
- SWOT analysis–if you take positive and negative factors both internal to and external to the project organization, you will get the strengths/weaknesses (internal), and opportunities/threats (external) to the project, which is wear the acronym SWOT comes from.
- Document analysis–project documents, particularly the project charter, are analyzed to get high-level risks on the current project, and project files from previous similar projects are also analyzed to get the individual risks from those projects.
Interpersonal and Team Skills
- Especially when using the data gathering technique of brainstorming, it requires special skills to be a facilitator of one those sessions because you have to encourage an open mode of discussion where ideas will not be shot down when given by any member of the discussion group, thus encouraging creativity in the process.
Prompt Lists
- This is a predetermined list of risk categories. A checklist is a list of actual risks from previous projects; the prompt list just gives the risk categories, and is a useful tool to be used in conjunction with the brainstorming technique mentioned
Meetings
- Like putting together the WBS, putting together a list of potential risks requires brainstorming which is best done in the setting of a group meeting.
process - outputs
Identify Risks: Outputs
Risk Register
- This document is similar to the stakeholder register in that it is created in one process, but is elaborated on during other processes throughout the course of the project.
- The risk register captures identified individual project risks. These risks after being identified will need to be identified, analyzed both quantitatively and qualitatively, and then risk responses will have to be developed for them in later processes.
- In this first process, the risks need to be identified, but if any information on risk owners (risk responses is available, it can be added at this point to be confirmed in later processes.
- Risk owners are those who have responsibility for monitoring and controlling those particular risks to which they are assigned, and implementing a risk response if the risk is triggered.
- Here are the elements the risk register should include:
- List of identified risks–it should be given a unique identifier in the risk register, and it should be described in detail, including their cause and their potential effect on the project.
- Potential risk owners–if a potential risk owner can be identified at this point, the risk owner is recorded in the risk register. This is confirmed in process 11.3 Perform Qualitative Risk Analysis.
- Potential risk response–if a potential risk response can be identified at this point, the risk response is recorded in the risk register.
Risk Report
- This is a new output for this process in the 6th Edition PMBOK® Guide. As the various risk processes are completed, the results are included in the risk report. The important results for this process that need to be concluded are:
- Sources of overall project risk, which may be obtained from the project charter.
- Summary information on individual project risks listed in the risk register,
Project Documents Updates
- Assumption log–if in identifying risks, any new assumptions are made, or new constraints are identified, the assumption log should be updated with this new information.
- Issue log–any new issues uncovered during this process of identifying risks should be added to the issue log.
- Lessons learned register–any techniques that were effective in identifying risks should be added to the lessons learned register in order to improve performance in later phases of the project.
