4squareviews

Qualitative risk analysis and quantitative risk analysis are different in the following ways.

• Qualitative risk analysis is based on the subjective impression of stakeholders regarding the probability and impact of individual project risks.   Quantitative risk analysis, on the other hand is based on the availability of high-quality objective data about the probability of those risks and objective data regarding their impact on the project baseline for scope, schedule, and cost.
• Quantitative risk analysis is appropriate for large or complex projects, or those that are strategically important or are required by key stakeholders or contractual requirements.
• Qualitative risk analysis focuses on individual project risks, but quantitative risk analysis evaluates the aggregated effect of these risks on the overall project outcome.    The overall goal is to be able to specify the level of confidence in being able to achieve the stated basic constraints of scope, time and cost.

This post deals with the inputs to this process.

11.4.1  Perform Quantitative Risk Analysis:   Inputs

11.4.1.1  Project Management Plan

The components of the project management plan that are used as inputs consist of a) the risk management plan component and the baselines for the three basic constraints of scope, time and cost.

• Risk management–the risk management plan should indicate whether the project is of sufficient size and complexity to warrant the time, cost and human energy spent in doing a quantitative risk analysis.
• Scope, schedule and cost baseline–these baselines give the starting point for evaluating individual project risks and other sources of uncertainty.   For example, any activity identified in the scope baseline component of the Work Breakdown Structure as being on the critical path should automatically be scrutinized as being higher risk because any delay in that activity will cause a delay in the entire project.

11.4.1.2 Project Documents

The PMBOK® Guide lists these in alphabetical order, but I am listing them below according to their category to make the list easier to comprehend.

Documents related to basic constraints and assumptions

• Assumption log–assumptions that pose a risk to project objectives should be examined as well as the effect of basic constraints of the scope, time and cost
• Milestone list–these define the schedule targets against which the results of a quantitative schedule risk analysis are compared (for example, a finding that there is 80% confidence in achieving the project deadline)
• Resource requirements–the required resources (both human resources and physical resources) can provide a starting point from which variability is evaluated.   For example, the delivery date of required key physical resources or the availability dates for key human resources would create risks to the project objectives if they are not adhered to.

Documents related to estimates

• Basis of estimates–this provides background on the estimate’s accuracy, methodology, and source of information.
• Cost estimates, duration estimates–three-point estimates which give the most likely estimate, as well as the optimistic and pessimistic estimates based on the triggering of certain risks, provide a starting point for the modeling of qualitative risk analysis.

Documents related to forecasts

• Cost forecast, schedule forecast–cost and schedule forecasts using earned value management such as the Estimate to Complete (ETC), the Budget at Completion (BAC), and the To-Complete Performance Index (TCPI) may be used in conjunction with quantitative risk analysis to determine the confidence level of achieving those targets.

Documents related to risks

• Risk register–this will include details of individual project risks to be used as input for the quantitative risk analysis done in this process.
• Risk report–this risk report describes sources of overall project risk (which can be found in the project charter)

11.4.1.3  Enterprise Environmental Factors

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

11.4.1.5  Organizational Process Assets

• Information from previous similar projects done by the organization.

The next post will cover the tools and techniques of quantitative risk analysis, but these are so numerous and some of them so complex that it will take a couple of posts to describe them all…

Filed under: Uncategorized | Leave a comment »

The results of the qualitative risk analysis performed in this process are put into the risk register and the risk report, with additional changes being made to the assumption log and issue log as necessary.

These are the main outputs of the process 11.3 Perform Qualitative Risk Analysis:

11.3.3  Perform Qualitative Risk Analysis:   Outputs

• Risk register–the risk register should have a list of identified risks and the risk owners based on the results of the last process 11.2 Identify Risks.   For each of these risk register entries, you should now add information on the following:
  • Assessments of probability and impacts for each individual project risk
  • The combined risk score and its priority level (very low, low, moderate, high, or very high)
  • Risk urgency information and/or additional risk categorization
  • Watch list for low-priority risks
