Risk Management-Identification
| (41 intermediate revisions by one user not shown) | |||
| Line 2: | Line 2: | ||
| − | + | ||
| + | The term ''risk identification'' refers to the investigation of objectives for opportunities and threats. The process is necessary for all projects, programmes and portfolios that strive to achieve a set of objectives with success. International standards made by Project Management Institute (PMI), PRojects IN Controlled Environments (PRINCE2) and the International Organization for Standardization (ISO) addresses tools and techniques in order to perform successful risk identification. The process might be thought of as simply listing the risks a team could think of. However, risk identification is more comprehensive than risk listing. Adopting a variety of identification techniques such as brainstorming, risk checklists and risk breakdown structure are necessary actions in order to output a thorough risk register, risk report and perform revision of project documents. Some key success factors for risk identification, amongst others, are the implementation of effective and clear communication, early and comprehensive identifications, inclusion of risks both as threats and opportunities and their impact as an individual or overall risk. Risk identification for projects, programmes or portfolios must be treated as an iterative process which needs to be managed according to their complexity and level of impact. | ||
| + | .<ref name="PMIStandard"/><ref name="P2"/><ref name="ISO"/> | ||
== Why identify risks? == | == Why identify risks? == | ||
| − | A risk is defined as the uncertainty of an event, that if occurs, impacts the event either in a positive or negative manner | + | A risk is defined as the uncertainty of an event, that if occurs, impacts the event either in a positive or negative manner (PMIStandard). When managing projects, programmes or portfolios, it is vital to identify and manage risks in order to prevent negative -, and benefit from positive, outcomes. The project, programme or portfolio manager should always make sure that risk identification and further risk management is carried out, but the ownership and responsibility of risks is distributed to relevant individuals, teams or departments. Risk management is a common practice and lies within the planning stage of project management. According to the “Standard for Risk Management in Portfolios, Programs, and Projects” published by the Project Management Institute (PMI)PMIStandard, identifying risks is the second out of seven stages within the risk management life cycle. Hence, identifying risks is one of the early stages of risk management and a necessity in order to pursue further risk management actions and prevent a negative impact on the projects’ success.<ref name="PMIStandard"/> |
== Context and Application == | == Context and Application == | ||
Risk identification is applied for projects, programmes and portfolios, whilst the techniques might vary due to complexity and size. As a part of the risk management life cycle, it is an important stage within the planning phase of risk management but is dependent on the following active steps in order to be put to practice and cause risk prevention. For a manager of either a project, programme or portfolio, risk identification is a practice that, if omitted, might lead to project failure.<ref name="PMIStandard"/><ref name="P2"/><ref name="ISO"/> | Risk identification is applied for projects, programmes and portfolios, whilst the techniques might vary due to complexity and size. As a part of the risk management life cycle, it is an important stage within the planning phase of risk management but is dependent on the following active steps in order to be put to practice and cause risk prevention. For a manager of either a project, programme or portfolio, risk identification is a practice that, if omitted, might lead to project failure.<ref name="PMIStandard"/><ref name="P2"/><ref name="ISO"/> | ||
| − | [[File: | + | |
| − | In 2019, PMI published the international standard “Standard for Risk Management in Portfolios, Programs, and Projects” PMIStandard. The standard is put to practice worldwide and is a tool for project, programme or portfolio managers to achieve success. PMI divides risks into two categories; individual risks that effect one or more objectives and overall risks as the uncertainty of the whole project, programme or portfolio that arises as a collection of all sources of uncertainty. Both individual and overall risks are important to identify within the identification process. Additionally, they address the risks with positive outcomes as opportunities and risks with negative outcomes as threats. The separate terms are applied to distinguish the possible outcomes and effects of risks within projects, programmes or portfolios. Other terms used to distinguish and characterise risks are conditional risks that will occur as an effect of another risk occurring. The term correlated risks is used for risks that vary accordingly due to a fixed correlation. Independent and dependent risks are also two terms addressed when stating the dependencies of two risks to one another. The wide termination of risks serves as a purpose to initiate structure and to differentiate them from one another.<ref name="PMIStandard"/><ref name="RiskEng"/> | + | [[File:Red.png|right|thumb|300px|Figure 1: Illustrates that identifying risks is a part of the risk management life cycle.Modified from<ref name="PMIStandard"/>.<ref name="Red"/>]] |
| − | In addition to PMI, ISO and PRINCE2 are two practiced standards that differ slightly from the methodology given by PMI. In terms of risk identification, PMI is the only standard that addresses the life cycle term, whilst ISO and Prince2 lists identification as either the first or second step within the procedure of risk management | + | In 2019, PMI published the international standard “Standard for Risk Management in Portfolios, Programs, and Projects” PMIStandard. The standard is put to practice worldwide and is a tool for project, programme or portfolio managers to achieve success. PMI divides risks into two categories; ''individual risks'' that effect one or more objectives and ''overall risks'' as the uncertainty of the whole project, programme or portfolio that arises as a collection of all sources of uncertainty. Both individual and overall risks are important to identify within the identification process. Additionally, they address the risks with positive outcomes as ''opportunities'' and risks with negative outcomes as ''threats''. The separate terms are applied to distinguish the possible outcomes and effects of risks within projects, programmes or portfolios. Other terms used to distinguish and characterise risks are ''conditional risks'' that will occur as an effect of another risk occurring. The term ''correlated risks'' is used for risks that vary accordingly due to a fixed correlation. ''Independent and dependent risks'' are also two terms addressed when stating the dependencies of two risks to one another. The wide termination of risks serves as a purpose to initiate structure and to differentiate them from one another.<ref name="PMIStandard"/><ref name="RiskEng"/> |
| + | In addition to PMI, ISO and PRINCE2 are two practiced standards that differ slightly from the methodology given by PMI. In terms of risk identification, PMI is the only standard that addresses the life cycle term, whilst ISO and Prince2 lists identification as either the first or second step within the procedure of risk management. However, all sources addresses the importance of risk management as a continuous procedure, as risks are not only to be identified at the beginning of a project, but is a continuous process from the projects’, programmes’, or portfolios’ initiation to completion. Hence, the methodology given by PMI, addressing risk identification as a step within a "life cycle", amplifies the importance of the practice throughout the whole project. The risk management life cycle is illustrated in Figure 1<ref name="Red"/>. <ref name="PMIStandard"/><ref name="P2"/><ref name="ISO"/> | ||
== Inputs == | == Inputs == | ||
| Line 25: | Line 28: | ||
==== Risk Checklists ==== | ==== Risk Checklists ==== | ||
Based on historical projects, programmes or portfolios with a comparable background, one can establish a risk checklist. The purpose of this checklist is to present individual risks that have occurred before and that might occur during the lifetime of the project, programme or portfolio. In order to use a checklist as a risk identification tool it is vital that the checklist is updated and covers risks from a variety of professions. | Based on historical projects, programmes or portfolios with a comparable background, one can establish a risk checklist. The purpose of this checklist is to present individual risks that have occurred before and that might occur during the lifetime of the project, programme or portfolio. In order to use a checklist as a risk identification tool it is vital that the checklist is updated and covers risks from a variety of professions. | ||
| − | As checklists might omit relevant risks that are not addressed as a historical risk, it is necessary to combine the technique with other risk identification techniques to identify all relevant risks. <ref name="PMIStandard"/><ref name=" | + | As checklists might omit relevant risks that are not addressed as a historical risk, it is necessary to combine the technique with other risk identification techniques to identify all relevant risks. <ref name="PMIStandard"/><ref name="P2"/><ref name="PMIGuide"/> |
==== Risk Breakdown Structure (RBS)==== | ==== Risk Breakdown Structure (RBS)==== | ||
| − | [[File: | + | [[File:PS.jpg|right|thumb|400px|Figure 2: Shows the risk breakdown structure for the PESTLE model. Modified from <ref name="P2"/>.<ref name="Pestle1"/>]]A risk breakdown structure (RBS) is a hierarchical decomposition of potential sources of risk<ref name="P2"/> . The structure aims to divide the risks into specific domains with enhanced detail and further subdivisions. The purpose of RBS is to make a detailed overview for the manager of the project, programme or portfolio of the different sections that the risks correspond to. There are several ways to organise the risk breakdown structure and each risk may be broken down differently according to complexity and size. In PRINCE2, the PESTLE (Political, Economic, Social, Technical, Legislative, Environmental) division is described as one of many generic subdivisions that can be implemented for a wide range of projects, programmes or portfolios. In addition to PESTLE, the guidebook for PMI addresses TECOP (technical, environmental, commercial, operational, political), and VUCA (volatility, uncertainty, complexity, ambiguity) as two other relevant generic structures suitable for RBS. <ref name="PMIGuide"/> |
| − | Figure 2 is a graphical representation of the template model and should be modified into further specific and relevant subdivisions when put to practice. | + | Figure 2 is a graphical representation of the PESTLE template model and should be modified into further specific and relevant subdivisions when put to practice. |
| − | + | ||
| − | An additional general RBS is | + | An additional general RBS is depicted in Figure 3<ref name="RBS14"/>. The figure is modified for the purpose of this article and illustrates a universal and general decomposition made by the Risk Management Specific Interest Group of the Project Management Institute (PMI Risk SIG) and the Risk Management Working Group of the International Council On Systems Engineering (INCOSE RMWG). The model breaks down the different risks associated to the categories: technology, management and external.<ref name="P2"/><ref name="PMIGuide"/><ref name="RBS"/> |
| + | [[File:RBS14.jpg|center|thumb|800px|Figure 3: Shows a generic risk breakdown structure based on PMI Risk SIG and INCOSE RMWG. Modified from <ref name="PMIGuide"/><ref name="RBS"/> ]] | ||
| + | |||
==== Interviews ==== | ==== Interviews ==== | ||
| − | For projects, programmes or portfolios with a strong connection or correlation to a historical and similar event one might strongly consider interviewing stakeholders, project managers, project participants or other persons in expertise. The aim of the interview should be to identify possible risks that they have experienced or new risks that they feel are relevant. In order for the interviews to be used as an identification technique it is vital that they are documented and support confidentiality contracts. <ref name="PMIGuide"/> | + | For projects, programmes or portfolios with a strong connection or correlation to a historical and similar event, one might strongly consider interviewing stakeholders, project managers, project participants or other persons in expertise. The aim of the interview should be to identify possible risks that they have experienced or new risks that they feel are relevant. In order for the interviews to be used as an identification technique it is vital that they are documented and support confidentiality contracts. <ref name="PMIGuide"/> |
==== Additional analytical tools ==== | ==== Additional analytical tools ==== | ||
| Line 55: | Line 60: | ||
==== Risk register ==== | ==== Risk register ==== | ||
| − | The aim of identifying risks is to gather them in a risk register that can actively be used by all active participants of the project, programme or portfolio. The risk register includes a thorough list of all risks identified with detailed information of their potential cause and effect. A specific risk owner may be addressed in order to specify the person or team responsible for monitoring and managing the risk. Possible responses to the risks should be included for | + | The aim of identifying risks is to gather them in a risk register that can actively be used by all active participants of the project, programme or portfolio. The risk register includes a thorough list of all risks identified with detailed information of their potential cause and effect. A specific risk owner may be addressed in order to specify the person or team responsible for monitoring and managing the risk. Possible responses to the risks should be included for those of predictable outcome. The complexity of the risk register and the length of each risk description will differ from the context of the project, programme or portfolio.<ref name="PMIGuide"/> |
==== Risk report ==== | ==== Risk report ==== | ||
| − | In addition to the risk register, a risk report can be composed in order to address the overall risk of a specific project, programme or portfolio. The risk report includes summaries of all individual risks and to which extent they impose a threat or opportunity to the project, programme or portfolio as a whole. Tools such as metrics, trends, or risk rating systems may be implied in order to inform the project manager and all relevant parties of historical data, statistics and degree of threat that the identified risks can cause. <ref name="PMIGuide"/> | + | In addition to the risk register, a risk report can be composed in order to address the overall risk of a specific project, programme or portfolio. The risk report includes summaries of all individual risks and to which extent they impose a threat or opportunity to the project, programme or portfolio as a whole. Tools such as metrics, trends, or risk rating systems may be implied in order to inform the project manager and all relevant parties of historical data, statistics and degree of threat that the identified risks can cause. <ref name="PMIGuide"/> |
==== Revision of project documents ==== | ==== Revision of project documents ==== | ||
| − | Lastly, the outcome of the identification process might have affected the initial assumptions and must therefore be re- assessed. This is an important process in order to include new aspects and concerns from the risk identification stage. For future projects it can also be relevant to compose a register of the tools and techniques used in the specific project, programme or portfolio in order to document what methods that were beneficial to use and which methods that didn’t serve a significant purpose during the risk identification process.<ref name="PMIGuide"/> | + | Lastly, the outcome of the identification process might have affected the initial assumptions and must therefore be re- assessed. This is an important process in order to include new aspects and concerns from the risk identification stage. For future projects it can also be relevant to compose a register of the tools and techniques used in the specific project, programme or portfolio in order to document what methods that were beneficial to use and which methods that didn’t serve a significant purpose during the risk identification process.<ref name="PMIGuide"/> |
== Key success factors for identifying risks == | == Key success factors for identifying risks == | ||
| Line 78: | Line 83: | ||
== Limitations of the current identification standards == | == Limitations of the current identification standards == | ||
| − | + | *The standards connected to risk identification lacks the connection to specific objectives as they are merely general approaches. The given approach might not be the most effective risk identification technique and it is therefore vital to use the standards but support them with historical projects with similar objectives. Additionally, there is no indicator as to how long time one should spend on risk identification. It is crucial to decide upon a reasonable timeframe for identifying risks as too much focus could end in slower project, programme or portfolio process and hinder success. <ref name="PMIStandard"/><ref name="P2"/><ref name="ISO"/> | |
| − | + | ||
| − | + | *The «Committee for Oversight and Assessment of U.S. Department of Energy Project Management» addresses the importance of project management personnel training in the book ''The Owner’s Role in Project Risk''. A limitation with the given methods is that the importance of analytical and management skills amongst the risk owners and risk managers is missing. An incompetent manager with a limited view of the objectives will not be able to identify risks unless assisted with a team of greater knowledge. <ref name="nat"/> | |
| − | *The | + | |
| − | *The experts’ bias should be taken into account during risk identification. If the outcome of the project, programme or portfolio will benefit | + | *The experts’, stakeholders’ or other influential parties’ bias should be taken into account during risk identification. If the outcome of the project, programme or portfolio will benefit them in a certain way then it is vital to be sceptical as to which extent they are trustworthy. Including a third part or a similar project team can help to prevent expert bias. It is the project owners who should ensure that identified risks are unbiased by using a team of people who are familiar with the methods required to reduce any possible bias. <ref name="nat"/> |
| + | |||
== Annotated bibliography == | == Annotated bibliography == | ||
| − | '''Project Management | + | '''National Research Council. 2005. The Owner's Role in Project Risk Management. Washington, DC: The National Academies Press''' |
| − | * | + | *The report is an outcome of the Committee of the Conference on Energy and Water Development of the 105th US Congress in 1997. Here, a review and assessment of the progress made in project management principles was conducted by the National Research Council (NRC) with request from the Department of Energy (DOE). The literature from chapter 4 “Risk Identification and Analysis” covers risk identification techniques and is used as an additional literature to the international standards. |
| − | |||
| − | |||
'''Munier, Nolberto (2014) , Risk Identification. In: Risk Management for Engineering Projects''' | '''Munier, Nolberto (2014) , Risk Identification. In: Risk Management for Engineering Projects''' | ||
| Line 99: | Line 103: | ||
== References == | == References == | ||
<references> | <references> | ||
| − | <ref name="PMIGuide">Project Management Institute, Inc.(PMI) (2017), Guide to the Project Management Body of Knowledge (PMBOK® Guide) (6th Edition) </ref> | + | <ref name="PMIGuide">Project Management Institute, Inc.(PMI) (2017), Guide to the Project Management Body of Knowledge (PMBOK® Guide) (6th Edition)</ref> |
<ref name="PMIStandard"> Project Management Institute, Inc.(PMI) (2019), Standard for Risk Management in Portfolios, Programs, and Projects</ref> | <ref name="PMIStandard"> Project Management Institute, Inc.(PMI) (2019), Standard for Risk Management in Portfolios, Programs, and Projects</ref> | ||
| Line 110: | Line 114: | ||
<ref name="RBS">Hillson, David (2003), Using a Risk Breakdown Structure in project management</ref> | <ref name="RBS">Hillson, David (2003), Using a Risk Breakdown Structure in project management</ref> | ||
| + | <ref name="nat"> National Research Council. 2005. The Owner's Role in Project Risk Management."4 Risk Identification and Analysis." Washington, DC: The National Academies Press. doi: 10.17226/11183.</ref> | ||
<ref name="Brainstorm">Eleazar, Hernández (2017), Brainstorming p.57-58. In: Leading Creative Teams Management Career Paths for Deigners, Developers, and Copywriters, APress</ref> | <ref name="Brainstorm">Eleazar, Hernández (2017), Brainstorming p.57-58. In: Leading Creative Teams Management Career Paths for Deigners, Developers, and Copywriters, APress</ref> | ||
| − | <ref name=" | + | <ref name="Red"> Inspired by: Project Management Institute, Inc. (PMI) (2019), Standard for Risk Management in Portfolios, Programs, and Projects</ref> |
| − | <ref name=" | + | <ref name="RBS14"> Inspired by: Hillson, David (2003), Using a Risk Breakdown Structure in project management</ref> |
<ref name="Pestle1"> Inspired by: AXELOS (2017), Managing Successful Projects with PRINCE2 2017 Edition</ref> | <ref name="Pestle1"> Inspired by: AXELOS (2017), Managing Successful Projects with PRINCE2 2017 Edition</ref> | ||
Latest revision as of 22:29, 28 February 2021
Developed by Maria Eileen Hubbuck (s210444)
The term risk identification refers to the investigation of objectives for opportunities and threats. The process is necessary for all projects, programmes and portfolios that strive to achieve a set of objectives with success. International standards made by Project Management Institute (PMI), PRojects IN Controlled Environments (PRINCE2) and the International Organization for Standardization (ISO) addresses tools and techniques in order to perform successful risk identification. The process might be thought of as simply listing the risks a team could think of. However, risk identification is more comprehensive than risk listing. Adopting a variety of identification techniques such as brainstorming, risk checklists and risk breakdown structure are necessary actions in order to output a thorough risk register, risk report and perform revision of project documents. Some key success factors for risk identification, amongst others, are the implementation of effective and clear communication, early and comprehensive identifications, inclusion of risks both as threats and opportunities and their impact as an individual or overall risk. Risk identification for projects, programmes or portfolios must be treated as an iterative process which needs to be managed according to their complexity and level of impact. .[1][2][3]
Contents |
[edit] Why identify risks?
A risk is defined as the uncertainty of an event, that if occurs, impacts the event either in a positive or negative manner (PMIStandard). When managing projects, programmes or portfolios, it is vital to identify and manage risks in order to prevent negative -, and benefit from positive, outcomes. The project, programme or portfolio manager should always make sure that risk identification and further risk management is carried out, but the ownership and responsibility of risks is distributed to relevant individuals, teams or departments. Risk management is a common practice and lies within the planning stage of project management. According to the “Standard for Risk Management in Portfolios, Programs, and Projects” published by the Project Management Institute (PMI)PMIStandard, identifying risks is the second out of seven stages within the risk management life cycle. Hence, identifying risks is one of the early stages of risk management and a necessity in order to pursue further risk management actions and prevent a negative impact on the projects’ success.[1]
[edit] Context and Application
Risk identification is applied for projects, programmes and portfolios, whilst the techniques might vary due to complexity and size. As a part of the risk management life cycle, it is an important stage within the planning phase of risk management but is dependent on the following active steps in order to be put to practice and cause risk prevention. For a manager of either a project, programme or portfolio, risk identification is a practice that, if omitted, might lead to project failure.[1][2][3]
In 2019, PMI published the international standard “Standard for Risk Management in Portfolios, Programs, and Projects” PMIStandard. The standard is put to practice worldwide and is a tool for project, programme or portfolio managers to achieve success. PMI divides risks into two categories; individual risks that effect one or more objectives and overall risks as the uncertainty of the whole project, programme or portfolio that arises as a collection of all sources of uncertainty. Both individual and overall risks are important to identify within the identification process. Additionally, they address the risks with positive outcomes as opportunities and risks with negative outcomes as threats. The separate terms are applied to distinguish the possible outcomes and effects of risks within projects, programmes or portfolios. Other terms used to distinguish and characterise risks are conditional risks that will occur as an effect of another risk occurring. The term correlated risks is used for risks that vary accordingly due to a fixed correlation. Independent and dependent risks are also two terms addressed when stating the dependencies of two risks to one another. The wide termination of risks serves as a purpose to initiate structure and to differentiate them from one another.[1][5] In addition to PMI, ISO and PRINCE2 are two practiced standards that differ slightly from the methodology given by PMI. In terms of risk identification, PMI is the only standard that addresses the life cycle term, whilst ISO and Prince2 lists identification as either the first or second step within the procedure of risk management. However, all sources addresses the importance of risk management as a continuous procedure, as risks are not only to be identified at the beginning of a project, but is a continuous process from the projects’, programmes’, or portfolios’ initiation to completion. Hence, the methodology given by PMI, addressing risk identification as a step within a "life cycle", amplifies the importance of the practice throughout the whole project. The risk management life cycle is illustrated in Figure 1[4]. [1][2][3]
[edit] Inputs
In order to carry out the identification process, it is vital to have information about the projects’ scope in the form of a project management plan, project documents, agreements, procurement documentation, enterprise environmental factors and organisational process assets. Together they form the inputs of the identification process. Therefore, it is of great importance to have established communication with managers, stakeholders, senior management, potential customers and all other active participants in the project, programme or portfolio in order to include all possible perspectives on risk identification. [3][6]
[edit] Techniques for risk identification
There is no specific technique that is strictly related to risk identification. However, all the addressed international standards list a selection of several techniques that can contribute to a thorough risk identification. The aim is to document the predictable risks and recognise that there might arise risks that are unpredictable from the current risk identification stage.
[edit] Brainstorming
The term brainstorming was first introduced in the book How to “Think Up” by Alex Faickney Osborn in 1942 as a unique technique incorporated by the advertisement agency BBDO. However, the term was not populated before Osborn published the book “Applied Imagination: Principles and Procedures of Creative Problem Solving” in 1953[7][5]. The principles of brainstorming might have been associated differently and used by several teams before Osborn addressed the term. However, since 1953 brainstorming has been the term used worldwide as a group creativity technique in order to obtain a list of spontaneous ideas and thoughts related to a specified topic. The idea of brainstorming in risk identifications is to gather all potential risks from a variety of disciplines within the project, programme or portfolio team and form a list of individual and overall risks. There are no strict boundaries, but the brainstorming may be divided into different project categories in order to structure the process. All thoughts should be noted down without criticism in order to broaden the framework and identify risks that might not be obvious by first glance. [1][7]
[edit] Risk Checklists
Based on historical projects, programmes or portfolios with a comparable background, one can establish a risk checklist. The purpose of this checklist is to present individual risks that have occurred before and that might occur during the lifetime of the project, programme or portfolio. In order to use a checklist as a risk identification tool it is vital that the checklist is updated and covers risks from a variety of professions. As checklists might omit relevant risks that are not addressed as a historical risk, it is necessary to combine the technique with other risk identification techniques to identify all relevant risks. [1][2][6]
[edit] Risk Breakdown Structure (RBS)
A risk breakdown structure (RBS) is a hierarchical decomposition of potential sources of risk[2] . The structure aims to divide the risks into specific domains with enhanced detail and further subdivisions. The purpose of RBS is to make a detailed overview for the manager of the project, programme or portfolio of the different sections that the risks correspond to. There are several ways to organise the risk breakdown structure and each risk may be broken down differently according to complexity and size. In PRINCE2, the PESTLE (Political, Economic, Social, Technical, Legislative, Environmental) division is described as one of many generic subdivisions that can be implemented for a wide range of projects, programmes or portfolios. In addition to PESTLE, the guidebook for PMI addresses TECOP (technical, environmental, commercial, operational, political), and VUCA (volatility, uncertainty, complexity, ambiguity) as two other relevant generic structures suitable for RBS. [6]
Figure 2 is a graphical representation of the PESTLE template model and should be modified into further specific and relevant subdivisions when put to practice.
An additional general RBS is depicted in Figure 3[9]. The figure is modified for the purpose of this article and illustrates a universal and general decomposition made by the Risk Management Specific Interest Group of the Project Management Institute (PMI Risk SIG) and the Risk Management Working Group of the International Council On Systems Engineering (INCOSE RMWG). The model breaks down the different risks associated to the categories: technology, management and external.[2][6][10]
[edit] Interviews
For projects, programmes or portfolios with a strong connection or correlation to a historical and similar event, one might strongly consider interviewing stakeholders, project managers, project participants or other persons in expertise. The aim of the interview should be to identify possible risks that they have experienced or new risks that they feel are relevant. In order for the interviews to be used as an identification technique it is vital that they are documented and support confidentiality contracts. [6]
[edit] Additional analytical tools
Tools within data analysis can be used during the process of risk identification in order to investigate existing project, programme or portfolio data.
Document analysis
- Uncertainty, imprecise definitions or lack of clarity within the project, programme or portfolio documents may be an underlying risk. Through an investigation of the documents and the different assets associated can help identify risks and clarify unclear statements.[6]
Analysis of existing assumptions and constraints
- Existing assumptions and constraints covered in the project management plan may need to be further analysed in order to prevent any risks within the assumptions and constraints themselves.[6]
SWOT analysis
- The analytical technique SWOT (strengths, weaknesses, opportunities, and threats) is a data analysis tool which, in risk identification, aims to broaden the identification perspective. As SWOT look not only at the specific project, programme or portfolio but also the organisation, it takes a step back to identify risks given by the environment. [6]
Root cause analysis
- In order to identify what risks that may occur from a known problem, one can use root cause analysis. Whilst root cause analysis generally aims to identify the causes and effects of a project, programme or portfolio problem, the tool can be utilised to further identify what risks that are linked to the effects. Identifying these risks will lead to a broader analysation and evaluation of the problems addressed.[6]
[edit] Outputs
[edit] Risk register
The aim of identifying risks is to gather them in a risk register that can actively be used by all active participants of the project, programme or portfolio. The risk register includes a thorough list of all risks identified with detailed information of their potential cause and effect. A specific risk owner may be addressed in order to specify the person or team responsible for monitoring and managing the risk. Possible responses to the risks should be included for those of predictable outcome. The complexity of the risk register and the length of each risk description will differ from the context of the project, programme or portfolio.[6]
[edit] Risk report
In addition to the risk register, a risk report can be composed in order to address the overall risk of a specific project, programme or portfolio. The risk report includes summaries of all individual risks and to which extent they impose a threat or opportunity to the project, programme or portfolio as a whole. Tools such as metrics, trends, or risk rating systems may be implied in order to inform the project manager and all relevant parties of historical data, statistics and degree of threat that the identified risks can cause. [6]
[edit] Revision of project documents
Lastly, the outcome of the identification process might have affected the initial assumptions and must therefore be re- assessed. This is an important process in order to include new aspects and concerns from the risk identification stage. For future projects it can also be relevant to compose a register of the tools and techniques used in the specific project, programme or portfolio in order to document what methods that were beneficial to use and which methods that didn’t serve a significant purpose during the risk identification process.[6]
[edit] Key success factors for identifying risks
A selection of key success factors for identifying risks are listed below. [1] [10]
- Early identification
- Manage risk identification as an iterative process
- Comprehensive identification
- Include both the identification of threats and opportunities
- Include a variety of departments for multiple perspectives
- Include both individual and overall risks
- Effective and clear communication
- View all stakeholders and contributors critically to minimise bias
- Use the agreed risk terminology
- Apply the agreed suitable risk identification techniques
[edit] Limitations of the current identification standards
- The standards connected to risk identification lacks the connection to specific objectives as they are merely general approaches. The given approach might not be the most effective risk identification technique and it is therefore vital to use the standards but support them with historical projects with similar objectives. Additionally, there is no indicator as to how long time one should spend on risk identification. It is crucial to decide upon a reasonable timeframe for identifying risks as too much focus could end in slower project, programme or portfolio process and hinder success. [1][2][3]
- The «Committee for Oversight and Assessment of U.S. Department of Energy Project Management» addresses the importance of project management personnel training in the book The Owner’s Role in Project Risk. A limitation with the given methods is that the importance of analytical and management skills amongst the risk owners and risk managers is missing. An incompetent manager with a limited view of the objectives will not be able to identify risks unless assisted with a team of greater knowledge. [11]
- The experts’, stakeholders’ or other influential parties’ bias should be taken into account during risk identification. If the outcome of the project, programme or portfolio will benefit them in a certain way then it is vital to be sceptical as to which extent they are trustworthy. Including a third part or a similar project team can help to prevent expert bias. It is the project owners who should ensure that identified risks are unbiased by using a team of people who are familiar with the methods required to reduce any possible bias. [11]
[edit] Annotated bibliography
National Research Council. 2005. The Owner's Role in Project Risk Management. Washington, DC: The National Academies Press
- The report is an outcome of the Committee of the Conference on Energy and Water Development of the 105th US Congress in 1997. Here, a review and assessment of the progress made in project management principles was conducted by the National Research Council (NRC) with request from the Department of Energy (DOE). The literature from chapter 4 “Risk Identification and Analysis” covers risk identification techniques and is used as an additional literature to the international standards.
Munier, Nolberto (2014) , Risk Identification. In: Risk Management for Engineering Projects
- Munier addresses the practice of risk identification specifically targeted to different fields of engineering. In chapter 4 Risk Identification he emphasizes the importance of RBS and presents a variety of different ways to structure the RBS recording to specific engineering projects
Hillson, David(2003), Using a Risk Breakdown Structure in project management
- Hillson is a Director of Project Management Professional Solutions Limited(PMProfessional) in the UK and an active member of the Association for Project Management (APM) and the Project Management Institute (PMI). In this article he urges “the need of structure” within risk identification and presents the concepts and importance of RBS.
[edit] References
- ↑ 1.0 1.1 1.2 1.3 1.4 1.5 1.6 1.7 1.8 1.9 Project Management Institute, Inc.(PMI) (2019), Standard for Risk Management in Portfolios, Programs, and Projects
- ↑ 2.0 2.1 2.2 2.3 2.4 2.5 2.6 2.7 AXELOS (2017), Managing Successful Projects with PRINCE2 2017 Edition
- ↑ 3.0 3.1 3.2 3.3 3.4 Project Committee ISO/PC 236 (2012), Project management, ISO 21500 Guidance on project management
- ↑ 4.0 4.1 Inspired by: Project Management Institute, Inc. (PMI) (2019), Standard for Risk Management in Portfolios, Programs, and Projects
- ↑ 5.0 5.1 Munier, Nolberto (2014) , Risk Identification. In: Risk Management for Engineering Projects
- ↑ 6.00 6.01 6.02 6.03 6.04 6.05 6.06 6.07 6.08 6.09 6.10 6.11 6.12 Project Management Institute, Inc.(PMI) (2017), Guide to the Project Management Body of Knowledge (PMBOK® Guide) (6th Edition)
- ↑ 7.0 7.1 Eleazar, Hernández (2017), Brainstorming p.57-58. In: Leading Creative Teams Management Career Paths for Deigners, Developers, and Copywriters, APress
- ↑ Inspired by: AXELOS (2017), Managing Successful Projects with PRINCE2 2017 Edition
- ↑ Inspired by: Hillson, David (2003), Using a Risk Breakdown Structure in project management
- ↑ 10.0 10.1 10.2 Hillson, David (2003), Using a Risk Breakdown Structure in project management
- ↑ 11.0 11.1 National Research Council. 2005. The Owner's Role in Project Risk Management."4 Risk Identification and Analysis." Washington, DC: The National Academies Press. doi: 10.17226/11183.
