http://13.50.150.85/api.php?action=feedcontributions&feedformat=atom&user=ChristofferFriis 2026-07-15T12:42:06Z User contributions MediaWiki 1.43.3 http://13.50.150.85/index.php?title=Identifying_risk&diff=101372 2021-02-28T22:01:02Z

<p>ChristofferFriis: </p> <hr /> <div>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. <br /> When a 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. <br /> When identifying risk, the step that you go through is create input, applying tools and techniques, and finally getting output. <br /> Creating input is essential for management to identifying the risks. Examples of what the input consist of: project management plan, project documents, and more.<br /> After creating input, certain tools can be used to identify the risks. An in-depth look into a selection of these tools can be found on this site, like: Expert judgement, data gathering, and data analysis. <br /> The last part is the output. The output is 3 folded; 1. Risk register. 2. Risk report. 3. Project documents updates. <br /> <br /> The 3 parts of identifying risks (input, tools &amp; output) will be descried in greater details. &lt;ref name=&quot;PMIGuide&quot;/&gt;&lt;ref name=&quot;std&quot;/&gt;&lt;ref name=&quot;Prince2&quot;/&gt;<br /> <br /> <br /> = Big idea = <br /> <br /> Identifying risk is a never-ending job for a project and should be treated as such. By not only identifying the risks at the beginning of the project, but throughout the project’s life cycle. Some risk will inevitably be overseen when first preforming the risk identification and new risk will arise. Therefore, this process needs to be repeated. &lt;ref name=&quot;PMIGuide&quot;/&gt;&lt;ref name=&quot;std&quot;/&gt;<br /> &lt;ref name=&quot;Prince2&quot;/&gt; <br /> <br /> When identifying risks, we seek to identify both individual projects risks and sources of overall project risk. When concluding this process, we should end 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 existing document to reflect new knowledge found. &lt;ref name=&quot;PMIGuide&quot;/&gt;<br /> <br /> To produce this output there must first be some input to work with. This is input like a project management plan, project document, and so on. The input is the first thing that must be in place. When it is, it enables us to use some given tools and techniques to identify the risks. These tools are not limited to the ones described on this page, but the ones highlighted are some good tools to use. &lt;ref name=&quot;PMIGuide&quot;/&gt;<br /> <br /> 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 participate in this process are: &lt;ref name=&quot;Prince2&quot;/&gt;<br /> &lt;ref name=&quot;PMIGuide&quot;/&gt;<br /> <br /> - Project manager <br /> <br /> - Project team <br /> <br /> - Risk specialist<br /> <br /> - Customers and end users <br /> <br /> - External subject experts <br /> <br /> - Relevant stakeholders<br /> <br /> - Internal risk management expert <br /> <br /> <br /> = Input =<br /> <br /> When talking input for risk identification we are talking about all documents and knowledge developed beforehand, that enables us to identify any risks. These are output from task/processes which were carried out prior to the risk identification. Hence, laying the groundwork to the actual risk identification. &lt;ref name=&quot;PMIGuide&quot;/&gt;<br /> <br /> Some examples of input needed are: <br /> <br /> • Project management plan <br /> <br /> • Project Documents <br /> <br /> • Agreements <br /> <br /> • Procurement documentation <br /> <br /> • Enterprise environmental factors <br /> <br /> • Organisational process assets<br /> <br /> <br /> === Project management plan ===<br /> The project management plan include knowledge from underlining components. These components include: <br /> <br /> • Requirements management plan<br /> <br /> • Schedule management plan <br /> <br /> • Cost management plan <br /> <br /> • Quality Management plan <br /> <br /> • Resource management plan <br /> <br /> • Risk management plan<br /> <br /> • Scope baseline<br /> <br /> • Schedule baseline <br /> <br /> • Cost baseline<br /> <br /> Other relevant Management plans, Baselines, or relevant documents can be included in the project management plan. &lt;ref name=&quot;PMIGuide&quot;/&gt;<br /> <br /> <br /> === Project Documents ===<br /> <br /> Some project documents can be included as input in the risk identification. Examples of these are: &lt;ref name=&quot;PMIGuide&quot;/&gt;<br /> <br /> • Assumption log<br /> <br /> • Cost estimates<br /> <br /> • Duration estimates <br /> <br /> • Issue log<br /> <br /> • Lessons learned register <br /> <br /> • Requirements documentation. <br /> <br /> • Resource requirements <br /> <br /> • Stakeholder register<br /> <br /> <br /> === Agreements ===<br /> There might be some agreement/contract with some external partner/stakeholders. The information in such an agreement may present both risks and opportunities for the project. Information in the agreement may include, but are not limited to, milestones dates, acceptance criteria, awards and penalties. &lt;ref name=&quot;PMIGuide&quot;/&gt;<br /> <br /> <br /> === Procurement documentation ===<br /> <br /> 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 therefore be reviewed for potential risks. &lt;ref name=&quot;PMIGuide&quot;/&gt;<br /> <br /> <br /> = Tools = <br /> <br /> From the generated and gathered input, the management team have a variety of tools in the toolbox, that will help them identify the risks. &lt;ref name=&quot;PMIGuide&quot;/&gt;<br /> <br /> Examples of such tools are: <br /> • Expert judgment <br /> <br /> • Data gathering (Brainstorming, Checklists, Interviews) <br /> <br /> • Root cause analysis <br /> <br /> • Assumption and constraint analysis <br /> <br /> • SWOT analysis <br /> <br /> • Risk breakdown structure <br /> <br /> • Document analysis<br /> <br /> • Interpersonal and team skills<br /> <br /> • Prompt lists <br /> <br /> • Meetings <br /> <br /> <br /> === Expert judgement ===<br /> <br /> The project manager should identify individuals or groups that could act as experts when identifying projects risks and the source of these risks. The expert should both consider specific risk and overall project risks. <br /> <br /> 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. &lt;ref name=&quot;PMIGuide&quot;/&gt;<br /> <br /> <br /> === Data gathering === <br /> <br /> There are multiple techniques to gather data related to risk. Here there are highlighted some, which are widely used<br /> <br /> ==== Brainstorming ====<br /> <br /> In a brainstorm the goal is to 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. <br /> <br /> 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. &lt;ref name=&quot;PMIGuide&quot;/&gt;<br /> <br /> ==== Checklist ====<br /> <br /> 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. &lt;ref name=&quot;std&quot;/&gt;<br /> <br /> The checklist is a good way for a company to transfer knowledge and learnings from project to project. <br /> However, this should not be seen as a reason not to carrier out a risk identification throughout the project life cycle. The checklist may not identify all risks, and other risks must also be explored. &lt;ref name=&quot;PMIGuide&quot;/&gt;<br /> <br /> ==== Interviews ====<br /> <br /> 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.). <br /> 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 a trusting and open environment to ensure the right information is extracted. &lt;ref name=&quot;PMIGuide&quot;/&gt;<br /> <br /> <br /> === Root cause analysis ===<br /> <br /> 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 underlining risk will also be solved. <br /> By stating a problem/benefit statement a root cause analysis can be used to detect threats or opportunities. &lt;ref name=&quot;PMIGuide&quot;/&gt;<br /> <br /> <br /> === Assumption and constraint analysis ===<br /> <br /> This is an analysis of the projects and project management plans underlining assumption and constraint. <br /> The assumptions, which the project has made, represent some unidentified risks. Analysing these assumptions will bring risk to light and assess their threat. <br /> 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. &lt;ref name=&quot;PMIGuide&quot;/&gt;<br /> <br /> <br /> === SWOT analysis ===<br /> <br /> SWOT is an analysis of the project and organizations strengths, weaknesses, opportunities and threats. It can be used to look at internally created risks for the project. It starts with an analysis of the company’s weaknesses and strengths. From this any threats or opportunities should be analyzed, as well as how the company’s weaknesses and strengths affects the given threats and opportunities. &lt;ref name=&quot;PMIGuide&quot;/&gt; &lt;ref name=&quot;std&quot;/&gt;<br /> <br /> <br /> === Risk breakdown structure === <br /> <br /> A risk breakdown structure is a hierarchical representation of risks. Meaning that it starts it that highest level and then moves down into more detailed levels. The RBS is not unlike the Work Breakdown Structure, and it will help the manager create an overview of the risk categories. &lt;ref name=&quot;Prince2&quot;/&gt;&lt;ref name=&quot;RBS&quot;/&gt;<br /> <br /> <br /> = Output =<br /> <br /> The output from identifying risk is three folded: the risk register, the risk report, and updates of project documents. <br /> <br /> <br /> === Risk register === <br /> <br /> The risk register is, as the name may suggest, where all individual risks are registered. This includes a list of all risk found in the identification process. All risks are registered with unique names and/or numbers, as well as a description of the risk so that the information doesn’t get lost. &lt;ref name=&quot;Prince2&quot;/&gt;<br /> <br /> 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. &lt;ref name=&quot;std&quot;/&gt;<br /> <br /> <br /> 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. <br /> <br /> 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. &lt;ref name=&quot;PMIGuide&quot;/&gt;<br /> <br /> <br /> === Risk report ===<br /> <br /> The risk report includes the sources of overall project risk, as well as a summary of individual project risks. &lt;ref name=&quot;PMIGuide&quot;/&gt;<br /> <br /> <br /> === Project documents updates ===<br /> <br /> 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. &lt;ref name=&quot;PMIGuide&quot;/&gt;<br /> <br /> <br /> = Limitations =<br /> <br /> All risk to a project will not be identified at ones. Even if all risk could be identified, changes are some will be missed/undetected. This only enhances the importance of conducting a risk identification process throughout the project’s life cycle. &lt;ref name=&quot;std&quot;/&gt;<br /> <br /> One should also be aware of expert bias. It is quite common and can be a threat to the quality of the risk identification, as well as the response. &lt;ref name=&quot;PMIGuide&quot;/&gt;<br /> <br /> <br /> = Annotated bibliography =<br /> <br /> • Project Management: A guide to the Project Management Body of Knowledge (PMBOK guide), 6th Edition (2017).<br /> <br /> For risk identification, chapter 11 is a very good walkthrough of how to conduct a risk identification process. <br /> <br /> <br /> • Standard for Risk Management in Portfolios, Programs, and Projects<br /> <br /> A very good reference for all things risks in projects, portfolios, and programs. <br /> <br /> <br /> • Managing Successful Projects with PRINCE2 2017 Edition<br /> <br /> Chapter 10 looks into risk, and PRINCE2 standards for handling risk, as well as what risk are. <br /> <br /> <br /> = References = <br /> &lt;references&gt;<br /> &lt;ref name=&quot;PMIGuide&quot;&gt;Guide to the Project Management Body of Knowledge (PMBOK® Guide) (6th Edition), Project Management Institute (PMI), Inc.(2017)&lt;/ref&gt;<br /> &lt;ref name=&quot;Prince2&quot;&gt;Managing Successful Projects with PRINCE2 2017 Edition, AXELOS (2017)&lt;/ref&gt;<br /> &lt;ref name=&quot;std&quot;&gt;Standard for Risk Management in Portfolios, Programs, and Projects, Project Management Institute, Inc. (PMI)<br /> (2019)&lt;/ref&gt;<br /> &lt;ref name=&quot;RBS&quot;&gt;Understanding the Risk Breakdown Structure (RBS), Internet article, 12/10/2018,( https://project-management.com/understanding-the-risk-breakdown-structure-rbs/),&lt;/ref&gt;</div>

ChristofferFriis http://13.50.150.85/index.php?title=Identifying_risk&diff=101367 2021-02-28T22:00:38Z

<p>ChristofferFriis: </p> <hr /> <div>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. <br /> When a 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. <br /> When identifying risk, the step that you go through is create input, applying tools and techniques, and finally getting output. <br /> Creating input is essential for management to identifying the risks. Examples of what the input consist of: project management plan, project documents, and more.<br /> After creating input, certain tools can be used to identify the risks. An in-depth look into a selection of these tools can be found on this site, like: Expert judgement, data gathering, and data analysis. <br /> The last part is the output. The output is 3 folded; 1. Risk register. 2. Risk report. 3. Project documents updates. <br /> <br /> The 3 parts of identifying risks (input, tools &amp; output) will be descried in greater details. &lt;ref name=&quot;PMIGuide&quot;/&gt;&lt;ref name=&quot;std&quot;/&gt;&lt;ref name=&quot;Prince2&quot;/&gt;<br /> <br /> <br /> = Big idea = <br /> <br /> Identifying risk is a never-ending job for a project and should be treated as such. By not only identifying the risks at the beginning of the project, but throughout the project’s life cycle. Some risk will inevitably be overseen when first preforming the risk identification and new risk will arise. Therefore, this process needs to be repeated. &lt;ref name=&quot;PMIGuide&quot;/&gt;&lt;ref name=&quot;std&quot;/&gt;<br /> &lt;ref name=&quot;Prince2&quot;/&gt; <br /> <br /> When identifying risks, we seek to identify both individual projects risks and sources of overall project risk. When concluding this process, we should end 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 existing document to reflect new knowledge found. &lt;ref name=&quot;PMIGuide&quot;/&gt;<br /> <br /> To produce this output there must first be some input to work with. This is input like a project management plan, project document, and so on. The input is the first thing that must be in place. When it is, it enables us to use some given tools and techniques to identify the risks. These tools are not limited to the ones described on this page, but the ones highlighted are some good tools to use. &lt;ref name=&quot;PMIGuide&quot;/&gt;<br /> <br /> 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 participate in this process are: &lt;ref name=&quot;Prince2&quot;/&gt;<br /> &lt;ref name=&quot;PMIGuide&quot;/&gt;<br /> <br /> - Project manager <br /> <br /> - Project team <br /> <br /> - Risk specialist<br /> <br /> - Customers and end users <br /> <br /> - External subject experts <br /> <br /> - Relevant stakeholders<br /> <br /> - Internal risk management expert <br /> <br /> <br /> = Input =<br /> <br /> When talking input for risk identification we are talking about all documents and knowledge developed beforehand, that enables us to identify any risks. These are output from task/processes which were carried out prior to the risk identification. Hence, laying the groundwork to the actual risk identification. &lt;ref name=&quot;PMIGuide&quot;/&gt;<br /> <br /> Some examples of input needed are: <br /> <br /> • Project management plan <br /> <br /> • Project Documents <br /> <br /> • Agreements <br /> <br /> • Procurement documentation <br /> <br /> • Enterprise environmental factors <br /> <br /> • Organisational process assets<br /> <br /> <br /> === Project management plan ===<br /> The project management plan include knowledge from underlining components. These components include: <br /> <br /> • Requirements management plan<br /> <br /> • Schedule management plan <br /> <br /> • Cost management plan <br /> <br /> • Quality Management plan <br /> <br /> • Resource management plan <br /> <br /> • Risk management plan<br /> <br /> • Scope baseline<br /> <br /> • Schedule baseline <br /> <br /> • Cost baseline<br /> <br /> Other relevant Management plans, Baselines, or relevant documents can be included in the project management plan. &lt;ref name=&quot;PMIGuide&quot;/&gt;<br /> <br /> <br /> === Project Documents ===<br /> <br /> Some project documents can be included as input in the risk identification. Examples of these are: &lt;ref name=&quot;PMIGuide&quot;/&gt;<br /> <br /> • Assumption log<br /> <br /> • Cost estimates<br /> <br /> • Duration estimates <br /> <br /> • Issue log<br /> <br /> • Lessons learned register <br /> <br /> • Requirements documentation. <br /> <br /> • Resource requirements <br /> <br /> • Stakeholder register<br /> <br /> <br /> === Agreements ===<br /> There might be some agreement/contract with some external partner/stakeholders. The information in such an agreement may present both risks and opportunities for the project. Information in the agreement may include, but are not limited to, milestones dates, acceptance criteria, awards and penalties. &lt;ref name=&quot;PMIGuide&quot;/&gt;<br /> <br /> <br /> === Procurement documentation ===<br /> <br /> 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 therefore be reviewed for potential risks. &lt;ref name=&quot;PMIGuide&quot;/&gt;<br /> <br /> <br /> = Tools = <br /> <br /> From the generated and gathered input, the management team have a variety of tools in the toolbox, that will help them identify the risks. &lt;ref name=&quot;PMIGuide&quot;/&gt;<br /> <br /> Examples of such tools are: <br /> • Expert judgment <br /> <br /> • Data gathering (Brainstorming, Checklists, Interviews) <br /> <br /> • Root cause analysis <br /> <br /> • Assumption and constraint analysis <br /> <br /> • SWOT analysis <br /> <br /> • Risk breakdown structure <br /> <br /> • Document analysis<br /> <br /> • Interpersonal and team skills<br /> <br /> • Prompt lists <br /> <br /> • Meetings <br /> <br /> <br /> === Expert judgement ===<br /> <br /> The project manager should identify individuals or groups that could act as experts when identifying projects risks and the source of these risks. The expert should both consider specific risk and overall project risks. <br /> <br /> 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. &lt;ref name=&quot;PMIGuide&quot;/&gt;<br /> <br /> <br /> === Data gathering === <br /> <br /> There are multiple techniques to gather data related to risk. Here there are highlighted some, which are widely used<br /> <br /> ==== Brainstorming ====<br /> <br /> In a brainstorm the goal is to 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. <br /> <br /> 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. &lt;ref name=&quot;PMIGuide&quot;/&gt;<br /> <br /> ==== Checklist ====<br /> <br /> 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. &lt;ref name=&quot;std&quot;/&gt;<br /> <br /> The checklist is a good way for a company to transfer knowledge and learnings from project to project. <br /> However, this should not be seen as a reason not to carrier out a risk identification throughout the project life cycle. The checklist may not identify all risks, and other risks must also be explored. &lt;ref name=&quot;PMIGuide&quot;/&gt;<br /> <br /> ==== Interviews ====<br /> <br /> 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.). <br /> 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 a trusting and open environment to ensure the right information is extracted. &lt;ref name=&quot;PMIGuide&quot;/&gt;<br /> <br /> <br /> === Root cause analysis ===<br /> <br /> 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 underlining risk will also be solved. <br /> By stating a problem/benefit statement a root cause analysis can be used to detect threats or opportunities. &lt;ref name=&quot;PMIGuide&quot;/&gt;<br /> <br /> <br /> === Assumption and constraint analysis ===<br /> <br /> This is an analysis of the projects and project management plans underlining assumption and constraint. <br /> The assumptions, which the project has made, represent some unidentified risks. Analysing these assumptions will bring risk to light and assess their threat. <br /> 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. &lt;ref name=&quot;PMIGuide&quot;/&gt;<br /> <br /> <br /> === SWOT analysis ===<br /> <br /> SWOT is an analysis of the project and organizations strengths, weaknesses, opportunities and threats. It can be used to look at internally created risks for the project. It starts with an analysis of the company’s weaknesses and strengths. From this any threats or opportunities should be analyzed, as well as how the company’s weaknesses and strengths affects the given threats and opportunities. &lt;ref name=&quot;PMIGuide&quot;/&gt; &lt;ref name=&quot;std&quot;/&gt;<br /> <br /> <br /> === Risk breakdown structure === <br /> <br /> A risk breakdown structure is a hierarchical representation of risks. Meaning that it starts it that highest level and then moves down into more detailed levels. The RBS is not unlike the Work Breakdown Structure, and it will help the manager create an overview of the risk categories. &lt;ref name=&quot;Prince2&quot;/&gt;&lt;ref name=&quot;RBS&quot;/&gt;<br /> <br /> <br /> = Output =<br /> <br /> The output from identifying risk is three folded: the risk register, the risk report, and updates of project documents. <br /> <br /> <br /> === Risk register === <br /> <br /> The risk register is, as the name may suggest, where all individual risks are registered. This includes a list of all risk found in the identification process. All risks are registered with unique names and/or numbers, as well as a description of the risk so that the information doesn’t get lost. &lt;ref name=&quot;Prince2&quot;/&gt;<br /> <br /> 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. &lt;ref name=&quot;std&quot;/&gt;<br /> <br /> <br /> 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. <br /> <br /> 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. &lt;ref name=&quot;PMIGuide&quot;/&gt;<br /> <br /> <br /> === Risk report ===<br /> <br /> The risk report includes the sources of overall project risk, as well as a summary of individual project risks. &lt;ref name=&quot;PMIGuide&quot;/&gt;<br /> <br /> <br /> === Project documents updates ===<br /> <br /> 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. &lt;ref name=&quot;PMIGuide&quot;/&gt;<br /> <br /> <br /> = Limitations =<br /> <br /> All risk to a project will not be identified at ones. Even if all risk could be identified, changes are some will be missed/undetected. This only enhances the importance of conducting a risk identification process throughout the project’s life cycle. &lt;ref name=&quot;std&quot;/&gt;<br /> <br /> One should also be aware of expert bias. It is quite common and can be a threat to the quality of the risk identification, as well as the response. &lt;ref name=&quot;PMIGuide&quot;/&gt;<br /> <br /> <br /> = Annotated bibliography =<br /> <br /> • Project Management: A guide to the Project Management Body of Knowledge (PMBOK guide), 6th Edition (2017).<br /> <br /> For risk identification, chapter 11 is a very good walkthrough of how to conduct a risk identification process. <br /> <br /> • Standard for Risk Management in Portfolios, Programs, and Projects<br /> <br /> A very good reference for all things risks in projects, portfolios, and programs. <br /> <br /> • Managing Successful Projects with PRINCE2 2017 Edition<br /> <br /> Chapter 10 looks into risk, and PRINCE2 standards for handling risk, as well as what risk are. <br /> <br /> <br /> = References = <br /> &lt;references&gt;<br /> &lt;ref name=&quot;PMIGuide&quot;&gt;Guide to the Project Management Body of Knowledge (PMBOK® Guide) (6th Edition), Project Management Institute (PMI), Inc.(2017)&lt;/ref&gt;<br /> &lt;ref name=&quot;Prince2&quot;&gt;Managing Successful Projects with PRINCE2 2017 Edition, AXELOS (2017)&lt;/ref&gt;<br /> &lt;ref name=&quot;std&quot;&gt;Standard for Risk Management in Portfolios, Programs, and Projects, Project Management Institute, Inc. (PMI)<br /> (2019)&lt;/ref&gt;<br /> &lt;ref name=&quot;RBS&quot;&gt;Understanding the Risk Breakdown Structure (RBS), Internet article, 12/10/2018,( https://project-management.com/understanding-the-risk-breakdown-structure-rbs/),&lt;/ref&gt;</div>

ChristofferFriis http://13.50.150.85/index.php?title=Identifying_risk&diff=101358 2021-02-28T21:59:41Z

<p>ChristofferFriis: </p> <hr /> <div>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. <br /> When a 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. <br /> When identifying risk, the step that you go through is create input, applying tools and techniques, and finally getting output. <br /> Creating input is essential for management to identifying the risks. Examples of what the input consist of: project management plan, project documents, and more.<br /> After creating input, certain tools can be used to identify the risks. An in-depth look into a selection of these tools can be found on this site, like: Expert judgement, data gathering, and data analysis. <br /> The last part is the output. The output is 3 folded; 1. Risk register. 2. Risk report. 3. Project documents updates. <br /> <br /> The 3 parts of identifying risks (input, tools &amp; output) will be descried in greater details. &lt;ref name=&quot;PMIGuide&quot;/&gt;&lt;ref name=&quot;std&quot;/&gt;&lt;ref name=&quot;Prince2&quot;/&gt;<br /> <br /> <br /> = Big idea = <br /> <br /> Identifying risk is a never-ending job for a project and should be treated as such. By not only identifying the risks at the beginning of the project, but throughout the project’s life cycle. Some risk will inevitably be overseen when first preforming the risk identification and new risk will arise. Therefore, this process needs to be repeated. &lt;ref name=&quot;PMIGuide&quot;/&gt;&lt;ref name=&quot;std&quot;/&gt;<br /> &lt;ref name=&quot;Prince2&quot;/&gt; <br /> <br /> When identifying risks, we seek to identify both individual projects risks and sources of overall project risk. When concluding this process, we should end 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 existing document to reflect new knowledge found. &lt;ref name=&quot;PMIGuide&quot;/&gt;<br /> <br /> To produce this output there must first be some input to work with. This is input like a project management plan, project document, and so on. The input is the first thing that must be in place. When it is, it enables us to use some given tools and techniques to identify the risks. These tools are not limited to the ones described on this page, but the ones highlighted are some good tools to use. &lt;ref name=&quot;PMIGuide&quot;/&gt;<br /> <br /> 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 participate in this process are: &lt;ref name=&quot;Prince2&quot;/&gt;<br /> &lt;ref name=&quot;PMIGuide&quot;/&gt;<br /> <br /> - Project manager <br /> <br /> - Project team <br /> <br /> - Risk specialist<br /> <br /> - Customers and end users <br /> <br /> - External subject experts <br /> <br /> - Relevant stakeholders<br /> <br /> - Internal risk management expert <br /> <br /> <br /> = Input =<br /> <br /> When talking input for risk identification we are talking about all documents and knowledge developed beforehand, that enables us to identify any risks. These are output from task/processes which were carried out prior to the risk identification. Hence, laying the groundwork to the actual risk identification. &lt;ref name=&quot;PMIGuide&quot;/&gt;<br /> <br /> Some examples of input needed are: <br /> <br /> • Project management plan <br /> <br /> • Project Documents <br /> <br /> • Agreements <br /> <br /> • Procurement documentation <br /> <br /> • Enterprise environmental factors <br /> <br /> • Organisational process assets<br /> <br /> <br /> === Project management plan ===<br /> The project management plan include knowledge from underlining components. These components include: <br /> <br /> • Requirements management plan<br /> <br /> • Schedule management plan <br /> <br /> • Cost management plan <br /> <br /> • Quality Management plan <br /> <br /> • Resource management plan <br /> <br /> • Risk management plan<br /> <br /> • Scope baseline<br /> <br /> • Schedule baseline <br /> <br /> • Cost baseline<br /> <br /> Other relevant Management plans, Baselines, or relevant documents can be included in the project management plan. &lt;ref name=&quot;PMIGuide&quot;/&gt;<br /> <br /> <br /> === Project Documents ===<br /> <br /> Some project documents can be included as input in the risk identification. Examples of these are: &lt;ref name=&quot;PMIGuide&quot;/&gt;<br /> <br /> • Assumption log<br /> <br /> • Cost estimates<br /> <br /> • Duration estimates <br /> <br /> • Issue log<br /> <br /> • Lessons learned register <br /> <br /> • Requirements documentation. <br /> <br /> • Resource requirements <br /> <br /> • Stakeholder register<br /> <br /> <br /> === Agreements ===<br /> There might be some agreement/contract with some external partner/stakeholders. The information in such an agreement may present both risks and opportunities for the project. Information in the agreement may include, but are not limited to, milestones dates, acceptance criteria, awards and penalties. &lt;ref name=&quot;PMIGuide&quot;/&gt;<br /> <br /> <br /> === Procurement documentation ===<br /> <br /> 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 therefore be reviewed for potential risks. &lt;ref name=&quot;PMIGuide&quot;/&gt;<br /> <br /> <br /> = Tools = <br /> <br /> From the generated and gathered input, the management team have a variety of tools in the toolbox, that will help them identify the risks. &lt;ref name=&quot;PMIGuide&quot;/&gt;<br /> <br /> Examples of such tools are: <br /> • Expert judgment <br /> <br /> • Data gathering (Brainstorming, Checklists, Interviews) <br /> <br /> • Root cause analysis <br /> <br /> • Assumption and constraint analysis <br /> <br /> • SWOT analysis <br /> <br /> • Risk breakdown structure <br /> <br /> • Document analysis<br /> <br /> • Interpersonal and team skills<br /> <br /> • Prompt lists <br /> <br /> • Meetings <br /> <br /> <br /> === Expert judgement ===<br /> <br /> The project manager should identify individuals or groups that could act as experts when identifying projects risks and the source of these risks. The expert should both consider specific risk and overall project risks. <br /> <br /> 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. &lt;ref name=&quot;PMIGuide&quot;/&gt;<br /> <br /> <br /> === Data gathering === <br /> <br /> There are multiple techniques to gather data related to risk. Here there are highlighted some, which are widely used<br /> <br /> ==== Brainstorming ====<br /> <br /> In a brainstorm the goal is to 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. <br /> <br /> 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. &lt;ref name=&quot;PMIGuide&quot;/&gt;<br /> <br /> ==== Checklist ====<br /> <br /> 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. &lt;ref name=&quot;std&quot;/&gt;<br /> <br /> The checklist is a good way for a company to transfer knowledge and learnings from project to project. <br /> However, this should not be seen as a reason not to carrier out a risk identification throughout the project life cycle. The checklist may not identify all risks, and other risks must also be explored. &lt;ref name=&quot;PMIGuide&quot;/&gt;<br /> <br /> ==== Interviews ====<br /> <br /> 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.). <br /> 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 a trusting and open environment to ensure the right information is extracted. &lt;ref name=&quot;PMIGuide&quot;/&gt;<br /> <br /> <br /> === Root cause analysis ===<br /> <br /> 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 underlining risk will also be solved. <br /> By stating a problem/benefit statement a root cause analysis can be used to detect threats or opportunities. &lt;ref name=&quot;PMIGuide&quot;/&gt;<br /> <br /> <br /> === Assumption and constraint analysis ===<br /> <br /> This is an analysis of the projects and project management plans underlining assumption and constraint. <br /> The assumptions, which the project has made, represent some unidentified risks. Analysing these assumptions will bring risk to light and assess their threat. <br /> 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. &lt;ref name=&quot;PMIGuide&quot;/&gt;<br /> <br /> <br /> === SWOT analysis ===<br /> <br /> SWOT is an analysis of the project and organizations strengths, weaknesses, opportunities and threats. It can be used to look at internally created risks for the project. It starts with an analysis of the company’s weaknesses and strengths. From this any threats or opportunities should be analyzed, as well as how the company’s weaknesses and strengths affects the given threats and opportunities. &lt;ref name=&quot;PMIGuide&quot;/&gt; &lt;ref name=&quot;std&quot;/&gt;<br /> <br /> <br /> === Risk breakdown structure === <br /> <br /> A risk breakdown structure is a hierarchical representation of risks. Meaning that it starts it that highest level and then moves down into more detailed levels. The RBS is not unlike the Work Breakdown Structure, and it will help the manager create an overview of the risk categories. &lt;ref name=&quot;Prince2&quot;/&gt;&lt;ref name=&quot;RBS&quot;/&gt;<br /> <br /> <br /> = Output =<br /> <br /> The output from identifying risk is three folded: the risk register, the risk report, and updates of project documents. <br /> <br /> <br /> === Risk register === <br /> <br /> The risk register is, as the name may suggest, where all individual risks are registered. This includes a list of all risk found in the identification process. All risks are registered with unique names and/or numbers, as well as a description of the risk so that the information doesn’t get lost. &lt;ref name=&quot;Prince2&quot;/&gt;<br /> <br /> 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. &lt;ref name=&quot;std&quot;/&gt;<br /> <br /> <br /> 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. <br /> <br /> 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. &lt;ref name=&quot;PMIGuide&quot;/&gt;<br /> <br /> <br /> === Risk report ===<br /> <br /> The risk report includes the sources of overall project risk, as well as a summary of individual project risks. &lt;ref name=&quot;PMIGuide&quot;/&gt;<br /> <br /> <br /> === Project documents updates ===<br /> <br /> 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. &lt;ref name=&quot;PMIGuide&quot;/&gt;<br /> <br /> <br /> = Limitations =<br /> <br /> All risk to a project will not be identified at ones. Even if all risk could be identified, changes are some will be missed/undetected. This only enhances the importance of conducting a risk identification process throughout the project’s life cycle. &lt;ref name=&quot;std&quot;/&gt;<br /> <br /> One should also be aware of expert bias. It is quite common and can be a threat to the quality of the risk identification, as well as the response. &lt;ref name=&quot;PMIGuide&quot;/&gt;<br /> <br /> <br /> = Annotated bibliography =<br /> <br /> • Project Management: A guide to the Project Management Body of Knowledge (PMBOK guide), 6th Edition (2017).<br /> For risk identification, chapter 11 is a very good walkthrough of how to conduct a risk identification process. <br /> <br /> • Standard for Risk Management in Portfolios, Programs, and Projects<br /> A very good reference for all things risks in projects, portfolios, and programs. <br /> <br /> • Managing Successful Projects with PRINCE2 2017 Edition<br /> Chapter 10 looks into risk, and PRINCE2 standards for handling risk, as well as what risk are. <br /> <br /> <br /> = References = <br /> &lt;references&gt;<br /> &lt;ref name=&quot;PMIGuide&quot;&gt;Guide to the Project Management Body of Knowledge (PMBOK® Guide) (6th Edition), Project Management Institute (PMI), Inc.(2017)&lt;/ref&gt;<br /> &lt;ref name=&quot;Prince2&quot;&gt;Managing Successful Projects with PRINCE2 2017 Edition, AXELOS (2017)&lt;/ref&gt;<br /> &lt;ref name=&quot;std&quot;&gt;Standard for Risk Management in Portfolios, Programs, and Projects, Project Management Institute, Inc. (PMI)<br /> (2019)&lt;/ref&gt;<br /> &lt;ref name=&quot;RBS&quot;&gt;Understanding the Risk Breakdown Structure (RBS), Internet article, 12/10/2018,( https://project-management.com/understanding-the-risk-breakdown-structure-rbs/),&lt;/ref&gt;</div>

ChristofferFriis http://13.50.150.85/index.php?title=Identifying_risk&diff=101328 2021-02-28T21:57:32Z

<p>ChristofferFriis: </p> <hr /> <div>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. <br /> When a 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. <br /> When identifying risk, the step that you go through is create input, applying tools and techniques, and finally getting output. <br /> Creating input is essential for management to identifying the risks. Examples of what the input consist of: project management plan, project documents, and more.<br /> After creating input, certain tools can be used to identify the risks. An in-depth look into a selection of these tools can be found on this site, like: Expert judgement, data gathering, and data analysis. <br /> The last part is the output. The output is 3 folded; 1. Risk register. 2. Risk report. 3. Project documents updates. <br /> <br /> The 3 parts of identifying risks (input, tools &amp; output) will be descried in greater details. &lt;ref name=&quot;PMIGuide&quot;/&gt;&lt;ref name=&quot;std&quot;/&gt;&lt;ref name=&quot;Prince2&quot;/&gt;<br /> <br /> <br /> = Big idea = <br /> <br /> Identifying risk is a never-ending job for a project and should be treated as such. By not only identifying the risks at the beginning of the project, but throughout the project’s life cycle. Some risk will inevitably be overseen when first preforming the risk identification and new risk will arise. Therefore, this process needs to be repeated. &lt;ref name=&quot;PMIGuide&quot;/&gt;&lt;ref name=&quot;std&quot;/&gt;<br /> &lt;ref name=&quot;Prince2&quot;/&gt; <br /> <br /> When identifying risks, we seek to identify both individual projects risks and sources of overall project risk. When concluding this process, we should end 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 existing document to reflect new knowledge found. &lt;ref name=&quot;PMIGuide&quot;/&gt;<br /> <br /> To produce this output there must first be some input to work with. This is input like a project management plan, project document, and so on. The input is the first thing that must be in place. When it is, it enables us to use some given tools and techniques to identify the risks. These tools are not limited to the ones described on this page, but the ones highlighted are some good tools to use. &lt;ref name=&quot;PMIGuide&quot;/&gt;<br /> <br /> 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 participate in this process are: &lt;ref name=&quot;Prince2&quot;/&gt;<br /> &lt;ref name=&quot;PMIGuide&quot;/&gt;<br /> <br /> - Project manager <br /> <br /> - Project team <br /> <br /> - Risk specialist<br /> <br /> - Customers and end users <br /> <br /> - External subject experts <br /> <br /> - Relevant stakeholders<br /> <br /> - Internal risk management expert <br /> <br /> <br /> = Input =<br /> <br /> When talking input for risk identification we are talking about all documents and knowledge developed beforehand, that enables us to identify any risks. These are output from task/processes which were carried out prior to the risk identification. Hence, laying the groundwork to the actual risk identification. &lt;ref name=&quot;PMIGuide&quot;/&gt;<br /> <br /> Some examples of input needed are: <br /> <br /> • Project management plan <br /> <br /> • Project Documents <br /> <br /> • Agreements <br /> <br /> • Procurement documentation <br /> <br /> • Enterprise environmental factors <br /> <br /> • Organisational process assets<br /> <br /> <br /> === Project management plan ===<br /> The project management plan include knowledge from underlining components. These components include: <br /> <br /> • Requirements management plan<br /> <br /> • Schedule management plan <br /> <br /> • Cost management plan <br /> <br /> • Quality Management plan <br /> <br /> • Resource management plan <br /> <br /> • Risk management plan<br /> <br /> • Scope baseline<br /> <br /> • Schedule baseline <br /> <br /> • Cost baseline<br /> <br /> Other relevant Management plans, Baselines, or relevant documents can be included in the project management plan. &lt;ref name=&quot;PMIGuide&quot;/&gt;<br /> <br /> === Project Documents ===<br /> <br /> Some project documents can be included as input in the risk identification. Examples of these are: &lt;ref name=&quot;PMIGuide&quot;/&gt;<br /> <br /> • Assumption log<br /> <br /> • Cost estimates<br /> <br /> • Duration estimates <br /> <br /> • Issue log<br /> <br /> • Lessons learned register <br /> <br /> • Requirements documentation. <br /> <br /> • Resource requirements <br /> <br /> • Stakeholder register<br /> <br /> === Agreements ===<br /> There might be some agreement/contract with some external partner/stakeholders. The information in such an agreement may present both risks and opportunities for the project. Information in the agreement may include, but are not limited to, milestones dates, acceptance criteria, awards and penalties. &lt;ref name=&quot;PMIGuide&quot;/&gt;<br /> <br /> === Procurement documentation ===<br /> <br /> 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 therefore be reviewed for potential risks. &lt;ref name=&quot;PMIGuide&quot;/&gt;<br /> <br /> = Tools = <br /> <br /> From the generated and gathered input, the management team have a variety of tools in the toolbox, that will help them identify the risks. &lt;ref name=&quot;PMIGuide&quot;/&gt;<br /> <br /> Examples of such tools are: <br /> • Expert judgment <br /> <br /> • Data gathering (Brainstorming, Checklists, Interviews) <br /> <br /> • Root cause analysis <br /> <br /> • Assumption and constraint analysis <br /> <br /> • SWOT analysis <br /> <br /> • Risk breakdown structure <br /> <br /> • Document analysis<br /> <br /> • Interpersonal and team skills<br /> <br /> • Prompt lists <br /> <br /> • Meetings <br /> <br /> === Expert judgement ===<br /> <br /> The project manager should identify individuals or groups that could act as experts when identifying projects risks and the source of these risks. The expert should both consider specific risk and overall project risks. <br /> <br /> 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. &lt;ref name=&quot;PMIGuide&quot;/&gt;<br /> <br /> === Data gathering === <br /> <br /> There are multiple techniques to gather data related to risk. Here there are highlighted some, which are widely used<br /> <br /> ==== Brainstorming ====<br /> <br /> In a brainstorm the goal is to 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. <br /> <br /> 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. &lt;ref name=&quot;PMIGuide&quot;/&gt;<br /> <br /> ==== Checklist ====<br /> <br /> 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. &lt;ref name=&quot;std&quot;/&gt;<br /> <br /> The checklist is a good way for a company to transfer knowledge and learnings from project to project. <br /> However, this should not be seen as a reason not to carrier out a risk identification throughout the project life cycle. The checklist may not identify all risks, and other risks must also be explored. &lt;ref name=&quot;PMIGuide&quot;/&gt;<br /> <br /> ==== Interviews ====<br /> <br /> 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.). <br /> 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 a trusting and open environment to ensure the right information is extracted. &lt;ref name=&quot;PMIGuide&quot;/&gt;<br /> <br /> <br /> === Root cause analysis ===<br /> <br /> 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 underlining risk will also be solved. <br /> By stating a problem/benefit statement a root cause analysis can be used to detect threats or opportunities. &lt;ref name=&quot;PMIGuide&quot;/&gt;<br /> <br /> === Assumption and constraint analysis ===<br /> <br /> This is an analysis of the projects and project management plans underlining assumption and constraint. <br /> The assumptions, which the project has made, represent some unidentified risks. Analysing these assumptions will bring risk to light and assess their threat. <br /> 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. &lt;ref name=&quot;PMIGuide&quot;/&gt;<br /> <br /> === SWOT analysis ===<br /> <br /> SWOT is an analysis of the project and organizations strengths, weaknesses, opportunities and threats. It can be used to look at internally created risks for the project. It starts with an analysis of the company’s weaknesses and strengths. From this any threats or opportunities should be analyzed, as well as how the company’s weaknesses and strengths affects the given threats and opportunities. &lt;ref name=&quot;PMIGuide&quot;/&gt; &lt;ref name=&quot;std&quot;/&gt;<br /> <br /> <br /> === Risk breakdown structure === <br /> <br /> A risk breakdown structure is a hierarchical representation of risks. Meaning that it starts it that highest level and then moves down into more detailed levels. The RBS is not unlike the Work Breakdown Structure, and it will help the manager create an overview of the risk categories. &lt;ref name=&quot;Prince2&quot;/&gt;&lt;ref name=&quot;RBS&quot;/&gt;<br /> <br /> = Output =<br /> <br /> The output from identifying risk is three folded: the risk register, the risk report, and updates of project documents. <br /> <br /> === Risk register === <br /> <br /> The risk register is, as the name may suggest, where all individual risks are registered. This includes a list of all risk found in the identification process. All risks are registered with unique names and/or numbers, as well as a description of the risk so that the information doesn’t get lost. &lt;ref name=&quot;Prince2&quot;/&gt;<br /> <br /> 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. &lt;ref name=&quot;std&quot;/&gt;<br /> <br /> <br /> 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. <br /> <br /> 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. &lt;ref name=&quot;PMIGuide&quot;/&gt;<br /> <br /> === Risk report ===<br /> <br /> The risk report includes the sources of overall project risk, as well as a summary of individual project risks. &lt;ref name=&quot;PMIGuide&quot;/&gt;<br /> <br /> === Project documents updates ===<br /> <br /> 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. &lt;ref name=&quot;PMIGuide&quot;/&gt;<br /> <br /> = Limitations =<br /> <br /> All risk to a project will not be identified at ones. Even if all risk could be identified, changes are some will be missed/undetected. This only enhances the importance of conducting a risk identification process throughout the project’s life cycle. &lt;ref name=&quot;std&quot;/&gt;<br /> <br /> One should also be aware of expert bias. It is quite common and can be a threat to the quality of the risk identification, as well as the response. &lt;ref name=&quot;PMIGuide&quot;/&gt;<br /> <br /> = Annotated bibliography =<br /> <br /> • Project Management: A guide to the Project Management Body of Knowledge (PMBOK guide), 6th Edition (2017).<br /> For risk identification, chapter 11 is a very good walkthrough of how to conduct a risk identification process. <br /> <br /> • Standard for Risk Management in Portfolios, Programs, and Projects<br /> A very good reference for all things risks in projects, portfolios, and programs. <br /> <br /> • Managing Successful Projects with PRINCE2 2017 Edition<br /> Chapter 10 looks into risk, and PRINCE2 standards for handling risk, as well as what risk are. <br /> <br /> = References = <br /> &lt;references&gt;<br /> &lt;ref name=&quot;PMIGuide&quot;&gt;Guide to the Project Management Body of Knowledge (PMBOK® Guide) (6th Edition), Project Management Institute (PMI), Inc.(2017)&lt;/ref&gt;<br /> &lt;ref name=&quot;Prince2&quot;&gt;Managing Successful Projects with PRINCE2 2017 Edition, AXELOS (2017)&lt;/ref&gt;<br /> &lt;ref name=&quot;std&quot;&gt;Standard for Risk Management in Portfolios, Programs, and Projects, Project Management Institute, Inc. (PMI)<br /> (2019)&lt;/ref&gt;<br /> &lt;ref name=&quot;RBS&quot;&gt;Understanding the Risk Breakdown Structure (RBS), Internet article, 12/10/2018,( https://project-management.com/understanding-the-risk-breakdown-structure-rbs/),&lt;/ref&gt;</div>

ChristofferFriis http://13.50.150.85/index.php?title=Identifying_risk&diff=101310 2021-02-28T21:55:50Z

<p>ChristofferFriis: </p> <hr /> <div>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. <br /> When a 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. <br /> When identifying risk, the step that you go through is create input, applying tools and techniques, and finally getting output. <br /> Creating input is essential for management to identifying the risks. Examples of what the input consist of: project management plan, project documents, and more.<br /> After creating input, certain tools can be used to identify the risks. An in-depth look into a selection of these tools can be found on this site, like: Expert judgement, data gathering, and data analysis. <br /> The last part is the output. The output is 3 folded; 1. Risk register. 2. Risk report. 3. Project documents updates. <br /> <br /> The 3 parts of identifying risks (input, tools &amp; output) will be descried in greater details. &lt;ref name=&quot;PMIGuide&quot;/&gt;&lt;ref name=&quot;std&quot;/&gt;&lt;ref name=&quot;Prince2&quot;/&gt;<br /> <br /> <br /> = Big idea = <br /> <br /> Identifying risk is a never-ending job for a project and should be treated as such. By not only identifying the risks at the beginning of the project, but throughout the project’s life cycle. Some risk will inevitably be overseen when first preforming the risk identification and new risk will arise. Therefore, this process needs to be repeated. &lt;ref name=&quot;PMIGuide&quot;/&gt;&lt;ref name=&quot;std&quot;/&gt;<br /> &lt;ref name=&quot;Prince2&quot;/&gt; <br /> <br /> When identifying risks, we seek to identify both individual projects risks and sources of overall project risk. When concluding this process, we should end 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 existing document to reflect new knowledge found. &lt;ref name=&quot;PMIGuide&quot;/&gt;<br /> <br /> To produce this output there must first be some input to work with. This is input like a project management plan, project document, and so on. The input is the first thing that must be in place. When it is, it enables us to use some given tools and techniques to identify the risks. These tools are not limited to the ones described on this page, but the ones highlighted are some good tools to use. &lt;ref name=&quot;PMIGuide&quot;/&gt;<br /> <br /> 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 participate in this process are: &lt;ref name=&quot;Prince2&quot;/&gt;<br /> &lt;ref name=&quot;PMIGuide&quot;/&gt;<br /> <br /> - Project manager <br /> <br /> - Project team <br /> <br /> - Risk specialist<br /> <br /> - Customers and end users <br /> <br /> - External subject experts <br /> <br /> - Relevant stakeholders<br /> <br /> - Internal risk management expert <br /> <br /> <br /> = Input =<br /> <br /> When talking input for risk identification we are talking about all documents and knowledge developed beforehand, that enables us to identify any risks. These are output from task/processes which were carried out prior to the risk identification. Hence, laying the groundwork to the actual risk identification. &lt;ref name=&quot;PMIGuide&quot;/&gt;<br /> <br /> Some examples of input needed are: <br /> <br /> • Project management plan <br /> <br /> • Project Documents <br /> <br /> • Agreements <br /> <br /> • Procurement documentation <br /> <br /> • Enterprise environmental factors <br /> <br /> • Organisational process assets<br /> <br /> <br /> === Project management plan ===<br /> The project management plan include knowledge from underlining components. These components include: <br /> <br /> • Requirements management plan<br /> <br /> • Schedule management plan <br /> <br /> • Cost management plan <br /> <br /> • Quality Management plan <br /> <br /> • Resource management plan <br /> <br /> • Risk management plan<br /> <br /> • Scope baseline<br /> <br /> • Schedule baseline <br /> <br /> • Cost baseline<br /> <br /> Other relevant Management plans, Baselines, or relevant documents can be included in the project management plan. &lt;ref name=&quot;PMIGuide&quot;/&gt;<br /> <br /> === Project Documents ===<br /> <br /> Some project documents can be included as input in the risk identification. Examples of these are: &lt;ref name=&quot;PMIGuide&quot;/&gt;<br /> <br /> • Assumption log<br /> <br /> • Cost estimates<br /> <br /> • Duration estimates <br /> <br /> • Issue log<br /> <br /> • Lessons learned register <br /> <br /> • Requirements documentation. <br /> <br /> • Resource requirements <br /> <br /> • Stakeholder register<br /> <br /> === Agreements ===<br /> There might be some agreement/contract with some external partner/stakeholders. The information in such an agreement may present both risks and opportunities for the project. Information in the agreement may include, but are not limited to, milestones dates, acceptance criteria, awards and penalties. &lt;ref name=&quot;PMIGuide&quot;/&gt;<br /> <br /> === Procurement documentation ===<br /> <br /> 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 therefore be reviewed for potential risks. &lt;ref name=&quot;PMIGuide&quot;/&gt;<br /> <br /> = Tools = <br /> <br /> From the generated and gathered input, the management team have a variety of tools in the toolbox, that will help them identify the risks. &lt;ref name=&quot;PMIGuide&quot;/&gt;<br /> <br /> Examples of such tools are: <br /> • Expert judgment <br /> <br /> • Data gathering (Brainstorming, Checklists, Interviews) <br /> <br /> • Root cause analysis <br /> <br /> • Assumption and constraint analysis <br /> <br /> • SWOT analysis <br /> <br /> • Risk breakdown structure <br /> <br /> • Document analysis<br /> <br /> • Interpersonal and team skills<br /> <br /> • Prompt lists <br /> <br /> • Meetings <br /> <br /> == Expert judgement == <br /> <br /> The project manager should identify individuals or groups that could act as experts when identifying projects risks and the source of these risks. The expert should both consider specific risk and overall project risks. <br /> <br /> 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. &lt;ref name=&quot;PMIGuide&quot;/&gt;<br /> <br /> == Data gathering == <br /> <br /> There are multiple techniques to gather data related to risk. Here there are highlighted some, which are widely used<br /> <br /> === Brainstorming ===<br /> <br /> In a brainstorm the goal is to 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. <br /> <br /> 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. &lt;ref name=&quot;PMIGuide&quot;/&gt;<br /> <br /> === Checklist ===<br /> <br /> 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. &lt;ref name=&quot;std&quot;/&gt;<br /> <br /> The checklist is a good way for a company to transfer knowledge and learnings from project to project. <br /> However, this should not be seen as a reason not to carrier out a risk identification throughout the project life cycle. The checklist may not identify all risks, and other risks must also be explored. &lt;ref name=&quot;PMIGuide&quot;/&gt;<br /> <br /> === Interviews ===<br /> <br /> 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.). <br /> 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 a trusting and open environment to ensure the right information is extracted. &lt;ref name=&quot;PMIGuide&quot;/&gt;<br /> <br /> <br /> === Root cause analysis ===<br /> <br /> 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 underlining risk will also be solved. <br /> By stating a problem/benefit statement a root cause analysis can be used to detect threats or opportunities. &lt;ref name=&quot;PMIGuide&quot;/&gt;<br /> <br /> === Assumption and constraint analysis ===<br /> <br /> This is an analysis of the projects and project management plans underlining assumption and constraint. <br /> The assumptions, which the project has made, represent some unidentified risks. Analysing these assumptions will bring risk to light and assess their threat. <br /> 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. &lt;ref name=&quot;PMIGuide&quot;/&gt;<br /> <br /> === SWOT analysis ===<br /> <br /> SWOT is an analysis of the project and organizations strengths, weaknesses, opportunities and threats. It can be used to look at internally created risks for the project. It starts with an analysis of the company’s weaknesses and strengths. From this any threats or opportunities should be analyzed, as well as how the company’s weaknesses and strengths affects the given threats and opportunities. &lt;ref name=&quot;PMIGuide&quot;/&gt; &lt;ref name=&quot;std&quot;/&gt;<br /> <br /> <br /> === Risk breakdown structure === <br /> <br /> A risk breakdown structure is a hierarchical representation of risks. Meaning that it starts it that highest level and then moves down into more detailed levels. The RBS is not unlike the Work Breakdown Structure, and it will help the manager create an overview of the risk categories. &lt;ref name=&quot;Prince2&quot;/&gt;&lt;ref name=&quot;RBS&quot;/&gt;<br /> <br /> = Output =<br /> <br /> The output from identifying risk is three folded: the risk register, the risk report, and updates of project documents. <br /> <br /> == Risk register == <br /> <br /> The risk register is, as the name may suggest, where all individual risks are registered. This includes a list of all risk found in the identification process. All risks are registered with unique names and/or numbers, as well as a description of the risk so that the information doesn’t get lost. &lt;ref name=&quot;Prince2&quot;/&gt;<br /> <br /> 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. &lt;ref name=&quot;std&quot;/&gt;<br /> <br /> <br /> 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. <br /> <br /> 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. &lt;ref name=&quot;PMIGuide&quot;/&gt;<br /> <br /> == Risk report == <br /> <br /> The risk report includes the sources of overall project risk, as well as a summary of individual project risks. &lt;ref name=&quot;PMIGuide&quot;/&gt;<br /> <br /> == Project documents updates == <br /> <br /> 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. &lt;ref name=&quot;PMIGuide&quot;/&gt;<br /> <br /> = Limitations =<br /> <br /> All risk to a project will not be identified at ones. Even if all risk could be identified, changes are some will be missed/undetected. This only enhances the importance of conducting a risk identification process throughout the project’s life cycle. &lt;ref name=&quot;std&quot;/&gt;<br /> <br /> One should also be aware of expert bias. It is quite common and can be a threat to the quality of the risk identification, as well as the response. &lt;ref name=&quot;PMIGuide&quot;/&gt;<br /> <br /> = Annotated bibliography =<br /> <br /> • Project Management: A guide to the Project Management Body of Knowledge (PMBOK guide), 6th Edition (2017).<br /> For risk identification, chapter 11 is a very good walkthrough of how to conduct a risk identification process. <br /> <br /> • Standard for Risk Management in Portfolios, Programs, and Projects<br /> A very good reference for all things risks in projects, portfolios, and programs. <br /> <br /> • Managing Successful Projects with PRINCE2 2017 Edition<br /> Chapter 10 looks into risk, and PRINCE2 standards for handling risk, as well as what risk are. <br /> <br /> = References = <br /> &lt;references&gt;<br /> &lt;ref name=&quot;PMIGuide&quot;&gt;Guide to the Project Management Body of Knowledge (PMBOK® Guide) (6th Edition), Project Management Institute (PMI), Inc.(2017)&lt;/ref&gt;<br /> &lt;ref name=&quot;Prince2&quot;&gt;Managing Successful Projects with PRINCE2 2017 Edition, AXELOS (2017)&lt;/ref&gt;<br /> &lt;ref name=&quot;std&quot;&gt;Standard for Risk Management in Portfolios, Programs, and Projects, Project Management Institute, Inc. (PMI)<br /> (2019)&lt;/ref&gt;<br /> &lt;ref name=&quot;RBS&quot;&gt;Understanding the Risk Breakdown Structure (RBS), Internet article, 12/10/2018,( https://project-management.com/understanding-the-risk-breakdown-structure-rbs/),&lt;/ref&gt;</div>

ChristofferFriis http://13.50.150.85/index.php?title=Identifying_risk&diff=101304 2021-02-28T21:55:20Z

<p>ChristofferFriis: </p> <hr /> <div>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. <br /> When a 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. <br /> When identifying risk, the step that you go through is create input, applying tools and techniques, and finally getting output. <br /> Creating input is essential for management to identifying the risks. Examples of what the input consist of: project management plan, project documents, and more.<br /> After creating input, certain tools can be used to identify the risks. An in-depth look into a selection of these tools can be found on this site, like: Expert judgement, data gathering, and data analysis. <br /> The last part is the output. The output is 3 folded; 1. Risk register. 2. Risk report. 3. Project documents updates. <br /> <br /> The 3 parts of identifying risks (input, tools &amp; output) will be descried in greater details. &lt;ref name=&quot;PMIGuide&quot;/&gt;&lt;ref name=&quot;std&quot;/&gt;<br /> <br /> <br /> = Big idea = <br /> <br /> Identifying risk is a never-ending job for a project and should be treated as such. By not only identifying the risks at the beginning of the project, but throughout the project’s life cycle. Some risk will inevitably be overseen when first preforming the risk identification and new risk will arise. Therefore, this process needs to be repeated. &lt;ref name=&quot;PMIGuide&quot;/&gt;&lt;ref name=&quot;std&quot;/&gt;<br /> &lt;ref name=&quot;Prince2&quot;/&gt; <br /> <br /> When identifying risks, we seek to identify both individual projects risks and sources of overall project risk. When concluding this process, we should end 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 existing document to reflect new knowledge found. &lt;ref name=&quot;PMIGuide&quot;/&gt;<br /> <br /> To produce this output there must first be some input to work with. This is input like a project management plan, project document, and so on. The input is the first thing that must be in place. When it is, it enables us to use some given tools and techniques to identify the risks. These tools are not limited to the ones described on this page, but the ones highlighted are some good tools to use. &lt;ref name=&quot;PMIGuide&quot;/&gt;<br /> <br /> 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 participate in this process are: &lt;ref name=&quot;Prince2&quot;/&gt;<br /> &lt;ref name=&quot;PMIGuide&quot;/&gt;<br /> <br /> - Project manager <br /> <br /> - Project team <br /> <br /> - Risk specialist<br /> <br /> - Customers and end users <br /> <br /> - External subject experts <br /> <br /> - Relevant stakeholders<br /> <br /> - Internal risk management expert <br /> <br /> <br /> = Input =<br /> <br /> When talking input for risk identification we are talking about all documents and knowledge developed beforehand, that enables us to identify any risks. These are output from task/processes which were carried out prior to the risk identification. Hence, laying the groundwork to the actual risk identification. &lt;ref name=&quot;PMIGuide&quot;/&gt;<br /> <br /> Some examples of input needed are: <br /> <br /> • Project management plan <br /> <br /> • Project Documents <br /> <br /> • Agreements <br /> <br /> • Procurement documentation <br /> <br /> • Enterprise environmental factors <br /> <br /> • Organisational process assets<br /> <br /> <br /> === Project management plan ===<br /> The project management plan include knowledge from underlining components. These components include: <br /> <br /> • Requirements management plan<br /> <br /> • Schedule management plan <br /> <br /> • Cost management plan <br /> <br /> • Quality Management plan <br /> <br /> • Resource management plan <br /> <br /> • Risk management plan<br /> <br /> • Scope baseline<br /> <br /> • Schedule baseline <br /> <br /> • Cost baseline<br /> <br /> Other relevant Management plans, Baselines, or relevant documents can be included in the project management plan. &lt;ref name=&quot;PMIGuide&quot;/&gt;<br /> <br /> === Project Documents ===<br /> <br /> Some project documents can be included as input in the risk identification. Examples of these are: &lt;ref name=&quot;PMIGuide&quot;/&gt;<br /> <br /> • Assumption log<br /> <br /> • Cost estimates<br /> <br /> • Duration estimates <br /> <br /> • Issue log<br /> <br /> • Lessons learned register <br /> <br /> • Requirements documentation. <br /> <br /> • Resource requirements <br /> <br /> • Stakeholder register<br /> <br /> === Agreements ===<br /> There might be some agreement/contract with some external partner/stakeholders. The information in such an agreement may present both risks and opportunities for the project. Information in the agreement may include, but are not limited to, milestones dates, acceptance criteria, awards and penalties. &lt;ref name=&quot;PMIGuide&quot;/&gt;<br /> <br /> === Procurement documentation ===<br /> <br /> 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 therefore be reviewed for potential risks. &lt;ref name=&quot;PMIGuide&quot;/&gt;<br /> <br /> = Tools = <br /> <br /> From the generated and gathered input, the management team have a variety of tools in the toolbox, that will help them identify the risks. &lt;ref name=&quot;PMIGuide&quot;/&gt;<br /> <br /> Examples of such tools are: <br /> • Expert judgment <br /> <br /> • Data gathering (Brainstorming, Checklists, Interviews) <br /> <br /> • Root cause analysis <br /> <br /> • Assumption and constraint analysis <br /> <br /> • SWOT analysis <br /> <br /> • Risk breakdown structure <br /> <br /> • Document analysis<br /> <br /> • Interpersonal and team skills<br /> <br /> • Prompt lists <br /> <br /> • Meetings <br /> <br /> == Expert judgement == <br /> <br /> The project manager should identify individuals or groups that could act as experts when identifying projects risks and the source of these risks. The expert should both consider specific risk and overall project risks. <br /> <br /> 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. &lt;ref name=&quot;PMIGuide&quot;/&gt;<br /> <br /> == Data gathering == <br /> <br /> There are multiple techniques to gather data related to risk. Here there are highlighted some, which are widely used<br /> <br /> === Brainstorming ===<br /> <br /> In a brainstorm the goal is to 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. <br /> <br /> 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. &lt;ref name=&quot;PMIGuide&quot;/&gt;<br /> <br /> === Checklist ===<br /> <br /> 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. &lt;ref name=&quot;std&quot;/&gt;<br /> <br /> The checklist is a good way for a company to transfer knowledge and learnings from project to project. <br /> However, this should not be seen as a reason not to carrier out a risk identification throughout the project life cycle. The checklist may not identify all risks, and other risks must also be explored. &lt;ref name=&quot;PMIGuide&quot;/&gt;<br /> <br /> === Interviews ===<br /> <br /> 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.). <br /> 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 a trusting and open environment to ensure the right information is extracted. &lt;ref name=&quot;PMIGuide&quot;/&gt;<br /> <br /> <br /> === Root cause analysis ===<br /> <br /> 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 underlining risk will also be solved. <br /> By stating a problem/benefit statement a root cause analysis can be used to detect threats or opportunities. &lt;ref name=&quot;PMIGuide&quot;/&gt;<br /> <br /> === Assumption and constraint analysis ===<br /> <br /> This is an analysis of the projects and project management plans underlining assumption and constraint. <br /> The assumptions, which the project has made, represent some unidentified risks. Analysing these assumptions will bring risk to light and assess their threat. <br /> 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. &lt;ref name=&quot;PMIGuide&quot;/&gt;<br /> <br /> === SWOT analysis ===<br /> <br /> SWOT is an analysis of the project and organizations strengths, weaknesses, opportunities and threats. It can be used to look at internally created risks for the project. It starts with an analysis of the company’s weaknesses and strengths. From this any threats or opportunities should be analyzed, as well as how the company’s weaknesses and strengths affects the given threats and opportunities. &lt;ref name=&quot;PMIGuide&quot;/&gt; &lt;ref name=&quot;std&quot;/&gt;<br /> <br /> <br /> === Risk breakdown structure === <br /> <br /> A risk breakdown structure is a hierarchical representation of risks. Meaning that it starts it that highest level and then moves down into more detailed levels. The RBS is not unlike the Work Breakdown Structure, and it will help the manager create an overview of the risk categories. &lt;ref name=&quot;Prince2&quot;/&gt;&lt;ref name=&quot;RBS&quot;/&gt;<br /> <br /> = Output =<br /> <br /> The output from identifying risk is three folded: the risk register, the risk report, and updates of project documents. <br /> <br /> == Risk register == <br /> <br /> The risk register is, as the name may suggest, where all individual risks are registered. This includes a list of all risk found in the identification process. All risks are registered with unique names and/or numbers, as well as a description of the risk so that the information doesn’t get lost. &lt;ref name=&quot;Prince2&quot;/&gt;<br /> <br /> 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. &lt;ref name=&quot;std&quot;/&gt;<br /> <br /> <br /> 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. <br /> <br /> 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. &lt;ref name=&quot;PMIGuide&quot;/&gt;<br /> <br /> == Risk report == <br /> <br /> The risk report includes the sources of overall project risk, as well as a summary of individual project risks. &lt;ref name=&quot;PMIGuide&quot;/&gt;<br /> <br /> == Project documents updates == <br /> <br /> 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. &lt;ref name=&quot;PMIGuide&quot;/&gt;<br /> <br /> = Limitations =<br /> <br /> All risk to a project will not be identified at ones. Even if all risk could be identified, changes are some will be missed/undetected. This only enhances the importance of conducting a risk identification process throughout the project’s life cycle. &lt;ref name=&quot;std&quot;/&gt;<br /> <br /> One should also be aware of expert bias. It is quite common and can be a threat to the quality of the risk identification, as well as the response. &lt;ref name=&quot;PMIGuide&quot;/&gt;<br /> <br /> = Annotated bibliography =<br /> <br /> • Project Management: A guide to the Project Management Body of Knowledge (PMBOK guide), 6th Edition (2017).<br /> For risk identification, chapter 11 is a very good walkthrough of how to conduct a risk identification process. <br /> <br /> • Standard for Risk Management in Portfolios, Programs, and Projects<br /> A very good reference for all things risks in projects, portfolios, and programs. <br /> <br /> • Managing Successful Projects with PRINCE2 2017 Edition<br /> Chapter 10 looks into risk, and PRINCE2 standards for handling risk, as well as what risk are. <br /> <br /> = References = <br /> &lt;references&gt;<br /> &lt;ref name=&quot;PMIGuide&quot;&gt;Guide to the Project Management Body of Knowledge (PMBOK® Guide) (6th Edition), Project Management Institute (PMI), Inc.(2017)&lt;/ref&gt;<br /> &lt;ref name=&quot;Prince2&quot;&gt;Managing Successful Projects with PRINCE2 2017 Edition, AXELOS (2017)&lt;/ref&gt;<br /> &lt;ref name=&quot;std&quot;&gt;Standard for Risk Management in Portfolios, Programs, and Projects, Project Management Institute, Inc. (PMI)<br /> (2019)&lt;/ref&gt;<br /> &lt;ref name=&quot;RBS&quot;&gt;Understanding the Risk Breakdown Structure (RBS), Internet article, 12/10/2018,( https://project-management.com/understanding-the-risk-breakdown-structure-rbs/),&lt;/ref&gt;</div>

ChristofferFriis http://13.50.150.85/index.php?title=Identifying_risk&diff=101294 2021-02-28T21:54:46Z

<p>ChristofferFriis: </p> <hr /> <div>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. <br /> When a 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. <br /> When identifying risk, the step that you go through is create input, applying tools and techniques, and finally getting output. <br /> Creating input is essential for management to identifying the risks. Examples of what the input consist of: project management plan, project documents, and more.<br /> After creating input, certain tools can be used to identify the risks. An in-depth look into a selection of these tools can be found on this site, like: Expert judgement, data gathering, and data analysis. <br /> The last part is the output. The output is 3 folded; 1. Risk register. 2. Risk report. 3. Project documents updates. <br /> <br /> The 3 parts of identifying risks (input, tools &amp; output) will be descried in greater details. &lt;ref name=&quot;PMIGuide&quot;/&gt;&lt;ref name=&quot;std&quot;/&gt;<br /> <br /> <br /> = Big idea = <br /> <br /> Identifying risk is a never-ending job for a project and should be treated as such. By not only identifying the risks at the beginning of the project, but throughout the project’s life cycle. Some risk will inevitably be overseen when first preforming the risk identification and new risk will arise. Therefore, this process needs to be repeated. &lt;ref name=&quot;PMIGuide&quot;/&gt;&lt;ref name=&quot;std&quot;/&gt;<br /> &lt;ref name=&quot;Prince2&quot;/&gt;<br /> <br /> <br /> When identifying risks, we seek to identify both individual projects risks and sources of overall project risk. When concluding this process, we should end 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 existing document to reflect new knowledge found. &lt;ref name=&quot;PMIGuide&quot;/&gt;<br /> <br /> To produce this output there must first be some input to work with. This is input like a project management plan, project document, and so on. The input is the first thing that must be in place. When it is, it enables us to use some given tools and techniques to identify the risks. These tools are not limited to the ones described on this page, but the ones highlighted are some good tools to use. &lt;ref name=&quot;PMIGuide&quot;/&gt;<br /> <br /> 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 participate in this process are: &lt;ref name=&quot;Prince2&quot;/&gt;<br /> &lt;ref name=&quot;PMIGuide&quot;/&gt;<br /> <br /> - Project manager <br /> <br /> - Project team <br /> <br /> - Risk specialist<br /> <br /> - Customers and end users <br /> <br /> - External subject experts <br /> <br /> - Relevant stakeholders<br /> <br /> - Internal risk management expert <br /> <br /> <br /> = Input =<br /> <br /> When talking input for risk identification we are talking about all documents and knowledge developed beforehand, that enables us to identify any risks. These are output from task/processes which were carried out prior to the risk identification. Hence, laying the groundwork to the actual risk identification. &lt;ref name=&quot;PMIGuide&quot;/&gt;<br /> <br /> Some examples of input needed are: <br /> <br /> • Project management plan <br /> <br /> • Project Documents <br /> <br /> • Agreements <br /> <br /> • Procurement documentation <br /> <br /> • Enterprise environmental factors <br /> <br /> • Organisational process assets<br /> <br /> <br /> === Project management plan ===<br /> The project management plan include knowledge from underlining components. These components include: <br /> <br /> • Requirements management plan<br /> <br /> • Schedule management plan <br /> <br /> • Cost management plan <br /> <br /> • Quality Management plan <br /> <br /> • Resource management plan <br /> <br /> • Risk management plan<br /> <br /> • Scope baseline<br /> <br /> • Schedule baseline <br /> <br /> • Cost baseline<br /> <br /> Other relevant Management plans, Baselines, or relevant documents can be included in the project management plan. &lt;ref name=&quot;PMIGuide&quot;/&gt;<br /> <br /> === Project Documents ===<br /> <br /> Some project documents can be included as input in the risk identification. Examples of these are: &lt;ref name=&quot;PMIGuide&quot;/&gt;<br /> <br /> • Assumption log<br /> <br /> • Cost estimates<br /> <br /> • Duration estimates <br /> <br /> • Issue log<br /> <br /> • Lessons learned register <br /> <br /> • Requirements documentation. <br /> <br /> • Resource requirements <br /> <br /> • Stakeholder register<br /> <br /> === Agreements ===<br /> There might be some agreement/contract with some external partner/stakeholders. The information in such an agreement may present both risks and opportunities for the project. Information in the agreement may include, but are not limited to, milestones dates, acceptance criteria, awards and penalties. &lt;ref name=&quot;PMIGuide&quot;/&gt;<br /> <br /> === Procurement documentation ===<br /> <br /> 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 therefore be reviewed for potential risks. &lt;ref name=&quot;PMIGuide&quot;/&gt;<br /> <br /> = Tools = <br /> <br /> From the generated and gathered input, the management team have a variety of tools in the toolbox, that will help them identify the risks. &lt;ref name=&quot;PMIGuide&quot;/&gt;<br /> <br /> Examples of such tools are: <br /> • Expert judgment <br /> <br /> • Data gathering (Brainstorming, Checklists, Interviews) <br /> <br /> • Root cause analysis <br /> <br /> • Assumption and constraint analysis <br /> <br /> • SWOT analysis <br /> <br /> • Risk breakdown structure <br /> <br /> • Document analysis<br /> <br /> • Interpersonal and team skills<br /> <br /> • Prompt lists <br /> <br /> • Meetings <br /> <br /> == Expert judgement == <br /> <br /> The project manager should identify individuals or groups that could act as experts when identifying projects risks and the source of these risks. The expert should both consider specific risk and overall project risks. <br /> <br /> 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. &lt;ref name=&quot;PMIGuide&quot;/&gt;<br /> <br /> == Data gathering == <br /> <br /> There are multiple techniques to gather data related to risk. Here there are highlighted some, which are widely used<br /> <br /> === Brainstorming ===<br /> <br /> In a brainstorm the goal is to 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. <br /> <br /> 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. &lt;ref name=&quot;PMIGuide&quot;/&gt;<br /> <br /> === Checklist ===<br /> <br /> 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. &lt;ref name=&quot;std&quot;/&gt;<br /> <br /> The checklist is a good way for a company to transfer knowledge and learnings from project to project. <br /> However, this should not be seen as a reason not to carrier out a risk identification throughout the project life cycle. The checklist may not identify all risks, and other risks must also be explored. &lt;ref name=&quot;PMIGuide&quot;/&gt;<br /> <br /> === Interviews ===<br /> <br /> 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.). <br /> 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 a trusting and open environment to ensure the right information is extracted. &lt;ref name=&quot;PMIGuide&quot;/&gt;<br /> <br /> <br /> === Root cause analysis ===<br /> <br /> 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 underlining risk will also be solved. <br /> By stating a problem/benefit statement a root cause analysis can be used to detect threats or opportunities. &lt;ref name=&quot;PMIGuide&quot;/&gt;<br /> <br /> === Assumption and constraint analysis ===<br /> <br /> This is an analysis of the projects and project management plans underlining assumption and constraint. <br /> The assumptions, which the project has made, represent some unidentified risks. Analysing these assumptions will bring risk to light and assess their threat. <br /> 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. &lt;ref name=&quot;PMIGuide&quot;/&gt;<br /> <br /> === SWOT analysis ===<br /> <br /> SWOT is an analysis of the project and organizations strengths, weaknesses, opportunities and threats. It can be used to look at internally created risks for the project. It starts with an analysis of the company’s weaknesses and strengths. From this any threats or opportunities should be analyzed, as well as how the company’s weaknesses and strengths affects the given threats and opportunities. &lt;ref name=&quot;PMIGuide&quot;/&gt; &lt;ref name=&quot;std&quot;/&gt;<br /> <br /> <br /> === Risk breakdown structure === <br /> <br /> A risk breakdown structure is a hierarchical representation of risks. Meaning that it starts it that highest level and then moves down into more detailed levels. The RBS is not unlike the Work Breakdown Structure, and it will help the manager create an overview of the risk categories. &lt;ref name=&quot;Prince2&quot;/&gt;&lt;ref name=&quot;RBS&quot;/&gt;<br /> <br /> = Output =<br /> <br /> The output from identifying risk is three folded: the risk register, the risk report, and updates of project documents. <br /> <br /> == Risk register == <br /> <br /> The risk register is, as the name may suggest, where all individual risks are registered. This includes a list of all risk found in the identification process. All risks are registered with unique names and/or numbers, as well as a description of the risk so that the information doesn’t get lost. &lt;ref name=&quot;Prince2&quot;/&gt;<br /> <br /> 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. &lt;ref name=&quot;std&quot;/&gt;<br /> <br /> <br /> 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. <br /> <br /> 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. &lt;ref name=&quot;PMIGuide&quot;/&gt;<br /> <br /> == Risk report == <br /> <br /> The risk report includes the sources of overall project risk, as well as a summary of individual project risks. &lt;ref name=&quot;PMIGuide&quot;/&gt;<br /> <br /> == Project documents updates == <br /> <br /> 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. &lt;ref name=&quot;PMIGuide&quot;/&gt;<br /> <br /> = Limitations =<br /> <br /> All risk to a project will not be identified at ones. Even if all risk could be identified, changes are some will be missed/undetected. This only enhances the importance of conducting a risk identification process throughout the project’s life cycle. &lt;ref name=&quot;std&quot;/&gt;<br /> <br /> One should also be aware of expert bias. It is quite common and can be a threat to the quality of the risk identification, as well as the response. &lt;ref name=&quot;PMIGuide&quot;/&gt;<br /> <br /> = Annotated bibliography =<br /> <br /> • Project Management: A guide to the Project Management Body of Knowledge (PMBOK guide), 6th Edition (2017).<br /> For risk identification, chapter 11 is a very good walkthrough of how to conduct a risk identification process. <br /> <br /> • Standard for Risk Management in Portfolios, Programs, and Projects<br /> A very good reference for all things risks in projects, portfolios, and programs. <br /> <br /> • Managing Successful Projects with PRINCE2 2017 Edition<br /> Chapter 10 looks into risk, and PRINCE2 standards for handling risk, as well as what risk are. <br /> <br /> = References = <br /> &lt;references&gt;<br /> &lt;ref name=&quot;PMIGuide&quot;&gt;Guide to the Project Management Body of Knowledge (PMBOK® Guide) (6th Edition), Project Management Institute (PMI), Inc.(2017)&lt;/ref&gt;<br /> &lt;ref name=&quot;Prince2&quot;&gt;Managing Successful Projects with PRINCE2 2017 Edition, AXELOS (2017)&lt;/ref&gt;<br /> &lt;ref name=&quot;std&quot;&gt;Standard for Risk Management in Portfolios, Programs, and Projects, Project Management Institute, Inc. (PMI)<br /> (2019)&lt;/ref&gt;<br /> &lt;ref name=&quot;RBS&quot;&gt;Understanding the Risk Breakdown Structure (RBS), Internet article, 12/10/2018,( https://project-management.com/understanding-the-risk-breakdown-structure-rbs/),&lt;/ref&gt;</div>

ChristofferFriis http://13.50.150.85/index.php?title=Identifying_risk&diff=100729 2021-02-28T20:43:10Z

<p>ChristofferFriis: </p> <hr /> <div>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. <br /> 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. <br /> When identifying risk, the step that you go through is create input, applying tools and techniques, and finally getting output. <br /> 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.<br /> 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. <br /> The last part is the output. The output is 3 folded; 1. Risk register. 2. Risk report. 3. Project documents updates. <br /> <br /> The 3 parts of identifying risks (input, tools &amp; output) will be descried in greater details. &lt;ref name=&quot;PMIGuide&quot;/&gt;&lt;ref name=&quot;Prince2&quot;/&gt;<br /> <br /> = Big idea = <br /> <br /> 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. Risk will be overseen the first time around and new risk will accurse. Therefore, this process needs to be repeated. &lt;ref name=&quot;PMIGuide&quot;/&gt;(ref2) &lt;ref name=&quot;Prince2&quot;/&gt;<br /> <br /> <br /> 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. &lt;ref name=&quot;PMIGuide&quot;/&gt;<br /> <br /> To produce this output there must first be some input to work with. This is input like project management plan, project document, and so on. The input is the first thing that must be in place. When it is, it enables us to us some given tools and techniques to identify the risks. These tools are not limited to the ones described on this page, but the ones highlighted are some good tools to use. &lt;ref name=&quot;PMIGuide&quot;/&gt;<br /> <br /> 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: &lt;ref name=&quot;Prince2&quot;/&gt;<br /> &lt;ref name=&quot;PMIGuide&quot;/&gt;<br /> <br /> - Project manager <br /> <br /> - Project team <br /> <br /> - Risk specialist<br /> <br /> - Customers and end users <br /> <br /> - External subject experts <br /> <br /> - Relevant stakeholders<br /> <br /> - Internal risk management expert <br /> <br /> <br /> = Input =<br /> <br /> 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. &lt;ref name=&quot;PMIGuide&quot;/&gt;<br /> <br /> Some examples of input needed are: <br /> <br /> • Project management plan <br /> <br /> • Project Documents <br /> <br /> • Agreements <br /> <br /> • Procurement documentation <br /> <br /> • Enterprise environmental factors <br /> <br /> • Organisational process assets<br /> <br /> <br /> === Project management plan ===<br /> The project management plan include knowledge from underlining components. These components include: <br /> <br /> • Requirements management plan<br /> <br /> • Schedule management plan <br /> <br /> • Cost management plan <br /> <br /> • Quality Management plan <br /> <br /> • Resource management plan <br /> <br /> • Risk management plan<br /> <br /> • Scope baseline<br /> <br /> • Schedule baseline <br /> <br /> • Cost baseline<br /> <br /> Other relevant Management plans, Baselines, or relevant documents can be included in the project management plan. &lt;ref name=&quot;PMIGuide&quot;/&gt;<br /> <br /> === Project Documents ===<br /> <br /> Some project documents can be included as input in the risk identification. Examples of these are: &lt;ref name=&quot;PMIGuide&quot;/&gt;<br /> <br /> • Assumption log<br /> <br /> • Cost estimates<br /> <br /> • Duration estimates <br /> <br /> • Issue log<br /> <br /> • Lessons learned register <br /> <br /> • Requirements documentation. <br /> <br /> • Resource requirements <br /> <br /> • Stakeholder register<br /> <br /> === Agreements ===<br /> 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. &lt;ref name=&quot;PMIGuide&quot;/&gt;<br /> <br /> === Procurement documentation ===<br /> <br /> 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. &lt;ref name=&quot;PMIGuide&quot;/&gt;<br /> <br /> = Tools = <br /> <br /> From the generated and gathered input, the management team have a variety of tools in the toolbox, that will help them identify the risks. &lt;ref name=&quot;PMIGuide&quot;/&gt;<br /> <br /> Examples of such tools are: <br /> • Expert judgment <br /> <br /> • Data gathering (Brainstorming, Checklists, Interviews) <br /> <br /> • Root cause analysis <br /> <br /> • Assumption and constraint analysis <br /> <br /> • SWOT analysis <br /> <br /> • Risk breakdown structure <br /> <br /> • Document analysis<br /> <br /> • Interpersonal and team skills<br /> <br /> • Prompt lists <br /> <br /> • Meetings <br /> <br /> == Expert judgement == <br /> <br /> 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. <br /> <br /> 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. &lt;ref name=&quot;PMIGuide&quot;/&gt;<br /> <br /> == Data gathering == <br /> <br /> There are multiple techniques to gather data related to risk. Here there are highlighted some, which are widely used<br /> <br /> === Brainstorming ===<br /> <br /> 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. <br /> <br /> 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. &lt;ref name=&quot;PMIGuide&quot;/&gt;<br /> <br /> === Checklist ===<br /> <br /> 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. (ref2)<br /> The checklist is a good way for a company to transfer knowledge and learnings from project to project. <br /> However, this should not be seen as a reason to not carrier out a risk identification. Other risk should also be explored. &lt;ref name=&quot;PMIGuide&quot;/&gt;<br /> <br /> === Interviews ===<br /> <br /> 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.). <br /> 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. &lt;ref name=&quot;PMIGuide&quot;/&gt;<br /> <br /> <br /> === Root cause analysis ===<br /> <br /> 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. <br /> By stating a problem/benefit statement a root cause analysis can be used to detect threats or opportunities. &lt;ref name=&quot;PMIGuide&quot;/&gt;<br /> <br /> === Assumption and constraint analysis ===<br /> <br /> This is an analysis of the projects and project management plans underlining assumption and constraint. <br /> The assumptions, which the project has made, represent some unidentified risks. Analysing these assumptions will bring risk to light and assess their threat. <br /> 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. &lt;ref name=&quot;PMIGuide&quot;/&gt;<br /> <br /> === SWOT analysis ===<br /> <br /> SWOT is an analysis of the project and organizations strengths, weaknesses, opportunities and treats. *** another source needed &lt;ref name=&quot;PMIGuide&quot;/&gt;<br /> <br /> === Risk breakdown structure === <br /> <br /> &lt;ref name=&quot;Prince2&quot;/&gt;<br /> <br /> = Output =<br /> <br /> The output from identifying risk is three folded: the risk register, the risk report, and updates of project documents. <br /> <br /> == Risk register == <br /> <br /> The risk register is, as the name may suggest, where all individual risks are registered. This includes a list of all risk fund in the identification process. All risks are registered with unique name, number, or similar, as well as a description of the risk so that the information don’t get lost. (ref2)<br /> 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. (ref2)<br /> <br /> 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. <br /> <br /> 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. &lt;ref name=&quot;PMIGuide&quot;/&gt;<br /> <br /> == Risk report == <br /> <br /> The risk report includes the sources of overall project risk, as well as a summary of individual project risks. &lt;ref name=&quot;PMIGuide&quot;/&gt;<br /> <br /> == Project documents updates == <br /> <br /> 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. &lt;ref name=&quot;PMIGuide&quot;/&gt;<br /> <br /> = Limitations =<br /> <br /> All risk to a project will not be identified at ones. Even if all risk could be identified, changes are some will be missed/undetected. (ref2)<br /> Expert bias &lt;ref name=&quot;PMIGuide&quot;/&gt;<br /> Big time use <br /> <br /> = Annotated bibliography =<br /> Key references:<br /> • Project Management: A guide to the Project Management Body of Knowledge (PMBOK guide), 6th Edition (2017)<br /> <br /> = References = <br /> &lt;references&gt;<br /> &lt;ref name=&quot;PMIGuide&quot;&gt;Guide to the Project Management Body of Knowledge (PMBOK® Guide) (6th Edition), Project Management Institute, Inc.(2017)&lt;/ref&gt;<br /> &lt;ref name=&quot;Prince2&quot;&gt;Managing Successful Projects with PRINCE2 2017 Edition, AXELOS (2017)&lt;/ref&gt;</div>

