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

11.1 Plan Risk Management

Description: it is a process of defining how to conduct risk management activities for a project.

Key benefit: it ensures that the degree, type, and visibility of risk management are proportionate to both risks and the importance of the project to the organization and other stakeholders.

Frequency: once or at predefined points in the project. It should begin when a project is conceived and should be completed early in the project. It may be necessary to revisit this process later in the project life cycle.

Process / Asset Group	Input	The Process	Output	Process / Asset Group
4.1 Develop Project Charter	Project charter	11.1 Plan Risk Management	Risk management plan	Project Management Plan
Project Management Plan	All components of the Project Management Plan
Project Documents	Stakeholder Register
Enterprise / Organization	Enterprise environment factors
	Organizational Process Assets

11.1.1 Inputs

11.1.1.1 Project Charter

The high-level project description and boundaries, high-level requirements, and risks.

11.1.1.2 Project Management Plan

All approved subsidiary management plans should be taken into consideration in order to make the risk management plan consistent with them.

11.1.1.3 Project Documents

Stakeholder register: details of the project's stakeholders and provides an overview of their project roles and their attitude toward risk on this project -> determining roles and responsibilities for managing risk on the project, as well as setting risk thresholds for the project.

11.1.1.4 Enterprise Environment Factors

Overall risk thresholds set by the organization or key stakeholders.

11.1.1.5 Organizational Process Assets

• Organizational risk policy;
• Risk categories, possibly organized into a risk breakdown structure;
• Common definitions of risk concepts and terms;
• Risk statement formats;
• Templates for the risk management plan, risk register, and risk report;
• Roles and responsibilities;
• Authority levels for decision making; and
• Lessons learned repository from previous similar projects.

11.1.2 Tools and Techniques

11.1.2.1 Expert Judgment

• Familiarity with the organization's approach to managing risk, including enterprise risk management where this is performed;
• Tailoring risk management to the specific needs of a project; and
• Types of risk that are likely to be encountered on projects in the same area.

11.1.2.2 Data Analysis

Stakeholder analysis to determine the risk appetite of project stakeholders.

11.1.2.3 Meetings

11.1.3 Outputs

11.1.3.1 Risk Management Plan

It is a component of the project management plan that describes how risk management activities will be structured and performed.

• Risk strategy. Describes the general approach to managing risk on this project.
• Methodology. Defines the specific approaches, tools, and data sources that will be used to perform risk management on the project.
• Roles and responsibilities. Defines the lead, support, and risk management team members for each type of activity described in the risk management plan, and clarifies their responsibilities.
• Funding. Identifies the funds needed to perform activities related to Project Risk Management. Establishes protocols for the application of contingency and management reserves.
• Timing. Defines when and how often the Project Risk Management processes will be performed throughout the project life cycle, and establishes risk management activities for inclusion into the project schedule.
• Risk categories. Provide a means for grouping individual project risks. A common way to structure risk categories is with a risk breakdown structure (RBS), which is a hierarchical representation of potential sources of risk.
• Stakeholder risk appetite. The risk appetites of key stakeholders on the project are recorded in the risk management plan, as they inform the details of the Plan Risk Management process. In particular, stakeholder risk appetite should be expressed as measurable risk thresholds around each project objective. These thresholds will determine the acceptable level of overall project risk exposure, and they are also used to inform the definitions of probability and impacts to be used when assessing and prioritizing individual project risks.
• Definitions of risk probability and impacts. Definitions of risk probability and impact levels are specific to the project context and reflect the risk appetite and thresholds of the organization and key stakeholders. The project may generate specific definitions of probability and impact levels or it may start with general definitions provided by the organization. The number of levels reflects the degree of detail required for the Project Risk Management process, with more levels used for a more detailed risk approach (typically five levels), and fewer for a simple process (usually three). An example of definitions of probability and impacts against three project objectives. These scales can be used to evaluate both threats and opportunities by interpreting the impact definitions as negative for threats (delay, additional cost, and performance shortfall) and positive for opportunities (reduced time or cost, and performance enhancement).
• Probability and impact matrix. Prioritization rules may be specified by the organization in advance of the project and be included in organizational process assets, or they may be tailored to the specific project. Opportunities and threats are represented in a common probability and impact matrix using positive definitions of impact for opportunities and negative impact definitions for threats. Descriptive terms (such as very high, high, medium, low, and very low) or numeric values can be used for probability and impact. Where numeric values are used, these can be multiplied to give a probability-impact score for each risk, which allows the relative priority of individual risks to be evaluated within each priority level. An example probability and impact matrix is presented in Figure 11-5, which also shows a possible numeric risk scoring scheme.
• Reporting formats. Reporting formats define how the outcomes of the Project Risk Management process will be documented, analyzed, and communicated. This section of the risk management plan describes the content and format of the risk register and the risk report, as well as any other required outputs from the Project Risk Management processes.
• Tracking. Tracking documents how risk activities will be recorded and how risk management processes will be audited.

