Test prep ch 11 risk

Risk

1. Is related to an uncertain event 2. May affect the project for good or bad. Although it usually has a negative connotation it may well have an upside.

Change requests

When risk events occur these are a natural outcome to the project. In addition even when events do not occur, the product may be changed as a result of new risk related information gathered during this process

Reserve analysis

A data analysis tool room therapy that analyzes data associated with monitor risks. This is a review that would alert the project manager if reserves fall below a threshold

Escalate

A key way of dealing with a threat. This is not a favor choice when dealing with risk. It should only be used when a risk response is outside of the project managers authority. If a threat is this, there needs to be a very clear handoff of responsibility as it becomes someone else's responsibility with this.

Acceptance

A key way of dealing with threats. It is a perfectly reasonable strategy for dealing with risk whether positive or negative. When doing this you're simply acknowledging that the best strategy may not be to escalate avoid transfer or mitigate it. It may just be to do this and continue with the project. If the cost or impact of other strategies is to great or the likelihood is low this is a great strategy. This may be active or passive. Passive requires no proactive steps. Active may involve setting aside a contingency reserve in case the risk event occurs

Avoid

A key way of dealing with threats. It's a very appropriate tool for working with undesirable risk in some circumstances. For instance, a software project may choose to avoid the risk associated with using a particular piece of cutting edge technology in favor of using a slower but more reliable technology.

Transfer

A key way of dealing with threats. To do this to another party outside of the project is to make it their responsibility. Contractual agreements and insurance are common ways to do this. The key here is at the risk is moved outside of the performing organization

PESTLE

A prompt list that stands for political, economic, social, technological, legal, and environmental

VUCA

A prop list that stands for Volatility, uncertainty, complexity, ambiguity

TECOP

A prop list that stands for technical, environmental, commercial, operational, and political

Detectability

A risk parameter. How easily a risk event can be noticed or recognized. Higher is more desirable

Manageability

A risk parameter. How easily a risks impact can be managed. Hire as more desirable

Strategic impact

A risk parameter. How likely the risk event is to impact the organization strategic goals. Lower this is more desirable

Dormancy

A risk parameter. How much time will likely pass after the risk is occurred before it is detected. A home water leak and a really huge room might have more this little water leak in the kitchen. Lower is more desirable.

Urgency

A risk parameter. How much time you have to respond to a risk event. In short amount of time does not necessarily make the risk important, but it does make it urgent. Lower urgency is more desirable

Connectivity

A risk parameter. Many negative project events that occur are actually a combination of numerous risk events. Often the way that risks occur is similar to the way Domino's fall, with one impacting the next and setting off a chain reaction. Understanding how risks are connected is important and lower this is more desirable

Propinquity

A risk parameter. This is the measure of how important the project stake holders perceive this risk to be. Lower is more desirable.

Controllability

A risk parameter.How easily a risk event can be changed. Software backups might be a way to help control the outcome of the example of malware. Higher this is more desirable

Proximity

A risk perimeter. How much time you have before the risk impacts project goals. Lower is more desirable

Tornado diagram

A sensitivity analysis named for its funnel shape of its bars Ranked from greatest to least. It provides a way to depict the project sensitivity to cost or other factors. This type of sensitivity analysis shows the impact of one change while holding other factors constant. By running this analysis against various risks, it will help the team understand which risks pose the greatest threats or potential rewards to the project

Share

A specific strategy taken to capitalize on positive risks. In order to share a positive risk, the project seeks to improve the chances of the risk occurring by working with another party. For example if a defense contractor identifies a positive risk of getting a large order, they may determine that sharing that risk by partnering with another defense firm or even a competitor would be an acceptable strategy

Escalate

A specific strategy taken to capitalize on positive risks. These opportunities are managed at a level above the project manager. For example at the risk of a technological breakthrough on the project is much bigger than the project, it may be appropriate to do this higher within the organization

Enhance

A specific strategy taken to capitalize on positive risks. To do this at first requires that you understand the underlying causes of the risk. By working to influence the underlying risk triggers, you can increase the likelihood of the risk occurring. For example an airline might add flights to a popular route during a holiday in order to do this and profitability during heavy travel times

Exploit

A specific strategy taken to capitalize on positive risks. Where this is concern you were trying to remove any uncertainty. For instance if a positive risk of finishing the project early as identified, and adding additional people to increase the possibility of that project is completed early would be an example of this