ChristofferFriis http://13.50.150.85/index.php?title=Identifying_risk&diff=100724 2021-02-28T20:42:44Z

<p>ChristofferFriis: </p> <hr /> <div>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. <br /> 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. <br /> When identifying risk, the step that you go through is create input, applying tools and techniques, and finally getting output. <br /> 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.<br /> 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. <br /> The last part is the output. The output is 3 folded; 1. Risk register. 2. Risk report. 3. Project documents updates. <br /> <br /> The 3 parts of identifying risks (input, tools &amp; output) will be descried in greater details. &lt;ref name=&quot;PMIGuide&quot;/&gt;<br /> <br /> = Big idea = <br /> <br /> 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. Risk will be overseen the first time around and new risk will accurse. Therefore, this process needs to be repeated. &lt;ref name=&quot;PMIGuide&quot;/&gt;(ref2) &lt;ref name=&quot;Prince2&quot;/&gt;<br /> <br /> <br /> 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. &lt;ref name=&quot;PMIGuide&quot;/&gt;<br /> <br /> To produce this output there must first be some input to work with. This is input like project management plan, project document, and so on. The input is the first thing that must be in place. When it is, it enables us to us some given tools and techniques to identify the risks. These tools are not limited to the ones described on this page, but the ones highlighted are some good tools to use. &lt;ref name=&quot;PMIGuide&quot;/&gt;<br /> <br /> 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: &lt;ref name=&quot;Prince2&quot;/&gt;<br /> &lt;ref name=&quot;PMIGuide&quot;/&gt;<br /> <br /> - Project manager <br /> <br /> - Project team <br /> <br /> - Risk specialist<br /> <br /> - Customers and end users <br /> <br /> - External subject experts <br /> <br /> - Relevant stakeholders<br /> <br /> - Internal risk management expert <br /> <br /> <br /> = Input =<br /> <br /> 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. &lt;ref name=&quot;PMIGuide&quot;/&gt;<br /> <br /> Some examples of input needed are: <br /> <br /> • Project management plan <br /> <br /> • Project Documents <br /> <br /> • Agreements <br /> <br /> • Procurement documentation <br /> <br /> • Enterprise environmental factors <br /> <br /> • Organisational process assets<br /> <br /> <br /> === Project management plan ===<br /> The project management plan include knowledge from underlining components. These components include: <br /> <br /> • Requirements management plan<br /> <br /> • Schedule management plan <br /> <br /> • Cost management plan <br /> <br /> • Quality Management plan <br /> <br /> • Resource management plan <br /> <br /> • Risk management plan<br /> <br /> • Scope baseline<br /> <br /> • Schedule baseline <br /> <br /> • Cost baseline<br /> <br /> Other relevant Management plans, Baselines, or relevant documents can be included in the project management plan. &lt;ref name=&quot;PMIGuide&quot;/&gt;<br /> <br /> === Project Documents ===<br /> <br /> Some project documents can be included as input in the risk identification. Examples of these are: &lt;ref name=&quot;PMIGuide&quot;/&gt;<br /> <br /> • Assumption log<br /> <br /> • Cost estimates<br /> <br /> • Duration estimates <br /> <br /> • Issue log<br /> <br /> • Lessons learned register <br /> <br /> • Requirements documentation. <br /> <br /> • Resource requirements <br /> <br /> • Stakeholder register<br /> <br /> === Agreements ===<br /> 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. &lt;ref name=&quot;PMIGuide&quot;/&gt;<br /> <br /> === Procurement documentation ===<br /> <br /> 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. &lt;ref name=&quot;PMIGuide&quot;/&gt;<br /> <br /> = Tools = <br /> <br /> From the generated and gathered input, the management team have a variety of tools in the toolbox, that will help them identify the risks. &lt;ref name=&quot;PMIGuide&quot;/&gt;<br /> <br /> Examples of such tools are: <br /> • Expert judgment <br /> <br /> • Data gathering (Brainstorming, Checklists, Interviews) <br /> <br /> • Root cause analysis <br /> <br /> • Assumption and constraint analysis <br /> <br /> • SWOT analysis <br /> <br /> • Risk breakdown structure <br /> <br /> • Document analysis<br /> <br /> • Interpersonal and team skills<br /> <br /> • Prompt lists <br /> <br /> • Meetings <br /> <br /> == Expert judgement == <br /> <br /> 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. <br /> <br /> 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. &lt;ref name=&quot;PMIGuide&quot;/&gt;<br /> <br /> == Data gathering == <br /> <br /> There are multiple techniques to gather data related to risk. Here there are highlighted some, which are widely used<br /> <br /> === Brainstorming ===<br /> <br /> 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. <br /> <br /> 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. &lt;ref name=&quot;PMIGuide&quot;/&gt;<br /> <br /> === Checklist ===<br /> <br /> 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. (ref2)<br /> The checklist is a good way for a company to transfer knowledge and learnings from project to project. <br /> However, this should not be seen as a reason to not carrier out a risk identification. Other risk should also be explored. &lt;ref name=&quot;PMIGuide&quot;/&gt;<br /> <br /> === Interviews ===<br /> <br /> 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.). <br /> 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. &lt;ref name=&quot;PMIGuide&quot;/&gt;<br /> <br /> <br /> === Root cause analysis ===<br /> <br /> 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. <br /> By stating a problem/benefit statement a root cause analysis can be used to detect threats or opportunities. &lt;ref name=&quot;PMIGuide&quot;/&gt;<br /> <br /> === Assumption and constraint analysis ===<br /> <br /> This is an analysis of the projects and project management plans underlining assumption and constraint. <br /> The assumptions, which the project has made, represent some unidentified risks. Analysing these assumptions will bring risk to light and assess their threat. <br /> 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. &lt;ref name=&quot;PMIGuide&quot;/&gt;<br /> <br /> === SWOT analysis ===<br /> <br /> SWOT is an analysis of the project and organizations strengths, weaknesses, opportunities and treats. *** another source needed &lt;ref name=&quot;PMIGuide&quot;/&gt;<br /> <br /> === Risk breakdown structure === <br /> <br /> &lt;ref name=&quot;Prince2&quot;/&gt;<br /> <br /> = Output =<br /> <br /> The output from identifying risk is three folded: the risk register, the risk report, and updates of project documents. <br /> <br /> == Risk register == <br /> <br /> The risk register is, as the name may suggest, where all individual risks are registered. This includes a list of all risk fund in the identification process. All risks are registered with unique name, number, or similar, as well as a description of the risk so that the information don’t get lost. (ref2)<br /> 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. (ref2)<br /> <br /> 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. <br /> <br /> 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. &lt;ref name=&quot;PMIGuide&quot;/&gt;<br /> <br /> == Risk report == <br /> <br /> The risk report includes the sources of overall project risk, as well as a summary of individual project risks. &lt;ref name=&quot;PMIGuide&quot;/&gt;<br /> <br /> == Project documents updates == <br /> <br /> 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. &lt;ref name=&quot;PMIGuide&quot;/&gt;<br /> <br /> = Limitations =<br /> <br /> All risk to a project will not be identified at ones. Even if all risk could be identified, changes are some will be missed/undetected. (ref2)<br /> Expert bias &lt;ref name=&quot;PMIGuide&quot;/&gt;<br /> Big time use <br /> <br /> = Annotated bibliography =<br /> Key references:<br /> • Project Management: A guide to the Project Management Body of Knowledge (PMBOK guide), 6th Edition (2017)<br /> <br /> = References = <br /> &lt;references&gt;<br /> &lt;ref name=&quot;PMIGuide&quot;&gt;Guide to the Project Management Body of Knowledge (PMBOK® Guide) (6th Edition), Project Management Institute, Inc.(2017)&lt;/ref&gt;<br /> &lt;ref name=&quot;Prince2&quot;&gt;Managing Successful Projects with PRINCE2 2017 Edition, AXELOS (2017)&lt;/ref&gt;</div>