Original post

11 Project Risk Management

Project Risk Management includes the processes of conducting risk management planning, identification, analysis, response planning, response implementation, and monitoring risk on a project. The objectives of project risk management are to increase the probability and/or impact of positive risks and to decrease the probability and/or impact of negative risks, in order to optimize the chances of project success.

Key Concepts for Project Risk Management

All projects are risky since they are unique undertakings with varying degrees of complexity that aim to deliver benefits. They do this in a context of constraints and assumptions, while responding to stakeholder expectations that may be conflicting and changing. Organizations should choose to take project risk in a controlled and intentional manner in order to create value while balancing risk and reward.

When unmanaged, these risks have the potential to cause the project to deviate from the plan and fail to achieve the defined project objectives.

Two level of of risks:

1. Individual project risk is an uncertain event or condition that, if it occurs, has a positive or negative effect on one or more project objectives.
2. Overall project risk is the effect of uncertainty on the project as a whole, arising from all sources of uncertainty including individual risks, representing the exposure of stakeholders to the implications of variations in project outcome, both positive and negative.

Risk can be positive (opportunity) and negative (threat).

Risk is initially addressed during project planning by shaping the project strategy. Risk should also be monitored and managed as the project progresses to ensure that the project stays on track and emergent risks are addressed.

The project team needs to know what level of risk exposure is acceptable in pursuit of the project objectives. This is defined by measurable risk thresholds that reflect the risk appetite of the organization and project stakeholders. Risk thresholds express the degree of acceptable variation around a project objective. They are explicitly stated and communicated to the project team and reflected in the definitions of risk impact levels for the project.

Trends and Emerging Practices in Project Risk Management

• Non-event risks.
  • Variability risk. Uncertainty exists about some key characteristics of a planned event or activity or decision. Examples of variability risks include: productivity may be above or below target, the number of errors found during testing may be higher or lower than expected. It can be addressed using Monte Carlo analysis, with the range of variation reflected in probability distributions, followed by actions to reduce the spread of possible outcomes.
  • Ambiguity risk. Uncertainty exists about what might happen in the future. Ambiguity risks are managed by defining those areas where there is a deficit of knowledge or understanding, then filling the gap by obtaining expert external input or bench-marking against best practices. Ambiguity is also addressed through incremental development, prototyping, or simulation.
• Project resilience. These are risks that can only be recognized after they have occurred. Emergent risks can be tackled through developing project resilience. This requires each project to have:
  • Right level of budget and schedule contingency for emergent risks, in addition to a specific risk budget for known risks;
  • Flexible project processes that can cope with emergent risk while maintaining overall direction toward project goals, including strong change management;
  • Empowered project team that has clear objectives and that is trusted to get the job done within agreed-upon limits;
  • Frequent review of early warning signs to identify emergent risks as early as possible;
  • Clear input from stakeholders to clarify areas where the project scope or strategy can be adjusted in response to emergent risks.
• Integrated risk management. Projects exist in an organizational context, and they may form part of a program or portfolio. Risk exists at each of these levels, and risks should be owned and managed at the appropriate level. This builds risk efficiency into the structure of programs and portfolios, providing the greatest overall value for a given level of risk exposure.

