12 Project Procurement Management

It includes the management and control processes required to develop and administer agreements: contracts, purchase orders, memorandum of agreements, service level agreement.

Key Concepts for Project Procurement Management

There can be significant legal obligations and penalties tied to the procurement process. The project manager should be familiar enough with the procurement process to make intelligent decisions regarding contracts and contractual relationships. The project manager is typically not authorized to sign legal agreements binding the organization; this is reserved for those who have the authority to do so.

Trends and Emerging Practices in Procurement Management

• Advances in tools. A single point where procurements can be advertised and provide sellers with a single source to find procurement documents and complete them directly online.
• More advanced risk management. To write contracts that accurately allocate specific risks to those entities most capable of managing them. No contractor is capable of managing all the possible major risks on a project. Contracts may specify that risk management be performed as part of the contract.
• Changing contracting processes. International contracts with multiple contractors from many countries => the use of internationally recognized standard contract forms is increasing in order to reduce problems and claims during execution.
• Logistics and supply chain management. For long-lead items, both the manufacture of the items and their transportation to the project site become schedule-drivers. Long-lead items may be procured in advance of other procurement contracts to meet the planned project completion date. It is possible to begin contracting for these long-lead materials, supplies, or equipment before the final design of the end product itself is completed based on the known requirements identified in the top-level design. Not only are primary sources of supplies identified early in the project, but secondary, back-up sources are also generally identified. Many countries around the world require international contractors to purchase certain minimum percentages of material and supplies from local vendors.
• Technology and stakeholder relations. Publicly funded projects are under increasing scrutiny. A trend in infrastructure and commercial construction projects is the use of technology including web cameras (webcams) to improve stakeholder communications and relations.
• Trial engagements. Some projects will engage several candidate sellers for initial deliverables and work products on a paid basis before making the full commitment to a larger portion of the project scopeTail

Tailoring Considerations

• Complexity of procurement. Is there one main procurement or are there multiple procurements at different times with different sellers that add to the complexity of the procurements?
• Physical location. Are the buyers and sellers in the same location, or reasonably close, or in different time zones, countries, or continents?
• Governance and regulatory environment. Are local laws and regulations regarding procurement activities integrated with the organization's procurement policies? How does this affect contract auditing requirements?
• Availability of contractors. Are there available contractors who are capable of performing the work?

Considerations for Agile/Adaptive Environment

Specific sellers may be used to extend the team. This collaborative working relationship can lead to a shared risk procurement model where both the buyer and the seller share in the risk and rewards associated with a project.

Larger projects may use an adaptive approach for some deliverables and a more stable approach for other parts. In these cases, a governing agreement such as a master services agreement (MSA) may be used for the overall engagement, with the adaptive work being placed in an appendix or supplement. This allows changes to occur on the adaptive scope without impacting the overall contract.

Link to the origin post

11.7 Monitor Risks

Description: the process of monitoring the implementation of agreed-upon risk response plans, tracking identified risks, identifying and analyzing new risks, and evaluating risk process effectiveness throughout the project. The process uses performance information generated during project execution to determine if:

• Implemented risk responses are effective,
• Level of overall project risk has changed,
• Status of identified individual project risks has changed,
• New individual project risks have arisen,
• Risk management approach is still appropriate,
• Project assumptions are still valid,
• Risk management policies and procedures are being followed,
• Contingency reserves for cost or schedule require modification, and
• Project strategy is still valid.

Key benefit: it enables project decisions to be based on current information about overall project risk exposure and individual project risks.

Frequency: throughout the project.

Process / Asset Group	Input	The Process	Output	Process / Asset Group
Project Management Plan	Risk management plan	11.7 Monitor Risks	Work performance information	4.5 Monitor and Control Project Work
Project Documents	Issue log		Change requests	4.6 Perform Integrated Change Control
	Lesson learned register		Components	Project Management Plan
	Risk register		Assumption log	Project Documents
	Risk report		Issue log
4.3 Direct and Manage Project Work	Work performance data		Lesson learned register
4.5 Monitor and Control Project Work	Work performance reports		Risk register
			Risk report
			Organizational process assets update	Enterprise / Organization

11.7.1 Inputs

11.7.1.1 Project Management Plan

