Identifying risk
| Line 10: | Line 10: | ||
= Big idea = | = Big idea = | ||
| − | + | Identifying risk is a never-ending job for a project and should be treated as such. By not only identifying risk at the beginning of the project, but throughout the project’s life cycle. | |
| + | When identifying risks, we seek to identify both individual projects risks and sources of overall project risk. With this process we should in up with some documentation of the risks. To be more specific, the output we achieve is a risk register and a risk report, as well as an opportunity to update exiting document to reflect new knowledge found. | ||
| + | |||
| + | All stakeholders should be encouraged to bring any risk they see to light. However, for the specific process of identifying risks the persons or groups that usually participants in this process are: | ||
| + | |||
| + | - Project manager | ||
| + | |||
| + | - Project team | ||
| + | |||
| + | - Risk specialist | ||
| + | |||
| + | - Customers and end users | ||
| + | |||
| + | - External subject experts | ||
| + | |||
| + | - Relevant stakeholders | ||
| + | |||
| + | - Internal risk management expert | ||
| + | |||
= Input = | = Input = | ||
| Line 35: | Line 53: | ||
• Requirements management plan | • Requirements management plan | ||
| + | |||
• Schedule management plan | • Schedule management plan | ||
| + | |||
• Cost management plan | • Cost management plan | ||
| + | |||
• Quality Management plan | • Quality Management plan | ||
| + | |||
• Resource management plan | • Resource management plan | ||
| + | |||
• Risk management plan | • Risk management plan | ||
| + | |||
• Scope baseline | • Scope baseline | ||
| + | |||
• Schedule baseline | • Schedule baseline | ||
| + | |||
• Cost baseline | • Cost baseline | ||
| Line 51: | Line 77: | ||
• Assumption log | • Assumption log | ||
| + | |||
• Cost estimates | • Cost estimates | ||
| + | |||
• Duration estimates | • Duration estimates | ||
| + | |||
• Issue log | • Issue log | ||
| + | |||
• Lessons learned register | • Lessons learned register | ||
| + | |||
• Requirements documentation. | • Requirements documentation. | ||
| + | |||
• Resource requirements | • Resource requirements | ||
| + | |||
• Stakeholder register | • Stakeholder register | ||
| Line 66: | Line 99: | ||
Procuring goods and services from external sources may increase or decrease the risks for the project, as well as introduce new risks. The most up to date procurement documentation should be reviewed for potential risks. | Procuring goods and services from external sources may increase or decrease the risks for the project, as well as introduce new risks. The most up to date procurement documentation should be reviewed for potential risks. | ||
| − | |||
| − | |||
| − | |||
| − | |||
= Tools = | = Tools = | ||
| Line 76: | Line 105: | ||
Examples of such tools are: | Examples of such tools are: | ||
| + | |||
• Expert judgment | • Expert judgment | ||
| + | |||
• Data gathering | • Data gathering | ||
| + | |||
o Brainstorming | o Brainstorming | ||
| + | |||
o Checklists | o Checklists | ||
| + | |||
o Interviews | o Interviews | ||
| + | |||
• Data analysis | • Data analysis | ||
| + | |||
o Root cause analysis | o Root cause analysis | ||
| + | |||
o Assumption and constraint analysis | o Assumption and constraint analysis | ||
| + | |||
o SWOT analysis | o SWOT analysis | ||
| + | |||
o Document analysis | o Document analysis | ||
| + | |||
• Interpersonal and team skills | • Interpersonal and team skills | ||
| + | |||
• Prompt lists | • Prompt lists | ||
| + | |||
• Meetings | • Meetings | ||
| − | == Expert judgement == | + | === Expert judgement === |
The project manager should identify individuals or groups that could act as expert on projects risk and the source of these risks. The expert should both consider specific risk and overall project risks. | The project manager should identify individuals or groups that could act as expert on projects risk and the source of these risks. The expert should both consider specific risk and overall project risks. | ||
| Line 96: | Line 138: | ||
The experts can be people with experience in a specific area relevant to the project. Or they could be people with some form of specialized knowledge that relate to the project. | The experts can be people with experience in a specific area relevant to the project. Or they could be people with some form of specialized knowledge that relate to the project. | ||
| − | == Data gathering == | + | === Data gathering === |
There are multiple techniques to gather data related to risk. Here there are highlighted some, which are widely used | There are multiple techniques to gather data related to risk. Here there are highlighted some, which are widely used | ||
| − | === Brainstorming === | + | ==== Brainstorming ==== |
In a brainstorm the goal is generate an overview of potential risk for the project. The brainstorm is carried out by the project team. However, have experts been gathered they should also participate in the brainstorm. | In a brainstorm the goal is generate an overview of potential risk for the project. The brainstorm is carried out by the project team. However, have experts been gathered they should also participate in the brainstorm. | ||
| Line 106: | Line 148: | ||
In a brainstorm there is a risk that the ideas generated are not described in full. This is something that the facilitator should have in mind, so that all risk is fully described and usable. | In a brainstorm there is a risk that the ideas generated are not described in full. This is something that the facilitator should have in mind, so that all risk is fully described and usable. | ||
| − | === Checklist === | + | ==== Checklist ==== |
Information and knowledge gather from similar projects, experience and other sources can be compiled into a checklist of risk. The checklist is a list of potential risk which have been seen before. This list can then be updated throughout the project. | Information and knowledge gather from similar projects, experience and other sources can be compiled into a checklist of risk. The checklist is a list of potential risk which have been seen before. This list can then be updated throughout the project. | ||
| Line 112: | Line 154: | ||
However, this should not be seen as a reason to not carrier out a risk identification. Other risk should also be explored. | However, this should not be seen as a reason to not carrier out a risk identification. Other risk should also be explored. | ||
| − | === Interviews === | + | ==== Interviews ==== |
Interview is another method of identifying project risks. The interviews can be carried out with any person or group that have relevant for the project (project participants, stakeholders, experts, ect.). | Interview is another method of identifying project risks. The interviews can be carried out with any person or group that have relevant for the project (project participants, stakeholders, experts, ect.). | ||
The danger with interviews is that the participant withholds information out fear, shame, or what have you. Therefore, it is essential for the interviews that they are carried out in trusting and open environment to ensure the right information is extracted. | The danger with interviews is that the participant withholds information out fear, shame, or what have you. Therefore, it is essential for the interviews that they are carried out in trusting and open environment to ensure the right information is extracted. | ||
| − | + | ||
=== Root cause analysis === | === Root cause analysis === | ||
| Line 141: | Line 183: | ||
The output from identifying risk is three folded: the risk register, the risk report, and updates of project documents. | The output from identifying risk is three folded: the risk register, the risk report, and updates of project documents. | ||
| − | == Risk register == | + | === Risk register === |
The risk register is, as the name may suggest, where all individual risk are registered. This includes a list of all risk fund in the identification process. All risk are registered with unique name, number, or similar, as well as a description of the risk so that the information don’t get lost. | The risk register is, as the name may suggest, where all individual risk are registered. This includes a list of all risk fund in the identification process. All risk are registered with unique name, number, or similar, as well as a description of the risk so that the information don’t get lost. | ||
| Line 150: | Line 192: | ||
As risk identification and risk management is an ongoing process throughout the project, the register should be kept up to date. Any results from other risk processes should also be recorded in the register. | As risk identification and risk management is an ongoing process throughout the project, the register should be kept up to date. Any results from other risk processes should also be recorded in the register. | ||
| − | == Risk report == | + | === Risk report === |
The risk report includes the sources of overall project risk, as well as a summary of individual project risks. | The risk report includes the sources of overall project risk, as well as a summary of individual project risks. | ||
| − | == Project documents updates == | + | === Project documents updates === |
It is important that in the end of the process of identifying risk, all relevant existing documents are updated. This could include documents such as: Assumption log, Issue log, and lessons learned register. | It is important that in the end of the process of identifying risk, all relevant existing documents are updated. This could include documents such as: Assumption log, Issue log, and lessons learned register. | ||
Revision as of 18:28, 28 February 2021
The process of identifying risk in project management can be summarised as both identifying individual risk for the project and sources of overall risk to the project. Thereafter documenting their characteristics. When the risk has been identified, this allows the project team to tackle the challenges arising with these risks. Identifying risks is a process that is performed throughout the project’s lifetime. When identifying risk, the step that you go through is create input, applying tools and techniques, and finally getting output. Creating input is essential for management to identifying the risk. Examples of what the input consist of: project management plan, project documents (Assumption log, cost estimates, issue log, etc), enterprise environmental factors, and much more. After creating input, certain tools can be used to identifying the risks. An in-depth look into them will come later, but some of them are: Expert judgement, data gathering, data analysis. The last part is the output. The output is 3 folded; 1. Risk register. 2. Risk report. 3. Project documents updates.
The 3 parts of identifying risks (input, tools & output) will be descried in greater details.
Contents |
Big idea
Identifying risk is a never-ending job for a project and should be treated as such. By not only identifying risk at the beginning of the project, but throughout the project’s life cycle. When identifying risks, we seek to identify both individual projects risks and sources of overall project risk. With this process we should in up with some documentation of the risks. To be more specific, the output we achieve is a risk register and a risk report, as well as an opportunity to update exiting document to reflect new knowledge found.
All stakeholders should be encouraged to bring any risk they see to light. However, for the specific process of identifying risks the persons or groups that usually participants in this process are:
- Project manager
- Project team
- Risk specialist
- Customers and end users
- External subject experts
- Relevant stakeholders
- Internal risk management expert
Input
When talking input for risk identification we are talking about all documents and knowledge developed beforehand, that enables us to identify risk. These are output from task/process carried out prior to the risk identification, which lay the groundwork to the actual risk identification.
Some examples of input needed are:
• Project management plan
• Project Documents
• Agreements
• Procurement documentation
• Enterprise environmental factors
• Organisational process assets
Project management plan
The project management plan include knowledge from underlining components. These components include:
• Requirements management plan
• Schedule management plan
• Cost management plan
• Quality Management plan
• Resource management plan
• Risk management plan
• Scope baseline
• Schedule baseline
• Cost baseline
Other relevant Management plans, Baselines, or relevant documents can be included in the project management plan.
Project Documents
Some project documents can be included as input in the risk identification. Examples of these are:
• Assumption log
• Cost estimates
• Duration estimates
• Issue log
• Lessons learned register
• Requirements documentation.
• Resource requirements
• Stakeholder register
Agreements
There might be some agreement/contract with some external partner/stakeholder. The information in such an agreement may present both risk and opportunities for the project. Information in the agreement may include, but are not limited to, milestones dates, acceptance criteria, awards and penalties.
Procurement documentation
Procuring goods and services from external sources may increase or decrease the risks for the project, as well as introduce new risks. The most up to date procurement documentation should be reviewed for potential risks.
Tools
From the input generated and gathered, the management team have a variety of tools in the toolbox, that will help them identify the risks.
Examples of such tools are:
• Expert judgment
• Data gathering
o Brainstorming
o Checklists
o Interviews
• Data analysis
o Root cause analysis
o Assumption and constraint analysis
o SWOT analysis
o Document analysis
• Interpersonal and team skills
• Prompt lists
• Meetings
Expert judgement
The project manager should identify individuals or groups that could act as expert on projects risk and the source of these risks. The expert should both consider specific risk and overall project risks.
The experts can be people with experience in a specific area relevant to the project. Or they could be people with some form of specialized knowledge that relate to the project.
Data gathering
There are multiple techniques to gather data related to risk. Here there are highlighted some, which are widely used
Brainstorming
In a brainstorm the goal is generate an overview of potential risk for the project. The brainstorm is carried out by the project team. However, have experts been gathered they should also participate in the brainstorm.
In a brainstorm there is a risk that the ideas generated are not described in full. This is something that the facilitator should have in mind, so that all risk is fully described and usable.
Checklist
Information and knowledge gather from similar projects, experience and other sources can be compiled into a checklist of risk. The checklist is a list of potential risk which have been seen before. This list can then be updated throughout the project. The checklist is a good way for a company to transfer knowledge and learnings from project to project. However, this should not be seen as a reason to not carrier out a risk identification. Other risk should also be explored.
Interviews
Interview is another method of identifying project risks. The interviews can be carried out with any person or group that have relevant for the project (project participants, stakeholders, experts, ect.). The danger with interviews is that the participant withholds information out fear, shame, or what have you. Therefore, it is essential for the interviews that they are carried out in trusting and open environment to ensure the right information is extracted.
Root cause analysis
The root cause analysis is a method used to identify the “why” of a risk, i.e. the underlying reason for the risk. When solving the root cause of a risk all risk underlining risk will also be solved. By stating a problem/benefit statement a root cause analysis can be used to detect threats or opportunities.
Assumption and constraint analysis
This is an analysis of the projects and project management plans underlining assumption and constraint. The assumptions, which the project has made, represent some unidentified risks. Analysing these assumptions will bring risk to light and assess their threat. The constraint that the project works under could potentially bring some opportunities to light. Analysing the constraint to see if any could be removed, or relaxed.
SWOT analysis
SWOT is an analysis of the project and organizations strengths, weaknesses, opportunities and treats. *** another source needed
Document analysis
- Maybe.
Output
The output from identifying risk is three folded: the risk register, the risk report, and updates of project documents.
Risk register
The risk register is, as the name may suggest, where all individual risk are registered. This includes a list of all risk fund in the identification process. All risk are registered with unique name, number, or similar, as well as a description of the risk so that the information don’t get lost. If there have been identified an owner of the risk, this person should also be registered. The same goes for potential risk responses. Have any responses been identified during the process of identifying the risk they should also be registered.
Any additional information that is relevant for the risk, and the handling of set risk, should also be registered. This could include information such as risk triggers, deadline for action, current risk status, and so on.
As risk identification and risk management is an ongoing process throughout the project, the register should be kept up to date. Any results from other risk processes should also be recorded in the register.
Risk report
The risk report includes the sources of overall project risk, as well as a summary of individual project risks.
Project documents updates
It is important that in the end of the process of identifying risk, all relevant existing documents are updated. This could include documents such as: Assumption log, Issue log, and lessons learned register.
Limitations
Annotated bibliography
Key references: • Project Management: A guide to the Project Management Body of Knowledge (PMBOK guide), 6th Edition (2017)
