Identifying risk - Revision history

ChristofferFriis at 22:01, 28 February 2021

2021-02-28T22:01:02Z

← Older revision		Revision as of 22:01, 28 February 2021
Line 227:		Line 227:

	For risk identification, chapter 11 is a very good walkthrough of how to conduct a risk identification process.		For risk identification, chapter 11 is a very good walkthrough of how to conduct a risk identification process.


	• Standard for Risk Management in Portfolios, Programs, and Projects		• Standard for Risk Management in Portfolios, Programs, and Projects

	A very good reference for all things risks in projects, portfolios, and programs.		A very good reference for all things risks in projects, portfolios, and programs.


	• Managing Successful Projects with PRINCE2 2017 Edition		• Managing Successful Projects with PRINCE2 2017 Edition

ChristofferFriis at 22:00, 28 February 2021

2021-02-28T22:00:38Z

← Older revision		Revision as of 22:00, 28 February 2021
Line 225:		Line 225:

	• Project Management: A guide to the Project Management Body of Knowledge (PMBOK guide), 6th Edition (2017).		• Project Management: A guide to the Project Management Body of Knowledge (PMBOK guide), 6th Edition (2017).

	For risk identification, chapter 11 is a very good walkthrough of how to conduct a risk identification process.		For risk identification, chapter 11 is a very good walkthrough of how to conduct a risk identification process.

	• Standard for Risk Management in Portfolios, Programs, and Projects		• Standard for Risk Management in Portfolios, Programs, and Projects

	A very good reference for all things risks in projects, portfolios, and programs.		A very good reference for all things risks in projects, portfolios, and programs.

	• Managing Successful Projects with PRINCE2 2017 Edition		• Managing Successful Projects with PRINCE2 2017 Edition

	Chapter 10 looks into risk, and PRINCE2 standards for handling risk, as well as what risk are.		Chapter 10 looks into risk, and PRINCE2 standards for handling risk, as well as what risk are.

ChristofferFriis at 21:59, 28 February 2021

2021-02-28T21:59:41Z

← Older revision		Revision as of 21:59, 28 February 2021
Line 77:		Line 77:

	Other relevant Management plans, Baselines, or relevant documents can be included in the project management plan. <ref name="PMIGuide"/>		Other relevant Management plans, Baselines, or relevant documents can be included in the project management plan. <ref name="PMIGuide"/>


	=== Project Documents ===		=== Project Documents ===
Line 97:		Line 98:

	• Stakeholder register		• Stakeholder register


	=== Agreements ===		=== Agreements ===
	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. <ref name="PMIGuide"/>		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. <ref name="PMIGuide"/>


	=== Procurement documentation ===		=== Procurement documentation ===

	Procuring goods and services from external sources may increase or decrease the risks for the project, as well as introduce new risks. The most up to date procurement documentation should therefore be reviewed for potential risks. <ref name="PMIGuide"/>		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. <ref name="PMIGuide"/>


	= Tools =		= Tools =
Line 129:		Line 133:

	• Meetings		• Meetings


	=== Expert judgement ===		=== Expert judgement ===
Line 135:		Line 140:

	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. <ref name="PMIGuide"/>		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. <ref name="PMIGuide"/>


	=== Data gathering ===		=== Data gathering ===
Line 163:		Line 169:
	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.		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.
	By stating a problem/benefit statement a root cause analysis can be used to detect threats or opportunities. <ref name="PMIGuide"/>		By stating a problem/benefit statement a root cause analysis can be used to detect threats or opportunities. <ref name="PMIGuide"/>


	=== Assumption and constraint analysis ===		=== Assumption and constraint analysis ===
Line 169:		Line 176:
	The assumptions, which the project has made, represent some unidentified risks. Analysing these assumptions will bring risk to light and assess their threat.		The assumptions, which the project has made, represent some unidentified risks. Analysing these assumptions will bring risk to light and assess their threat.
	The constraint that the project works under could potentially bring some opportunities to light. Analysing the constraint to see if any could be removed, or relaxed. <ref name="PMIGuide"/>		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. <ref name="PMIGuide"/>


	=== SWOT analysis ===		=== SWOT analysis ===