Risk breakdown structure

A tool for creating consistent risk categories. It is graphical, hierarchical decomposition used to facilitate understanding and organization. We are breaking down the categories of risks, and not the work. You are not breaking down the actual risks, because they won't all be known until we perform the identify risk process. Instead you are breaking down the categories of risks that you will evaluate such as internal risks, external risks, technology, integration problems.

Implement risk responses process for agile

Agile project often implement Spike solutions which help evaluate a risk and determine which course to take

Contingent response strategies

Also known as a contingency plan or a fallback plan is one where the project team may make one decision related to the risk but make that decision contingent upon certain conditions. For example a project team may decide to mitigate the technology risk by hiring an outside firm with expertise in that technology but that decision might be contingent upon the outside for meeting intermediate milestones related to that risk

Work performance data

An input into the monitor risk process. This provides information on the results of the plan. For instance the status of a deliverable provides helpful information related to schedule risk, cost risk, or other areas of concern

Risk register

An output of identify risks process. It is a list of all risks, their causes and any possible responses to those risks that can be identified at this point in the project. The identify risks process built this.

Active acceptance

And key way of dealing with threats. This may involve setting aside a contingency reserve in case the risk event occurs

Mitigate

And key way of dealing with threats. To do this simply means to make it less. For instance if you were concerned about the risk of weather damage to a construction project, you might choose to construct the building outside of the rainy season. It does not eliminate the risk, but it should diminish it

Influence diagrams

Another useful data analysis tool used in perform quantitative analysis process. It depicts the actors or entities, influences, and possible outcomes

Threats

Anything that could potentially jeopardize the goals of the project.

Risk categorization

Categorizing the detailed risks can help you build a better big picture of the risks. This may help you understand which parts of the project have the highest degree of uncertainty. The RBS is a common way to help organize the identified risks in the categories

Meetings

Create a project culture we're bringing up items related to Risk in these is always acceptable and risk is discussed regularly

Technical performance analysis

Data analysis tool where you analyze the technical performance of the process that are associated with monitor risks. This compare the results with the plan. For example a project to construct a roadway might measure specific links of road with what they had planned to have completed at a point in time.

Risk data quality assessment

If the data about the risks is not high quality, and the decisions you make will naturally have more uncertainty. The data should be objectively evaluating to determine whether or not it is accurate and of acceptable quality. For instance if you were evaluating where the risk for a construction project, you would need to evaluate the quality of the weather data you were using. This is a tool for perform qualitative analysis

Plan risk responses process

In this process we are now ready to create a detailed plan for managing the risks. This creates a plan for how each risk will be handled. Risks can be positive or negative, so careful consideration must be given to each risk. This is the last planning process within risk, and is the one that is most oriented toward taking action. This plan is actionable as it assigns specific tasks and responsibilities to specific team members. It's performed after all of the other risk planning processes have been completed. The risk register flows in as an input and the updated risk register emerges as its primary output.

Cost benefit analysis

Many risks come down to an impact in terms of money. Using this technique you would make sure that the response does not cost more than the risk. This is a tool used in the plan risk responses process

Project documents updates

New risk information, whether it is changes to risk estimates are actual numbers such as cost related to whether damage, should be regularly updated in the risk register

Hierarchical charts

One example is a bubble chart, which shows rankings plotted on an X & Y axis and a third dimension of data shown by the size of the data point. Used during perform qualitative analysis process

Procurement documentation

Portions of the project that are procured from outside organizations carry their own inherent risks. This brought into this process will help the team spot and identify these risks.

Document analysis

Reading the project documentation can be a very good way to identify the risks. Remember that a risk is an area of uncertainty, and areas were project documentation is not clear might be an indicator of underlying risks.

Tailored risk approach

The approach you choose needs to be tailored to fit with the factors that influence your project such as size of project, project complexity, inherit project risk, project methodology, importance

Change requests

The key output to the implement risk responses process. After the risks have been identified analyzed and the responses planned, these are the primary way those responses are implemented

Monte Carlo analysis

The most common type of risk simulation. It is a tool that takes details in assemble the big picture. Performed by a computer that throws large numbers of what if scenarios at the schedule activities are at individual costs to see the impact of certain risk events. This technique will show you it is not always evident by simply looking at the schedule or the budget. It will often identify tasks that may not appear inherently high risk, but in the event they are the later that they exceed budget, the whole project may be adversely affected