ChristofferFriis http://13.50.150.85/index.php?title=Identifying_risk&diff=100714 2021-02-28T20:41:16Z

<p>ChristofferFriis: </p> <hr /> <div>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. <br /> 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. <br /> When identifying risk, the step that you go through is create input, applying tools and techniques, and finally getting output. <br /> 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.<br /> 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. <br /> The last part is the output. The output is 3 folded; 1. Risk register. 2. Risk report. 3. Project documents updates. <br /> <br /> The 3 parts of identifying risks (input, tools &amp; output) will be descried in greater details. &lt;ref name=&quot;PMIGuide&quot;/&gt;<br /> <br /> = Big idea = <br /> <br /> 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. Risk will be overseen the first time around and new risk will accurse. Therefore, this process needs to be repeated. &lt;ref name=&quot;PMIGuide&quot;/&gt;(ref2)(ref3) <br /> <br /> 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. &lt;ref name=&quot;PMIGuide&quot;/&gt;<br /> <br /> To produce this output there must first be some input to work with. This is input like project management plan, project document, and so on. The input is the first thing that must be in place. When it is, it enables us to us some given tools and techniques to identify the risks. These tools are not limited to the ones described on this page, but the ones highlighted are some good tools to use. &lt;ref name=&quot;PMIGuide&quot;/&gt;<br /> <br /> 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: (ref3)&lt;ref name=&quot;PMIGuide&quot;/&gt;<br /> <br /> - Project manager <br /> <br /> - Project team <br /> <br /> - Risk specialist<br /> <br /> - Customers and end users <br /> <br /> - External subject experts <br /> <br /> - Relevant stakeholders<br /> <br /> - Internal risk management expert <br /> <br /> <br /> = Input =<br /> <br /> 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. &lt;ref name=&quot;PMIGuide&quot;/&gt;<br /> <br /> Some examples of input needed are: <br /> <br /> • Project management plan <br /> <br /> • Project Documents <br /> <br /> • Agreements <br /> <br /> • Procurement documentation <br /> <br /> • Enterprise environmental factors <br /> <br /> • Organisational process assets<br /> <br /> <br /> === Project management plan ===<br /> The project management plan include knowledge from underlining components. These components include: <br /> <br /> • Requirements management plan<br /> <br /> • Schedule management plan <br /> <br /> • Cost management plan <br /> <br /> • Quality Management plan <br /> <br /> • Resource management plan <br /> <br /> • Risk management plan<br /> <br /> • Scope baseline<br /> <br /> • Schedule baseline <br /> <br /> • Cost baseline<br /> <br /> Other relevant Management plans, Baselines, or relevant documents can be included in the project management plan. &lt;ref name=&quot;PMIGuide&quot;/&gt;<br /> <br /> === Project Documents ===<br /> <br /> Some project documents can be included as input in the risk identification. Examples of these are: &lt;ref name=&quot;PMIGuide&quot;/&gt;<br /> <br /> • Assumption log<br /> <br /> • Cost estimates<br /> <br /> • Duration estimates <br /> <br /> • Issue log<br /> <br /> • Lessons learned register <br /> <br /> • Requirements documentation. <br /> <br /> • Resource requirements <br /> <br /> • Stakeholder register<br /> <br /> === Agreements ===<br /> 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. &lt;ref name=&quot;PMIGuide&quot;/&gt;<br /> <br /> === Procurement documentation ===<br /> <br /> 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. &lt;ref name=&quot;PMIGuide&quot;/&gt;<br /> <br /> = Tools = <br /> <br /> From the generated and gathered input, the management team have a variety of tools in the toolbox, that will help them identify the risks. &lt;ref name=&quot;PMIGuide&quot;/&gt;<br /> <br /> Examples of such tools are: <br /> • Expert judgment <br /> <br /> • Data gathering (Brainstorming, Checklists, Interviews) <br /> <br /> • Root cause analysis <br /> <br /> • Assumption and constraint analysis <br /> <br /> • SWOT analysis <br /> <br /> • Risk breakdown structure <br /> <br /> • Document analysis<br /> <br /> • Interpersonal and team skills<br /> <br /> • Prompt lists <br /> <br /> • Meetings <br /> <br /> == Expert judgement == <br /> <br /> 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. <br /> <br /> 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. &lt;ref name=&quot;PMIGuide&quot;/&gt;<br /> <br /> == Data gathering == <br /> <br /> There are multiple techniques to gather data related to risk. Here there are highlighted some, which are widely used<br /> <br /> === Brainstorming ===<br /> <br /> 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. <br /> <br /> 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. &lt;ref name=&quot;PMIGuide&quot;/&gt;<br /> <br /> === Checklist ===<br /> <br /> 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. (ref2)<br /> The checklist is a good way for a company to transfer knowledge and learnings from project to project. <br /> However, this should not be seen as a reason to not carrier out a risk identification. Other risk should also be explored. &lt;ref name=&quot;PMIGuide&quot;/&gt;<br /> <br /> === Interviews ===<br /> <br /> 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.). <br /> 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. &lt;ref name=&quot;PMIGuide&quot;/&gt;<br /> <br /> <br /> === Root cause analysis ===<br /> <br /> 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. <br /> By stating a problem/benefit statement a root cause analysis can be used to detect threats or opportunities. &lt;ref name=&quot;PMIGuide&quot;/&gt;<br /> <br /> === Assumption and constraint analysis ===<br /> <br /> This is an analysis of the projects and project management plans underlining assumption and constraint. <br /> The assumptions, which the project has made, represent some unidentified risks. Analysing these assumptions will bring risk to light and assess their threat. <br /> 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. &lt;ref name=&quot;PMIGuide&quot;/&gt;<br /> <br /> === SWOT analysis ===<br /> <br /> SWOT is an analysis of the project and organizations strengths, weaknesses, opportunities and treats. *** another source needed &lt;ref name=&quot;PMIGuide&quot;/&gt;<br /> <br /> === Risk breakdown structure === <br /> <br /> (ref3)<br /> <br /> = Output =<br /> <br /> The output from identifying risk is three folded: the risk register, the risk report, and updates of project documents. <br /> <br /> == Risk register == <br /> <br /> The risk register is, as the name may suggest, where all individual risks are registered. This includes a list of all risk fund in the identification process. All risks are registered with unique name, number, or similar, as well as a description of the risk so that the information don’t get lost. (ref2)<br /> 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. (ref2)<br /> <br /> 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. <br /> <br /> 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. &lt;ref name=&quot;PMIGuide&quot;/&gt;<br /> <br /> == Risk report == <br /> <br /> The risk report includes the sources of overall project risk, as well as a summary of individual project risks. &lt;ref name=&quot;PMIGuide&quot;/&gt;<br /> <br /> == Project documents updates == <br /> <br /> 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. &lt;ref name=&quot;PMIGuide&quot;/&gt;<br /> <br /> = Limitations =<br /> <br /> All risk to a project will not be identified at ones. Even if all risk could be identified, changes are some will be missed/undetected. (ref2)<br /> Expert bias &lt;ref name=&quot;PMIGuide&quot;/&gt;<br /> Big time use <br /> <br /> = Annotated bibliography =<br /> Key references:<br /> • Project Management: A guide to the Project Management Body of Knowledge (PMBOK guide), 6th Edition (2017)<br /> <br /> = References = <br /> &lt;references&gt;<br /> &lt;ref name=&quot;PMIGuide&quot;&gt;Guide to the Project Management Body of Knowledge (PMBOK® Guide) (6th Edition), Project Management Institute, Inc.(2017)&lt;/ref&gt;<br /> &lt;ref name=&quot;Prince2&quot;&gt;Managing Successful Projects with PRINCE2 2017 Edition, AXELOS (2017)&lt;/ref&gt;</div>