The risk management plan - guidance on how and when risks should be reviewed, which policies and procedures should be followed, the roles and responsibilities in the monitoring process, and reporting formats.

11.7.1.2 Project Documents

• Issue log.
• Lesson learned register.
• Risk register.
• Risk report.

11.7.1.3 Work Performance Data

Data on project status such as

• Risk responses that have been implemented,
• Risks that have occurred,
• Risks that are active and those that have been closed out.

11.7.1.4 Work Performance Reports

The information is relevant when monitoring performance-related risks:

• Variance analysis
• Earned value data
• Forecasting data

11.7.2 Tools and Techniques

11.7.2.1 Data Analysis

• Technical performance analysis. Technical performance analysis compares technical accomplishments during project execution to the schedule of technical achievement. It requires the definition of objective, quantifiable measures of technical performance, which can be used to compare actual results against targets. Such technical performance measures may include weight, transaction times, number of delivered defects, storage capacity, etc. Deviation can indicate the potential impact of threats or opportunities.
• Reserve analysis. Reserve analysis compares the amount of the contingency reserves remaining to the amount of risk remaining at any time in the project in order to determine if the remaining reserve is adequate. This may be communicated using various graphical representations, including a burndown chart.

11.7.2.2 Audits

A type of audit that may be used to consider the effectiveness of the risk management process. The project manager is responsible for ensuring that risk audits are performed at an appropriate frequency, as defined in the project's risk management plan. Risk audits may be included during routine project review meetings or may form part of a risk review meeting, or the team may choose to hold separate risk audit meetings. The format for the risk audit and its objectives should be clearly defined before the audit is conducted.

11.7.2.3 Meetings

Risk reviews are scheduled regularly and should examine and document the effectiveness of risk responses in dealing with overall project risk and with identified individual project risks. Risk reviews may also result in

• Identification of new individual project risks, (including secondary risks that arise from agreed-upon risk responses),
• Reassessment of current risks,
• The closing of risks that are outdated,
• Issues that have arisen as the result of risks that have occurred, and
• Identification of lessons to be learned for implementation in ongoing phases in the current project or in similar projects in the future.

The risk review may be conducted as part of a periodic project status meeting or a dedicated risk review meeting may be held, as specified in the risk management plan.

11.7.3 Outputs

11.7.3.1 Work Performance Information

How project risk management is performing by comparing the individual risks that have occurred with the expectation of how they would occur.

11.7.3.2 Change Requests

11.7.3.3 Project Management Plan Updates

11.7.3.4 Project Document Updates

• Assumption log.
• Issue log.
• Lesson learned register.
• Risk register.
• Risk report.
  • Reflect the current status of major individual project risks
  • The current level of overall project risk.
  • Details of the top individual project risks,
  • Agreed-upon responses and owners,
  • Conclusions and
  • Recommendations.
  • Conclusions from risk audits on the effectiveness of the risk management process.

11.7.3.5 Organizational Process Asset Updates

• Templates for the risk management plan, risk register, and risk report; and
• Risk breakdown structure.

Ling to the original post

11.6 Implement Risk Responses

Description: the process of implementing agreed-upon risk response plans.

Key benefit: it ensures that agreed-upon risk responses are executed as planned in order to address overall project risk exposure, minimize individual project threats, and maximize individual project opportunities.

Frequency: throughout the project.

Process / Asset Group	Input	The Process	Output	Process / Asset Group
Project Management Plan	Risk management plan	11.6 Implement Risk Responses	Change requests	4.6 Perform Integrated Change Control
Project Documents	Lesson learned register		Lesson learned register	Project Documents
	Risk register		Issue log
	Risk report		Project team assignment
Enterprise / Organization	Organizational process assets		Risk register
			Risk report

11.6.1 Inputs

11.6.1.1 Project Management Plan

The risk management plan

• Lists the roles and responsibilities of project team members and other stakeholders for risk management.
• Defines the level of detail for the risk management methodology for the project.
• Specifies risk thresholds for the project based on the risk appetite of key stakeholders, which define the acceptable target that the implementation of risk responses is required to achieve.

11.6.1.2 Project Documents