• Risk report–the risk report that goes out to all stakeholders concerned with risk should include the following:
  • The most important individual projects risks with the highest probability/impact
  • Prioritized list of all identified risks on the project
  • Summary conclusion
• Assumption log–if during this process, new assumptions are made, or new constraints identified, these may  be added to the assumption log
• Issue log–if during this process, any new issues are uncovered or any changes are made to the currently logged issues, the log is updated to reflect them

The next process is taking the qualitative analyis and going one step further and doing a qualitative analysis.   The next post will cover the inputs to this process.

Filed under: Uncategorized | Leave a comment »

This process takes the individual project risks identified in the last process 11.2 Identify Risks and starts to categorize them by assessing their probability of occurring and their potential impact on the project if they do occur.   Why do this assessment?   Because it allows you to prioritize them so that you are concentrating on higher risks.   There are four basic ways of dealing with negative risk to a project:

• Accept–for low-impact, low-probability risks
• Transfer–for high-impact, low-probability risks:   transferring some of the risk via insurance.
• Mitigate–for low-impact, high-probability risks:   taking preventive measures to lower the probability that the risk may occur, or to mitigate the impact if it does occur.   You can’t stop it from raining, for example, but you can take an umbrella to prevent yourself from getting soaked if it does rain.
• Avoid–for high-probability, high-impact risks:   figuring out possible alternatives to reduce the probability, or by outsourcing higher-risk activities to other companies more experienced in dealing with that risk.

This general framework of generic risk strategies comes from the 5th Edition PMBOK® Guide,; although it does not explicitly appear in the 6th Edition, I still found it a useful framework for conceptualizing how the qualitative analysis of risk leads to some generic strategies for dealing with individual project risks based on their category according to probability and impact.    It is in the next process with quantitative risk analysis that an individual risk response can be crafted.

11.3.2  Perform Qualitative Analysis:   Tools and Techniques

11.3.2.1  Expert Judgment

This is one of the “generic” techniques used in a lot of planning processes.   It means asking for subject matter experts, in this case on the subject of qualitative risk analysis, to help your project team assess the probability and impacts of individual project risks.   These are people who have either done a similar analysis before, and particularly those who have analyzed a similar project to the one currently being done by your organization.

11.3.2.2  Data Gathering

Interviews with stakeholders are one way of assessing the probability and impact of individual project risks.

11.3.2.3  Data Analysis

• Risk probability and impact statement:   risk probability is the likelihood that a specific risk will occur, and risk impact is the potential effect on one or more project objectives such as schedule, cost, quality or overall performance of scope.  Although it is a qualitative analysis meaning that is based on the subjective impressions of people, it can be nonetheless quantified to a certain extent by giving a scale or range for the probability and/or impact.   For example, you could use the following scheme to rate each risk from 1 to 5:
  • Very low (1)
  • Low (2)
  • Moderate (3)
  • High (4)
  • Very high (5)

Or you could try rating each risk from between 0 and 1, with “very low” being close to 0 and “very high” being close to 1.   It depends on how your organization classifies risk and this should be included in the risk management plan.

When you combine the two factors together, you will get a combined probability and impact rating.   In the top scheme above, the combined rating will be from 1 to 25, and in the bottom rating, it will be between 0 and 1.   An example of such a combined probability and impact rating matrix is given in Figure 11-5 on page 408 of the 6th edition of PMBOK® Guide.

Usually risks that are both low impact and probability are put on a “watch list”, where they are simply accepted (meaning that there is no specific risk response to try to mitigate the impact or probability), but are monitored to see if they increase in probability or impact during the course of the project, in which case a risk response may have to be developed.

• Risk data quality assessment–although this is most often done during the monitoring and control process group, it is important to review the results of the qualitative risk analysis to make sure they are accurate.
• Assessment of other risk parameters–although probability and impact are the most important parameters to assess, your organization may add others, such as “urgency”, the period of time within which a risk response needs to be implemented for that particular risk.   The complete list of these additional parameters are listed on p. 424 of the 6th edition of PMBOK® Guide.