Tailoring Considerations

• Project size by.
  • Budget,
  • Duration,
  • Scope, or
  • Team size.
• Project complexity.
• Project importance.
• Development approach. Waterfall, iterative, agile, ...

Considerations for Agile/Adaptive Environments

High-variability environments, by definition, incur more uncertainty and risk -> use of frequent reviews of incremental work products and cross-functional project teams to accelerate knowledge sharing and ensure that risk is understood and managed. Risk is considered when selecting the content of each iteration, and risks will also be identified, analyzed, and managed during each iteration.

Additionally, the requirements are kept as a living document that is updated regularly, and work may be reprioritized as the project progresses, based on an improved understanding of current risk exposure.

Original post

10.3 Monitor Communications

Description: it is the process of ensuring timely and appropriate collection, creation, distribution, storage, retrieval, management, monitoring, and the ultimate disposition of project information. It identifies all aspects of effective communications (choice of technology, methods, techniques). Adjustments if methods and techniques to accommodate the changing needs of stakeholders and the project.

Techniques and considerations for effective communications management:

• Sender-receiver models. Incorporating feedback loops to provide opportunities for interaction/participation and remove barriers to effective communication.
• Choice of media. Decisions about application of communications artifacts to meet specific project needs, such as when to communicate in writing versus orally, when to prepare an informal memo versus a formal report, and when to use push/pull options and the choice of appropriate technology.
• Writing style. Appropriate use of active versus passive voice, sentence structure, and word choice.
• Meeting management. Preparing an agenda, inviting essential participants, and ensuring they attend. Dealing with conflicts within the meeting or resulting from inadequate follow-up of minutes and actions, or attendance of the wrong people.
• Presentations. Awareness of the impact of body language and design of visual aids.
• Facilitation. Building consensus and overcoming obstacles such as difficult group dynamics, and maintaining interest and enthusiasm among group members.
• Active listening. Listening actively involves acknowledging, clarifying and confirming, understanding, and removing barriers that adversely affect comprehension.

Process / Asset Group	Input	The process	Output	Process / Asset Group
Project Management Plan	Resource Management Plan	10.2 Manage Communications	Project Communications	Project Documents
	Communications management plan		Issue log	Project Management Plan
	Stakeholder engagement plan		Lesson learned register
Project Documents	Change log		Project schedule
	Issue log		Risk register
	Lesson learned register		Stakeholder register
	Quality report		Communications management plan	Project Management Plan
	Risk report		Stakeholder engagement plan	Enterprise / Organization
	Stakeholder register
4.5 Monitor and Control Project Work	Work performance reports
Enterprise / Organization	Enterprise environment factors
	Organizational process assets

Key benefit: it enables an efficient and effective information flow between the project team and the stakeholders.

Frequency: throughout the project.

10.2.1 Inputs

10.2.1.1 Project Management Plan

• Resource management plan. Describes the communications that are needed for management of team or physical resources.
• Communications management plan. How project communications will be planned, structured, monitored, and controlled.
• Stakeholder engagement plan. How stakeholders will be engaged through appropriate communication strategies.

10.2.1.2 Project Documents

• Change log. Used to communicate changes and approved, deferred, and rejected change requests to the impacted stakeholders.
• Issue log. Issues is communicated to impacted stakeholders.
• Lessons learned register.
• Quality report. It is forwarded to those who can take corrective actions in order to achieve the project quality expectations.
  • Quality issues,
  • Project and product improvements, and
  • Process improvements.
• Risk report. Information on sources of overall project risk, together with summary information on identified individual project risks. This information is communicated to risk owners and other impacted stakeholders.
• Stakeholder register. Identifies the individuals, groups, or organizations that will need various types of information.

10.2.1.3 Work Performance Reports

Status reports and progress reports.

10.2.1.4 Enterprise Environmental Factors