• Lesson learned register.
• Risk register. Records the agreed-upon risk responses for each individual risk and the nominated owners for each response plan.
• Risk report. Includes
  • An assessment of the current overall project risk exposure,
  • The agreed-upon risk response strategy.
  • Describes the major individual project risks with their planned responses.

11.6.1.3 Organizational Process Assets

The lessons learned repository.

11.6.2 Tools and Techniques

11.6.2.1 Expert Judgement

To validate or modify risk responses if necessary, and decide how to implement them in the most efficient and effective manner.

11.6.2.2 Interpersonal and Team Skills

Influencing.

11.6.2.3 Project Management Informational System (PMIS)

11.6.3 Outputs

11.6.3.1 Change Requests

11.6.3.2 Project Documents Updates

• Issue log.
• Lesson learned register. Updated with information on challenges encountered when implementing risk responses and how they could have been avoided, as well as approaches that worked well for implementing risk responses.
• Project team assignments.
• Risk register. Updated to reflect any changes to the previously agreed-upon risk responses for individual project risks that are subsequently made as a result of the Implement Risk Responses process.
• Risk report. 

Link to the original post.

11.5 Plan Risk Responses

Description: the process of developing options, selecting strategies, and agreeing on actions to address overall project risk exposure and individual project risks. The process allocates resources and inserts activities into project documents and the project management plan as needed. Unsuitable risk responses can have the converse effect. Once risks have been identified, analyzed, and prioritized, plans should be developed by the nominated risk owner for addressing every individual project risk the project team considers to be sufficiently important, either because of the threat it poses to the project objectives or the opportunity it offers. Risk responses should be appropriate for the significance of the risk, cost-effective in meeting the challenge, realistic within the project context, agreed upon by all parties involved, and owned by a responsible person. Secondary risks should also be identified. Secondary risks are risks that arise as a direct result of implementing a risk response. A contingency reserve is often allocated for time or cost. If developed, it may include identification of the conditions that trigger its use.

Key benefit: it identifies appropriate ways to address overall project risk and individual project risks.

Frequency: throughout the project.

Process / Asset Group	Input	The Process	Output	Process / Asset Group
Project Management Plan	Resource management plan	11.5 Plan Risk Responses	Change requests	4.6 Perform Integrated Change Control
	Risk management plan			Project Management Plan
	Cost baseline		Schedule management plan
Project Documents	Lesson learned register		Cost management plan
	Project schedule		Quality management plan
	Resource breakdown structure		Resource management plan
	Resource calendars		Procurement management plan
	Risk register		Scope baseline
	Risk report		Schedule baseline
	Stakeholder register		Cost baseline
Enterprise / Organization	Enterprise environmental factors		Assumption log	Project Documents
	Organizational process assets		Cost forecasts
			Lesson learned regiaster
			Project schedule
			Project team assignment
			Risk register
			Risk report

10.5.1 Inputs

11.5.1.1 Project Management Plan

• Resource management plan. To help determine how resources allocated to agreed-upon risk responses will be coordinated with other project resources.
• Risk management plan. Risk management roles and responsibilities and risk thresholds.
• Cost baseline. Information on the contingency fund.

11.5.1.2 Project Documents

• Lesson learned register.
• Project schedule. To determine how agreed-upon risk responses will be scheduled alongside other project activities.
• Project team assignments. The resources that can be allocated to agreed-upon risk responses.
• Resource calendars. When potential resources are available to be allocated to agreed-upon risk responses.
• Risk register. Details of individual project risks that have been identified and prioritized, and for which risk responses are required. The priority level for each risk can help to guide the selection of appropriate risk responses. The nominated risk owner for each risk. It may also contain preliminary risk responses identified earlier in the Project Risk Management process.
• Risk report. The current level of overall risk exposure.
• Stakeholder register. Potential owners for risk responses.

11.5.1.3 Enterprise Environmental Factors

The risk appetite and thresholds of key stakeholders.

11.5.1.4 Organizational Process Assets

• Templates for the risk management plan, risk register, and risk report;
• Historical databases; and
• Lessons learned repositories from similar projects.

11.5.2 Tools and Techniques

11.5.2.1 Expert Judgment

• Threat response strategies,
• Opportunity response strategies,
• Contingent response strategies, and
• Overall project risk response strategies.