Root cause analysis

The primary tools used to analyze data in the identify risk process. This is using Ishikawa, Fishbone, diagrams or the 5 why technique to trace risk events back to identify the underlying factors that lead to them.

Assumptions and constraint analysis

The project management plan is largely built around these and these need to be analyzed and challenge from time to time. If the project finds that they can relax a constraint, example this project needs to use all open source software, this may open the door for more options and planning and execution. Likewise if an assumption, positive or negative, is found to be incorrect, it can greatly impact the project, example external software API is the project need will be available before development begins

Representations of uncertainty

The project team needs to have some way of showing the likelihood of a risky occurrence. Common types of probability distributions are triangular and beta.

Risk management plan

The real purpose of the plan risk management process. It is a roadmap to the other six risk management processes. It defines what level of risk will be considered tolerable for the project, how risk will be managed, who will be responsible for risk activities, the amount of time and resource that will be allotted to risk activities, and how risk findings will be communicated it also includes a description of how the risks will be categorized. It also may contain more information such as standard vocabulary about probability and impact that apply to the project

Risk Audits

These are focused on overall risk management. They are more about the top down process that about the individual risks. These evaluate how the risk management plan and the risk response planer working at the project progresses and also whether or not the risks that were identified and prioritize are actually occurring. A tool used in monitor risks process

Decision tree analysis

These are used to show probability and arrive at a dollar amount associated with each risk. For each branch, you compute the expected monetary value for the event. The EMV you should take into consideration each probability included in the branch.

Work performance reports

These do not focus so much on what has been done as they do on how it was done. For instance where the work performance information provides information on the status of the deliverable, this focuses on cost time and quality performance. Where this is concerned, the actual results are compared against baselines to show how the project is performing against the plan

Agreements

These should be treated as a contract. Contracts almost always have enforcements and penalties if the terms are not met, and often times they have rewards if the terms are met or exceeded. These potential penalties and rewards represent a type of risk

Overall project risk

Things that threaten the success of the project.

Risk probability and impact assessment / probability and impact matrix PIM

This assist you when evaluating risks to determine what the highest priority should be. The way it is used is that each risk in the risk register is evaluated for its likelihood of occurring and its potential impact on the project. Each of these two values is given a ranking such as low medium or high or one through 10 and are multiplied together to get a risk score. The resulting score is used to set the priorities.

Alternative analysis

This is a data analysis used to look at alternative ways to deal with a risk events in general. For example if there are too many unknowns related to a particular building material, and alternative material maybe the rational choice. This is a tool used in the plan risk responses process

Monitor risks process

This is a monitoring and controlling process that looks back over the plans and any execution that has taken place in comparison with each other. You're asking questions such as did we plan properly? Did the results come out the way we anticipated? If the results did not match the plan should we take corrective action by modifying the plan or by changing the way we are executing? Are there lessons learned that we need to feed into future activities or projects? Is it more risk is concerned we've done quite a bit of planning, identifying, analyzing, and predicting this process takes a look back to evaluate how all of that planning is lining up with reality. It is performed almost continually throughout the project.

Identify risks process

This is a planning process that evaluates the project to create a list of the risks that could potentially impact the project and to understand the nature of those risks. It is often performed multiple times on the project. This may be especially true in this case since your understanding of risk, and the nature of risks themselves will change and evolve as a project progresses. This process builds the risk register, which is needed before the remaining five risk processes may be performed. This list of risks will drive the other risk processes. Although it is performed early on in the project, risks change over time and new risks arise. It may be necessary to perform this process multiple times throughout the project

Implement risk responses process

This is an executing process that puts the risk response plan into action. When this is performed depends upon the risks you have identified. It may begin as soon as you have completed the processing process of plan risk responses plans were written to be implemented, and when it comes to risk you've done a lot of planning and the previous five processes

SWOT analysis

This is particularly useful since it is a tool used to measure the projects strengths, weaknesses, opportunities, and threats. Each one of these is plotted in the quadrant where the weaknesses (usually internal) and threats (usually external) represent the highest negative risk, and the quadrant where strengths (usually internal) and opportunities (usually external) are highest will represent the highest positive risk on the project. This can help give you another perspective on risk that will often help you identify your most significant project risk factors