11.3.2.4  Interpersonal and Team Skills

Here is another “generic” tool and technique used in conjunction with gathering data in many planning processes.   Facilitation is like a group interview technique where participants focus on the risk analysis task  and reach a consensus on assessments of probability and impact rather than just having individual interviews.

11.3.2.5  Risk Categorization

There is a tool called a Risk Breakdown Structure which helps categorize risks based on their source such as the following suggested categories listed in Figure 11-4 on p. 406 of the 6th edition of PMBOK® Guide:

• Technical risk
• Management risk
• Commercial risk
• External risk

Grouping risk into these categories can help in focusing on particular types of risk, and developing generic risk responses to address groups of risks related to the same source.

11.3.2.6  Data Representation

• Probability and impact matrix–this is a grid for mapping the probability and impact of each individual risk, with an example being given in Figure 11.5 on p. 408 of the 6th edition of PMBOK® Guide.
• Hierarchical charts–another possible form of data representation would be if there are three parameters, so for example, the probability and urgency would be represented by the x- and y-axis, and the impact denoted by a bubble which represents the size of the potential impact on the project.   An example of what this looks like is included on Figure 11-10 on p. 426 of the 6th edition of the PMBOK® Guide.

11.3.2.7  Meetings

PMI recommends that there be special meetings devoted specifically to the discussion of individual project risks.   This is not just during the planning phase, like in this process of assessing their probability and impact, but also during other processes.

The meeting related to this process should include the following:

• Review of the list of previous identified risks
• Risk owner allocated to each individual project risk
• Reviewing the probability and impact scales to be used during the analysis
• Conducting an assessment of the probability and impact of the individual project risks and using probability/impact matrix to get combined rating
• Categorization and prioritization of risks based on combined probability/impact rating
• Identification of additional risks (to be added to the risk register)

The next post will be on the outputs of this process.

Filed under: Uncategorized | 14 Comments »

In the last process 11.2 Identify Risks, individual project risks were identified, and in this process and the next one, these identified risks will be analyzed in two ways:   first qualitatively then quantitatively.

In the first qualitative analysis, you take the risk and assess its probability of occurrence and its impact on the project.   The key benefit is that it prioritizes risks so that you can focus the team’s efforts on high-priority risks.   The reason why this analysis is called qualitative is because it is based on the subjective perceptions of risk by the project team.

It is in the next process of quantitative risk analysis that the project team starts using objective measures in order to get a better handle on the magnitude of the individual risks involved.

So what are the inputs to this process?   Of course the project management plan, in particular the risk management plan component, will be used because it gives guidelines on how to do all of the risk management processes, including this one.   Project documents will be needed, the most obvious one being the risk register, but other documents may be consulted as well such as the assumption log (for both the key assumptions and constraints) and the stakeholder register (in order to assign possible risk owners).

11.3.1  Perform Qualitative Risk Analysis:  Inputs

11.3.1.1 Project Management Plan

As mentioned above, the risk management plan, one of the component plans of the overall project management plan, is an important input.   In particular, the following elements are of particular interest to this process.

• Roles and responsibilities–who is the lead of the risk management team and who are the team members?   Who will support the activities within the organization?  What are the specific responsibilities of each member of the team?
• Schedule–defines when and how often risk management processes will be performed throughout the project life cycle, and establishes those risk management activities that will be included into the project schedule., including those related to this process of qualitative risk analysis.
• Budget–gives the budget for risk management activities that will be included into the project budget, including those related to this process of qualitative risk analysis.
• Risk categories–a risk breakdown structure or RBS is a representation of potential sources of risk on a project.   Creating an RBS helps the project team consider the full range of sources from which individual project risks may arise.

• Definitions of risk probability and impact–used in this process 11.3 Perform Qualitative Risk Analysis, the probability and impact matrix divides these concepts into qualitative thresholds like “low”, “medium” and “high”.   The definition of these thresholds is important to establish at the beginning of the project.
• Stakeholder risk appetite–this should be expressed in terms of measurable risk thresholds around each project objective in order to determine the acceptable level of overall project risk exposure.