11.5.2.2 Data Gathering

Interviews.

11.5.2.3 Interpersonal and Team Skills

Facilitation. To understand the risk, identify and compare alternative possible risk response strategies, choose an appropriate response strategy, and identify and overcome sources of bias.

11.5.2.4 Strategies for Threats

1. Escalate. A threat is outside the scope of the project or that the proposed response would exceed the project manager's authority. Escalated risks are managed at the program level, portfolio level, or other relevant part of the organization, and not on the project level. It is important that ownership of escalated threats is accepted by the relevant party in the organization. Escalated threats are not monitored further by the project team after escalation, although they may be recorded in the risk register for information.
2. Avoid. To eliminate the threat or protect the project from its impact. Change the project management plan/objectives => reduce probability of the risk to zero.
   1. Remove the cause of the a threat;
   2. Extend the schedule;
   3. Change the project strategy;
   4. Reduce scope;
   5. Clarify requirements;
   6. Obtain information;
   7. Improve communication;
   8. Acquire expertise.
3. Transfer. Shifting ownership of a threat to a third party to manage the risk and to bear the impact if the threat occurs:
   1. Use of insurance;
   2. Performance bonds;
   3. Warranties;
   4. Guaranties;
   5. Agreements.
4. Mitigate. Reduce the probability of occurrence and/or impact of a threat. Action to mitigate risks, redundancies, others.
5. Accept. No proactive action is taken. Active acceptance - create a contingency reserves. Passive - periodic review only.

11.5.2.5 Strategies for Opportunities

1. Escalate.
2. Exploit.
3. Share.
4. Enhance. Increase the probability and/or impact of an opportunity.
5. Accept.

11.5.2.6 Contingent Response Strategies

For some risks, it is appropriate for the project team to make a response plan that will only be executed under certain predefined conditions, if it is believed that there will be sufficient warning to implement the plan. Events that trigger the contingency response, such as missing intermediate milestones or gaining higher priority with a seller, should be defined and tracked. Risk responses identified using this technique are often called contingency plans or fallback plans and include identified triggering events that set the plans in effect.

11.5.2.7 Strategies for Overall Project Risk

• Escalate.
• Exploit.
• Transfer/Share.
• Mitigate/Enhance.
• Accept.

11.5.2.8 Data Analysis

• Alternatives analysis. A simple comparison of the characteristics and requirements of alternative risk response options.
• Cost-benefit analysis.

11.5.2.9 Decision Making

Multicriteria decision analysis uses a decision matrix to provide a systematic approach for establishing key decision criteria, evaluating and ranking alternatives, and selecting a preferred option. Criteria for risk response selection may include but are not limited to

• Cost of response,
• Likely effectiveness of response in changing probability and/or impact,
• Resource availability,
• Timing constraints (urgency, proximity, and dormancy),
• Level of impact if the risk occurs,
• Effect of response on related risks,
• Introduction of secondary risks,
• Etc.

11.5.3 Outputs

11.5.3.1 Change Requests

11.5.3.2 Project Management Plan Updates

• Schedule management plan. Changes to resource loading and leveling, or updates to the schedule strategy.
• Cost management plan. Changes to cost accounting, tracking, and reports, as well as updates to the budget strategy and how contingency reserves are consumed.
• Quality management plan. Changes to approaches for meeting requirements, quality management approaches, or quality control processes.
• Resource management plan. Changes to resource allocation, as well as updates to the resource strategy.
• Procurement management plan. Alterations in the make-or-buy decision or contract type(s).
• Scope baseline.
• Schedule baseline.
• Cost baseline.

11.5.3.3 Project Documents Updates

• Assumption log. New assumptions and constraints.
• Cost forecasts.
• Lesson learned register.
• Project schedule.
• Project team assignment.
• Risk register.
  • Agreed-upon response strategies.
  • Specific actions to implement the chosen response strategy.
  • Trigger conditions, symptoms, and warning signs of a risk occurrence.
  • Budget and schedule activities required to implement the chosen responses.
  • Contingency plans and risk triggers that call for their execution.
  • Fallback plans for use when a risk that has occurred and the primary response proves to be inadequate.
  • Residual risks that are expected to remain after planned responses have been taken or accepted.
  • Secondary risks that arise as a direct outcome of a risk response.
  
  Link to the original post