ChristofferFriis http://13.50.150.85/index.php?title=Identifying_risk&diff=100698 2021-02-28T20:38:53Z

<p>ChristofferFriis: </p> <hr /> <div>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. <br /> 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. <br /> When identifying risk, the step that you go through is create input, applying tools and techniques, and finally getting output. <br /> 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.<br /> 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. <br /> The last part is the output. The output is 3 folded; 1. Risk register. 2. Risk report. 3. Project documents updates. <br /> <br /> The 3 parts of identifying risks (input, tools &amp; output) will be descried in greater details. &lt;ref name=&quot;PMIGuide&quot;/&gt;<br /> <br /> = Big idea = <br /> <br /> 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. Risk will be overseen the first time around and new risk will accurse. Therefore, this process needs to be repeated. &lt;ref name=&quot;PMIGuide&quot;/&gt;(ref2)(ref3) <br /> <br /> 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. &lt;ref name=&quot;PMIGuide&quot;/&gt;<br /> <br /> To produce this output there must first be some input to work with. This is input like project management plan, project document, and so on. The input is the first thing that must be in place. When it is, it enables us to us some given tools and techniques to identify the risks. These tools are not limited to the ones described on this page, but the ones highlighted are some good tools to use. &lt;ref name=&quot;PMIGuide&quot;/&gt;<br /> <br /> 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: (ref3)&lt;ref name=&quot;PMIGuide&quot;/&gt;<br /> <br /> - Project manager <br /> <br /> - Project team <br /> <br /> - Risk specialist<br /> <br /> - Customers and end users <br /> <br /> - External subject experts <br /> <br /> - Relevant stakeholders<br /> <br /> - Internal risk management expert <br /> <br /> <br /> = Input =<br /> <br /> 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. &lt;ref name=&quot;PMIGuide&quot;/&gt;<br /> <br /> Some examples of input needed are: <br /> <br /> • Project management plan <br /> <br /> • Project Documents <br /> <br /> • Agreements <br /> <br /> • Procurement documentation <br /> <br /> • Enterprise environmental factors <br /> <br /> • Organisational process assets<br /> <br /> <br /> === Project management plan ===<br /> The project management plan include knowledge from underlining components. These components include: <br /> <br /> • Requirements management plan<br /> <br /> • Schedule management plan <br /> <br /> • Cost management plan <br /> <br /> • Quality Management plan <br /> <br /> • Resource management plan <br /> <br /> • Risk management plan<br /> <br /> • Scope baseline<br /> <br /> • Schedule baseline <br /> <br /> • Cost baseline<br /> <br /> Other relevant Management plans, Baselines, or relevant documents can be included in the project management plan. &lt;ref name=&quot;PMIGuide&quot;/&gt;<br /> <br /> === Project Documents ===<br /> <br /> Some project documents can be included as input in the risk identification. Examples of these are: &lt;ref name=&quot;PMIGuide&quot;/&gt;<br /> <br /> • Assumption log<br /> <br /> • Cost estimates<br /> <br /> • Duration estimates <br /> <br /> • Issue log<br /> <br /> • Lessons learned register <br /> <br /> • Requirements documentation. <br /> <br /> • Resource requirements <br /> <br /> • Stakeholder register<br /> <br /> === Agreements ===<br /> 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. &lt;ref name=&quot;PMIGuide&quot;/&gt;<br /> <br /> === Procurement documentation ===<br /> <br /> 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. &lt;ref name=&quot;PMIGuide&quot;/&gt;<br /> <br /> = Tools = <br /> <br /> From the generated and gathered input, the management team have a variety of tools in the toolbox, that will help them identify the risks. &lt;ref name=&quot;PMIGuide&quot;/&gt;<br /> <br /> Examples of such tools are: <br /> • Expert judgment <br /> <br /> • Data gathering (Brainstorming, Checklists, Interviews) <br /> <br /> • Root cause analysis <br /> <br /> • Assumption and constraint analysis <br /> <br /> • SWOT analysis <br /> <br /> • Risk breakdown structure <br /> <br /> • Document analysis<br /> <br /> • Interpersonal and team skills<br /> <br /> • Prompt lists <br /> <br /> • Meetings <br /> <br /> == Expert judgement == <br /> <br /> 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. <br /> <br /> 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. &lt;ref name=&quot;PMIGuide&quot;/&gt;<br /> <br /> == Data gathering == <br /> <br /> There are multiple techniques to gather data related to risk. Here there are highlighted some, which are widely used<br /> <br /> === Brainstorming ===<br /> <br /> 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. <br /> <br /> 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. &lt;ref name=&quot;PMIGuide&quot;/&gt;<br /> <br /> === Checklist ===<br /> <br /> 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. (ref2)<br /> The checklist is a good way for a company to transfer knowledge and learnings from project to project. <br /> However, this should not be seen as a reason to not carrier out a risk identification. Other risk should also be explored. &lt;ref name=&quot;PMIGuide&quot;/&gt;<br /> <br /> === Interviews ===<br /> <br /> 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.). <br /> 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. &lt;ref name=&quot;PMIGuide&quot;/&gt;<br /> <br /> <br /> === Root cause analysis ===<br /> <br /> 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. <br /> By stating a problem/benefit statement a root cause analysis can be used to detect threats or opportunities. &lt;ref name=&quot;PMIGuide&quot;/&gt;<br /> <br /> === Assumption and constraint analysis ===<br /> <br /> This is an analysis of the projects and project management plans underlining assumption and constraint. <br /> The assumptions, which the project has made, represent some unidentified risks. Analysing these assumptions will bring risk to light and assess their threat. <br /> 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. &lt;ref name=&quot;PMIGuide&quot;/&gt;<br /> <br /> === SWOT analysis ===<br /> <br /> SWOT is an analysis of the project and organizations strengths, weaknesses, opportunities and treats. *** another source needed &lt;ref name=&quot;PMIGuide&quot;/&gt;<br /> <br /> === Risk breakdown structure === <br /> <br /> (ref3)<br /> <br /> = Output =<br /> <br /> The output from identifying risk is three folded: the risk register, the risk report, and updates of project documents. <br /> <br /> == Risk register == <br /> <br /> The risk register is, as the name may suggest, where all individual risks are registered. This includes a list of all risk fund in the identification process. All risks are registered with unique name, number, or similar, as well as a description of the risk so that the information don’t get lost. (ref2)<br /> 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. (ref2)<br /> <br /> 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. <br /> <br /> 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. &lt;ref name=&quot;PMIGuide&quot;/&gt;<br /> <br /> == Risk report == <br /> <br /> The risk report includes the sources of overall project risk, as well as a summary of individual project risks. &lt;ref name=&quot;PMIGuide&quot;/&gt;<br /> <br /> == Project documents updates == <br /> <br /> 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. &lt;ref name=&quot;PMIGuide&quot;/&gt;<br /> <br /> = Limitations =<br /> <br /> All risk to a project will not be identified at ones. Even if all risk could be identified, changes are some will be missed/undetected. (ref2)<br /> Expert bias &lt;ref name=&quot;PMIGuide&quot;/&gt;<br /> Big time use <br /> <br /> = Annotated bibliography =<br /> Key references:<br /> • Project Management: A guide to the Project Management Body of Knowledge (PMBOK guide), 6th Edition (2017)<br /> <br /> = References = <br /> &lt;references&gt;<br /> &lt;ref name=&quot;PMIGuide&quot;&gt;Guide to the Project Management Body of Knowledge (PMBOK® Guide) (6th Edition), Project Management Institute, Inc.(2017)&lt;/ref&gt;</div>