Line 178:		Line 186:

	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. <ref name="Prince2"/><ref name="RBS"/>		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. <ref name="Prince2"/><ref name="RBS"/>


	= Output =		= Output =

	The output from identifying risk is three folded: the risk register, the risk report, and updates of project documents.		The output from identifying risk is three folded: the risk register, the risk report, and updates of project documents.


	=== Risk register ===		=== Risk register ===
Line 193:		Line 203:

	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. <ref name="PMIGuide"/>		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. <ref name="PMIGuide"/>


	=== Risk report ===		=== Risk report ===

	The risk report includes the sources of overall project risk, as well as a summary of individual project risks. <ref name="PMIGuide"/>		The risk report includes the sources of overall project risk, as well as a summary of individual project risks. <ref name="PMIGuide"/>


	=== Project documents updates ===		=== Project documents updates ===

	It is important that in the end of the process of identifying risk, all relevant existing documents are updated. This could include documents such as: Assumption log, Issue log, and lessons learned register. <ref name="PMIGuide"/>		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. <ref name="PMIGuide"/>


	= Limitations =		= Limitations =
Line 207:		Line 220:

	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. <ref name="PMIGuide"/>		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. <ref name="PMIGuide"/>


	= Annotated bibliography =		= Annotated bibliography =
Line 218:		Line 232:
	• Managing Successful Projects with PRINCE2 2017 Edition		• Managing Successful Projects with PRINCE2 2017 Edition
	Chapter 10 looks into risk, and PRINCE2 standards for handling risk, as well as what risk are.		Chapter 10 looks into risk, and PRINCE2 standards for handling risk, as well as what risk are.


	= References =		= References =

ChristofferFriis at 21:57, 28 February 2021

2021-02-28T21:57:32Z

← Older revision		Revision as of 21:57, 28 February 2021
Line 130:		Line 130:
	• Meetings		• Meetings

	== Expert judgement ==		=== Expert judgement ===

	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.		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.
Line 136:		Line 136:
	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. <ref name="PMIGuide"/>		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. <ref name="PMIGuide"/>

	== Data gathering ==		=== Data gathering ===

	There are multiple techniques to gather data related to risk. Here there are highlighted some, which are widely used		There are multiple techniques to gather data related to risk. Here there are highlighted some, which are widely used

	=== Brainstorming ===		==== Brainstorming ====

	In a brainstorm the goal is 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.		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.
Line 146:		Line 146:
	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. <ref name="PMIGuide"/>		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. <ref name="PMIGuide"/>

	=== Checklist ===		==== Checklist ====

	Information and knowledge gather from similar projects, experience and other sources can be compiled into a checklist of risk. The checklist is a list of potential risk which have been seen before. This list can then be updated throughout the project. <ref name="std"/>		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. <ref name="std"/>
Line 153:		Line 153:
	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. <ref name="PMIGuide"/>		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. <ref name="PMIGuide"/>

	=== Interviews ===		==== Interviews ====

	Interview is another method of identifying project risks. The interviews can be carried out with any person or group that have relevant for the project (project participants, stakeholders, experts, ect.).		Interview is another method of identifying project risks. The interviews can be carried out with any person or group that have relevant for the project (project participants, stakeholders, experts, ect.).
Line 183:		Line 183:
	The output from identifying risk is three folded: the risk register, the risk report, and updates of project documents.		The output from identifying risk is three folded: the risk register, the risk report, and updates of project documents.

	== Risk register ==		=== Risk register ===

	The risk register is, as the name may suggest, where all individual 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. <ref name="Prince2"/>		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. <ref name="Prince2"/>
Line 194:		Line 194:
	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. <ref name="PMIGuide"/>		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. <ref name="PMIGuide"/>

	== Risk report ==		=== Risk report ===

	The risk report includes the sources of overall project risk, as well as a summary of individual project risks. <ref name="PMIGuide"/>		The risk report includes the sources of overall project risk, as well as a summary of individual project risks. <ref name="PMIGuide"/>

	== Project documents updates ==		=== Project documents updates ===

	It is important that in the end of the process of identifying risk, all relevant existing documents are updated. This could include documents such as: Assumption log, Issue log, and lessons learned register. <ref name="PMIGuide"/>		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. <ref name="PMIGuide"/>