• Organizational culture, political climate, and governance framework;
• Personnel administration policies;
• Stakeholder risk thresholds;
• Established communication channels, tools, and systems;
• Global, regional, or local trends and practices or habits; and
• Geographic distribution of facilities and resources.

10.2.1.5 Organizational Process Assets

• Corporate policies and procedures for social media, ethics, and security;
• Corporate policies and procedures for issue, risk, change, and data management;
• Organizational communication requirements;
• Standardized guidelines for development, exchange, storage, and retrieval of information; and
• Historical information from previous projects, including the lessons learned repository.

10.2.2 Tools and Techniques

10.2.2.1 Communication Technology

Factors that influence the technology include :

• Whether the team is colocated,
• The confidentiality of any information that needs to be shared,
• Resources available to the team members, and
• how the organization's culture influences the way in which meetings and discussions are normally conducted.

10.2.2.2 Communication Method

10.2.2.3 Communication Skills

• Communication competence.
• Feedback. Feedback is information about reactions to communications, a deliverable, or a situation. Feedback supports interactive communication between the project manager, team and all other project stakeholders. Examples include coaching, mentoring, and negotiating.
• Nonverbal. Examples of nonverbal communication include appropriate body language to transmit meaning through gestures, tone of voice, and facial expressions. Mirroring and eye contact are also important techniques.
• Presentations. A presentation is the formal delivery of information and/or documentation:
  • Progress reports and information updates to stakeholders;
  • Background information to support decision making;
  • General information about the project and its objectives, for the purposes of raising the profile of the work of the project and the team;
  • Specific information aimed at increasing understanding and support of the work and objectives of the project.

10.2.2.4 Project Management Information System (PMIS)

• Electronic project management tools.
• Electronic communications management.
• Social media management.

10.2.2.5 Project Reporting

The act of collecting and distributing project information.

10.2.2.6 Interpersonal and Team Skills

• Active listening.
• Conflict management.
• Cultural awareness.
• Meeting management.
• Networking.
• Political awareness.

10.2.2.7 Meetings

10.2.3. Outputs

10.2.3.1 Project Communications

• Performance reports,
• Deliverable status,
• Schedule progress,
• Cost incurred, Presentations, and
• Other information required by stakeholders.

10.2.3.2 Project Management Plan Updates

• Communications management plan. Changes are made to the project communications approach.
• Stakeholder engagement plan. Updated stakeholder communication requirements and agreed-upon communications strategies.

10.2.3.3 Project Documents Updates

• Issue log.
• Lessons learned register. Approaches that worked well and what did not work well for managing communications.
• Project schedule.
• Risk register.
• Stakeholder register.

10.2.3.4 Organizational Process Assets Updates

• Project records such as correspondence, memos, meeting minutes and other documents used on the project; and
• Planned and ad hoc project reports and presentations.

Link to the original publication

10.2 Manage Communications

Description: It is the process of ensuring timely and appropriate collection, creation, distribution, storage, retrieval, management, monitoring, and the ultimate disposition of project information. Ensures that the information being communicated to project stakeholders has been appropriately generated and formatted, and received by the intended audience. It also provides opportunities for stakeholders to make requests for further information, clarification, and discussion. Techniques and considerations:

• Sender-receiver models.
• Choice of media.
• Writing style.
• Meeting management.
• Presentations.
• Facilitation.
• Active listening.

Key benefit: enables an efficient and effective information flow between the project team and the stakeholders.

Frequency: throughout the project.

Process/ Asset Group	Input	The process	Output	Process / Asset Group
Project Management Plan	Resource Management Plan	10.2 Manage Communications	Project Communications	Project Documents
	Communications Management Plan		Issue Log
	Stakeholder engagement plan		Lesson learned register
Project Documents	Change log		Project Schedule
	Issue log		Risk register
	Lesson learned register		Stakeholder register
	Quality report		Communications management plan	Project Management Plan
	Risk report		Stakeholder engagement plan
	Stakeholder register		Organizational processes assets updates	Enterprise / Organization
4.5 Monitor and Control Project Work	Work performance reports
Enterprise / Organization	Enterprise environment factors
	Organizational process assets