ChristofferFriis http://13.50.150.85/index.php?title=Identifying_risk&diff=100665 2021-02-28T20:36:26Z

<p>ChristofferFriis: </p> <hr /> <div>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. <br /> 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. <br /> When identifying risk, the step that you go through is create input, applying tools and techniques, and finally getting output. <br /> 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.<br /> 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. <br /> The last part is the output. The output is 3 folded; 1. Risk register. 2. Risk report. 3. Project documents updates. <br /> <br /> The 3 parts of identifying risks (input, tools &amp; output) will be descried in greater details. &lt;ref name=&quot;PMIGuide&quot;/&gt;<br /> <br /> = Big idea = <br /> <br /> 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. Risk will be overseen the first time around and new risk will accurse. Therefore, this process needs to be repeated. (ref2)(ref3) <br /> <br /> 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. <br /> <br /> To produce this output there must first be some input to work with. This is input like project management plan, project document, and so on. The input is the first thing that must be in place. When it is, it enables us to us some given tools and techniques to identify the risks. These tools are not limited to the ones described on this page, but the ones highlighted are some good tools to use. <br /> <br /> 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: (ref3)<br /> <br /> - Project manager <br /> <br /> - Project team <br /> <br /> - Risk specialist<br /> <br /> - Customers and end users <br /> <br /> - External subject experts <br /> <br /> - Relevant stakeholders<br /> <br /> - Internal risk management expert <br /> <br /> <br /> = Input =<br /> <br /> 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. <br /> <br /> Some examples of input needed are: <br /> <br /> • Project management plan <br /> <br /> • Project Documents <br /> <br /> • Agreements <br /> <br /> • Procurement documentation <br /> <br /> • Enterprise environmental factors <br /> <br /> • Organisational process assets<br /> <br /> <br /> === Project management plan ===<br /> The project management plan include knowledge from underlining components. These components include: <br /> <br /> • Requirements management plan<br /> <br /> • Schedule management plan <br /> <br /> • Cost management plan <br /> <br /> • Quality Management plan <br /> <br /> • Resource management plan <br /> <br /> • Risk management plan<br /> <br /> • Scope baseline<br /> <br /> • Schedule baseline <br /> <br /> • Cost baseline<br /> <br /> Other relevant Management plans, Baselines, or relevant documents can be included in the project management plan. <br /> <br /> === Project Documents ===<br /> <br /> Some project documents can be included as input in the risk identification. Examples of these are: <br /> <br /> • Assumption log<br /> <br /> • Cost estimates<br /> <br /> • Duration estimates <br /> <br /> • Issue log<br /> <br /> • Lessons learned register <br /> <br /> • Requirements documentation. <br /> <br /> • Resource requirements <br /> <br /> • Stakeholder register<br /> <br /> === Agreements ===<br /> 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. <br /> <br /> === Procurement documentation ===<br /> <br /> 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. <br /> <br /> = Tools = <br /> <br /> From the generated and gathered input, the management team have a variety of tools in the toolbox, that will help them identify the risks. <br /> <br /> Examples of such tools are: <br /> • Expert judgment <br /> <br /> • Data gathering (Brainstorming, Checklists, Interviews) <br /> <br /> • Root cause analysis <br /> <br /> • Assumption and constraint analysis <br /> <br /> • SWOT analysis <br /> <br /> • Risk breakdown structure <br /> <br /> • Document analysis<br /> <br /> • Interpersonal and team skills<br /> <br /> • Prompt lists <br /> <br /> • Meetings <br /> <br /> == Expert judgement == <br /> <br /> 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. <br /> <br /> 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. <br /> <br /> == Data gathering == <br /> <br /> There are multiple techniques to gather data related to risk. Here there are highlighted some, which are widely used<br /> <br /> === Brainstorming ===<br /> <br /> 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. <br /> <br /> 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. <br /> <br /> === Checklist ===<br /> <br /> 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. (ref2)<br /> The checklist is a good way for a company to transfer knowledge and learnings from project to project. <br /> However, this should not be seen as a reason to not carrier out a risk identification. Other risk should also be explored. <br /> <br /> === Interviews ===<br /> <br /> 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.). <br /> 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. <br /> <br /> <br /> === Root cause analysis ===<br /> <br /> 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. <br /> By stating a problem/benefit statement a root cause analysis can be used to detect threats or opportunities. <br /> <br /> === Assumption and constraint analysis ===<br /> <br /> This is an analysis of the projects and project management plans underlining assumption and constraint. <br /> The assumptions, which the project has made, represent some unidentified risks. Analysing these assumptions will bring risk to light and assess their threat. <br /> 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. <br /> <br /> === SWOT analysis ===<br /> <br /> SWOT is an analysis of the project and organizations strengths, weaknesses, opportunities and treats. *** another source needed <br /> <br /> === Risk breakdown structure === <br /> <br /> (ref3)<br /> <br /> = Output =<br /> <br /> The output from identifying risk is three folded: the risk register, the risk report, and updates of project documents. <br /> <br /> == Risk register == <br /> <br /> The risk register is, as the name may suggest, where all individual risks are registered. This includes a list of all risk fund in the identification process. All risks are registered with unique name, number, or similar, as well as a description of the risk so that the information don’t get lost. (ref2)<br /> 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. (ref2)<br /> <br /> 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. <br /> <br /> 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. <br /> <br /> == Risk report == <br /> <br /> The risk report includes the sources of overall project risk, as well as a summary of individual project risks. <br /> <br /> == Project documents updates == <br /> <br /> 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. <br /> <br /> = Limitations =<br /> <br /> All risk to a project will not be identified at ones. Even if all risk could be identified, changes are some will be missed/undetected. (ref2)<br /> Expert bias <br /> Big time use <br /> <br /> = Annotated bibliography =<br /> Key references:<br /> • Project Management: A guide to the Project Management Body of Knowledge (PMBOK guide), 6th Edition (2017)<br /> <br /> = References = <br /> &lt;references&gt;<br /> &lt;ref name=&quot;PMIGuide&quot;&gt;Guide to the Project Management Body of Knowledge (PMBOK® Guide) (6th Edition), Project Management Institute, Inc.(2017)&lt;/ref&gt;</div>

ChristofferFriis http://13.50.150.85/index.php?title=Identifying_risk&diff=100654 2021-02-28T20:35:38Z

<p>ChristofferFriis: </p> <hr /> <div>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. <br /> 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. <br /> When identifying risk, the step that you go through is create input, applying tools and techniques, and finally getting output. <br /> 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.<br /> 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. <br /> The last part is the output. The output is 3 folded; 1. Risk register. 2. Risk report. 3. Project documents updates. <br /> <br /> The 3 parts of identifying risks (input, tools &amp; output) will be descried in greater details. &lt;ref name=&quot;PMIGuide/&quot;&gt;<br /> <br /> = Big idea = <br /> <br /> 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. Risk will be overseen the first time around and new risk will accurse. Therefore, this process needs to be repeated. (ref2)(ref3) <br /> <br /> 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. <br /> <br /> To produce this output there must first be some input to work with. This is input like project management plan, project document, and so on. The input is the first thing that must be in place. When it is, it enables us to us some given tools and techniques to identify the risks. These tools are not limited to the ones described on this page, but the ones highlighted are some good tools to use. <br /> <br /> 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: (ref3)<br /> <br /> - Project manager <br /> <br /> - Project team <br /> <br /> - Risk specialist<br /> <br /> - Customers and end users <br /> <br /> - External subject experts <br /> <br /> - Relevant stakeholders<br /> <br /> - Internal risk management expert <br /> <br /> <br /> = Input =<br /> <br /> 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. <br /> <br /> Some examples of input needed are: <br /> <br /> • Project management plan <br /> <br /> • Project Documents <br /> <br /> • Agreements <br /> <br /> • Procurement documentation <br /> <br /> • Enterprise environmental factors <br /> <br /> • Organisational process assets<br /> <br /> <br /> === Project management plan ===<br /> The project management plan include knowledge from underlining components. These components include: <br /> <br /> • Requirements management plan<br /> <br /> • Schedule management plan <br /> <br /> • Cost management plan <br /> <br /> • Quality Management plan <br /> <br /> • Resource management plan <br /> <br /> • Risk management plan<br /> <br /> • Scope baseline<br /> <br /> • Schedule baseline <br /> <br /> • Cost baseline<br /> <br /> Other relevant Management plans, Baselines, or relevant documents can be included in the project management plan. <br /> <br /> === Project Documents ===<br /> <br /> Some project documents can be included as input in the risk identification. Examples of these are: <br /> <br /> • Assumption log<br /> <br /> • Cost estimates<br /> <br /> • Duration estimates <br /> <br /> • Issue log<br /> <br /> • Lessons learned register <br /> <br /> • Requirements documentation. <br /> <br /> • Resource requirements <br /> <br /> • Stakeholder register<br /> <br /> === Agreements ===<br /> 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. <br /> <br /> === Procurement documentation ===<br /> <br /> 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. <br /> <br /> = Tools = <br /> <br /> From the generated and gathered input, the management team have a variety of tools in the toolbox, that will help them identify the risks. <br /> <br /> Examples of such tools are: <br /> • Expert judgment <br /> <br /> • Data gathering (Brainstorming, Checklists, Interviews) <br /> <br /> • Root cause analysis <br /> <br /> • Assumption and constraint analysis <br /> <br /> • SWOT analysis <br /> <br /> • Risk breakdown structure <br /> <br /> • Document analysis<br /> <br /> • Interpersonal and team skills<br /> <br /> • Prompt lists <br /> <br /> • Meetings <br /> <br /> == Expert judgement == <br /> <br /> 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. <br /> <br /> 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. <br /> <br /> == Data gathering == <br /> <br /> There are multiple techniques to gather data related to risk. Here there are highlighted some, which are widely used<br /> <br /> === Brainstorming ===<br /> <br /> 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. <br /> <br /> 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. <br /> <br /> === Checklist ===<br /> <br /> 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. (ref2)<br /> The checklist is a good way for a company to transfer knowledge and learnings from project to project. <br /> However, this should not be seen as a reason to not carrier out a risk identification. Other risk should also be explored. <br /> <br /> === Interviews ===<br /> <br /> 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.). <br /> 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. <br /> <br /> <br /> === Root cause analysis ===<br /> <br /> 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. <br /> By stating a problem/benefit statement a root cause analysis can be used to detect threats or opportunities. <br /> <br /> === Assumption and constraint analysis ===<br /> <br /> This is an analysis of the projects and project management plans underlining assumption and constraint. <br /> The assumptions, which the project has made, represent some unidentified risks. Analysing these assumptions will bring risk to light and assess their threat. <br /> 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. <br /> <br /> === SWOT analysis ===<br /> <br /> SWOT is an analysis of the project and organizations strengths, weaknesses, opportunities and treats. *** another source needed <br /> <br /> === Risk breakdown structure === <br /> <br /> (ref3)<br /> <br /> = Output =<br /> <br /> The output from identifying risk is three folded: the risk register, the risk report, and updates of project documents. <br /> <br /> == Risk register == <br /> <br /> The risk register is, as the name may suggest, where all individual risks are registered. This includes a list of all risk fund in the identification process. All risks are registered with unique name, number, or similar, as well as a description of the risk so that the information don’t get lost. (ref2)<br /> 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. (ref2)<br /> <br /> 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. <br /> <br /> 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. <br /> <br /> == Risk report == <br /> <br /> The risk report includes the sources of overall project risk, as well as a summary of individual project risks. <br /> <br /> == Project documents updates == <br /> <br /> 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. <br /> <br /> = Limitations =<br /> <br /> All risk to a project will not be identified at ones. Even if all risk could be identified, changes are some will be missed/undetected. (ref2)<br /> Expert bias <br /> Big time use <br /> <br /> = Annotated bibliography =<br /> Key references:<br /> • Project Management: A guide to the Project Management Body of Knowledge (PMBOK guide), 6th Edition (2017)<br /> <br /> = References = <br /> &lt;references&gt;<br /> &lt;ref name=&quot;PMIGuide&quot;&gt;Guide to the Project Management Body of Knowledge (PMBOK® Guide) (6th Edition), Project Management Institute, Inc.(2017)&lt;/ref&gt;</div>

ChristofferFriis http://13.50.150.85/index.php?title=Identifying_risk&diff=100642 2021-02-28T20:34:43Z

<p>ChristofferFriis: </p> <hr /> <div>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. <br /> 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. <br /> When identifying risk, the step that you go through is create input, applying tools and techniques, and finally getting output. <br /> 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.<br /> 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. <br /> The last part is the output. The output is 3 folded; 1. Risk register. 2. Risk report. 3. Project documents updates. <br /> <br /> The 3 parts of identifying risks (input, tools &amp; output) will be descried in greater details. &lt;ref name=&quot;PMIGuide&quot;&gt;<br /> <br /> = Big idea = <br /> <br /> 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. Risk will be overseen the first time around and new risk will accurse. Therefore, this process needs to be repeated. (ref2)(ref3) <br /> <br /> 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. <br /> <br /> To produce this output there must first be some input to work with. This is input like project management plan, project document, and so on. The input is the first thing that must be in place. When it is, it enables us to us some given tools and techniques to identify the risks. These tools are not limited to the ones described on this page, but the ones highlighted are some good tools to use. <br /> <br /> 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: (ref3)<br /> <br /> - Project manager <br /> <br /> - Project team <br /> <br /> - Risk specialist<br /> <br /> - Customers and end users <br /> <br /> - External subject experts <br /> <br /> - Relevant stakeholders<br /> <br /> - Internal risk management expert <br /> <br /> <br /> = Input =<br /> <br /> 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. <br /> <br /> Some examples of input needed are: <br /> <br /> • Project management plan <br /> <br /> • Project Documents <br /> <br /> • Agreements <br /> <br /> • Procurement documentation <br /> <br /> • Enterprise environmental factors <br /> <br /> • Organisational process assets<br /> <br /> <br /> === Project management plan ===<br /> The project management plan include knowledge from underlining components. These components include: <br /> <br /> • Requirements management plan<br /> <br /> • Schedule management plan <br /> <br /> • Cost management plan <br /> <br /> • Quality Management plan <br /> <br /> • Resource management plan <br /> <br /> • Risk management plan<br /> <br /> • Scope baseline<br /> <br /> • Schedule baseline <br /> <br /> • Cost baseline<br /> <br /> Other relevant Management plans, Baselines, or relevant documents can be included in the project management plan. <br /> <br /> === Project Documents ===<br /> <br /> Some project documents can be included as input in the risk identification. Examples of these are: <br /> <br /> • Assumption log<br /> <br /> • Cost estimates<br /> <br /> • Duration estimates <br /> <br /> • Issue log<br /> <br /> • Lessons learned register <br /> <br /> • Requirements documentation. <br /> <br /> • Resource requirements <br /> <br /> • Stakeholder register<br /> <br /> === Agreements ===<br /> 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. <br /> <br /> === Procurement documentation ===<br /> <br /> 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. <br /> <br /> = Tools = <br /> <br /> From the generated and gathered input, the management team have a variety of tools in the toolbox, that will help them identify the risks. <br /> <br /> Examples of such tools are: <br /> • Expert judgment <br /> <br /> • Data gathering (Brainstorming, Checklists, Interviews) <br /> <br /> • Root cause analysis <br /> <br /> • Assumption and constraint analysis <br /> <br /> • SWOT analysis <br /> <br /> • Risk breakdown structure <br /> <br /> • Document analysis<br /> <br /> • Interpersonal and team skills<br /> <br /> • Prompt lists <br /> <br /> • Meetings <br /> <br /> == Expert judgement == <br /> <br /> 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. <br /> <br /> 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. <br /> <br /> == Data gathering == <br /> <br /> There are multiple techniques to gather data related to risk. Here there are highlighted some, which are widely used<br /> <br /> === Brainstorming ===<br /> <br /> 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. <br /> <br /> 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. <br /> <br /> === Checklist ===<br /> <br /> 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. (ref2)<br /> The checklist is a good way for a company to transfer knowledge and learnings from project to project. <br /> However, this should not be seen as a reason to not carrier out a risk identification. Other risk should also be explored. <br /> <br /> === Interviews ===<br /> <br /> 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.). <br /> 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. <br /> <br /> <br /> === Root cause analysis ===<br /> <br /> 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. <br /> By stating a problem/benefit statement a root cause analysis can be used to detect threats or opportunities. <br /> <br /> === Assumption and constraint analysis ===<br /> <br /> This is an analysis of the projects and project management plans underlining assumption and constraint. <br /> The assumptions, which the project has made, represent some unidentified risks. Analysing these assumptions will bring risk to light and assess their threat. <br /> 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. <br /> <br /> === SWOT analysis ===<br /> <br /> SWOT is an analysis of the project and organizations strengths, weaknesses, opportunities and treats. *** another source needed <br /> <br /> === Risk breakdown structure === <br /> <br /> (ref3)<br /> <br /> = Output =<br /> <br /> The output from identifying risk is three folded: the risk register, the risk report, and updates of project documents. <br /> <br /> == Risk register == <br /> <br /> The risk register is, as the name may suggest, where all individual risks are registered. This includes a list of all risk fund in the identification process. All risks are registered with unique name, number, or similar, as well as a description of the risk so that the information don’t get lost. (ref2)<br /> 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. (ref2)<br /> <br /> 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. <br /> <br /> 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. <br /> <br /> == Risk report == <br /> <br /> The risk report includes the sources of overall project risk, as well as a summary of individual project risks. <br /> <br /> == Project documents updates == <br /> <br /> 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. <br /> <br /> = Limitations =<br /> <br /> All risk to a project will not be identified at ones. Even if all risk could be identified, changes are some will be missed/undetected. (ref2)<br /> Expert bias <br /> Big time use <br /> <br /> = Annotated bibliography =<br /> Key references:<br /> • Project Management: A guide to the Project Management Body of Knowledge (PMBOK guide), 6th Edition (2017)<br /> <br /> = References = <br /> &lt;references&gt;<br /> &lt;ref name=&quot;PMIGuide&quot;&gt;Guide to the Project Management Body of Knowledge (PMBOK® Guide) (6th Edition), Project Management Institute, Inc.(2017)&lt;/ref&gt;</div>

ChristofferFriis http://13.50.150.85/index.php?title=Identifying_risk&diff=100598 2021-02-28T20:29:51Z