11.4 Perform Quantitative Risk Analysis

Description: the process of numerically analyzing the combined effect of identified individual project risks and other sources of uncertainty on overall project objectives. It usually requires specialized risk software and expertise in the development and interpretation of risk models. It also consumes additional time and cost. It is the only reliable method to assess overall project risk through evaluating the aggregated effect on project outcomes of all individual project risks and other sources of uncertainty. It uses information on individual project risks that have been assessed by the Perform Qualitative Risk Analysis process.

Key benefit: it quantifies overall project risk exposure, can also provide additional quantitative risk information to support risk planning.

Frequency: throughout the project (if used on the project).

Process / Asset Group	Input	The Process	Output	Process / Asset Group
Project Management Plan	Risk Management Plan	11.4 Perform Quantitative Risk Analysis	Risk Report	Project Documents
	Scope baseline
	Schedule baseline
	Cost baseline
Project Documents	Assumption log
	Base of estimates
	Cost estimates
	Cost forecasts
	Duration Estimates
	Milestone list
	Resource requirements
	Risk register
	Risk report
	Schedule forecasts
Enterprise / Organization	Enterprise Environment Factors
	Organizational process assets

11.4.1 Inputs

11.4.1.1 Project Management Plan

• Risk management plan. Whether quantitative risk analysis is required for the project. It also details the resources available for the analysis and the expected frequency of analyses.
• Scope baseline. The starting point from which the effect of individual project risks and other sources of uncertainty are evaluated.
• Schedule baseline. The starting point from which the effect of individual project risks and other sources of uncertainty can be evaluated.
• Cost baseline. The starting point from which the effect of individual project risks and other sources of uncertainty can be evaluated.

11.4.1.2 Project Documents

• Assumption log.
• Basis of estimates. It may be reflected in variability modeled during a quantitative risk analysis process. This may include information on the estimate's purpose, classification, assumed accuracy, methodology, and source.
• Cost estimates.
• Cost forecasts. Estimate to complete (ETC), estimate at completion (EAC), budget at completion (BAC), and to-complete performance index (TCPI) may be compared to the results of a quantitative cost risk analysis to determine the confidence level associated with achieving these targets.
• Duration estimates.
• Milestone list.
• Resource requirements.
• Risk register.
• Risk report.
• Schedule forecast.

11.4.1.3 Enterprise Environmental Factors

• Industry studies of similar projects;
• Published material, including commercial risk databases or checklists.

11.4.1.4 Organizational Process Assets

Information from similar completed projects.

14.4.2 Tools and Techniques

11.4.2.1 Expert Judgement

• Translating information on individual project risks and other sources of uncertainty into numeric inputs for the quantitative risk analysis model,
• Selecting the most appropriate representation of uncertainty to model particular risks or other sources of uncertainty,
• Modeling techniques that are appropriate in the context of the project,
• Identifying which tools would be most suitable for the selected modeling techniques, and
• Interpreting the outputs of quantitative risk analysis.

14.4.2.2 Data Gathering

Interviews.

14.4.2.3 Interpersonal and Team Skills

Facilitation.

14.4.2.4 Representations of Uncertainty

Range of possible values with distribution types:

• Triangular
• Normal
• Lognormal
• Beta
• Uniform
• Discrete

Risks as probabilistic branches. Branches are most useful for risks that might occur independently of any planned activity. Where risks are related, for example, with a common cause or a logical dependency, correlation is used in the model to indicate this relationship.

14.4.2.5 Data Analysis

• Simulation. A model that simulates the combined effects of individual project risks and other sources of uncertainty to evaluate their potential impact on achieving project objectives. a criticality analysis that determines which elements of the risk model have the greatest effect on the project critical path. A criticality index is calculated for each element in the risk model, which gives the frequency with which that element appears on the critical path during the simulation, usually expressed as a percentage.
• Sensitivity analysis. Which individual project risks or other sources of uncertainty have the most potential impact on project outcomes. It correlates variations in project outcomes with variations in elements of the quantitative risk analysis model.