10.2.1 Inputs

10.2.1.1 Project Management Plan

• Resource management plan. Describes the communications that are needed for management of team or physical resources.
• Communications management plan. Describes how project communications will be planned, structured, monitored, and controlled.
• Stakeholder engagement plan. Describes how stakeholders will be engaged through appropriate communication strategies.

10.2.1.2 Project Documents

• Change log. To communicate changes and approved, deferred, and rejected change requests to the impacted stakeholders.
• Issue log.
• Lessons learned register.
• Quality report. Quality issues, project and product improvements, and process improvements.
• Risk report. Presents information on sources of overall project risk, together with summary information on identified individual project risks.
• Stakeholder register. Identifies the individuals, groups, or organizations that will need various types of information.

10.2.1.3 Work Performance Reports

Status reports and progress reports.

10.2.1.4 Enterprise Environmental Factors

• Organizational culture, political climate, and governance framework;
• Personnel administration policies;
• Stakeholder risk thresholds;
• Established communication channels, tools, and systems;
• Global, regional, or local trends and practices or habits; and
• Geographic distribution of facilities and resources.

10.2.1.5 Organizational Process Assets

• Corporate policies and procedures for social media, ethics, and security;
• Corporate policies and procedures for issue, risk, change, and data management;
• Organizational communication requirements;
• Standardized guidelines for development, exchange, storage, and retrieval of information; and
• Historical information from previous projects, including the lessons learned repository.

10.2.2 Tools and Techniques

10.2.2.1 Communication Technology

• Whether the team is colocated,
• The confidentiality of any information that needs to be shared,
• Resources available to the team members, and
• How the organization's culture influences the way in which meetings and discussions are normally conducted.

10.2.2.2 Communication Methods

Flexibility in the event that the membership of the stakeholder community changes or their needs and expectations change.

10.2.2.3 Communication Skills

• Communication competence. A combination of tailored communication skills that considers factors such as clarity of purpose in key messages, effective relationships and information sharing, and leadership behaviors.
• Feedback. Information about reactions to communications, a deliverable, or a situation.
• Nonverbal. Appropriate body language to transmit meaning through gestures, tone of voice, and facial expressions.
• Presentations. The formal delivery of information and/or documentation. Presentations will be successful when the content and delivery take the following into account:
  • The audience, their expectations, and needs; and
  • The needs and objectives of the project and project team.

10.2.2.4 Project Management Information System (PMIS)

Ensures that stakeholders can easily retrieve the information they need in a timely way.

10.2.2.5 Project Reporting

Collecting and distributing project information. Project information is distributed to many groups of stakeholders and should be adapted to provide information at an appropriate level, format, and detail for each type of stakeholder.

10.2.2.6 Interpersonal and Team Skills

• Active listening. Involve acknowledging, clarifying and confirming, understanding, and removing barriers that adversely affect comprehension.
• Conflict management.
• Cultural awareness.
• Meeting management. Meeting management is taking steps to ensure meetings meet their intended objectives effectively and efficiently. The following steps should be used for meeting planning:
  • Prepare and distribute the agenda stating the objectives of the meeting.
  • Ensure that the meetings start and finish at the published time.
  • Ensure the appropriate participants are invited and attend.
  • Stay on topic.
  • Manage expectations, issues, and conflicts during the meeting.
  • Record all actions and those who have been allocated the responsibility for completing the action.
• Networking.
• Political awareness.

10.2.2.7 Meetings

10.2.3 Outputs

10.2.3.1 Project Communications

• Performance reports,
• Deliverable status,
• Schedule progress,
• Cost incurred,
• Presentations, and
• Other information required by stakeholders.

10.2.3.2 Project Management Plan Updates

Changes are going through the organization's change control process via a change request.

Updated components:

• Communications management plan. Changes to the project communications approach.
• Stakeholder engagement plan. Updated stakeholder communication requirements and agreed-upon communications strategies.

10.2.3.3 Project Documents Updates