<p>ChristofferFriis: </p> <hr /> <div>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. <br /> 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. <br /> When identifying risk, the step that you go through is create input, applying tools and techniques, and finally getting output. <br /> 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.<br /> 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. <br /> The last part is the output. The output is 3 folded; 1. Risk register. 2. Risk report. 3. Project documents updates. <br /> <br /> The 3 parts of identifying risks (input, tools &amp; output) will be descried in greater details. <br /> <br /> = Big idea = <br /> <br /> 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. Risk will be overseen the first time around and new risk will accurse. Therefore, this process needs to be repeated. (ref2)(ref3) <br /> <br /> 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. <br /> <br /> To produce this output there must first be some input to work with. This is input like project management plan, project document, and so on. The input is the first thing that must be in place. When it is, it enables us to us some given tools and techniques to identify the risks. These tools are not limited to the ones described on this page, but the ones highlighted are some good tools to use. <br /> <br /> 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: (ref3)<br /> <br /> - Project manager <br /> <br /> - Project team <br /> <br /> - Risk specialist<br /> <br /> - Customers and end users <br /> <br /> - External subject experts <br /> <br /> - Relevant stakeholders<br /> <br /> - Internal risk management expert <br /> <br /> <br /> = Input =<br /> <br /> 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. <br /> <br /> Some examples of input needed are: <br /> <br /> • Project management plan <br /> <br /> • Project Documents <br /> <br /> • Agreements <br /> <br /> • Procurement documentation <br /> <br /> • Enterprise environmental factors <br /> <br /> • Organisational process assets<br /> <br /> <br /> === Project management plan ===<br /> The project management plan include knowledge from underlining components. These components include: <br /> <br /> • Requirements management plan<br /> <br /> • Schedule management plan <br /> <br /> • Cost management plan <br /> <br /> • Quality Management plan <br /> <br /> • Resource management plan <br /> <br /> • Risk management plan<br /> <br /> • Scope baseline<br /> <br /> • Schedule baseline <br /> <br /> • Cost baseline<br /> <br /> Other relevant Management plans, Baselines, or relevant documents can be included in the project management plan. <br /> <br /> === Project Documents ===<br /> <br /> Some project documents can be included as input in the risk identification. Examples of these are: <br /> <br /> • Assumption log<br /> <br /> • Cost estimates<br /> <br /> • Duration estimates <br /> <br /> • Issue log<br /> <br /> • Lessons learned register <br /> <br /> • Requirements documentation. <br /> <br /> • Resource requirements <br /> <br /> • Stakeholder register<br /> <br /> === Agreements ===<br /> 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. <br /> <br /> === Procurement documentation ===<br /> <br /> 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. <br /> <br /> = Tools = <br /> <br /> From the generated and gathered input, the management team have a variety of tools in the toolbox, that will help them identify the risks. <br /> <br /> Examples of such tools are: <br /> • Expert judgment <br /> <br /> • Data gathering (Brainstorming, Checklists, Interviews) <br /> <br /> • Root cause analysis <br /> <br /> • Assumption and constraint analysis <br /> <br /> • SWOT analysis <br /> <br /> • Risk breakdown structure <br /> <br /> • Document analysis<br /> <br /> • Interpersonal and team skills<br /> <br /> • Prompt lists <br /> <br /> • Meetings <br /> <br /> == Expert judgement == <br /> <br /> 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. <br /> <br /> 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. <br /> <br /> == Data gathering == <br /> <br /> There are multiple techniques to gather data related to risk. Here there are highlighted some, which are widely used<br /> <br /> === Brainstorming ===<br /> <br /> 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. <br /> <br /> 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. <br /> <br /> === Checklist ===<br /> <br /> 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. (ref2)<br /> The checklist is a good way for a company to transfer knowledge and learnings from project to project. <br /> However, this should not be seen as a reason to not carrier out a risk identification. Other risk should also be explored. <br /> <br /> === Interviews ===<br /> <br /> 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.). <br /> 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. <br /> <br /> <br /> === Root cause analysis ===<br /> <br /> 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. <br /> By stating a problem/benefit statement a root cause analysis can be used to detect threats or opportunities. <br /> <br /> === Assumption and constraint analysis ===<br /> <br /> This is an analysis of the projects and project management plans underlining assumption and constraint. <br /> The assumptions, which the project has made, represent some unidentified risks. Analysing these assumptions will bring risk to light and assess their threat. <br /> 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. <br /> <br /> === SWOT analysis ===<br /> <br /> SWOT is an analysis of the project and organizations strengths, weaknesses, opportunities and treats. *** another source needed <br /> <br /> === Risk breakdown structure === <br /> <br /> (ref3)<br /> <br /> = Output =<br /> <br /> The output from identifying risk is three folded: the risk register, the risk report, and updates of project documents. <br /> <br /> == Risk register == <br /> <br /> The risk register is, as the name may suggest, where all individual risks are registered. This includes a list of all risk fund in the identification process. All risks are registered with unique name, number, or similar, as well as a description of the risk so that the information don’t get lost. (ref2)<br /> 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. (ref2)<br /> <br /> 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. <br /> <br /> 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. <br /> <br /> == Risk report == <br /> <br /> The risk report includes the sources of overall project risk, as well as a summary of individual project risks. <br /> <br /> == Project documents updates == <br /> <br /> 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. <br /> <br /> = Limitations =<br /> <br /> All risk to a project will not be identified at ones. Even if all risk could be identified, changes are some will be missed/undetected. (ref2)<br /> Expert bias <br /> Big time use <br /> <br /> = Annotated bibliography =<br /> Key references:<br /> • Project Management: A guide to the Project Management Body of Knowledge (PMBOK guide), 6th Edition (2017)</div>

ChristofferFriis http://13.50.150.85/index.php?title=Identifying_risk&diff=100577 2021-02-28T20:27:03Z

<p>ChristofferFriis: </p> <hr /> <div>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. <br /> 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. <br /> When identifying risk, the step that you go through is create input, applying tools and techniques, and finally getting output. <br /> 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.<br /> 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. <br /> The last part is the output. The output is 3 folded; 1. Risk register. 2. Risk report. 3. Project documents updates. <br /> <br /> The 3 parts of identifying risks (input, tools &amp; output) will be descried in greater details. <br /> <br /> = Big idea = <br /> <br /> 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. Risk will be overseen the first time around and new risk will accurse. Therefore, this process needs to be repeated. (ref2)(ref3) <br /> <br /> 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. <br /> <br /> To produce this output there must first be some input to work with. This is input like project management plan, project document, and so on. The input is the first thing that must be in place. When it is, it enables us to us some given tools and techniques to identify the risks. These tools are not limited to the ones described on this page, but the ones highlighted are some good tools to use. <br /> <br /> 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: (ref3)<br /> <br /> - Project manager <br /> - Project team <br /> - Risk specialist<br /> - Customers and end users <br /> - External subject experts <br /> - Relevant stakeholders<br /> - Internal risk management expert <br /> <br /> <br /> = Input =<br /> <br /> 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. <br /> <br /> Some examples of input needed are: <br /> <br /> • Project management plan <br /> • Project Documents <br /> • Agreements <br /> • Procurement documentation <br /> • Enterprise environmental factors <br /> • Organisational process assets<br /> <br /> <br /> === Project management plan ===<br /> The project management plan include knowledge from underlining components. These components include: <br /> <br /> • Requirements management plan<br /> • Schedule management plan <br /> • Cost management plan <br /> • Quality Management plan <br /> • Resource management plan <br /> • Risk management plan<br /> • Scope baseline<br /> • Schedule baseline <br /> • Cost baseline<br /> <br /> Other relevant Management plans, Baselines, or relevant documents can be included in the project management plan. <br /> <br /> === Project Documents ===<br /> <br /> Some project documents can be included as input in the risk identification. Examples of these are: <br /> <br /> • Assumption log<br /> • Cost estimates<br /> • Duration estimates <br /> • Issue log<br /> • Lessons learned register <br /> • Requirements documentation. <br /> • Resource requirements <br /> • Stakeholder register<br /> <br /> === Agreements ===<br /> 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. <br /> <br /> === Procurement documentation ===<br /> <br /> 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. <br /> <br /> = Tools = <br /> <br /> From the generated and gathered input, the management team have a variety of tools in the toolbox, that will help them identify the risks. <br /> <br /> Examples of such tools are: <br /> • Expert judgment <br /> • Data gathering <br /> o Brainstorming <br /> o Checklists <br /> o Interviews<br /> • Data analysis <br /> o Root cause analysis <br /> o Assumption and constraint analysis <br /> o SWOT analysis <br /> o Document analysis<br /> • Interpersonal and team skills<br /> • Prompt lists <br /> • Meetings <br /> <br /> == Expert judgement == <br /> <br /> 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. <br /> <br /> 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. <br /> <br /> == Data gathering == <br /> <br /> There are multiple techniques to gather data related to risk. Here there are highlighted some, which are widely used<br /> <br /> === Brainstorming ===<br /> <br /> 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. <br /> <br /> 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. <br /> <br /> === Checklist ===<br /> <br /> 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. (ref2)<br /> The checklist is a good way for a company to transfer knowledge and learnings from project to project. <br /> However, this should not be seen as a reason to not carrier out a risk identification. Other risk should also be explored. <br /> <br /> === Interviews ===<br /> <br /> 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.). <br /> 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. <br /> <br /> <br /> === Root cause analysis ===<br /> <br /> 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. <br /> By stating a problem/benefit statement a root cause analysis can be used to detect threats or opportunities. <br /> <br /> === Assumption and constraint analysis ===<br /> <br /> This is an analysis of the projects and project management plans underlining assumption and constraint. <br /> The assumptions, which the project has made, represent some unidentified risks. Analysing these assumptions will bring risk to light and assess their threat. <br /> 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. <br /> <br /> === SWOT analysis ===<br /> <br /> SWOT is an analysis of the project and organizations strengths, weaknesses, opportunities and treats. *** another source needed <br /> <br /> === Risk breakdown structure === <br /> <br /> (ref3)<br /> <br /> = Output =<br /> <br /> The output from identifying risk is three folded: the risk register, the risk report, and updates of project documents. <br /> <br /> == Risk register == <br /> <br /> The risk register is, as the name may suggest, where all individual risks are registered. This includes a list of all risk fund in the identification process. All risks are registered with unique name, number, or similar, as well as a description of the risk so that the information don’t get lost. (ref2)<br /> 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. (ref2)<br /> <br /> 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. <br /> <br /> 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. <br /> <br /> == Risk report == <br /> <br /> The risk report includes the sources of overall project risk, as well as a summary of individual project risks. <br /> <br /> == Project documents updates == <br /> <br /> 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. <br /> <br /> = Limitations =<br /> <br /> All risk to a project will not be identified at ones. Even if all risk could be identified, changes are some will be missed/undetected. (ref2)<br /> Expert bias <br /> Big time use <br /> <br /> = Annotated bibliography =<br /> Key references:<br /> • Project Management: A guide to the Project Management Body of Knowledge (PMBOK guide), 6th Edition (2017)</div>

ChristofferFriis http://13.50.150.85/index.php?title=Identifying_risk&diff=99978 2021-02-28T18:33:39Z

<p>ChristofferFriis: </p> <hr /> <div>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. <br /> 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. <br /> When identifying risk, the step that you go through is create input, applying tools and techniques, and finally getting output. <br /> 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.<br /> 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. <br /> The last part is the output. The output is 3 folded; 1. Risk register. 2. Risk report. 3. Project documents updates. <br /> <br /> The 3 parts of identifying risks (input, tools &amp; output) will be descried in greater details. <br /> <br /> = Big idea = <br /> <br /> 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. <br /> 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. <br /> <br /> 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:<br /> <br /> - Project manager <br /> <br /> - Project team <br /> <br /> - Risk specialist <br /> <br /> - Customers and end users <br /> <br /> - External subject experts <br /> <br /> - Relevant stakeholders<br /> <br /> - Internal risk management expert <br /> <br /> <br /> = Input =<br /> <br /> 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. <br /> <br /> Some examples of input needed are: <br /> <br /> • Project management plan <br /> <br /> • Project Documents <br /> <br /> • Agreements <br /> <br /> • Procurement documentation <br /> <br /> • Enterprise environmental factors <br /> <br /> • Organisational process assets<br /> <br /> <br /> === Project management plan ===<br /> The project management plan include knowledge from underlining components. These components include: <br /> <br /> • Requirements management plan<br /> <br /> • Schedule management plan <br /> <br /> • Cost management plan <br /> <br /> • Quality Management plan <br /> <br /> • Resource management plan <br /> <br /> • Risk management plan<br /> <br /> • Scope baseline<br /> <br /> • Schedule baseline <br /> <br /> • Cost baseline<br /> <br /> Other relevant Management plans, Baselines, or relevant documents can be included in the project management plan. <br /> <br /> === Project Documents ===<br /> <br /> Some project documents can be included as input in the risk identification. Examples of these are: <br /> <br /> • Assumption log<br /> <br /> • Cost estimates<br /> <br /> • Duration estimates <br /> <br /> • Issue log<br /> <br /> • Lessons learned register <br /> <br /> • Requirements documentation. <br /> <br /> • Resource requirements <br /> <br /> • Stakeholder register<br /> <br /> === Agreements ===<br /> 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. <br /> <br /> === Procurement documentation ===<br /> <br /> 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. <br /> <br /> <br /> = Tools = <br /> <br /> From the input generated and gathered, the management team have a variety of tools in the toolbox, that will help them identify the risks. <br /> <br /> Examples of such tools are: <br /> <br /> • Expert judgment <br /> <br /> • Data gathering <br /> <br /> - Brainstorming <br /> <br /> - Checklists <br /> <br /> - Interviews<br /> <br /> • Data analysis <br /> <br /> o Root cause analysis <br /> <br /> o Assumption and constraint analysis <br /> <br /> o SWOT analysis <br /> <br /> o Document analysis<br /> <br /> • Interpersonal and team skills<br /> <br /> • Prompt lists <br /> <br /> • Meetings <br /> <br /> === Expert judgement ===<br /> <br /> 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. <br /> <br /> 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. <br /> <br /> === Data gathering === <br /> <br /> There are multiple techniques to gather data related to risk. Here there are highlighted some, which are widely used<br /> <br /> ==== Brainstorming ====<br /> <br /> 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. <br /> <br /> 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. <br /> <br /> ==== Checklist ====<br /> <br /> 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. <br /> The checklist is a good way for a company to transfer knowledge and learnings from project to project. <br /> However, this should not be seen as a reason to not carrier out a risk identification. Other risk should also be explored. <br /> <br /> ==== Interviews ====<br /> <br /> 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.). <br /> 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. <br /> <br /> <br /> <br /> === Root cause analysis ===<br /> <br /> 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. <br /> By stating a problem/benefit statement a root cause analysis can be used to detect threats or opportunities. <br /> <br /> === Assumption and constraint analysis ===<br /> <br /> This is an analysis of the projects and project management plans underlining assumption and constraint. <br /> The assumptions, which the project has made, represent some unidentified risks. Analysing these assumptions will bring risk to light and assess their threat. <br /> 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. <br /> <br /> === SWOT analysis ===<br /> <br /> SWOT is an analysis of the project and organizations strengths, weaknesses, opportunities and treats. *** another source needed <br /> <br /> ===Document analysis ===<br /> ***Maybe.<br /> <br /> = Output =<br /> <br /> The output from identifying risk is three folded: the risk register, the risk report, and updates of project documents. <br /> <br /> === Risk register ===<br /> <br /> 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. <br /> 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. <br /> <br /> 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. <br /> <br /> 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. <br /> <br /> === Risk report ===<br /> <br /> The risk report includes the sources of overall project risk, as well as a summary of individual project risks. <br /> <br /> === Project documents updates === <br /> <br /> 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. <br /> <br /> = Limitations =<br /> <br /> = Annotated bibliography =<br /> Key references:<br /> • Project Management: A guide to the Project Management Body of Knowledge (PMBOK guide), 6th Edition (2017)</div>

ChristofferFriis http://13.50.150.85/index.php?title=Identifying_risk&diff=99975 2021-02-28T18:33:15Z

<p>ChristofferFriis: </p> <hr /> <div>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. <br /> 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. <br /> When identifying risk, the step that you go through is create input, applying tools and techniques, and finally getting output. <br /> 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.<br /> 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. <br /> The last part is the output. The output is 3 folded; 1. Risk register. 2. Risk report. 3. Project documents updates. <br /> <br /> The 3 parts of identifying risks (input, tools &amp; output) will be descried in greater details. <br /> <br /> = Big idea = <br /> <br /> 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. <br /> 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. <br /> <br /> 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:<br /> <br /> - Project manager <br /> <br /> - Project team <br /> <br /> - Risk specialist <br /> <br /> - Customers and end users <br /> <br /> - External subject experts <br /> <br /> - Relevant stakeholders<br /> <br /> - Internal risk management expert <br /> <br /> <br /> = Input =<br /> <br /> 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. <br /> <br /> Some examples of input needed are: <br /> <br /> • Project management plan <br /> <br /> • Project Documents <br /> <br /> • Agreements <br /> <br /> • Procurement documentation <br /> <br /> • Enterprise environmental factors <br /> <br /> • Organisational process assets<br /> <br /> <br /> === Project management plan ===<br /> The project management plan include knowledge from underlining components. These components include: <br /> <br /> • Requirements management plan<br /> <br /> • Schedule management plan <br /> <br /> • Cost management plan <br /> <br /> • Quality Management plan <br /> <br /> • Resource management plan <br /> <br /> • Risk management plan<br /> <br /> • Scope baseline<br /> <br /> • Schedule baseline <br /> <br /> • Cost baseline<br /> <br /> Other relevant Management plans, Baselines, or relevant documents can be included in the project management plan. <br /> <br /> === Project Documents ===<br /> <br /> Some project documents can be included as input in the risk identification. Examples of these are: <br /> <br /> • Assumption log<br /> <br /> • Cost estimates<br /> <br /> • Duration estimates <br /> <br /> • Issue log<br /> <br /> • Lessons learned register <br /> <br /> • Requirements documentation. <br /> <br /> • Resource requirements <br /> <br /> • Stakeholder register<br /> <br /> === Agreements ===<br /> 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. <br /> <br /> === Procurement documentation ===<br /> <br /> 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. <br /> <br /> <br /> = Tools = <br /> <br /> From the input generated and gathered, the management team have a variety of tools in the toolbox, that will help them identify the risks. <br /> <br /> Examples of such tools are: <br /> <br /> • Expert judgment <br /> <br /> • Data gathering <br /> <br /> o Brainstorming <br /> <br /> o Checklists <br /> <br /> o Interviews<br /> <br /> • Data analysis <br /> <br /> o Root cause analysis <br /> <br /> o Assumption and constraint analysis <br /> <br /> o SWOT analysis <br /> <br /> o Document analysis<br /> <br /> • Interpersonal and team skills<br /> <br /> • Prompt lists <br /> <br /> • Meetings <br /> <br /> === Expert judgement ===<br /> <br /> 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. <br /> <br /> 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. <br /> <br /> === Data gathering === <br /> <br /> There are multiple techniques to gather data related to risk. Here there are highlighted some, which are widely used<br /> <br /> ==== Brainstorming ====<br /> <br /> 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. <br /> <br /> 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. <br /> <br /> ==== Checklist ====<br /> <br /> 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. <br /> The checklist is a good way for a company to transfer knowledge and learnings from project to project. <br /> However, this should not be seen as a reason to not carrier out a risk identification. Other risk should also be explored. <br /> <br /> ==== Interviews ====<br /> <br /> 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.). <br /> 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. <br /> <br /> <br /> <br /> === Root cause analysis ===<br /> <br /> 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. <br /> By stating a problem/benefit statement a root cause analysis can be used to detect threats or opportunities. <br /> <br /> === Assumption and constraint analysis ===<br /> <br /> This is an analysis of the projects and project management plans underlining assumption and constraint. <br /> The assumptions, which the project has made, represent some unidentified risks. Analysing these assumptions will bring risk to light and assess their threat. <br /> 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. <br /> <br /> === SWOT analysis ===<br /> <br /> SWOT is an analysis of the project and organizations strengths, weaknesses, opportunities and treats. *** another source needed <br /> <br /> ===Document analysis ===<br /> ***Maybe.<br /> <br /> = Output =<br /> <br /> The output from identifying risk is three folded: the risk register, the risk report, and updates of project documents. <br /> <br /> === Risk register ===<br /> <br /> 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. <br /> 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. <br /> <br /> 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. <br /> <br /> 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. <br /> <br /> === Risk report ===<br /> <br /> The risk report includes the sources of overall project risk, as well as a summary of individual project risks. <br /> <br /> === Project documents updates === <br /> <br /> 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. <br /> <br /> = Limitations =<br /> <br /> = Annotated bibliography =<br /> Key references:<br /> • Project Management: A guide to the Project Management Body of Knowledge (PMBOK guide), 6th Edition (2017)</div>

ChristofferFriis http://13.50.150.85/index.php?title=Identifying_risk&diff=99971 2021-02-28T18:32:52Z

<p>ChristofferFriis: </p> <hr /> <div>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. <br /> 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. <br /> When identifying risk, the step that you go through is create input, applying tools and techniques, and finally getting output. <br /> 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.<br /> 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. <br /> The last part is the output. The output is 3 folded; 1. Risk register. 2. Risk report. 3. Project documents updates. <br /> <br /> The 3 parts of identifying risks (input, tools &amp; output) will be descried in greater details. <br /> <br /> = Big idea = <br /> <br /> 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. <br /> 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. <br /> <br /> 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:<br /> <br /> - Project manager <br /> <br /> - Project team <br /> <br /> - Risk specialist <br /> <br /> - Customers and end users <br /> <br /> - External subject experts <br /> <br /> - Relevant stakeholders<br /> <br /> - Internal risk management expert <br /> <br /> <br /> = Input =<br /> <br /> 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. <br /> <br /> Some examples of input needed are: <br /> <br /> • Project management plan <br /> <br /> • Project Documents <br /> <br /> • Agreements <br /> <br /> • Procurement documentation <br /> <br /> • Enterprise environmental factors <br /> <br /> • Organisational process assets<br /> <br /> <br /> === Project management plan ===<br /> The project management plan include knowledge from underlining components. These components include: <br /> <br /> • Requirements management plan<br /> <br /> • Schedule management plan <br /> <br /> • Cost management plan <br /> <br /> • Quality Management plan <br /> <br /> • Resource management plan <br /> <br /> • Risk management plan<br /> <br /> • Scope baseline<br /> <br /> • Schedule baseline <br /> <br /> • Cost baseline<br /> <br /> Other relevant Management plans, Baselines, or relevant documents can be included in the project management plan. <br /> <br /> === Project Documents ===<br /> <br /> Some project documents can be included as input in the risk identification. Examples of these are: <br /> <br /> • Assumption log<br /> <br /> • Cost estimates<br /> <br /> • Duration estimates <br /> <br /> • Issue log<br /> <br /> • Lessons learned register <br /> <br /> • Requirements documentation. <br /> <br /> • Resource requirements <br /> <br /> • Stakeholder register<br /> <br /> === Agreements ===<br /> 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. <br /> <br /> === Procurement documentation ===<br /> <br /> 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. <br /> <br /> <br /> = Tools = <br /> <br /> From the input generated and gathered, the management team have a variety of tools in the toolbox, that will help them identify the risks. <br /> <br /> Examples of such tools are: <br /> <br /> • Expert judgment <br /> <br /> • Data gathering <br /> <br /> o Brainstorming <br /> <br /> o Checklists <br /> <br /> o Interviews<br /> <br /> • Data analysis <br /> <br /> o Root cause analysis <br /> <br /> o Assumption and constraint analysis <br /> <br /> o SWOT analysis <br /> <br /> o Document analysis<br /> <br /> • Interpersonal and team skills<br /> <br /> • Prompt lists <br /> <br /> • Meetings <br /> <br /> === Expert judgement ===<br /> <br /> 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. <br /> <br /> 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. <br /> <br /> === Data gathering === <br /> <br /> There are multiple techniques to gather data related to risk. Here there are highlighted some, which are widely used<br /> <br /> ==== Brainstorming ====<br /> <br /> 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. <br /> <br /> 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. <br /> <br /> ==== Checklist ====<br /> <br /> 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. <br /> The checklist is a good way for a company to transfer knowledge and learnings from project to project. <br /> However, this should not be seen as a reason to not carrier out a risk identification. Other risk should also be explored. <br /> <br /> ==== Interviews ====<br /> <br /> 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.). <br /> 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. <br /> <br /> <br /> <br /> === Root cause analysis ===<br /> <br /> 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. <br /> By stating a problem/benefit statement a root cause analysis can be used to detect threats or opportunities. <br /> <br /> === Assumption and constraint analysis ===<br /> <br /> This is an analysis of the projects and project management plans underlining assumption and constraint. <br /> The assumptions, which the project has made, represent some unidentified risks. Analysing these assumptions will bring risk to light and assess their threat. <br /> 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. <br /> <br /> === SWOT analysis ===<br /> <br /> SWOT is an analysis of the project and organizations strengths, weaknesses, opportunities and treats. *** another source needed <br /> <br /> ===Document analysis ===<br /> ***Maybe.<br /> <br /> = Output =<br /> <br /> The output from identifying risk is three folded: the risk register, the risk report, and updates of project documents. <br /> <br /> === Risk register ===<br /> <br /> 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. <br /> 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. <br /> <br /> 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. <br /> <br /> 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. <br /> <br /> === Risk report ===<br /> <br /> The risk report includes the sources of overall project risk, as well as a summary of individual project risks. <br /> <br /> === Project documents updates === <br /> <br /> 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. <br /> <br /> = Limitations =<br /> <br /> = Annotated bibliography =<br /> Key references:<br /> • Project Management: A guide to the Project Management Body of Knowledge (PMBOK guide), 6th Edition (2017)</div>

ChristofferFriis http://13.50.150.85/index.php?title=Identifying_risk&diff=99089 2021-02-28T16:28:02Z