• Decision tree analysis used to support selection of the best of several alternative courses of action. Alternative paths through the project are shown in the decision tree using branches representing different decisions or events, each of which can have associated costs and related individual project risks (including both threats and opportunities). The end-points of branches in the decision tree represent the outcome from following that particular path, which can be negative or positive.

• Influence diagrams. graphical aids to decision making under uncertainty. An influence diagram represents a project or situation within the project as a set of entities, outcomes, and influences, together with the relationships and effects between them. Where an element in the influence diagram is uncertain as a result of the existence of individual project risks or other sources of uncertainty, this can be represented in the influence diagram using ranges or probability distributions. The influence diagram is then evaluated using a simulation technique, such as Monte Carlo analysis, to indicate which elements have the greatest influence on key outcomes. Outputs from an influence diagram are similar to other quantitative risk analysis methods, including S-curves and tornado diagrams.

11.4.3 Outputs

11.4.3.1 Project Documents Updates

Risk report:

• Assessment of overall project risk exposure.
  • Chances of project success, indicated by the probability that the project will achieve its key objectives.
  • Degree of inherent variability remaining within the project at the time the analysis was conducted, indicated by the range of possible project outcomes.
• Detailed probabilistic analysis of the project. S-curves, tornado diagrams, and criticality analysis, together with a narrative interpretation of the results.
  • Amount of contingency reserve needed to provide a specified level of confidence;
  • Identification of individual project risks or other sources of uncertainty that have the greatest effect on the project critical path; and
  • Major drivers of overall project risk, with the greatest influence on uncertainty in project outcomes.
• Prioritized list of individual project risks.
• Trends in quantitative risk analysis results.
• Recommended risk responses.

Link to the original post

11.3 Perform Qualitative Risk Analysis

Description: the process of prioritizing individual project risks for further analysis or action by assessing their probability of occurrence and impact and other characteristics. Such assessments are subjective as they are based on perceptions of risk by the project team and other stakeholders. So it requires explicit identification and management of the risk attitudes of key participants. The process establishes the relative priorities of individual project risks for Plan Risk Responses. It identifies a risk owner for each risk who will take responsibility for planning an appropriate risk response and ensuring that it is implemented. Perform Qualitative Risk Analysis also lays the foundation for Perform Quantitative Risk Analysis if this process is required.

Key benefits: it focuses effort on high-priority risks.

Frequency: throughout the project.

Process / Asset Group	Input	The process	Output	Process / Asset Group
Project Management Plan	Risk management plan	11.3 Perform Qualitative Risk Analysis	Assumption log	Project Documents
Project Documents	Assumption log		Issue log
	Risk register		Risk register
	Stakeholder register		Risk report
Enterprise / Organization	Enterprise environment factors
	Organization process assets

11.3.1 Inputs

11.3.1.1 Project Management Plan

The risk management plan. Roles and responsibilities for conducting risk management, budgets for risk management, schedule activities for risk management, risk categories (often defined in a risk breakdown structure), definitions of probability and impact, the probability and impact matrix, and stakeholders’ risk thresholds.

11.3.1.2 Project Documents

• Assumption log. For identifying, managing, and monitoring key assumptions and constraints that may affect the project.
• Risk register. Details of each identified individual project risk.
• Stakeholder register. Details of project stakeholders who may be nominated as risk owners.

11.3.1.3 Enterprise Environment Factors

• Industry studies of similar projects,
• Published material, including commercial risk databases or checklists.

11.3.1.4 Organizational Process Assets

Information from similar completed projects.

11.3.2 Tools and Techniques

11.3.2.1 Expert Judgement

• Previous similar projects, and
• Qualitative risk analysis.

11.3.2.2 Data Gathering

Interviews.

11.3.2.3 Data Analysis