11.3.1.2   Project Documents

• Assumption log–this is the log you create to keep track of monitoring key assumptions and constraints that may affect the project.   High-level strategic and operational assumptions and constraints are identified in the business case (a document prepared by business analysts) and are listed in the project charter.   Lower-level assumptions related to individual activities and tasks are identified throughout the project, such as
  • Technical specifications
  • Estimates (for both cost and schedule)
• The risk register, the output of the last process 11.2 Identify Risks, will contain details of each identified individual project risk that will be assessed during the Perform Qualitative Risk Analysis process.   Details regarding the probability and impact of each individual risk will be added to the risk register as a result of this process.
• Stakeholder register–this will include details of project stakeholders who may be nominated as risk owners.   They will be consulted during this process to get their perceptions of the probability and impact of the risks they have been assigned.

11.3.1.3  Enterprise Environmental Factors

• Published material, including commercial risk databases or checklists, from similar projects.

11.3.1.4  Organizational Process Assets

• Information from similar completed projects done by the organization.

The next post will discuss the tools and techniques of this process.   Some are generic, that is, used in a lot of other processes as well, such as expert judgment, and interpersonal and team skills.   Some, such as the data gathering technique of interviews, are used in other processes.   The data analysis techniques of risk probability and impact assessment, however, is unique to this process.

Filed under: Uncategorized | Leave a comment »

I’ve been busy with a move, which is a project of its own, but I’ve finally finished unpacking, and consider this moving project officially CLOSED.   So today I am resuming my daily task of summarizing the contents of the 6th Edition PMBOK® Guide, and I left off at describing the outputs of the process 11.2 Identify Risks.

11.2.3 Identify Risks:  Outputs

11.2.3.1 Risk Register