<p>ChristofferFriis: </p> <hr /> <div>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. <br /> 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. <br /> When identifying risk, the step that you go through is create input, applying tools and techniques, and finally getting output. <br /> 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.<br /> 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. <br /> The last part is the output. The output is 3 folded; 1. Risk register. 2. Risk report. 3. Project documents updates. <br /> <br /> The 3 parts of identifying risks (input, tools &amp; output) will be descried in greater details. <br /> <br /> = Big idea = <br /> <br /> 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. <br /> 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. <br /> <br /> 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:<br /> <br /> - Project manager <br /> <br /> - Project team <br /> <br /> - Risk specialist <br /> <br /> - Customers and end users <br /> <br /> - External subject experts <br /> <br /> - Relevant stakeholders<br /> <br /> - Internal risk management expert <br /> <br /> <br /> = Input =<br /> <br /> 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. <br /> <br /> Some examples of input needed are: <br /> <br /> • Project management plan <br /> <br /> • Project Documents <br /> <br /> • Agreements <br /> <br /> • Procurement documentation <br /> <br /> • Enterprise environmental factors <br /> <br /> • Organisational process assets<br /> <br /> <br /> === Project management plan ===<br /> The project management plan include knowledge from underlining components. These components include: <br /> <br /> • Requirements management plan<br /> <br /> • Schedule management plan <br /> <br /> • Cost management plan <br /> <br /> • Quality Management plan <br /> <br /> • Resource management plan <br /> <br /> • Risk management plan<br /> <br /> • Scope baseline<br /> <br /> • Schedule baseline <br /> <br /> • Cost baseline<br /> <br /> Other relevant Management plans, Baselines, or relevant documents can be included in the project management plan. <br /> <br /> === Project Documents ===<br /> <br /> Some project documents can be included as input in the risk identification. Examples of these are: <br /> <br /> • Assumption log<br /> <br /> • Cost estimates<br /> <br /> • Duration estimates <br /> <br /> • Issue log<br /> <br /> • Lessons learned register <br /> <br /> • Requirements documentation. <br /> <br /> • Resource requirements <br /> <br /> • Stakeholder register<br /> <br /> === Agreements ===<br /> 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. <br /> <br /> === Procurement documentation ===<br /> <br /> 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. <br /> <br /> <br /> = Tools = <br /> <br /> From the input generated and gathered, the management team have a variety of tools in the toolbox, that will help them identify the risks. <br /> <br /> Examples of such tools are: <br /> <br /> • Expert judgment <br /> <br /> • Data gathering <br /> <br /> o Brainstorming <br /> <br /> o Checklists <br /> <br /> o Interviews<br /> <br /> • Data analysis <br /> <br /> o Root cause analysis <br /> <br /> o Assumption and constraint analysis <br /> <br /> o SWOT analysis <br /> <br /> o Document analysis<br /> <br /> • Interpersonal and team skills<br /> <br /> • Prompt lists <br /> <br /> • Meetings <br /> <br /> === Expert judgement ===<br /> <br /> 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. <br /> <br /> 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. <br /> <br /> === Data gathering === <br /> <br /> There are multiple techniques to gather data related to risk. Here there are highlighted some, which are widely used<br /> <br /> ==== Brainstorming ====<br /> <br /> 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. <br /> <br /> 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. <br /> <br /> ==== Checklist ====<br /> <br /> 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. <br /> The checklist is a good way for a company to transfer knowledge and learnings from project to project. <br /> However, this should not be seen as a reason to not carrier out a risk identification. Other risk should also be explored. <br /> <br /> ==== Interviews ====<br /> <br /> 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.). <br /> 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. <br /> <br /> <br /> <br /> === Root cause analysis ===<br /> <br /> 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. <br /> By stating a problem/benefit statement a root cause analysis can be used to detect threats or opportunities. <br /> <br /> === Assumption and constraint analysis ===<br /> <br /> This is an analysis of the projects and project management plans underlining assumption and constraint. <br /> The assumptions, which the project has made, represent some unidentified risks. Analysing these assumptions will bring risk to light and assess their threat. <br /> 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. <br /> <br /> === SWOT analysis ===<br /> <br /> SWOT is an analysis of the project and organizations strengths, weaknesses, opportunities and treats. *** another source needed <br /> <br /> ===Document analysis ===<br /> ***Maybe.<br /> <br /> = Output =<br /> <br /> The output from identifying risk is three folded: the risk register, the risk report, and updates of project documents. <br /> <br /> === Risk register ===<br /> <br /> 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. <br /> 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. <br /> <br /> 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. <br /> <br /> 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. <br /> <br /> === Risk report ===<br /> <br /> The risk report includes the sources of overall project risk, as well as a summary of individual project risks. <br /> <br /> === Project documents updates === <br /> <br /> 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. <br /> <br /> = Limitations =<br /> <br /> = Annotated bibliography =<br /> Key references:<br /> • Project Management: A guide to the Project Management Body of Knowledge (PMBOK guide), 6th Edition (2017)</div>

ChristofferFriis http://13.50.150.85/index.php?title=Identifying_risk&diff=97730 2021-02-28T11:22:35Z

<p>ChristofferFriis: </p> <hr /> <div>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. <br /> 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. <br /> When identifying risk, the step that you go through is create input, applying tools and techniques, and finally getting output. <br /> 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.<br /> 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. <br /> The last part is the output. The output is 3 folded; 1. Risk register. 2. Risk report. 3. Project documents updates. <br /> <br /> The 3 parts of identifying risks (input, tools &amp; output) will be descried in greater details. <br /> <br /> = Big idea = <br /> <br /> ***Identifying risk is a never ending job <br /> <br /> = Input =<br /> <br /> 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. <br /> <br /> Some examples of input needed are: <br /> <br /> • Project management plan <br /> <br /> • Project Documents <br /> <br /> • Agreements <br /> <br /> • Procurement documentation <br /> <br /> • Enterprise environmental factors <br /> <br /> • Organisational process assets<br /> <br /> <br /> === Project management plan ===<br /> The project management plan include knowledge from underlining components. These components include: <br /> <br /> • Requirements management plan<br /> • Schedule management plan <br /> • Cost management plan <br /> • Quality Management plan <br /> • Resource management plan <br /> • Risk management plan<br /> • Scope baseline<br /> • Schedule baseline <br /> • Cost baseline<br /> <br /> Other relevant Management plans, Baselines, or relevant documents can be included in the project management plan. <br /> <br /> === Project Documents ===<br /> <br /> Some project documents can be included as input in the risk identification. Examples of these are: <br /> <br /> • Assumption log<br /> • Cost estimates<br /> • Duration estimates <br /> • Issue log<br /> • Lessons learned register <br /> • Requirements documentation. <br /> • Resource requirements <br /> • Stakeholder register<br /> <br /> === Agreements ===<br /> 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. <br /> <br /> === Procurement documentation ===<br /> <br /> 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. <br /> <br /> === Enterprise environmental factors ===<br /> <br /> <br /> === Organisational process assets ===<br /> <br /> = Tools = <br /> <br /> From the input generated and gathered, the management team have a variety of tools in the toolbox, that will help them identify the risks. <br /> <br /> Examples of such tools are: <br /> • Expert judgment <br /> • Data gathering <br /> o Brainstorming <br /> o Checklists <br /> o Interviews<br /> • Data analysis <br /> o Root cause analysis <br /> o Assumption and constraint analysis <br /> o SWOT analysis <br /> o Document analysis<br /> • Interpersonal and team skills<br /> • Prompt lists <br /> • Meetings <br /> <br /> == Expert judgement == <br /> <br /> 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. <br /> <br /> 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. <br /> <br /> == Data gathering == <br /> <br /> There are multiple techniques to gather data related to risk. Here there are highlighted some, which are widely used<br /> <br /> === Brainstorming ===<br /> <br /> 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. <br /> <br /> 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. <br /> <br /> === Checklist ===<br /> <br /> 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. <br /> The checklist is a good way for a company to transfer knowledge and learnings from project to project. <br /> However, this should not be seen as a reason to not carrier out a risk identification. Other risk should also be explored. <br /> <br /> === Interviews ===<br /> <br /> 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.). <br /> 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. <br /> <br /> == Data analysis ==<br /> <br /> === Root cause analysis ===<br /> <br /> 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. <br /> By stating a problem/benefit statement a root cause analysis can be used to detect threats or opportunities. <br /> <br /> === Assumption and constraint analysis ===<br /> <br /> This is an analysis of the projects and project management plans underlining assumption and constraint. <br /> The assumptions, which the project has made, represent some unidentified risks. Analysing these assumptions will bring risk to light and assess their threat. <br /> 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. <br /> <br /> === SWOT analysis ===<br /> <br /> SWOT is an analysis of the project and organizations strengths, weaknesses, opportunities and treats. *** another source needed <br /> <br /> ===Document analysis ===<br /> ***Maybe.<br /> <br /> = Output =<br /> <br /> The output from identifying risk is three folded: the risk register, the risk report, and updates of project documents. <br /> <br /> == Risk register == <br /> <br /> 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. <br /> 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. <br /> <br /> 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. <br /> <br /> 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. <br /> <br /> == Risk report == <br /> <br /> The risk report includes the sources of overall project risk, as well as a summary of individual project risks. <br /> <br /> == Project documents updates == <br /> <br /> 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. <br /> <br /> = Limitations =<br /> <br /> = Annotated bibliography =<br /> Key references:<br /> • Project Management: A guide to the Project Management Body of Knowledge (PMBOK guide), 6th Edition (2017)</div>

ChristofferFriis http://13.50.150.85/index.php?title=Identifying_risk&diff=97725 2021-02-28T11:21:55Z

<p>ChristofferFriis: </p> <hr /> <div>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. <br /> 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. <br /> When identifying risk, the step that you go through is create input, applying tools and techniques, and finally getting output. <br /> 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.<br /> 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. <br /> The last part is the output. The output is 3 folded; 1. Risk register. 2. Risk report. 3. Project documents updates. <br /> <br /> The 3 parts of identifying risks (input, tools &amp; output) will be descried in greater details. <br /> <br /> = Big idea = <br /> <br /> ***Identifying risk is a never ending job <br /> <br /> = Input =<br /> <br /> 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. <br /> <br /> Some examples of input needed are: <br /> <br /> • Project management plan <br /> • Project Documents <br /> • Agreements <br /> • Procurement documentation <br /> • Enterprise environmental factors <br /> • Organisational process assets<br /> <br /> <br /> === Project management plan ===<br /> The project management plan include knowledge from underlining components. These components include: <br /> <br /> • Requirements management plan<br /> • Schedule management plan <br /> • Cost management plan <br /> • Quality Management plan <br /> • Resource management plan <br /> • Risk management plan<br /> • Scope baseline<br /> • Schedule baseline <br /> • Cost baseline<br /> <br /> Other relevant Management plans, Baselines, or relevant documents can be included in the project management plan. <br /> <br /> === Project Documents ===<br /> <br /> Some project documents can be included as input in the risk identification. Examples of these are: <br /> <br /> • Assumption log<br /> • Cost estimates<br /> • Duration estimates <br /> • Issue log<br /> • Lessons learned register <br /> • Requirements documentation. <br /> • Resource requirements <br /> • Stakeholder register<br /> <br /> === Agreements ===<br /> 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. <br /> <br /> === Procurement documentation ===<br /> <br /> 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. <br /> <br /> === Enterprise environmental factors ===<br /> <br /> <br /> === Organisational process assets ===<br /> <br /> = Tools = <br /> <br /> From the input generated and gathered, the management team have a variety of tools in the toolbox, that will help them identify the risks. <br /> <br /> Examples of such tools are: <br /> • Expert judgment <br /> • Data gathering <br /> o Brainstorming <br /> o Checklists <br /> o Interviews<br /> • Data analysis <br /> o Root cause analysis <br /> o Assumption and constraint analysis <br /> o SWOT analysis <br /> o Document analysis<br /> • Interpersonal and team skills<br /> • Prompt lists <br /> • Meetings <br /> <br /> == Expert judgement == <br /> <br /> 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. <br /> <br /> 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. <br /> <br /> == Data gathering == <br /> <br /> There are multiple techniques to gather data related to risk. Here there are highlighted some, which are widely used<br /> <br /> === Brainstorming ===<br /> <br /> 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. <br /> <br /> 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. <br /> <br /> === Checklist ===<br /> <br /> 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. <br /> The checklist is a good way for a company to transfer knowledge and learnings from project to project. <br /> However, this should not be seen as a reason to not carrier out a risk identification. Other risk should also be explored. <br /> <br /> === Interviews ===<br /> <br /> 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.). <br /> 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. <br /> <br /> == Data analysis ==<br /> <br /> === Root cause analysis ===<br /> <br /> 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. <br /> By stating a problem/benefit statement a root cause analysis can be used to detect threats or opportunities. <br /> <br /> === Assumption and constraint analysis ===<br /> <br /> This is an analysis of the projects and project management plans underlining assumption and constraint. <br /> The assumptions, which the project has made, represent some unidentified risks. Analysing these assumptions will bring risk to light and assess their threat. <br /> 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. <br /> <br /> === SWOT analysis ===<br /> <br /> SWOT is an analysis of the project and organizations strengths, weaknesses, opportunities and treats. *** another source needed <br /> <br /> ===Document analysis ===<br /> ***Maybe.<br /> <br /> = Output =<br /> <br /> The output from identifying risk is three folded: the risk register, the risk report, and updates of project documents. <br /> <br /> == Risk register == <br /> <br /> 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. <br /> 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. <br /> <br /> 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. <br /> <br /> 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. <br /> <br /> == Risk report == <br /> <br /> The risk report includes the sources of overall project risk, as well as a summary of individual project risks. <br /> <br /> == Project documents updates == <br /> <br /> 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. <br /> <br /> = Limitations =<br /> <br /> = Annotated bibliography =<br /> Key references:<br /> • Project Management: A guide to the Project Management Body of Knowledge (PMBOK guide), 6th Edition (2017)</div>

ChristofferFriis http://13.50.150.85/index.php?title=Identifying_risk&diff=97721 2021-02-28T11:21:06Z

<p>ChristofferFriis: </p> <hr /> <div>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. <br /> 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. <br /> When identifying risk, the step that you go through is create input, applying tools and techniques, and finally getting output. <br /> 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.<br /> 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. <br /> The last part is the output. The output is 3 folded; 1. Risk register. 2. Risk report. 3. Project documents updates. <br /> <br /> The 3 parts of identifying risks (input, tools &amp; output) will be descried in greater details. <br /> <br /> = Big idea = <br /> <br /> ***Identifying risk is a never ending job <br /> <br /> = Input =<br /> <br /> 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. <br /> <br /> Some examples of input needed are: <br /> <br /> • Project management plan <br /> • Project Documents <br /> • Agreements <br /> • Procurement documentation <br /> • Enterprise environmental factors <br /> • Organisational process assets<br /> <br /> <br /> == Project management plan ==<br /> The project management plan include knowledge from underlining components. These components include: <br /> <br /> • Requirements management plan<br /> • Schedule management plan <br /> • Cost management plan <br /> • Quality Management plan <br /> • Resource management plan <br /> • Risk management plan<br /> • Scope baseline<br /> • Schedule baseline <br /> • Cost baseline<br /> <br /> Other relevant Management plans, Baselines, or relevant documents can be included in the project management plan. <br /> <br /> == Project Documents ==<br /> <br /> Some project documents can be included as input in the risk identification. Examples of these are: <br /> <br /> • Assumption log<br /> • Cost estimates<br /> • Duration estimates <br /> • Issue log<br /> • Lessons learned register <br /> • Requirements documentation. <br /> • Resource requirements <br /> • Stakeholder register<br /> <br /> == Agreements ==<br /> 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. <br /> <br /> == Procurement documentation ==<br /> <br /> 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. <br /> <br /> == Enterprise environmental factors ==<br /> <br /> <br /> == Organisational process assets ==<br /> <br /> = Tools = <br /> <br /> From the input generated and gathered, the management team have a variety of tools in the toolbox, that will help them identify the risks. <br /> <br /> Examples of such tools are: <br /> • Expert judgment <br /> • Data gathering <br /> o Brainstorming <br /> o Checklists <br /> o Interviews<br /> • Data analysis <br /> o Root cause analysis <br /> o Assumption and constraint analysis <br /> o SWOT analysis <br /> o Document analysis<br /> • Interpersonal and team skills<br /> • Prompt lists <br /> • Meetings <br /> <br /> == Expert judgement == <br /> <br /> 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. <br /> <br /> 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. <br /> <br /> == Data gathering == <br /> <br /> There are multiple techniques to gather data related to risk. Here there are highlighted some, which are widely used<br /> <br /> === Brainstorming ===<br /> <br /> 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. <br /> <br /> 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. <br /> <br /> === Checklist ===<br /> <br /> 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. <br /> The checklist is a good way for a company to transfer knowledge and learnings from project to project. <br /> However, this should not be seen as a reason to not carrier out a risk identification. Other risk should also be explored. <br /> <br /> === Interviews ===<br /> <br /> 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.). <br /> 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. <br /> <br /> == Data analysis ==<br /> <br /> === Root cause analysis ===<br /> <br /> 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. <br /> By stating a problem/benefit statement a root cause analysis can be used to detect threats or opportunities. <br /> <br /> === Assumption and constraint analysis ===<br /> <br /> This is an analysis of the projects and project management plans underlining assumption and constraint. <br /> The assumptions, which the project has made, represent some unidentified risks. Analysing these assumptions will bring risk to light and assess their threat. <br /> 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. <br /> <br /> === SWOT analysis ===<br /> <br /> SWOT is an analysis of the project and organizations strengths, weaknesses, opportunities and treats. *** another source needed <br /> <br /> ===Document analysis ===<br /> ***Maybe.<br /> <br /> = Output =<br /> <br /> The output from identifying risk is three folded: the risk register, the risk report, and updates of project documents. <br /> <br /> == Risk register == <br /> <br /> 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. <br /> 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. <br /> <br /> 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. <br /> <br /> 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. <br /> <br /> == Risk report == <br /> <br /> The risk report includes the sources of overall project risk, as well as a summary of individual project risks. <br /> <br /> == Project documents updates == <br /> <br /> 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. <br /> <br /> = Limitations =<br /> <br /> = Annotated bibliography =<br /> Key references:<br /> • Project Management: A guide to the Project Management Body of Knowledge (PMBOK guide), 6th Edition (2017)</div>

ChristofferFriis http://13.50.150.85/index.php?title=Identifying_risk&diff=96115 2021-02-27T15:11:51Z

<p>ChristofferFriis: </p> <hr /> <div>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. <br /> 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. <br /> When identifying risk, the step that you go through is create input, applying tools and techniques, and finally getting output. <br /> 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.<br /> 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. <br /> The last part is the output. The output is 3 folded; 1. Risk register. 2. Risk report. 3. Project documents updates. <br /> <br /> The 3 parts of identifying risks (input, tools &amp; output) will be descried in greater details. <br /> <br /> = Big idea = <br /> <br /> <br /> = Input =<br /> <br /> 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. <br /> <br /> Some examples of input needed are: <br /> <br /> • Project management plan <br /> • Project Documents <br /> • Agreements <br /> • Procurement documentation <br /> • Enterprise environmental factors <br /> • Organisational process assets<br /> <br /> <br /> == Project management plan ==<br /> The project management plan include knowledge from underlining components. These components include: <br /> <br /> • Requirements management plan<br /> • Schedule management plan <br /> • Cost management plan <br /> • Quality Management plan <br /> • Resource management plan <br /> • Risk management plan<br /> • Scope baseline<br /> • Schedule baseline <br /> • Cost baseline<br /> <br /> Other relevant Management plans, Baselines, or relevant documents can be included in the project management plan. <br /> <br /> == Project Documents ==<br /> <br /> Some project documents can be included as input in the risk identification. Examples of these are: <br /> <br /> • Assumption log<br /> • Cost estimates<br /> • Duration estimates <br /> • Issue log<br /> • Lessons learned register <br /> • Requirements documentation. <br /> • Resource requirements <br /> • Stakeholder register<br /> <br /> == Agreements ==<br /> 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. <br /> <br /> == Procurement documentation ==<br /> <br /> 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. <br /> <br /> == Enterprise environmental factors ==<br /> <br /> <br /> == Organisational process assets ==<br /> <br /> = Tools = <br /> <br /> From the input generated and gathered, the management team have a variety of tools in the toolbox, that will help them identify the risks. <br /> <br /> Examples of such tools are: <br /> • Expert judgment <br /> • Data gathering <br /> o Brainstorming <br /> o Checklists <br /> o Interviews<br /> • Data analysis <br /> o Root cause analysis <br /> o Assumption and constraint analysis <br /> o SWOT analysis <br /> o Document analysis<br /> • Interpersonal and team skills<br /> • Prompt lists <br /> • Meetings <br /> <br /> == Expert judgement == <br /> <br /> 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. <br /> <br /> 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. <br /> <br /> == Data gathering == <br /> <br /> There are multiple techniques to gather data related to risk. Here there are highlighted some, which are widely used<br /> <br /> === Brainstorming ===<br /> <br /> 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. <br /> <br /> 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. <br /> <br /> === Checklist ===<br /> <br /> 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. <br /> The checklist is a good way for a company to transfer knowledge and learnings from project to project. <br /> However, this should not be seen as a reason to not carrier out a risk identification. Other risk should also be explored. <br /> <br /> === Interviews ===<br /> <br /> 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.). <br /> The danger with interviews is that the participant withhold 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 insure the right information is extracted. <br /> <br /> == Data analysis ==<br /> <br /> === Root cause analysis ===<br /> <br /> === Assumption and constraint analysis ===<br /> <br /> === SWOT analysis ===<br /> <br /> ===Document analysis ===<br /> <br /> <br /> = Output =<br /> <br /> = Limitations =<br /> <br /> = Annotated bibliography =<br /> Key references:<br /> • Project Management: A guide to the Project Management Body of Knowledge (PMBOK guide), 6th Edition (2017)</div>

ChristofferFriis http://13.50.150.85/index.php?title=Identifying_risk&diff=95968 2021-02-27T14:08:08Z

<p>ChristofferFriis: </p> <hr /> <div>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. <br /> 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. <br /> When identifying risk, the step that you go through is create input, applying tools and techniques, and finally getting output. <br /> 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.<br /> 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. <br /> The last part is the output. The output is 3 folded; 1. Risk register. 2. Risk report. 3. Project documents updates. <br /> <br /> The 3 parts of identifying risks (input, tools &amp; output) will be descried in greater details. <br /> <br /> = Big idea = <br /> <br /> <br /> = Input =<br /> <br /> -Thinks that is needed to conduct the risk identification.<br /> <br /> == Project management plan ==<br /> == Project Documents ==<br /> == Agreements ==<br /> == Procurement documentation ==<br /> == Enterprise environmental factors ==<br /> == Organisational process assets ==<br /> <br /> = Tools = <br /> <br /> == Data gathering == <br /> <br /> === Brainstorming ===<br /> <br /> === Checklist ===<br /> <br /> === Interviews ===<br /> <br /> == Data analysis ==<br /> <br /> === Root cause analysis ===<br /> <br /> === Assumption and constraint analysis ===<br /> <br /> === SWOT analysis ===<br /> <br /> ===Document analysis ===<br /> <br /> <br /> = Output =<br /> <br /> = Limitations =<br /> <br /> = Annotated bibliography =<br /> Key references:<br /> • Project Management: A guide to the Project Management Body of Knowledge (PMBOK guide), 6th Edition (2017)</div>

ChristofferFriis http://13.50.150.85/index.php?title=Identifying_risk&diff=94006 2021-02-25T20:56:03Z

<p>ChristofferFriis: </p> <hr /> <div>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. <br /> 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. <br /> When identifying risk, the step that you go through is create input, applying tools and techniques, and finally getting output. <br /> 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.<br /> 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. <br /> The last part is the output. The output is 3 folded; 1. Risk register. 2. Risk report. 3. Project documents updates. <br /> <br /> The 3 parts of identifying risks (input, tools &amp; output) will be descried in greater details. <br /> <br /> = Big idea = <br /> <br /> <br /> = Input =<br /> <br /> -Thinks that is needed to conduct the risk identification.<br /> <br /> == Project management plan ==<br /> == Project Documents ==<br /> == Agreements ==<br /> == Procurement documentation ==<br /> == Enterprise environmental factors ==<br /> == Organisational process assets ==<br /> <br /> = Tools = <br /> <br /> <br /> = Output =<br /> <br /> = Limitations =<br /> <br /> = Annotated bibliography =<br /> Key references:<br /> • Project Management: A guide to the Project Management Body of Knowledge (PMBOK guide), 6th Edition (2017)</div>

ChristofferFriis http://13.50.150.85/index.php?title=Identifying_risk&diff=93970 2021-02-25T20:15:55Z

<p>ChristofferFriis: </p> <hr /> <div>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. <br /> 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. <br /> When identifying risk, the step that you go through is create input, applying tools and techniques, and finally getting output. <br /> 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.<br /> 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. <br /> The last part is the output. The output is 3 folded; 1. Risk register. 2. Risk report. 3. Project documents updates. <br /> <br /> The 3 parts of identifying risks (input, tools &amp; output) will be descried in greater details. <br /> <br /> = Big idea = <br /> <br /> <br /> = Input =<br /> <br /> == Project management plan ==<br /> == Project Documents ==<br /> == Agreements ==<br /> == Procurement documentation ==<br /> == Enterprise environmental factors ==<br /> == Organisational process assets ==<br /> <br /> = Tools = <br /> <br /> <br /> = Output =<br /> <br /> = Limitations =<br /> <br /> = Annotated bibliography =<br /> Key references:<br /> • Project Management: A guide to the Project Management Body of Knowledge (PMBOK guide), 6th Edition (2017)</div>

ChristofferFriis http://13.50.150.85/index.php?title=Identifying_risk&diff=93969 2021-02-25T20:15:26Z

<p>ChristofferFriis: </p> <hr /> <div>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. <br /> 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. <br /> When identifying risk, the step that you go through is create input, applying tools and techniques, and finally getting output. <br /> 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.<br /> 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. <br /> The last part is the output. The output is 3 folded; 1. Risk register. 2. Risk report. 3. Project documents updates. <br /> <br /> The 3 parts of identifying risks (input, tools &amp; output) will be descried in greater details. <br /> <br /> = Big idea = <br /> <br /> <br /> = Input =<br /> <br /> == Project management plan ==<br /> == Project Documents ==<br /> == Agreements ==<br /> == Procurement documentation ==<br /> == Enterprise environmental factors ==<br /> == Organisational process assets ==<br /> <br /> == Tools == <br /> <br /> <br /> == Output == <br /> <br /> == Limitations == <br /> <br /> == Annotated bibliography == <br /> Key references:<br /> • Project Management: A guide to the Project Management Body of Knowledge (PMBOK guide), 6th Edition (2017)</div>