Plan risk management

This is the process that is concerned with one thing, creating the risk management plan. In this process, the remaining six management processes are planned. How they will be conducted is documented in the risk management plan, which is typically general and high-level in nature. When you are performing this, you usually are not concerned with specific project risks. Instead you will focus on how risks will be approached on a project.'s process creates the roadmap for the other six processes the more risk that is inherent on the project, and the more important project is to the organization, the more resources you would typically apply to performing this process. This process is general and high-level in nature and takes place early on in the project before many of the other planning processes are performed. Because it can significantly influence decisions made about scope time cost quality and procurement

Risk report

This is updated in the perform quantitative analysis process to include the results of your quantitative analysis. This can include anything from the ranking of the risks to the diagrams used in the data analysis section. The main point is to update this which will feed the next process

Prompt list

This is used by the project team to help facilitate a risk review. They are often use periodically or between each phase to serve as a kind of framework for identifying the new risks that might have arisen. There are three different frameworks PESTLE, TECOP, and VUCA. For example a project team might ask, since our last review what political economic social technological legal environmental changes or developments have there been that could impact our project? Risk management is an ongoing set a processes and these give you a framework to make this easier

Risk report

This looks at the factors contributing to risk and high-level information on the identified risks. This is more of a summary document and will likely be more verbose about what things are contributing to project risk

Plan a risk responses process for agile

This process continues the predictive planning centric approach. It does not translate well to agile although it could be performed on a smaller scale for an upcoming iteration

Monitor risks process for agile

This process evaluates how the plan lines up with reality. It is difficult to apply an agile project the way it is implement it on a predictive one

Plan risk management process for agile

This process is an example of one that was designed for predictive approach. Agile as a sort of built-in risk management plan which is to manage risk through small incremental development and delivery. And agile project would not produce a large risk management plan, detailing the approach to the other processes.

Identify risk processes for agile

This process is difficult to translate to agile, however it may be performed when planning for an iteration. If there were risks of the agile team was concerned about, creating a list of these would be appropriate. Agile project seek to identify risks early and to respond to them rapidly. They take smaller steps to minimize risk. As uncertainty on a project evolves and changes it may change the prioritization of backlogged work for you

Perform qualitative risk analysis process

This process is usually done rapidly in order to determine which risks are the highest priority on the project. This process takes each risk from the risk register and works to analyze the probability of Whitaker and its impact if it does. By using the probability and impact matrix PIMA prioritization and ranking can be created which is updated on the risk register. This process helps your rank and prioritize the risks so that you can put the right emphasis on the right risks. It helps to ensure that time and resources are spent in the right risk areas. It is performed more than once on the project Because it can be performed fairly quickly relative to the other processes, and it is normal for their risks and their underlying characteristics to change over the life of a project making this process important to revisit often

Perform qualitative & qualitative risk analysis processes for agile

This process requires a thorough risk register, so it is unlikely to be performed on an agile project to the degree that is performed on a predictor project. Still the same tools and techniques could be applied here

Perform quantitative risk analysis process

This process seeks to assign a project value to quantify the risks that have been ranked by perform qualitative risk analysis. This likely value is most often specified in terms of cost or time. Not all projects need to perform this process. For many projects the previous process of qualitative risk will be sufficient. However if your project is large, complex, strategic, required by contract, required by key stakeholder, you may decide to carry it out. This process updates the risk register in this information will be used by the next three processes. And it is usually performed right after qualitative risk analysis and sometimes performed at the same time

Risk register

This provides a list of all identified risks on the project, what the possible reactions to this risk are, with the root causes are, and what categories the risks fall into. It is also common to update the RBS with the more specific information. This contains the identified risks, the potential risk owners, and a list of potential responses to those risks. This is an output to the identify risks process

Passive acceptance

This requires no proactive steps. And key way of dealing with threats.

Individual project risk

This threatens an objective. For example if a decision is made to move something from a local server into the cloud in order to save money and improve up time, there might be an individual risk associated with that. If the move cannot be carried out, it might threaten the objectives of saving money and increasing of time, but it could still be moved back to the local server and continue the project

Brainstorming and checklists

To data gathering techniques that are important to help make sure the right risks are identified. Used in the identify risk process.