This document is similar to the stakeholder register in that it is created in one process, but is elaborated on during other processes throughout the course of the project.   The risk register captures identified individual project risks.   These risks after being identified will need to be identified, analyzed both quantitatively and qualitatively, and then risk responses will have to be developed for them in later processes.   In this first process, the risks need to be identified, but if any information on risk owners (risk responses is available, it can be added at this point to be confirmed in later processes. Risk owners are those who have responsibility for monitoring and controlling those particular risks to which they are assigned, and implementing a risk response if the risk is triggered.

Here are the elements the risk register should include:

• List of identified risks–it should be given a unique identifier in the risk register, and it should be described in detail, including their cause and their potential effect on the project.
• Potential risk owners–if a potential risk owner can be identified at this point, the risk owner is recorded in the risk register.   This is confirmed in process 11.3 Perform Qualitative Risk Analysis.
• Potential risk response–if a potential risk response can be identified at this point, the risk response is recorded in the risk register.   This is confirmed in process 11.5 Plan Risk Responses.

11.2.3.2  Risk Report

This is a new output for this process in the 6th Edition PMBOK® Guide.   As the various risk processes are completed, the results are included in the risk report.   The important results for this process that need to be concluded are:

• Sources of overall project risk, which may be obtained from the project charter.
• Summary information on individual project risks listed in the risk register, such as:
  • Number of identified threats and opportunities
  • Distribution of risks across risk categories (based on source of risks)
  • Any metrics and trends to be used in future risk reports

11.2.3.3.  Project Documents Updates

• Assumption log–if in identifying risks, any new assumptions are made, or new constraints are identified, the assumption log should be updated with this new information.
• Issue log–any new issues uncovered during this process of identifying risks should be added to the issue log.
• Lessons learned register–any techniques that were effective in identifying risks should be added to the lessons learned register in order to improve performance in later phases of the project.

The next process will start the analysis of the risks listed in the risk register.

Filed under: Uncategorized | Leave a comment »

Identification of risks is something which requires the project manager to cast the net far and wide in order to find sources that will give information on potential risks to the project.   These range from the usual “generic” tools and techniques of expert judgment and meetings, to those more specific to this risk management knowledge area, especially in the area of data analysis.

11.2.2.1 Expert Judgment

Experts should be consulted who have expertise in individual project risks (especially those who were involved previously in similar projects) and those stakeholders with a grasp of risk management who can weigh in on the overall project risks based on their expertise in the field.

11.2.2.2  Data Gathering

There are many ways of gathering data regarding risk:  through written documents (checklists), through interviews with individual stakeholders, and group meetings with project team members and stakeholders in order to brainstorm regarding potential sources of risk.

• Brainstorming–ideas are generated under the guidance of a facilitator either in a free-form fashion or by using more structured techniques.   A particular useful starting point for these discussions is the Risk Breakdown Structure, which categorizes risk by its potential source.
• Checklists–this is using lists of potential risks that were developed based on previous similar projects.   Of course, even if a previous project was similar, care must be taken to account for the differences by going over all risks on the checklist to make sure they actually apply in the current project.
• Interviews–conversations with stakeholders and subject matter experts in the field of risk management can be used to get contributions to the list of potential risks on the project.

11.2.2.3  Data Analysis

• Root cause analysis–just as root cause analysis can be used to discover the underlying causes that lead to an actual problem (a defect), it can also be used to identify the causes of a potential problem.   You start with the potential problem, such as cost overruns and schedule delays, and go back to find out those factors which might lead to this problem.
• Assumption and constraint analysis–a project is conceived with a set of assumptions and within a series of constraints (schedule, cost, quality, scope, etc.).  The validity of these assumptions and constraints are analyzed to determine which pose a potential risk to the project.
• SWOT analysis–if you take positive and negative factors both internal to and external to the project organization, you will get the strengths/weaknesses (internal), and opportunities/threats (external) to the project, which is wear the acronym SWOT comes from.
• Document analysis–project documents, particularly the project charter, are analyzed to get high-level risks on the current project, and project files from previous similar projects are also analyzed to get the individual risks from those projects.

11.2.2.4  Interpersonal and Team Skills

Especially when using the data gathering technique of brainstorming, it requires special skills to be a facilitator of one those sessions because you have to encourage an open mode of discussion where ideas will not be shot down when given by any member of the discussion group, thus encouraging creativity in the process.

11.2.2.5  Prompt Lists

This is a predetermined list of risk categories.   A checklist is a list of actual risks from previous projects; the prompt list just gives the risk categories, and is a useful tool to be used in conjunction with the brainstorming technique mentioned in the paragraph 11.2.2.2 above.

11.2.2.6  Meetings

Like putting together the WBS, putting together a list of potential risks requires brainstorming which is best done in the setting of a group meeting.

The next post will cover the outputs of this process.

Filed under: Uncategorized | Leave a comment »

After the first planning process which creates the Risk Management Plan, which shows how to do risk management on the project, this is the first process that starts of considering individual risks on the project.

Risks are found among all the other constraints on the project, so the inputs will come from the knowledge areas for scope, schedule, cost, quality, and resources.   In particular, you will want to look at the management plans for these knowledge areas, the three performance baselines (scope, schedule, and cost), and project documents from these knowledge areas.

11.2.1  Identify Risks:  Inputs

11.2.1.1  Project Management Plan

The components of the overall project management plan that are inputs to this process include:

• Requirements management plan–the requirements management plan may indicate which project objectives that are particularly at risk
• Schedule management plan–the schedule management plan may identify areas that are subject to uncertainty or ambiguity with respect to the schedule.   Note:   activities on the critical path will automatically be of higher risk to the project, as any delay in their execution will result in a delay in the final deadline of the project.
• Cost management plan–the cost management plan may identify areas that are subject to uncertainty or ambiguity with respect to the budget.
• Quality management plan–the quality management plan may identify areas that are subject to uncertainty or ambiguity, or where key assumptions with regards to quality have been made that might give rise to risk.
• Resource management plan–the resource management plan may identify areas that are subject to uncertainty or ambiguity, or where key assumptions with regards to critical resources have been made that might give rise to risk.
• Risk management plan–includes the following elements relevant to this process:
  • Lists risk-related roles and responsibilities on the project
  • Indicates how risk management activities are included in the budget and schedule
  • Describes categories of risk
• Scope baseline–indicates deliverables in the scope statement which might give rise to risk.   The WBS can be used as a framework for identifying individual risks.
• Schedule baseline–May be used to identify milestones and deliverable due dates that are subject to uncertainty or ambiguity, or where key assumptions with regards to the schedule have been made that might give rise to risk.
• Cost baseline–May be used to identify costs or funding requirements that are subject to uncertainty or ambiguity, or where key assumptions with regards to costs have been made that might give rise to risk.

11.2.1.2  Project Documents

• Assumption log–assumptions and constraints recorded in the assumption log may give rise to individual project risks and may also influence the level of overall project risk.
• Cost estimation–cost estimates provide quantitative assessments of project costs, ideally expressed as a range, indicating the degree of risk, where a structured review of the documents may indicate that the current estimate is insufficient and poses a risk to the project.
• Duration estimation–duration estimates provide quantitative assessments of project durations, ideally expressed as a range, indicating the degree of risk, where a structured review of the documents may indicate that the current estimate is insufficient and poses a risk to the project.
• Issue log–issues recorded in the issue log may give rise to individual project risks and may also influence the level of overall project risk.
• Lessons learned register–this is where lessons learned during the process of risk identification will be recorded and reviewed in later processes of the project to determine whether similar risks might recur during the remainder of the project.
• Requirements documentation–the project requirements should be analyzed during this process to identify those that could be at risk.
• Resource requirements–resource requirements provide quantitative assessments of project resource requirements, ideally expressed as a range, indicating the degree of risk, where a structured review of the documents may indicate that the current estimate is insufficient and poses a risk to the project.
• Stakeholder register–Indicates which individuals or groups might participate in identifying risks to the project.   It also details those individuals who are available to act as risk owners.

11.2.1.3  Agreements

If the project requires the external procurement of resources, the agreements may have information such as milestone dates, delivery dates, contract type, acceptance criteria, and awards and penalties that can present threats or opportunities.

11.2.1.4  Procurement Documentation

If the project requires the external procurement of resources, the initial procurement documentation should be reviewed, because procuring goods and services from outside the organization may increase or decrease overall project risk and introduce additional individual project risks (for example, if the procurement of a critical component has a delay in the delivery date).

11.2.1.5  Enterprise Environmental Factors

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

11.2.1.6  Organizational Process Assets

• Project files, including actual data and checklists, from previous similar projects
• Risk statement formats
• Organizational and project process controls for risk

The next post will cover the tools and techniques of this process.

Filed under: Uncategorized | Leave a comment »

This post covers the outputs of the process 11.1 Plan Risk Management.   Actually, there is only output and that is the Risk Management Plan.   Here are the elements that should go into such a plan:

• Risk strategy–the organization’s general approach to managing risk on projects
• Methodology–specific approaches, tools (like the probability and impact matrix) and data sources that will be used to perform risk management on the project.
• Rules and responsibilities–who is the lead of the risk management team and who are the team members?   Who will support the activities within the organization?  What are the specific responsibilities of each member of the team?
• Funding–this clarifies the protocols for application of contingency and management reserves.   Remember, contingency reserves are for those risks that are on the risk register (the “known unknowns”) vs. those risks that are not (the “unknown unknowns.”
• Schedule–defines when and how often risk management processes will be performed throughout the project life cycle, and establishes those risk management activities that will be included into the project schedule.
• Risk categories–a risk breakdown structure or RBS is a representation of potential sources of risk on a project.   Creating an RBS helps the project team consider the full range of sources from which individual project risks may arise.
• Stakeholder risk appetite–this should be expressed in terms of measurable risk thresholds around each project objective in order to determine the acceptable level of overall project risk exposure.
• Definitions of risk probability and impact–used in process 11.3 Perform Qualitative Risk Analysis, the probability and impact matrix divides these concepts into qualitative thresholds like “low”, “medium” and “high”.   The definition of these thresholds is important to establish at the beginning of the project.
• Probability and impact matrix–not only the definitions of the individual thresholds, but how these thresholds will interact must be determined ahead of time.   Also, the overall strategies of dealing with these categories should be defined.   Will the company accept those risks in the “low” category, mitigate those in the “medium” category, and avoid those in the “high” category, for example?
• Reporting formats–this shows how the outcomes of the risk management process 11.6 Implement Risk Responses and 11.7 Monitor Risks will be reported to stakeholders.
• Tracking–shows how risk activities will be tracked using the risk register and how risk management activities will be audited.

The next process starts the specific risk management planning process of identifying risks.   The inputs to that process are in the following post.

Filed under: Uncategorized | Leave a comment »

The process of creating the Risk Management Plan is like all the similar processes for other knowledge areas.   Consequently, there are some tools and techniques which are “generic”, that is, common to all of these processes that create a management plan that is a component of the overall Project Management Plan.    One tool and technique, Data Analysis, uses stakeholder analysis and is specific to this particular process.

11.1.2.1  Expert Judgment

In creating the risk management plan, it’s pretty clear that you will want to consult with SMEs (subject matter experts) who have expertise in the area of risk management.   This may include the following:

• Experts in risk management in general, especially those who are familiar with the organization’s approach to risk management
• Those who have handled risk management on other similar projects and who can therefore advise on the types of risk likely to be encountered on the current project

11.1.2.2   Data Analysis

Stakeholder analysis can be used to determine the risk tolerance of key stakeholders on the project.

11.1.2.3 Meetings

Project team members, members of the organization who are responsible for risk management, and key stakeholders are those whom you want to invite to meetings to discuss the risk management plan.   The meetings will define the risk management activities that will be done in all of the other six processes in this knowledge area.

The next post will be the outputs of this process, the main one being the Risk Management Plan.

Filed under: Uncategorized | Leave a comment »

Although risk management is among the most complex of the knowledge areas when it comes to the planning process group, the first process is the same as all the others.   It is Plan Risk Management, which has as its output the Risk Management Plan.   This post goes over the inputs to this process.

11.1.1  Plan Risk Management:  Inputs

11.1.1.1  Project Charter

The project charter contains a high-level project description and project boundaries, meaning not just what is within the scope of the project but also what is excluded from the scope.   High-level risks that the project sponsor is aware of and is concerned about can be put in the project charter as well.   That’s why it’s the first course for a project manager to find out about the risks associated with the project.   Sometimes there is a connection between the high-level scope description, including the exclusions, and the high-level description of the risks.   It may be possible that something may considered “out of bounds” for the project for the very reason that it represents taking on a higher risk than the sponsor it comfortable with.

11.1.1.2  Project Management Plan

All of the components of the project management plan, particularly the subsidiary management plans for all the other knowledge areas, and the additional ones having to do with requirements (dealing with scope management), and change/configuration management (dealing with integration management), are all sources of risk and so any risk management plan needs to be consistent with these other components.

11.1.1.3  Project Documents

The stakeholder register is probably the most important input for this process.   You will want to discuss their attitude towards overall risk, as well as getting their opinion on the identification of individual risks on the project.

11.1.1.4  Enterprise Environmental Factors

Overall risk thresholds set by the organization or by key stakeholders will influence how much risk you intend to take on during the course of the project.

11.1.1.5  Organizational Process Assets

• Organizational risk policy
• Risk statement formats, templates for the risk management plan, risk categories organized into a risk breakdown structure, and common definitions of risk concepts and terms
• Authority levels of decision making (this will affect your risk responses)
• Roles and responsibilities within the organization, especially as it pertains to risk management
• Lessons learned repository from previous similar projects

The next post will cover the tools and techniques of this process.

Filed under: Uncategorized | 1 Comment »