• Risk data quality assessment. It may be assessed via a questionnaire measuring the project's stakeholder perceptions of various characteristics, which may include completeness, objectivity, relevancy, and timeliness. A weighted average of selected data quality characteristics can then be generated to give an overall quality score.
• Risk probability and impact assessment. Probability and impact are assessed for each identified individual project risk. Differences in the levels of probability and impact perceived by stakeholders are to be expected, and such differences should be explored. Explanatory detail, including assumptions justifying the levels assigned, are also recorded. Risk probabilities and impacts are assessed using the definitions given in the risk management plan.
• Assessment of other risk parameters.
  • Urgency. The period of time within which a response to the risk is to be implemented in order to be effective. A short period indicates high urgency.
  • Proximity. The period of time before the risk might have an impact on one or more project objectives. A short period indicates high proximity.
  • Dormancy. The period of time that may elapse after a risk has occurred before its impact is discovered. A short period indicates low dormancy.
  • Manageability. The ease with which the risk owner (or owning organization) can manage the occurrence or impact of a risk. Where management is easy, manageability is high.
  • Controllability. The degree to which the risk owner (or owning organization) is able to control the risk's outcome. Where the outcome can be easily controlled, controllability is high.
  • Detectability. The ease with which the results of the risk occurring, or being about to occur, can be detected and recognized. Where the risk occurrence can be detected easily, detectability is high.
  • Connectivity. The extent to which the risk is related to other individual project risks. Where a risk is connected to many other risks, connectivity is high.
  • Strategic impact. The potential for the risk to have a positive or negative effect on the organization's strategic goals. Where the risk has a major effect on strategic goals, strategic impact is high.
  • Propinquity. The degree to which a risk is perceived to matter by one or more stakeholders. Where a risk is perceived as very significant, propinquity is high.

11.3.2.4 Interpersonal and Team Skills

Facilitation.

11.3.2.5 Risk Categorization

Risks to the project can be categorized by

• Sources of risk RBS;
• The area of the project affected (WBS);
• Common root causes ;
• Other useful categories (e.g., project phase, project budget, and roles and responsibilities)

to determine the areas of the project most exposed to the effects of uncertainty. Risk categories that may be used for the project are defined in the risk management plan.

11.3.2.6 Data Representation

• Probability and impact matrix. A grid for mapping the probability of each risk occurrence and its impact on project objectives if that risk occurs. This matrix specifies combinations of probability and impact that allow individual project risks to be divided into priority groups. Individual project risks are assigned to a priority level based on the combination of their assessed probability and impact, using a probability and impact matrix.
• Hierarchical charts. For 3d measure of risk bubble chart can be used.

11.3.2.7 Meetings

Risk workshop. The goals of this meeting include the review of previously identified risks, assessment of probability and impacts (and possibly other risk parameters), categorization, and prioritization. A risk owner, who will be responsible for planning an appropriate risk response and for reporting progress on managing the risk, will be allocated to each individual project risk as part of the Perform Qualitative Risk Analysis process.

11.3.3 Outputs

11.3.3.1 Project Documents Updates

• Assumption log.
• Issue log.
• Risk register.
• Risk report.

Link to the original post

11.2 Identify Risks

Description: it is the process of identifying individual project risks as well as resources of overall project risks, and documenting their characteristics.

Key benefit: documentation of existing individual project risks and the sources of overall project risks.

Frequency: throughout the project. An iterative process

Process / Asset Group	Input	The Process	Output	Process / Asset Group
Project Management Plan	Requirements management plan	11.2 Identify Risks	Risk register	Project Documents
	Schedule management plan		Risk Report
	Cost management plan		Assumption log
	Resource management plan		Issue log
	Quality management plan		Lesson learned register
	Risk management plan
	Scope baseline
	Schedule baseline
	Cost baseline
Project Documents	Assumption log
	Cost estimates
	Duration estimates
	Issue log
	Lesson learned register
	Requirements documentation
	Resource requirements
	Stakeholder register
12.1 Plan Procurement Management	Procurement documentation
12.2 Conduct Procurements	Agreements
Enterprise / Organization	Enterprise environment factors
	Organizational process assets

All project stakeholders should be encouraged to identify individual project risks. It is particularly important to involve the project team so they can develop and maintain a sense of ownership and responsibility for identified individual project risks, the level of overall project risk, and associated risk response actions.

Risk owners for individual project risks may be nominated as part of the Identify Risks process, and will be confirmed during the Perform Qualitative Risk Analysis process. Preliminary risk responses may also be identified and recorded and will be reviewed and confirmed as part of the Plan Risk Responses process.

11.2.1 Inputs

11.2.1.1 Project Management Plan