ChristofferFriis http://13.50.150.85/index.php?title=Identifying_risk&diff=93968 2021-02-25T20:14:29Z

<p>ChristofferFriis: </p> <hr /> <div>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. <br /> 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. <br /> When identifying risk, the step that you go through is create input, applying tools and techniques, and finally getting output. <br /> 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.<br /> 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. <br /> The last part is the output. The output is 3 folded; 1. Risk register. 2. Risk report. 3. Project documents updates. <br /> <br /> The 3 parts of identifying risks (input, tools &amp; output) will be descried in greater details. <br /> <br /> == Big idea == <br /> <br /> <br /> == Input == <br /> <br /> = Project management plan =<br /> = Project Documents =<br /> = Agreements =<br /> = Procurement documentation =<br /> = Enterprise environmental factors =<br /> = Organisational process assets =<br /> <br /> == Tools == <br /> <br /> <br /> == Output == <br /> <br /> == Limitations == <br /> <br /> == Annotated bibliography == <br /> Key references:<br /> • Project Management: A guide to the Project Management Body of Knowledge (PMBOK guide), 6th Edition (2017)</div>

ChristofferFriis http://13.50.150.85/index.php?title=Identifying_risk&diff=93967 2021-02-25T20:14:02Z

<p>ChristofferFriis: </p> <hr /> <div>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. <br /> 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. <br /> When identifying risk, the step that you go through is create input, applying tools and techniques, and finally getting output. <br /> 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.<br /> 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. <br /> The last part is the output. The output is 3 folded; 1. Risk register. 2. Risk report. 3. Project documents updates. <br /> <br /> The 3 parts of identifying risks (input, tools &amp; output) will be descried in greater details. <br /> <br /> == Big idea == <br /> <br /> <br /> == Input == <br /> <br /> = Project management plan === <br /> = Project Documents === <br /> = Agreements === <br /> = Procurement documentation ===<br /> = Enterprise environmental factors ===<br /> = Organisational process assets === <br /> <br /> == Tools == <br /> <br /> <br /> == Output == <br /> <br /> == Limitations == <br /> <br /> == Annotated bibliography == <br /> Key references:<br /> • Project Management: A guide to the Project Management Body of Knowledge (PMBOK guide), 6th Edition (2017)</div>

ChristofferFriis http://13.50.150.85/index.php?title=Identifying_risk&diff=93965 2021-02-25T20:13:34Z

<p>ChristofferFriis: </p> <hr /> <div>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. <br /> 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. <br /> When identifying risk, the step that you go through is create input, applying tools and techniques, and finally getting output. <br /> 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.<br /> 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. <br /> The last part is the output. The output is 3 folded; 1. Risk register. 2. Risk report. 3. Project documents updates. <br /> <br /> The 3 parts of identifying risks (input, tools &amp; output) will be descried in greater details. <br /> <br /> == Big idea == <br /> <br /> <br /> == Input == <br /> <br /> === Project management plan === <br /> === Project Documents === <br /> === Agreements === <br /> === Procurement documentation ===<br /> === Enterprise environmental factors ===<br /> === Organisational process assets === <br /> <br /> == Tools == <br /> <br /> <br /> == Output == <br /> <br /> == Limitations == <br /> <br /> == Annotated bibliography == <br /> Key references:<br /> • Project Management: A guide to the Project Management Body of Knowledge (PMBOK guide), 6th Edition (2017)</div>

ChristofferFriis http://13.50.150.85/index.php?title=Identifying_risk&diff=92381 2021-02-23T20:58:01Z

<p>ChristofferFriis: </p> <hr /> <div>The process of identifying risk in project management can be summarized as both identifying individual risk for the project and sources of overall risk to the project. Thereafter documenting their characteristics. <br /> 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. <br /> When identifying risk, the step that you go through is create input, applying tools and techniques, and finally getting output. <br /> 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.<br /> 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. <br /> The last part is the output. The output is 3 folded; 1. Risk register. 2. Risk report. 3. Project documents updates. <br /> <br /> The 3 parts of identifying risks (input, tools &amp; output) will be descried in greater details. <br /> <br /> == Big idea == <br /> <br /> <br /> == Input == <br /> <br /> == Tools == <br /> <br /> <br /> == Output == <br /> <br /> == Limitations == <br /> <br /> == Annotated bibliography == <br /> Key references:<br /> • Project Management: A guide to the Project Management Body of Knowledge (PMBOK guide), 6th Edition (2017)</div>

ChristofferFriis http://13.50.150.85/index.php?title=Identifying_risk&diff=92379 2021-02-23T20:56:40Z

<p>ChristofferFriis: </p> <hr /> <div>The process of identifying risk in project management can be summarized as both identifying individual risk for the project and sources of overall risk to the project. Thereafter documenting their characteristics. <br /> 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. <br /> When identifying risk, the step that you go through is create input, applying tools and techniques, and finally getting output. <br /> 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.<br /> 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. <br /> The last part is the output. The output is 3 folded; 1. Risk register. 2. Risk report. 3. Project documents updates. <br /> <br /> The 3 parts of identifying risks (input, tools &amp; output) will be descried in greater details. <br /> <br /> == Big idea == <br /> <br /> Key references:<br /> • Project Management: A guide to the Project Management Body of Knowledge (PMBOK guide), 6th Edition (2017)</div>

ChristofferFriis http://13.50.150.85/index.php?title=Identifying_risk&diff=81509 2021-02-14T21:28:59Z

<p>ChristofferFriis: </p> <hr /> <div>The process of identifying risk in project management can be summarized as both identifying individual risk for the project and sources of overall risk to the project. Thereafter documenting their characteristics. <br /> 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. <br /> When identifying risk, the step that you go through is create input, applying tools and techniques, and finally getting output. <br /> 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.<br /> 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. <br /> The last part is the output. The output is 3 folded; 1. Risk register. 2. Risk report. 3. Project documents updates. <br /> <br /> The 3 parts of identifying risks (input, tools &amp; output) will be descried in greater details. <br /> <br /> Key references:<br /> • Project Management: A guide to the Project Management Body of Knowledge (PMBOK guide), 6th Edition (2017)</div>

ChristofferFriis http://13.50.150.85/index.php?title=Identifying_risk&diff=81507 2021-02-14T21:28:42Z

<p>ChristofferFriis: </p> <hr /> <div>The process of identifying risk in project management can be summarized as both identifying individual risk for the project and sources of overall risk to the project. Thereafter documenting their characteristics. <br /> 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. <br /> When identifying risk, the step that you go through is create input, applying tools and techniques, and finally getting output. <br /> 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.<br /> 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. <br /> The last part is the output. The output is 3 folded; 1. Risk register. 2. Risk report. 3. Project documents updates. <br /> <br /> The 3 parts of identifying risks (input, tools &amp; output) will be descried in greater details. <br /> <br /> Key references:<br /> • Project Management: A guide to the Project Management Body of Knowledge (PMBOK guide)<br /> 6th Edition (2017)</div>

ChristofferFriis http://13.50.150.85/index.php?title=Identifying_risk&diff=79903 2021-02-13T12:22:51Z

<p>ChristofferFriis: Created page with &quot;Identifying risk&quot;</p> <hr /> <div>Identifying risk</div>

ChristofferFriis http://13.50.150.85/index.php?title=Articles_Spring_Term_2021&diff=79902 2021-02-13T12:22:03Z

<p>ChristofferFriis: /* Overview of 2021 Wiki Collections */</p> <hr /> <div>=Overview of 2021 Wiki Collections=<br /> <br /> {| class=&quot;wikitable sortable&quot;<br /> |+Spring Term 2021 Wiki Collections<br /> |Group name<br /> |First name<br /> |Surname<br /> |Student number<br /> |[[Article name]]<br /> |-<br /> |-<br /> |TAs Example<br /> |Thomas<br /> |Giannoulopoulos<br /> |s192419<br /> |[[APPM Example 2021]]<br /> |-<br /> |-<br /> |Group 12<br /> |Christian<br /> |Frøsig<br /> |s175044<br /> |[[Belbin's 9 team roles]]<br /> |-<br /> |-<br /> |Group 1<br /> |Oliver<br /> |K. Vittrup<br /> |s163754<br /> |[[Top-down vs bottom-up estimations]]<br /> |-<br /> |-<br /> |44<br /> |Jeyad<br /> |M. Baig<br /> |s153585<br /> |[[Task Management - 3 Levels of Planning Methods]]<br /> |-<br /> |-<br /> |Group 17<br /> |Quoc-Khanh Rose-Marie Therese<br /> |Madsen<br /> |s123462<br /> |[[Applying Tuckman’s model for team development]]<br /> |-<br /> |-<br /> |31<br /> |Haoxiang<br /> |Sang<br /> |s192258<br /> |[[Cost control with statistic tools]]<br /> |-<br /> |-<br /> |Not yet<br /> |He<br /> |Fan<br /> |s192195<br /> |[[Work Break Down Structure]]<br /> |-<br /> |-<br /> |Group 19<br /> |Ángel<br /> |Castro del Olmo<br /> |s193246<br /> |[[Stakeholder Engagement and Sustainability in Maritime Spatial Planning]]<br /> |-<br /> |-<br /> |44<br /> |Abdullah Shams<br /> |Turkmani<br /> |s153337<br /> |[[ICT Agreement]]<br /> |-<br /> |-<br /> |Group 17<br /> |Jacopo<br /> |Renzi<br /> |s210445<br /> |[[Double Diamond Model]]<br /> |-<br /> |-<br /> |Group 35<br /> |Helga Sigríður<br /> |Magnúsdóttir<br /> |s202027<br /> |[[Network Planning]]<br /> |-<br /> |-<br /> |12<br /> |Cæcilie<br /> |Kortbæk<br /> |163873<br /> |[[Double diamond]]<br /> |-<br /> |-<br /> |Group 18<br /> |Frithjof Johannes<br /> |Thiem<br /> |s202972<br /> |[[DevOps]]<br /> |-<br /> |-<br /> |12<br /> |Emilie<br /> |Winther Schmidt<br /> |163884<br /> |[[Iron Triangle]]<br /> |-<br /> |-<br /> |12<br /> |Anna<br /> |Fredgaard<br /> |s163887<br /> |[[Active Listening Technique]]<br /> |-<br /> |-<br /> |35<br /> |Ruben<br /> |Raes<br /> |s202029<br /> |[[Iron Triangle of Project Management]]<br /> |-<br /> |-<br /> |21<br /> |Claudia<br /> |Balcells<br /> |s202939<br /> |[[APPPM Issue Tree]]<br /> |-<br /> |-<br /> |35<br /> |Brynja<br /> |Gudmundsdottir<br /> |s202030<br /> |[[FAST goals]]<br /> |-<br /> |-<br /> |16<br /> |Andrea<br /> |Pin Morales<br /> |s205567<br /> |[[The Business Case]]<br /> |-<br /> |-<br /> |16<br /> |Lena Maria<br /> |Thyen<br /> |s202969<br /> |[[The 7 Habits of Highly Effective People]]<br /> |-<br /> |-<br /> |35<br /> |Úlfar<br /> |Viktorsson<br /> |s202022<br /> |[[The 4 Disciplines of Execution]]<br /> |-<br /> |-<br /> |16<br /> |Moritz<br /> |Rindermann<br /> |s202976<br /> |[[Tuckmans model for Team Development]]<br /> |-<br /> |-<br /> |Group 29<br /> |Heiðdís Ósk<br /> |Pétursdóttir<br /> |s202025<br /> |[[Efficiency and Effectiveness]]<br /> |-<br /> |-<br /> |31<br /> |Xabier<br /> |Martínez de Zabarte<br /> |s210323<br /> |[[Scrumban]]<br /> |-<br /> |-<br /> |17<br /> |Aldís Braga<br /> |Eiríksdóttir<br /> |s202045<br /> |[[Blake-Mouton Managerial Grid]]<br /> |-<br /> |-<br /> |32<br /> |Jan Otis<br /> | Ernst<br /> |s210433<br /> |[[RACI Matrix]]<br /> |-<br /> |-<br /> |3<br /> |Julie<br /> | Finne-Ipsen<br /> |s153987<br /> |[[Kahneman - Two Thinking Systems]]<br /> |-<br /> |-<br /> |24<br /> |Maria Eileen<br /> | Hubbuck<br /> |s210444<br /> |[[Risk Management-Identification]]<br /> |-<br /> |-<br /> |11<br /> |Alina<br /> | Barun<br /> |s202514<br /> |[[Maslow's Hierarchy of Needs]]<br /> |-<br /> |-<br /> |24<br /> |Felix Vinzenz<br /> |Wütherich<br /> |s202968<br /> |[[Emotional Intelligence and Leadership]]<br /> |-<br /> |-<br /> |28<br /> |Ariadna<br /> |Ramos<br /> |s191852<br /> |[[The Work Breakdown Structure (WBS)]]<br /> |-<br /> |-<br /> |Group 27<br /> |Jakob<br /> |Grønvald<br /> |s164346<br /> |[[Maslow‘s Hierarchy of Needs, Motivation in the workplace]]<br /> |-<br /> |-<br /> |Group 16<br /> |Martina<br /> |Rampazzo<br /> |s202895<br /> |[[Earned value management (EVM)]]<br /> |-<br /> |-<br /> |Group 2<br /> |John<br /> |Fritz<br /> |s202967<br /> |[[Learning plan]]<br /> |-<br /> |-<br /> |Group 24<br /> |Henning<br /> |Duwe<br /> |s210450<br /> |[[SWOT Analysis]]<br /> |-<br /> |-<br /> |Group 14<br /> |Søren Emil<br /> |Kjær<br /> |s201528<br /> |[[GANTT]]<br /> |-<br /> |-<br /> |Group 23<br /> |Mathilde Kremmer<br /> |Broberg<br /> |s175074<br /> |[[Corrective and Preventive Actions (CAPA)]]<br /> |-<br /> |-<br /> |Group 14<br /> |Rune Lykke<br /> |Høg<br /> |s165012<br /> |[[The use of the A3 management process]]<br /> |-<br /> |-<br /> |Group 35<br /> |Tinna Hrönn<br /> |Unudóttir<br /> |s202032<br /> |[[Constructive communication]]<br /> |-<br /> |-<br /> |Group 17<br /> |Eva Rún<br /> |Arnarsdóttir<br /> |s203214<br /> |[[Biases in Project Management]]<br /> |-<br /> |-<br /> |Group 24<br /> |Astrid<br /> |Skovhus<br /> |s164499<br /> |[[Getting Things Done (GTD)]]<br /> |-<br /> |-<br /> |Group 7<br /> |Phillip<br /> |Dyrberg<br /> |s164503<br /> |[[Double diamond: A design process model]]<br /> |-<br /> |-<br /> |Group 14<br /> |Amanda Emilie<br /> |Søborg Berthelsen<br /> |s154707<br /> |[[The Johari Window]]<br /> |-<br /> |-<br /> |Group 23<br /> |Nicolai Mossing<br /> |Madsen<br /> |s164515<br /> |[[SMART Goals (Specific, Measurable, Attainable, Relevant, Time-bound)]]<br /> |-<br /> |-<br /> |Group 27<br /> |Marie-Louise Wolfsberg<br /> |Schmidt<br /> |s164417<br /> |[[The Affect Heuristic]]<br /> |-<br /> |-<br /> |Group 4<br /> |Erika Marie<br /> |Strøm<br /> |s203224<br /> |[[Parkinson’s Law]]<br /> |-<br /> |-<br /> |Group 16<br /> |Beatrice<br /> |Ranzato<br /> |s202887<br /> |[[X-Matrix Hoshin Kanri]]<br /> |-<br /> |-<br /> |Group 9<br /> |Helene Waldmann<br /> |Jørgensen<br /> |s173891<br /> |[[Lag &amp; Lead]]<br /> |-<br /> |-<br /> |Group 4<br /> |Zahra<br /> |Al-Mosawi<br /> |s193938<br /> |[[Project Communications Management]]<br /> |-<br /> |-<br /> |Group 14<br /> |William Axel Linderoth<br /> |Michaelen<br /> |s153275<br /> |[[Design-Build]]<br /> |-<br /> |-<br /> |Group 31<br /> |Jesús <br /> |Gracia Yoldi<br /> |s210111<br /> |[[Kanban in APPPM]]<br /> |-<br /> |-<br /> |Group 35<br /> |Katrín Erla <br /> |Bergsveinsdóttir<br /> |s202026<br /> |[[Contingency plans]]<br /> |-<br /> |-<br /> |Group 1<br /> |Cecilie Marie Raagaard <br /> |Christensen<br /> |s160832<br /> |[[Work breakdown structure (WBS)]]<br /> |-<br /> |-<br /> |Group 19<br /> |Ali Jamal<br /> |Jomeh<br /> |s173741<br /> |[[SMART goals: A project management tool]]<br /> |-<br /> |-<br /> |Group 15<br /> |Tobias <br /> |Hyldmo<br /> |s206658<br /> |[[High performing teams]]<br /> |-<br /> |-<br /> |Group 5<br /> |Samah<br /> |Said<br /> |s203228<br /> |[[Business Process Excellence (BPEX)]]<br /> |-<br /> |-<br /> |Group 3<br /> |Emilie<br /> |Torp<br /> |s153320<br /> |[[Goal Hierarchy]]<br /> |-<br /> |-<br /> |Group 3<br /> |Victor Nørregaard<br /> |Schwærter<br /> |s164745<br /> |[[Milestone Planning]]<br /> |-<br /> |-<br /> |Group 9<br /> |Jacob<br /> |Ammitsøe<br /> |s173849<br /> |[[Self-Awareness]]<br /> |-<br /> |-<br /> |Group 18<br /> |Anna<br /> |Bjørn Reland<br /> |s154556<br /> |[[Choosing the appropriate medium (oral – written – hybrids)]]<br /> |-<br /> |-<br /> |Group 10<br /> |Wail<br /> |Atrari<br /> |s170706<br /> |[[The Double Diamond Tool: Prevent budget overruns and delays in your projects]]<br /> |-<br /> |Group 10<br /> |Helená Evin<br /> |Cinar<br /> |s164741<br /> |[[SWOT Analysis Management]]<br /> |-<br /> |-<br /> |Group 10<br /> |Mohammad<br /> |Abou Hassan<br /> |s160101<br /> |[[Implementing SWOT]]<br /> |-<br /> |-<br /> |Group 10<br /> |Ahmet<br /> |Akgül<br /> |s152597<br /> |[[Smart goals (Specific, Measurable, Achievable, Realistic, and Timely)]]<br /> |- <br /> |- <br /> |Group 2<br /> |Amalie<br /> |N. Müller<br /> |s173675<br /> |[[Big five personality traits (OCEAN model)]]<br /> |- <br /> |- <br /> |Group 29<br /> |Pétursdóttir<br /> |Stefanía Ósk<br /> |s202044<br /> |[[Management vs leadership qualities]]<br /> |- <br /> |- <br /> |Group 10<br /> |Abdulahi<br /> |Hayle Hassan<br /> |s164691<br /> |[[Stakeholder management]]<br /> |-<br /> |-<br /> |Group 27<br /> |Louise<br /> |Landschoff<br /> |s165111<br /> |[[SCRUM - A Project Management Framework]]<br /> |-<br /> |-<br /> |Group 10<br /> |Sara<br /> |Alabiidi<br /> |s164650<br /> |[[The Blake-Mouton Managerial Grid]]<br /> |-<br /> |-<br /> |Group 4<br /> |Felix<br /> |Dressel<br /> |s202965<br /> |[[SPALTEN]]<br /> |-<br /> |-<br /> |Group 11<br /> |Sandra<br /> |Nielsen<br /> |s153370<br /> |[[Conflict ladder]]<br /> |-<br /> |-<br /> |Group 11<br /> |Lise Munch<br /> |Nordheim<br /> |s200400<br /> |[[McGregor's X &amp; Y theory]]<br /> |-<br /> |-<br /> |Group 2<br /> |Simon<br /> |Knutsson<br /> |s202041<br /> |[[Earned Value Management (EVM)]]<br /> |-<br /> |-<br /> |Group 12<br /> |Christoffer<br /> |Askgaard<br /> |s165098<br /> |[[Design the team you need to succeed using Belbin's team roles]]<br /> |-<br /> |-<br /> |Group 24<br /> |Gaute Bø<br /> |Aaløkken<br /> |s202065<br /> |[[Diversity in teams]]<br /> |-<br /> |-<br /> |Group 2<br /> |Lukas<br /> |Tanzer<br /> |s200120<br /> |[[Continuous Improvement]]<br /> |-<br /> |-<br /> |Group 7<br /> |Sofie<br /> |Lundsteen<br /> |s170285<br /> |[[Team roles at work]]<br /> |-<br /> |-<br /> |Group 14<br /> |Josefine<br /> |M. Schuler<br /> |s154055<br /> |[[Applying the Hawthorne studies to project management]]<br /> |-<br /> |-<br /> |Group 3<br /> |Amalie Nordstrøm<br /> |Nielsen<br /> |s153272<br /> |[[The seven characteristic principles]]<br /> |-<br /> |-<br /> |Group 14<br /> |Louise Damborg<br /> |Frederiksen<br /> |s185238<br /> |[[Bias in a Team Setting]]<br /> |-<br /> |-<br /> |Group 1<br /> |Georg Holger<br /> |Waage<br /> |s163819<br /> |[[Fishbone Diagram]]<br /> |-<br /> |-<br /> |Group 28<br /> |Özgenur<br /> |Baştuğ<br /> |s203033<br /> |[[Variation Orders in Construction Projects]]<br /> |-<br /> |-<br /> |Group 9<br /> |Mads<br /> |Møhlenberg<br /> |s173879<br /> |[[A hybrid consisting of Agile and Stage Gate]]<br /> |-<br /> |-<br /> |Group 29<br /> |Svanhvít Birta<br /> |Guðmundsdóttir<br /> |s203174<br /> |[[Project Milestones]]<br /> |-<br /> |-<br /> |Group 23<br /> |Bente<br /> |Meidahl Münsberg<br /> |s175068<br /> |[[Gantt Charts]]<br /> |-<br /> |-<br /> |Group 27<br /> |Frederik<br /> |Carlsson <br /> |s164345<br /> |[[FAST Goals]]<br /> |-<br /> |-<br /> |Group 11<br /> |Tobias<br /> |Rydahl <br /> |s200471<br /> |[[Using DISC assessment for project team management]]<br /> |-<br /> |-<br /> |Group 7<br /> |Mads <br /> |Støjfer-Hønberg<br /> |s174303<br /> |[[SCRUM - An Agile Project Management Framework]]<br /> |-<br /> |-<br /> |Group 21<br /> |Matthieu <br /> |Buy<br /> |s202925<br /> |[[The Five-Factor Model (OCEAN)]]<br /> |-<br /> |-<br /> |Group 18<br /> |Astrid Helene<br /> |Erecius<br /> |s171013<br /> |[[Choosing communication media for negotiation]]<br /> |-<br /> |-<br /> |Group 44<br /> |Zainab<br /> |Jalal<br /> |s165491<br /> |[[Work Breakdown Structure in project management]]<br /> |-<br /> |-<br /> |Group 2<br /> |Anna Felicia Mai<br /> |Lindström<br /> |s202046<br /> |[[Project Status Reporting]]<br /> |-<br /> |-<br /> |Group 28<br /> |Alberto<br /> |Melloni<br /> |s202894<br /> |[[Pre-mortem analysis]]<br /> |-<br /> |-<br /> |Group 29<br /> |Thore Uwe<br /> |Aye<br /> |s202746<br /> |[[Quality Gates in Project Management]]<br /> |-<br /> |-<br /> |Group 9<br /> |Lydia<br /> |Tsintzou<br /> |s193745<br /> |[[SWOT Analysis Guide]]<br /> |-<br /> |-<br /> |Group 28<br /> |Kendra Ana<br /> |Rodríguez López<br /> |s200182<br /> |[[Choosing by Advantages Decision-Making System]]<br /> |-<br /> |-<br /> |Group 4<br /> |Christine<br /> |Fryland<br /> |s153875<br /> |[[Theory X-Y]]<br /> |-<br /> |-<br /> |Group 28<br /> |Manas P.<br /> |Dalvi<br /> |s210143<br /> |[[Effective Tools for Multiple Project Management]]<br /> -<br /> |-<br /> |Group 12<br /> |Joakim<br /> |Vollertzen<br /> |s163947<br /> |[[Extreme Project Management (XPM)]]<br /> |-<br /> |-<br /> |Group 19<br /> |Shubham<br /> |Ingole<br /> |s200092<br /> |[[Stakeholder Management Strategies]]<br /> |-<br /> |-<br /> |Group 31<br /> |Alvaro<br /> |Bello<br /> |s210447<br /> |[[Forecasting and estimation techniques]]<br /> |-<br /> |-<br /> |Group 09<br /> |Dorothea<br /> |Georgiadou<br /> |s200230<br /> |[[Risk Register analysis]]<br /> |-<br /> |-<br /> |Group 09<br /> |Maria Konstantina<br /> |Papaioannou<br /> |s195550<br /> |[[Fishbone diagram analysis]]<br /> |-<br /> |-<br /> |Group 21<br /> |Kelvin<br /> |Scott-Fordsmand<br /> |s174312<br /> |[[RiskRegister]]<br /> |-<br /> |-<br /> |Group 18<br /> |Christoffer Friis<br /> |Hansen<br /> |s164569<br /> |[[Identifying risk]]</div>

ChristofferFriis