ChristofferFriis at 21:55, 28 February 2021

2021-02-28T21:55:50Z

← Older revision		Revision as of 21:55, 28 February 2021
Line 6:		Line 6:
	The last part is the output. The output is 3 folded; 1. Risk register. 2. Risk report. 3. Project documents updates.		The last part is the output. The output is 3 folded; 1. Risk register. 2. Risk report. 3. Project documents updates.

	The 3 parts of identifying risks (input, tools & output) will be descried in greater details. <ref name="PMIGuide"/><ref name="std"/>		The 3 parts of identifying risks (input, tools & output) will be descried in greater details. <ref name="PMIGuide"/><ref name="std"/><ref name="Prince2"/>

ChristofferFriis at 21:55, 28 February 2021

2021-02-28T21:55:20Z

← Older revision		Revision as of 21:55, 28 February 2021
Line 12:		Line 12:

	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. <ref name="PMIGuide"/><ref name="std"/>		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. <ref name="PMIGuide"/><ref name="std"/>
	<ref name="Prince2"/>		<ref name="Prince2"/>


	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. <ref name="PMIGuide"/>		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. <ref name="PMIGuide"/>

ChristofferFriis at 21:54, 28 February 2021

2021-02-28T21:54:46Z

Show changes

ChristofferFriis at 20:43, 28 February 2021

2021-02-28T20:43:10Z

← Older revision		Revision as of 20:43, 28 February 2021
Line 6:		Line 6:
	The last part is the output. The output is 3 folded; 1. Risk register. 2. Risk report. 3. Project documents updates.		The last part is the output. The output is 3 folded; 1. Risk register. 2. Risk report. 3. Project documents updates.

	The 3 parts of identifying risks (input, tools & output) will be descried in greater details. <ref name="PMIGuide"/>		The 3 parts of identifying risks (input, tools & output) will be descried in greater details. <ref name="PMIGuide"/><ref name="Prince2"/>

	= Big idea =		= Big idea =

ChristofferFriis at 20:42, 28 February 2021

2021-02-28T20:42:44Z

← Older revision		Revision as of 20:42, 28 February 2021
Line 10:		Line 10:
	= Big idea =		= Big idea =

	Identifying risk is a never-ending job for a project and should be treated as such. By not only identifying risk at the beginning of the project, but throughout the project’s life cycle. Risk will be overseen the first time around and new risk will accurse. Therefore, this process needs to be repeated. <ref name="PMIGuide"/>(ref2)~~(ref3)~~		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. <ref name="PMIGuide"/>(ref2) <ref name="Prince2"/>


	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. <ref name="PMIGuide"/>		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. <ref name="PMIGuide"/>
Line 16:		Line 17:
	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. <ref name="PMIGuide"/>		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. <ref name="PMIGuide"/>

	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)~~<ref name="PMIGuide"/>		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: <ref name="Prince2"/>
			<ref name="PMIGuide"/>

	- Project manager		- Project manager
Line 172:		Line 174:
	=== Risk breakdown structure ===		=== Risk breakdown structure ===

	~~(ref3)~~		<ref name="Prince2"/>

	= Output =		= Output =

ChristofferFriis at 20:41, 28 February 2021

2021-02-28T20:41:16Z

← Older revision		Revision as of 20:41, 28 February 2021
Line 208:		Line 208:
	<references>		<references>
	<ref name="PMIGuide">Guide to the Project Management Body of Knowledge (PMBOK® Guide) (6th Edition), Project Management Institute, Inc.(2017)</ref>		<ref name="PMIGuide">Guide to the Project Management Body of Knowledge (PMBOK® Guide) (6th Edition), Project Management Institute, Inc.(2017)</ref>
			<ref name="Prince2">Managing Successful Projects with PRINCE2 2017 Edition, AXELOS (2017)</ref>