Check out my Linkdin Profile at www.linkedin.com/in/dritter5! I’d love to hear your comments on what services you would like provided.
Quantitative Risk Analysis is performed on risks that have been prioritized by the Qualitative Risk Analysis process. The Quantitative Risk Analysis process analyzes the effect of those risk events and assigns a numerical rating to those risks. It also presents a quantitative approach to making decisions in the presence of uncertainty. Since it is more expensive, it is only done on those risks we already identified as potentially and substantially impacting the project’s competing demands.
This process uses techniques such as Monte Carlo simulation and decision tree analysis to:
· Quantify the possible outcomes for the project and their probabilities
· Assess the probability of achieving specific project objectives
· Identify risks requiring the most attention by quantifying their relative contribution to overall project risk
· Identify realistic and achievable cost, schedule, or scope targets, given the project risks
· Determine the best project management decision when some conditions or outcomes are uncertain.
Quantitative Risk Analysis generally follows the Qualitative Risk Analysis process, although experienced risk managers sometimes perform it directly after Risk Identification. In some cases, Quantitative Risk Analysis may not be required to develop effective risk responses. Availability of time and budget, and the need for qualitative or quantitative statements about risk and impacts, will determine which method(s) to use on any particular project. Quantitative Risk Analysis should be repeated after Risk Response Planning, as well as part of Risk Monitoring and Control, to determine if the overall project risk has been satisfactorily decreased. Trends can indicate the need for more or less risk management action.
· Interviewing. Interviewing techniques are used to quantify the probability and impact of risks on project objectives. The information needed depends upon the type of probability distributions that will be used. For instance, information would be gathered on the optimistic (low), pessimistic (high), and most likely scenarios for some commonly used distributions, and the mean and standard deviation for others. Documenting the rationale of the risk ranges is an important component of the risk interview, because it can provide information on reliability and credibility of the analysis.
· Probability distributions. Continuous probability distributions represent the uncertainty in values, such as durations of schedule activities and costs of project components. Discrete distributions can be used to represent uncertain events, such as the outcome of a test or a possible scenario in a decision tree.
· Expert judgment. Subject matter experts internal or external to the organizations such as engineering or statistical experts, validate data and techniques.
Quantitative Risk Analysis and Modeling Techniques:
· Sensitivity analysis. Sensitivity analysis helps to determine which risks have the most potential impact on the project. It examines the extent to which the uncertainty of each project element affects the objective being examined when all other uncertain elements are held at their baseline values. One typical display of sensitivity analysis is the tornado diagram, which is useful for comparing relative importance of variables that have a high degree of uncertainty to those that are more stable.
· Expected monetary value analysis. Expected monetary value (EMV) analysis is a statistical concept that calculates the average outcome when the future includes scenarios that may or may not happen (i.e., analysis under uncertainty). The EMV of opportunities will generally be expressed as positive values, while those of risks will be negative. EMV is calculated by multiplying the value of each possible outcome by its probability of occurrence, and adding them together. A common use of this type of analysis is in decision tree analysis. Modeling and simulation are recommended for use in cost and schedule risk analysis, because they are more powerful and less subject to misuse than EMV analysis.
· Decision tree analysis. Decision tree analysis is usually structured using a decision tree diagram that describes a situation under consideration, and the implications of each of the available choices and possible scenarios. It incorporates the cost of each available choice, the probabilities of each possible scenario, and the rewards of each alternative logical path. Solving the decision tree provides the EMV (or other measure of interest to the organization) for each alternative, when all the rewards and subsequent decisions are quantified.
Modeling and simulation:
A project simulation uses a model that translates the uncertainties specified at a detailed level of the project into their potential impact on project objectives. Simulations are typically performed using the Monte Carlo technique. In a simulation, the project model is computed many times (iterated), with the input values randomized from a probability distribution function (e.g., cost of project elements or duration of schedule activities) chosen for each iteration from the probability distributions of each variable. A probability distribution (e.g., total cost or completion date) is calculated.
For a cost risk analysis, a simulation can use the traditional project WBS or a cost breakdown structure as its model. For a schedule risk analysis, the precedence diagramming method (PDM) schedule is used.
There are two cycles of analysis that can be done on risks after they have been identified before Risk Planning occurs. The first is Qualitative Risk Analysis which includes methods for prioritizing the identified risks for further action, such as Quantitative Risk Analysis or Risk Response Planning. Organizations can improve the project’s performance effectively by focusing on high-priority risks.
Qualitative Risk Analysis assesses the priority of identified risks using their probability of occurring, the corresponding impact on project objectives if the risks do occur, as well as other factors such as the time frame and risk tolerance of the project constraints of cost, schedule, scope, and quality. Stakeholder risk tolerances must be taken into account in this phase. Everyone knows that if you change one side of the triple constraint triangle (cost, schedule and scope/quality), then one of the other factors change. For example, if you add to the scope, either cost (hiring more engineers) or schedule will change. As the Project Manager, it is vital that you know which one of these factors drive the Stakeholders. It may be time to market (schedule), cost or functionality (scope/quality).
Definitions of the levels of probability and impact, and expert interviewing, can help to correct biases that are often present in the data used in this process. The time criticality of risk-related actions may magnify the importance of a risk. An evaluation of the quality of the available information on project risks also helps understand the assessment of the risk’s importance to the project.
Qualitative Risk Analysis is usually a rapid and cost-effective means of establishing priorities for Risk Response Planning, and lays the foundation for Quantitative Risk Analysis (a much more rigorous and expensive process) if this is required. Qualitative Risk Analysis should be revisited during the project’s life cycle to stay current with changes in the project risks.
Qualitative Risk Analysis requires outputs of the Risk Management Planning and Risk Identification processes. This process can lead into Quantitative Risk Analysis or directly into Risk Response Planning.
Risk Probability and Impact Assessment
Risk probability assessment investigates the likelihood that each specific risk will occur. Risk impact assessment investigates the potential effect on a project objective such as time, cost, scope, or quality, including both negative effects for threats and positive effects for opportunities.
Probability and impact are assessed for each identified risk. Risks can be assessed in interviews or meetings with participants selected for their familiarity with the risk categories on the agenda. Project team members and, perhaps, knowledgeable persons from outside the project, are included. Expert judgment is required, since there may be little information on risks from the organization’s database of past projects. Using outside experts to help in the assessment is very helpful since they are experts and they are not as biased as the project team. I have found this technique to be very useful.
The level of probability for each risk and its impact on each objective is evaluated during the interview or meeting. Explanatory detail, including assumptions justifying the levels assigned, is also recorded. Risk probabilities and impacts are rated according to the definitions given in the risk management plan. Sometimes, risks with obviously low ratings of probability and impact will not be rated, but will be included on a watch-list for future monitoring.
Probability and Impact Matrix
Risks can be prioritized for further quantitative analysis and response, based on their risk rating. Ratings are assigned to risks based on their assessed probability and impact. Evaluation of each risk’s importance and, hence, priority for attention is typically conducted using a look-up table or a probability and impact matrix. Such a matrix specifies combinations of probability and impact that lead to rating the risks as low, moderate, or high priority.
Descriptive terms or numeric values can be used, depending on organizational preference. The organization should determine which combinations of probability and impact result in a classification of high risk, moderate risk and low risk.
Usually, these risk rating rules are specified by the organization in advance of the project, and included in organizational process assets. Risk rating rules can be tailored in the Risk Management Planning process to the specific project.
An organization can rate a risk separately for each objective (e.g., cost, time, and scope). In addition, it can develop ways to determine one overall rating for each risk. Finally, opportunities and threats can be handled in the same matrix using definitions of the different levels of impact that are appropriate for each.
The risk score helps guide risk responses. For example, risks that have a negative impact on objectives if they occur (threats), and that are in the high-risk zone of the matrix, may require priority action and aggressive response strategies. Threats in the low-risk zone may not require proactive management action beyond being placed on a watch list or adding a contingency reserve.
Similarly for opportunities, those in the high-risk zone that can be obtained most easily and offer the greatest benefit should, therefore, be targeted first. Opportunities in the low-risk zone should be monitored. Earned Monetary Value (EMV) is a good technique to use here.
Risk Data Quality Assessment
A qualitative risk analysis requires accurate and unbiased data if it is to be credible. Analysis of the quality of risk data is a technique to evaluate the degree to which the data about risks is useful for risk management. It involves examining the degree to which the risk is understood and the accuracy, quality, reliability, and integrity of the data about the risk.
The use of low-quality risk data may lead to a qualitative risk analysis of little use to the project. If data quality is unacceptable, it may be necessary to gather better data.
Risks to the project can be categorized by sources of risk (e.g., using the RBS), the area of the project affected (e.g., using the WBS), or other useful category (e.g., project phase) to determine areas of the project most exposed to the effects of uncertainty. Grouping risks by common root causes can lead to developing effective risk responses.
Risk Urgency Assessment
Risks requiring near-term responses may be considered more urgent to address. Indicators of priority can include time to affect a risk response, symptoms and warning signs, and the risk rating.
All projects have risks. It is the job of the Project Manager to identify these risks as part of the Risk Management Planning Process. Risk Identification determines which risks might affect the project and documents their characteristics. Participants in risk identification activities can include the following, where appropriate: project manager, project team members, risk management team (if assigned), subject matter experts from outside the project team, customers, end users, other project managers, stakeholders, and risk management experts. While these personnel are often key participants for risk identification, all project personnel should be encouraged to identify risks. I worked on a project where we used several of these techniques. I will point those out to you in the following sections.
Risk identification is an integrative process. The frequency of iteration and who participates in each cycle will vary from case to case. The project team should be involved in the process so that they can develop and maintain a sense of ownership of, and responsibility for, the risks and associated risk response actions. Stakeholders outside the project team may provide additional objective information. Especially important is the risk tolerance of the Stakeholders. This is invaluable information in Risk Planning.
The Risk Identification process usually leads to the Qualitative Risk Analysis process. Alternatively, it can lead directly to the Quantitative Risk Analysis process when conducted by an experienced risk manager. On some occasions, simply the identification of a risk may suggest its response, and these should be recorded for further analysis and implementation in the Risk Response Planning process.
A structured review may be performed of project documentation, including plans, assumptions, prior project files, and other information. The quality of the plans, as well as consistency between those plans and with the project requirements and assumptions, can be indicators of risk in the project.
Information Gathering Techniques
I worked on a project where we spent three days planning the project. We engaged several experts in our technology to help us with the Information Gathering Techniques. This helped the project a lot since we (the project team) were not experts at the time of the project. They were very helpful in the brainstorming and Delphi techniques. During each following phase of the project, the Risk list should be looked at to see if any further risks have been identified.
Examples of information gathering techniques used in identifying risk can include:
· Brainstorming. The goal of brainstorming is to obtain a comprehensive list of project risks. Our project team performed the brainstorming with a multidisciplinary set of experts not on the team. Ideas about project risk are generated under the leadership of a facilitator. Categories of risk such as a risk breakdown structure can be used as a framework. (see earlier post) Risks are then identified and categorized by type of risk and their definitions are sharpened.
· Delphi technique. The Delphi technique is a way to reach a consensus of experts. We used Project risk experts as well as Technology experts to participate in this technique anonymously. A facilitator uses a questionnaire to solicit ideas about the important project risks. The responses are summarized and are then sent back to the experts for further comment. Consensus may be reached in a few rounds of this process. The Delphi technique helps reduce bias in the data and keeps any one person from having undue influence on the outcome.
· Interviewing. We also interviewed experienced project participants, stakeholders and subject matter experts to identify risks. Interviews are one of the main sources of risk identification data gathering.
· Root cause identification. This is an inquiry into the essential causes of a project’s risks. It sharpens the definition of the risk and allows grouping risks by causes. Effective risk responses can be developed if the root cause of the risk is addressed.
· Strengths, weaknesses, opportunities, and threats (SWOT) analysis. This technique ensures examination of the project from each of the SWOT perspectives, to increase the breadth of considered. Our project team used this technique to more fully examine the risks that had been identified.
· Checklist Analysis. Risk identification checklists can be developed based on historical information and knowledge that has been accumulated from previous similar projects and from other sources of information. This means you have to record project information at the end of the project to build the historical database. The lowest level of the risk breakdown structure can also be used as a risk checklist. While a checklist can be quick and simple, it is impossible to build an exhaustive one. Care should be taken to explore items that do not appear on the checklist. The checklist should be reviewed during project closure to improve it for use on future projects.
· Assumptions Analysis. Every project is conceived and developed based on a set of hypotheses, scenarios, or assumptions. Assumptions analysis is a tool that explores the validity of assumptions as they apply to the project. It identifies risks to the project from inaccuracy, inconsistency, or incompleteness of assumptions.
· Diagramming Techniques. Risk diagramming techniques may include:
o Cause-and-effect diagrams. These are also known as Ishikawa or fishbone diagrams, and are useful for identifying causes of risks. We used these frequently in projects.
o System or process flow charts. These show how various elements of system interrelate, and the mechanism of causation. Seeing the flow sometimes triggers someone to identify a risk that may have slipped through the cracks.
o Influence diagrams. These are graphical representations of situations showing causal influences, time ordering of events, and other relationships among variables and outcomes.
You can never spend too much time in identifying risks. After the list is made, qualitative and quantitative analysis is done to figure out which risks you spend time and/or money on. Murphy’s law is always a good one!
When doing Risk Management Planning, one input you need is a Risk Breakdown Structure. The model is similar to the Work Breakdown Structure. It may change during the Risk Management Planning Process. Here is an example Risk Management breakdown:
- Company Vision
- Project Management
Risk Breakdown Structures will vary between projects. One benefit of doing one is to remind those people engaged in the Risk Identification process of areas to think about. It will also be an input to Qualitative Risk Analysis where probabilities and impacts are assigned. The impacts can be numerical or High, Medium, Low.
Risks are then prioritized according to their potential implications for affecting the Project’s success. Other things to take into account are stakeholder’s risk tolerance levels, reporting formats and how you will track the risks. The next step in the process will be Risk Identification.
I know all of you have had a project from hell. Mine was a project that had 4 releases before I took it over, so I had no ability to pick my team. The team dynamics had gotten so bad, and the code was so buggy, that the sales people wouldn’t sell the product!
This is the approach I took. I interviewed everyone involved in the project and quickly found out that the main problem was the technical leader. No one liked working with him and he thought he was the God of engineering. The technical writer was ready to go to HR with a charge of sexual harassment. That I had to inform the VP of engineering and the VP of HR in case the charge was made real and we had a legal issue on our hands.
I also worked extensively with the technical leader in the areas of communications and relationship building. The two of us were able to work well together, but somehow he couldn’t translate it to the rest of the team. He didn’t even know when he committed something that would be taken the wrong way. Whenever that happened, I immediately gave him feedback in the hopes he would start to learn to recognize these situations before they incurred and change his behavior.
Using other eye’s to help
When that didn’t work, I brought in a consulting team to help us agree on a mission, goals, roles and how we would run meetings. I invited people from all disciplines; software engineering, technical documentation, first and second level support, sales, marketing, services and quality.
The meetings were heated but we all were able to come up with an agreeable way to run the project. When we had a 3 month checkup with our consulting team, we were not doing much better. It came to the point where one of the support members verbally abused me in public. I had to make a decision, so I told the technical leader that his expertise was needed as a technical guru, but that I was give the project lead role to someone else on the team. Things slowly became better. The project team met to decide how to make the product more supportable and profitable. (Upper level management was ready to cancel the project at this point). We came up with a plan to have the people who knew the code best to do a massive code review and pick the hot spots that had to be rewritten.
The technical leader ended up leaving because it was his complicated, uncommented code that was causing the most problems.
But there was a good ending. I presented this plan to upper management (which would take us a year without releasing while we were rewriting the code) expecting them to reject it. When we got the go ahead – we knew failure was not an option.
We included the whole team to draft a set of metrics that the code had to pass and refused to release it until the key support personnel gave it the ok. One of my inputs to these metrics was constant communications to the point that we met every day to plan the next day’s activities. We won a prize within a year for raising sales so dramatically.
That was my hardest project, but we all learned a lot. My only regret was that I couldn’t save the technical leader. He was very brilliant, but refused to mentor anyone of the team. My message to you is there is no project that is impossible.
Have a great day! Donna
What Goes Into a Risk Management Plan?
Whenever I managed a project, I paid a lot of attention to the Risk Management Planning. PMI is working on a Standard for Risk Management which can tell you just how important it is to make or break a successful project. It is a subject worthy of an entire standard.
The things the Risk Management Plan includes are:
1. Risk Management Planning – this is deciding how to approach, plan and execute the risk management activities for a project.
2. Risk Identification – this determines which risks may affect the project and documenting their characteristics. Some risks are not important enough to do further work on them. This all depends on the risk tolerance of the Stakeholders. For example, if you were buying a car and identified the risks as having a major repair or replacing a tire, you may consider the risk of replacing a tire not to be of significant consequence to stop you from buying the car. If, however, you thing the risk of losing the engine block to be high, you would probably pass on the car.
3. Qualitative Risk Analysis – this is the process of prioritizing risks for subsequent further analysis or action by accessing and combining their probability of occurrence and impact. In the car analogy, replacing the tire may have a high probability but a low impact. In this case, you may cease to analysis it further but perhaps put a budget contingency in for the possible replacement.
4. Quantitative Risk Analysis – this is where you numerically analyze the effect on the overall project objectives of the identified risks.
5. Risk Response Planning – for a subset of the identified risks, you develop options and actions to enhance opportunities, and to reduce threat to project objectives. Note: not all risks are bad. You may have a risk of getting increased resources.
6. Risk Monitoring and Control – this is where you track identified risks, monitor residual risks (that may come from an action to reduce the primary risk), identify new risks, execute risk response plans and evaluate their effectiveness during the project life cycle.
These processes interact with each other and with the processes of the other knowledge areas. Each process can involve effort from one or more groups of team members based on the needs of the project. Processes in practice may overlap and interact in details not presented in this post. I will write a separate post talking about process interactions.
[i] Most of this information can be found in Guide to the Project Management Body of Knowledge (PMBOK Guide) 3rd addition. @2004 Project Management Institute, Four Campus Boulevard, Newton Square, PA 19703-3299 USA
What goes into a Project Plan?
1. The Scope Management Plan: This is a document that defines the Scope of the Project. It is especially important to be though and accurate because it feeds into the Requirements document. It is also important that all the Stakeholders buy into it. It should be signed off before going the next step. If the Scope changes it has to go through a change management process and all of the Stakeholders must sign off on it.
2. Schedule Management Plan: The Schedule Management Plan is a component part of the Project Plan that is use in Activity resource planning. The Activity resource plan includes expert judgment, various levels of resource levels or skills, size of machines, tools and make/buy decisions.
3. Cost Management Plan: Costs will adhere to a prescribed precision based on the scope of the project and may include a contingency amount. Various cost measures or other indicators (e.g. person-days, volume of product).
4. Quality Management Plan: The Quality Management Plan describes how the project team will implement the organization’s quality policy. It must address the quality control, quality management and continuous process improvement for the project.
5. Staffing Management Plan: Identifying project roles, responsibilities and reporting relationships. Obtaining the human resources to complete the project. Improving the competencies and interaction of team members to enhance project performance. Team building plays a big part here.
6. Communications Plan: Determining the information needs of the stakeholders. Making needed communications available to the stakeholders in a timely manner. Collecting and distributing performance information including status reports, performance reports and forecasting.
7. Risk Management Plan: The Risk Management Plan includes risk identification, risk analysis, risk response planning, monitoring and control.
8. The Procurement Plan: This plan includes what has to be procured, who will provide the estimates, types of contracts to be used, managing multiple providers, constraints and assumptions that could affect the contract and handling make/buy decisions. [i]
[i] Guide to the Project Management Body of Knowledge (PMBOK@ Guide) Third Edition @2004 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA
This is a process concerned with identifying, analyzing, and responding to project risk. (PMBOK)
It is also the art and science of identifying, assessing and responding to project risk throughout the life of a project and in the best interests of its objectives. Now in all of the projects I’ve managed in my 30 years of experience, there has always been risk.
The trick to the game is to figure out what the risk tolerance of your stakeholders is. How much risk are they willing to put up with and how much do they want solid fallback plans for?
In some cases, a level of uncertainty is acceptable and the level of contingency planning can be as simple as put another person on the project, or slip the schedule.
Sometimes it’s not so simple, and the stakeholders want to know the monetary value or expected value of the probability of a risk occurring. The basic level for excepted value is:
Expected monetary value (EMV) = probability * impact
The expected value result can either be added to the costs of the project or subtracted from the project’s profit. The project profit or cost is usually referred to as the baseline. The baseline is the initial approved cost or profit structure for the project.
Project EMV = project cost + risk expected value – opportunity expected value
= project value/profit – risk expected value + opportunity expected value
Remember, risk increases the cost and decreases the profit; and opportunity increases the profit and decreases the cost. Risks are bad things that may (often do) happen to us on projects, sometimes expressed as “threats”. Opportunities are good things that may happen to us on projects and may enhance the overall situation.
With that in mind, let’s work through a few examples.
Example: You have a project with total planned costs of $100,000. What information of value to an expected monetary analysis do you have so far? The baseline ($100,000). Now with that bit of information, let’s add some more considerations and complexity to it. For this same project, with total planned costs of $100,000, there is a risk that one of your team members, Matthew, will be crowned Prince of Arabia! If that happens, we’ll lose $8,000 in the process of replacing him on the team. Now what new information do you have that helps you out? You have the Risk Impact ($8000).
After checking with highly placed sources within Arabia, we have learned that there is about a 60% chance that Matthew will be approved as the new Prince. What new information do we have now? We have the probability (60%).
Now for this project we know that the cost is $100,000, and there is a 60% chance we’ll lose Matthew, costing the project $8000. What is the Expected Value of this risk happening to our project? In this instance, we are looking at the expected value of the risk. It has a potential cost of $8000. But, since the probability of it happening is only 60%, its EMV = $8000*.6 = $4800. We have now calculated the EMV for this risk event. We have to apply the EMV in the context of the project as a whole. What is the EMV of the cost of the whole project? The answer is $104,800 ($100,000 + $4,800).
We also need to consider any opportunities which may offset the cost of the risk. For this project, in addition to the potential concerns of Matthew’s leaving, we have just received some good news! We may have the opportunity of a bonus from the customer, which would reduce costs by $20,000. The chance of us getting the bonus is 30%. What is the expected value of this chance? It is $6000, 30%*$20,000. Are you still with me here?
Now we have a lot more information for the stakeholders. The project will cost $100,000. There is a risk of losing Matthew at an additional cost of $8000, but there is only a 60% chance of that occurring. There is also an opportunity for a bonus of $20,000, with a chance of 30% of that occurring. With all of these considerations, what is the Expected Monetary Value of this Project? It is $98,800. This is calculated by taking the cost baseline of $100,000 + $4800 (risk of losing Matthew) and subtracting the EMV of the opportunity because it will affect our costs. That is $6000. So the total Expected Monetary Value of this project is $98,800. That incorporates both known risks and opportunities.
For our project we now have a new perspective. Nancy from accounting finally came through with the numbers on how we are expected to profit from the project. Specifically, she was able to establish that the project will yield about $210,000 in revenues. That will be offset by the cost of $100,000, but management is asking for a risk analysis. To review, what is the baseline profit of the project? It is $110,000 ($210,000 – $100,000).
Next we need to take into account the risk of losing Matthew which would increase cost by $8000. There is also an opportunity of a bonus that will increase revenues. Let’s list our information:
· The project has a cost baseline of $100,000
· Revenues are anticipated at $210,000
· There is a 60% chance we’ll lose Matthew at a cost of $8000
· There is a 30% chance we’ll earn a bonus of $20,000
· For a few kickers, there is a 10% chance we’ll hit obstacles increasing costs by $30,000
· There’s a %70 chance we’ll have a legal fight costing $10,000
With all of this new data, what is the new EMV? It is $100,000 (baseline cost) – $4800 ($8000 * %60) + $6000 ($20,000*30%)-$3000 ($30,000* %10) – $7000 ($10,000*70) = $101,200
So from a risk perspective, this project is worth doing.
Lack of knowledge of future events
Goals of PRM
To identify project risks and develop strategies which either significantly reduce them or take steps to avoid them.
The probability those outcomes will be favorable.
The probability those outcomes will be unfavorable.
Is the cumulative effect of the chances of uncertain occurrences adversely affecting project objectives.
1. Risk Event – Precisely what might happen to the detriment of the project
2. Risk Probability – How likely the event is to occur
3. Amount at Stake – The severity of the consequences
Probability = Frequency of relevant events
Total number of possible events
Risk Event Status (criterion value or ranking)
Risk Event status = risk probability x amount at stake
1. Risk Identification
Determining which risks are likely to affect the project and documenting the characteristics of each. Can be classified as:
a. Scope – Risk associated with changes of scope or the subsequent need for “fixes” to achieve the required technical deliverables.
b. Quality – Failure to complete tasks to the required level of technical or quality performance
c. Schedule – Failure to complete tasks within the estimated time limits, or risks associated with dependency network logic
d. Cost – Failure to complete tasks within the estimated budget allowances
2. Risk Quantification
Evaluating risks and risk interactions to assess the range of possible project outcomes.
3. Risk Response Development
Defining enhancement steps for opportunities and responses to threats.
4. Risk Response Control
Responding to changes in risk over the course of the project.
a. Product description
Risk depends on the nature of the product. Proven technology has less risk than products requiring innovation and invention.
b. Other Planning outputs
Review outputs from the processes for possible risks, e.g., WBS, cost estimates and schedule duration’s, staffing plan, procurement management plan.
c. Historical information
2. Tools and Techniques
Helps understand the cause and effects of risks.
a. Sources of Risks
This includes such items as stakeholder actions, unreliable estimates, team turnover, changes in requirements, insufficiently skilled staff.
b. Potential Risk Events
Precisely what might happen to the detriment of the project, such as natural disasters, requirement for development of new technology, etc.
c. Risk symptoms
These sometimes are called triggers, early warning of an impending event, etc.
d. Inputs to other processes
Risks can be inputs to other processes as constraints or assumptions.
a. Stakeholder risk tolerances
This provides a screen for both inputs and outputs to risk quantification.
b. Sources of risk
c. Potential risk events
d. Cost Estimates
e. Activity duration estimates
2. Tools and Techniques
a. Expected Monetary value
This is the product of risk event probability of occurring times the risk event value (could be a gain or loss).
b. Statistical sums
This calculates the range of alternative project budgets from the cost estimates for individual work items.
The most common is Monte Carlo analysis, which is used to analyze the behavior or performance of the system. The results of a schedule simulation may be used to quantify the risk of various schedule alternatives, different project strategies, and different paths through the network or individual activities.
d. Decision Tree
e. Expert Judgment
a. Opportunities to pursue, threats to respond to
This is a list of opportunities that should be pursued and threats that require attention.
b. Opportunities to ignore, threats to accept
- Business Analyst
- Communications Management
- earned value
- knowledge areas
- Living Your Best Life
- Performance Management
- Phase Review Process
- Project Initiation
- Project Management
- Project Phases
- quality management
- Risk Management
- Schedule Management
- Scope Management
- Writing and Documentaiton
- Young Life