• Issue log. Any communication issues on the project.
• Lessons learned register. Information on challenges encountered and how they could have been avoided as well as approaches that worked well and what did not work well.
• Project schedule.
• Risk register.
• Stakeholder register.

10.2.3.4 Organizational Process Assets Updates

• Project records such as correspondence, memos, meeting minutes and other documents used on the project;
• Planned and ad-hoc project reports and presentations.

10.1 Plan Communications Management

Description: the process of developing an appropriate approach and plan for project communications activities based on the information needs of each stakeholder or group, available organizational assets, and the needs of the project. Communication management plan is developed early in the project life cycle during stakeholder identification and project management plan development. Reviewed and modified regularly.

Methods of storage, retrieval, and ultimate disposition of the project information documented.

Key benefit: a documented approach to effectively and efficiently engage stakeholders by presenting relevant information in a timely manner.

Frequency: throughout the project as needed.

Process / Asset Group	Input	The process	Output	Process/ Asset Group
4.1 Develop Project Charter	Project Charter	10.1 Plan Communication Management	Communication Management Plan	Project Management Plan
Project Management Plan	Resource Management Plan		Project Schedule	Project Documents
	Stakeholder engagement plan		Stakeholder register
Project Documents	Requirements Documentation
	Stakeholder register
Enterprise / Organization	Enterprise Environmental Factors
	Organizational Process Assets

10.1.1 Input

10.1.1.1 Project Charter

Identifies the key stakeholder list, information about the roles and responsibilities of the stakeholders.

10.1.1.2 Project Management Plan

• Resource management plan. How team resources will be categorized, allocated, managed, and released.
• Stakeholder engagement plan. Identifies the management strategies required to effectively engage stakeholders.

10.1.1.3 Project Documents

• Requirements documentation. Requirements for stakeholder communications.
• Stakeholder register. To plan communications activities with stakeholders.

10.1.1.4 Enterprise Environmental Factors

• Organizational culture, political climate, and governance framework;
• Personnel administration policies;
• Stakeholder risk thresholds;
• Established communication channels, tools, and systems;
• Global, regional, or local trends, practices, or habits; and
• Geographic distribution of facilities and resources.

10.1.1.5 Organizational Process Assets

• Organizational policies and procedures for social media, ethics, and security;
• Organizational policies and procedures for issue, risk, change, and data management;
• Organizational communication requirements;
• Standardized guidelines for development, exchange, storage, and retrieval of information;
• Historical information and lessons learned repository; and
• Stakeholder and communications data and information from previous projects.

10.1.2 Tools and Techniques

10.1.2.1 Expert Judgement

• Politics and power structures in the organization;
• Environment and culture of the organization and other customer organizations;
• Organizational change management approach and practices;
• Industry or type of project deliverables;
• Organizational communications technologies;
• Organizational policies and procedures regarding legal requirements of corporate communications;
• Organizational policies and procedures regarding security; and
• Stakeholders, including customers or sponsors.

10.1.2.2 Communication Requirements Analysis

• Stakeholder information and communication requirements from within the stakeholder register and stakeholder engagement plan;
• Number of potential communication channels or paths, including one-to-one, one-to-many, and many-to-many communications;
• Organizational charts;
• Project organization and stakeholder responsibility, relationships, and interdependencies;
• Development approach;
• Disciplines, departments, and specialties involved in the project;
• Logistics of how many persons will be involved with the project and at which locations;
• Internal information needs (e.g., when communicating within organizations);
• External information needs (e.g., when communicating with the media, public, or contractors); and
• Legal requirements.

10.1.2.3 Communication Technology

• Conversations,
• Meetings,
• Written documents,
• Databases,
• Social media, and
• Websites.

Factors that can affect the choice of communication:

• Urgency of the need for information. The urgency, frequency, and format of the information.
• Availability and reliability of technology. Compatible, available, and accessible for all stakeholders.
• Ease of use.
• Project environment.
  • Face-to-face basis or in a virtual environment;
  • Located in one or multiple time zones;
  • Multiple languages for communication;
  • Various aspects of culture.