• Requirements management plan. May indicate project objectives that are particularly at risk.
• Schedule management plan. May identify areas that are subject to uncertainty or ambiguity.
• Cost management plan.
• Quality management plan.
• Resource management plan.
• Risk management plan.
• Scope baseline.
• Schedule baseline.
• Cost baseline.

11.2.1.2 Project Documents

• Assumption log.
• Cost estimates.
• Duration estimates.
• Issue log.
• Lessons learned register.
• Requirements documentation.
• Resource requirements.
• Stakeholder register.

11.2.1.3 Agreements

It may have information such as milestone dates, contract type, acceptance criteria, and awards and penalties that can present threats or opportunities.

11.2.1.4 Procurement Documentation

The initial procurement documentation should be reviewed as procuring goods and services from outside the organization may increase or decrease overall project risk and may introduce additional individual project risks.

11.2.1.5 Enterprise Environment Factors

• Published material, including commercial risk databases or checklists,
• Academic studies,
• Benchmarking results, and
• Industry studies of similar projects.

11.2.1.6 Organizational Process Assets

Project files, including actual data,
Organizational and project process controls,
Risk statement formats, and
Checklists from previous similar projects.

11.2.2 Tools and Techniques

11.2.2.1 Expert Judgement

11.2.2.2 Data Gathering

• Brainstorming. The goal of brainstorming is to obtain a comprehensive list of individual project risks and sources of overall project risk. Categories of risk, such as in a risk breakdown structure, can be used as a framework. Particular attention should be paid to ensuring that risks identified through brainstorming are clearly described, since the technique can result in ideas that are not fully formed.
• Checklists. Risk checklists are developed based on historical information and knowledge that has been accumulated from similar projects and from other sources of information. The organization may maintain a risk checklist based on its own completed projects or may use generic risk checklists from the industry. While a checklist may be quick and simple to use, it is impossible to build an exhaustive one, and care should be taken to ensure the checklist is not used to avoid the effort of proper risk identification.
• Interviews.

11.2.2.3 Data Analysis

• Root cause analysis.
• Assumption and constraint analysis. Threats may be identified from the inaccuracy, instability, inconsistency, or incompleteness of assumptions. Constraints may give rise to opportunities through removing or relaxing a limiting factor that affects the execution of a project or process.
• SWOT analysis. (strengths, weaknesses, opportunities, and threats)
• Document analysis.

11.2.2.4 Interpersonal and Team Skills

Facilitation.

11.2.2.5 Prompt Lists

A predetermined list of risk categories that might give rise to individual project risks and that could also act as sources of overall project risk. The risk categories in the lowest level of the risk breakdown structure can be used as a prompt list for individual project risks.

• PESTLE (political, economic, social, technological, legal, environmental).
• TECOP (technical, environmental, commercial, operational, political), or
• VUCA (volatility, uncertainty, complexity, ambiguity).

11.2.2.6 Meetings

Often called a risk workshop.

11.2.3 Outputs

11.2.3.1 Risk Register

It captures details of identified individual project risks. May contain limited or extensive risk information depending on project variables such as size and complexity.

A short risk title, risk category, current risk status, one or more causes, one or more effects on objectives, risk triggers (events or conditions that indicate that a risk is about to occur), WBS reference of affected activities, and timing information (when was the risk identified, when might the risk occur, when might it no longer be relevant, and what is the deadline for taking action).

• List of identified risks. Each individual project risk is given a unique identifier in the risk register. A structured risk statement may be used to distinguish risks from their cause(s) and their effect(s).
• Potential risk owners. Where a potential risk owner has been identified during the Identify Risks process, the risk owner is recorded in the risk register. This will be confirmed during the Perform Qualitative Risk Analysis process.
• List of potential risk responses.

11.2.3.2 Risk Report

Information on sources of overall project risk, together with summary information on identified individual project risks. It is developed progressively throughout the Project Risk Management process.

• Sources of overall project risk, indicating which are the most important drivers of overall project risk exposure; and
• Summary information on identified individual project risks, such as number of identified threats and opportunities, distribution of risks across risk categories, metrics and trends, etc.

11.2.3.3 Project Documents Updates

• Assumption log.
• Issue log.
• Lessons learned register.

Link to the original post