• Sensitivity and confidentiality of the information.
  • Sensitive or confidential;
  • To ensure appropriate behavior, security, and the protection of proprietary information.

10.1.2.4 Communication Models

• Sample basic sender/receiver communication model. Two parties: a sender and a receiver. This model is concerned with ensuring that the message is delivered, rather than understood. Steps:
  • Encode.
  • Transmit message.
  • Decode.
• Sample interactive communication model. A sender and a receiver. The model recognizes the need to ensure the massage is understood. Steps:
  • Encode.
  • Transmit message.
  • Decode.
  • Acknowledge. Signal the message is received.
  • Feedback/response. Return ideas in a new message to the first party.

The sender is responsible for the transmission of the message, ensuring the information being communicated is clear and complete, and confirming the message is correctly interpreted.

The receiver is responsible for ensuring that the information is received in its entirety, interpreted correctly, and acknowledged or responded to appropriately.

10.1.2.5 Communication Methods

• Interactive communication. Exchange of information in real time. It employs communications artifacts such as meetings, phone calls, instant messaging, some forms of social media, and videoconferencing.
• Push communication. Sent or distributed directly to specific recipients who need to receive the information. This ensures that the information is distributed but does not ensure that it actually reached or was understood by the intended audience. Push communications artifacts include letters, memos, reports, emails, faxes, voice mails, blogs, and press releases.
• Pull communication. Web portals, intranet sites, e-learning, lessons learned databases, or knowledge repositories.

Major communication forms:

• Interpersonal communication.
• Small group communication. 3~6 persons.
• Public communication. A single speaker addressing a group of people.
• Mass communication.
• Networks and social computing communication.

Communications artifact and methods:

• Notice boards,
• Newsletters/in-house magazines/e-magazines,
• Letters to staff/volunteers,
• Press releases,
• Annual reports,
• Emails and intranets,
• Web portals and other information repositories (for pull communication)
• Phone conversations,
• Presentations,
• Team briefings/group meetings,
• Focus groups,
• Face-to-face formal or informal meetings between various stakeholders,
• Consultation groups or staff forums, and
• Social computing technology and media.

10.1.2.6 Interpersonal and Team Skills

• Communication styles assessment.
• Political awareness. The recognition of power relationships, both formal and informal, and also the willingness to operate within these structures.
• Cultural awareness. An understanding of the differences between individuals, groups, and organizations and adapting the project's communication strategy in the context of these differences.

10.1.2.7 Data Representation

A stakeholder engagement assessment matrix.

10.1.2.8 Meetings

Virtual (e-meetings) or face-to-face meetings, and can be supported with document collaboration technologies, including email messages and project websites.

10.1.3 Outputs

10.1.3.1 Communications Management Plan

It is a component of the project management plan that describes how project communications will be planned, structured, implemented, and monitored for effectiveness.

Contains:

• Stakeholder communication requirements;
• Information to be communicated, including language, format, content, and level of detail;
• Escalation processes;
• Reason for the distribution of that information;
• Timeframe and frequency for the distribution of required information and receipt of acknowledgment or response, if applicable;
• Person responsible for communicating the information;
• Person responsible for authorizing release of confidential information;
• Person or groups who will receive the information, including information about their needs, requirements, and expectations;
• Methods or technologies used to convey the information, such as memos, email, press releases, or social media;
• Resources allocated for communication activities, including time and budget;
• Method for updating and refining the communications management plan as the project progresses and develops, such as when the stakeholder community changes as the project moves through different phases;
• Glossary of common terminology;
• Flow charts of the information flow in the project, workflows with possible sequence of authorization, list of reports, meeting plans, etc.; and
• Constraints derived from specific legislation or regulation, technology, organizational policies, etc.

Plan can include guidelines and templates for project status meetings, meetings, e-mail messages.

10.1.3.2 Project Management Plan Updates

Change control.

The stakeholder engagement plan.

10.1.3.3 Project Documents Updates

• Project schedule.
• Stakeholder register.