Risk Response Plans

Now that we've identified and prioritized the project risks, it's time to build response plans, these plans are proactive measures to try and do the following:

• Avoid the risk
• Mitigate the risk's impact or probability
• Transfer it to a 3rd party.

there may also be risks that have such a low RPN/Probability/Impact that we may choose to just accept or there just may be no way to avoid, mitigate or transfer the risk and we have to accept it.

Risks with negative impact

1. Accept: by accepting a risk we decide not to take an preventative action; accepted risks are monitored throughout the project in status updates. accepting risk is not the same as ignoring risk
2. Mitigate: try to adjust the budget, scope, or schedule to reduce the likelihood of the impact and/or probability of risks
3. Avoid: Take preventative actions to eliminate the chance of the risk occurring.
4. Transfer: this does not eliminate the risk, but moves it to a 3rd party that is better equipped to deal with the risk.

Commonly 

• Low priority risks are accepted
• Medium & High priority risks are mitigated 
• Ideally Medium & High priority risks are avoided
• however avoiding a risk may not be feasible or the cost outweighs the impact

Risks with positive Impact

1. Accept:the risk is observed in status meeting and if occurs will be happily accepted, but no proactive measures will be taken to insight the risk
2. Enhance: implement proactive measure to try and insight the risk
3. Exploit: try to ensure the risk will occur.
4. Share: try to share the risk occurrence with a 3rd party

once the risk response plans are established the project scope, schedule and budget must be updated to ensure that these risk response plans are available should the need arise.

Risk Identification

All projects have varying levels of risk, the more unknowns the more risk, Risk planning is the process of proactively preparing for risks, these proactive measures are part of the project scope, budget and schedule. One thing to keep in mind is the difference between a risk and an issue, a risk is something that can be identified and planned for an issue is something out of left field that needs to be dealt with for example lightning strikes the project sponsor, whereas a risk could be new legislation that may or may not be passed during the project.

We plan for risks early on because preparing for a risk will greatly decrease the cost of resolution if identified and prepared for vs taking the project by surprise. The greatest level of unknown is also at the start of the project, as the project moves through the execution phase more and more of the unknowns are identified and risks tend to decrease as the project approaches closing.

Risk Identification 
Risk planning starts with identify risks, the whole project team should be involved in this process; risks can be: technological, economic, cultural, environmental, organizational, external, internal, business, resources, schedule, budget, profit, quality of deliverables, etc. the list goes on, what has to be established is the likely hood of a risk affecting the project, this can be done by:

• Review historical records of similar projects 
• Use a checklist of common risks that can occur
• Brainstorm with the team what possible risks might occur 
• Review the Project Scope (WBS and activities), schedule, and budget for any assumptions that could manifest themselves into risks
• Any risks identified outright when creating the project documents

When identifying risks it is important to not just identify the event but also the impact of the risk. It is easy to focus on the negative risks, but there could also be positive risks, that is events that might occur that could benefit the project; such positive risks should also be identified.

Risks should be captured in a document called a "Risk Register" or "Risk Log"

Not all risks have an equal chance of occurring and since there is far more risks in a project then can possibly be addressed it is imperative that the risks with the highest chance of occurring are the risks the project is prepared for.

Qualitative Risk Analysis

allows the prioritization of risks based on

• likely of occurring
• their impact
• ease of identifying their occurrence 

The risk matrix is designed in such a fashion that it uses a heat map to establish the order that risks should be panned for

for example a risk that has a high impact and a medium probability falls into the top middle square which is red. whereas a risk that has a low probability and impact would fall into the bottom left square that has a risk of green. 

the idea is that all red risks need to of high priority, usually all read and yellow risks have mitigation plans and green risks are reviewed to decide if they need a specific mitigation plan.

For a more sophisticated scale we can use the RPN or risk priority number, this number is generated 

by multiplying the probability value by the impact value by the detraction value 

Probability	Impact	Detection
Won't happen Not likely to happen May or may not happen Likely to happen Definitely will happen	No Impact Not significant May or may not be significant Significant Severe	Definite Detection Easy to detect May or may not be detected Difficult to detect Impossible to detect

with these scales in place and our rpn formula
rpn = probability * impact * detection

Risk	Impact	Probability	Detection	RPN
Risk # 4	4	4	5	80
Risk # 2	3	4	2	48
Risk # 1	2	4	2	16
Risk # 3	1	2	3	6

Risks are ordered from highest RPN to lowest , there is no hard had fast rule as to how many risks should be planned for but between the top 1/3rd and 1/2 is a usual amount.

Baseline a Project

Once the entire project plane is complete, that is the budget, schedule, and scope are agreed to by the project sponsor and management; this is known as the baseline. the baseline is used to monitor and control the project throughout the execution phase, at the very least the documents that are baselined are:

• the Scope Statement
• the Requirements document
• the WBS
• the schedule
• the time-phased budget

Once a project it baselined the only way to make modifications to it is through the "Change Control Process" that was defined in the {charter???}, this is to help insure that the Stakeholders expectations and requirements are met. by following the "Change control process" any changes are reviewed and agreed with by the stakeholders.

Scope Creep vs Scope Change

Scope creep is when requirements work their way into your project through a back channel that is they do not go through the "Change control process" and as such the project scope, budget or schedule do not get adjusted putting the project at risk of failure, whereas scope change does go through the "Change control process" and thus all stakeholders are aware of the change and how it will affect the scoped, budget and delivery of the project.

it is essential that any change to the project, scope, budged or schedule is captured and approved before it is implemented. No changes are allowed to be made to the project baseline without written notice that is approved, if approved this notice is called a "Change Notice" and it is a formal proposal to modify any document, deliverable or the schedule baseline.   

Schedule Optimization

Once we've attempted resource smoothing and still needed to leverage resource leveling which in most cases will elongate a project delivery date, we must agree with the sponsor and management on the appropriate course of action, should it be deemed that a delay in project delivery is unacceptable then the options are as follows

Crashing: is used to add resources to a project to meet an accelerated or constrained delivery date. When crashing a project schedule it is important to not only focus on the critical path, but ensure that as the original critical path is shrunk that no new critical paths do not emerge and if they do to focus on them. Forcing employees to work overtime is also considered crashing.

Crashing may seem attractive initially but it increases the required budget costs and has an adverse affect on moral if personnel are required to work overtime. bringing more personnel  onto a project also has adverse effects, these newbies often come with a learning curve and use up the time of your seasoned personnel slowing productivity initially before the newbs are ramped up.

the decision to crash and how much to crash a project should be made very carefully. 

Fast Tracking:If a project cannot be elongated and suffers from a resource constraint once it has been smoothed and leveled and adding resources is not an option then a PM can attempt to fast track some activities that is to look at sections of the critical path where alternative paths have slack, and leverage that slack to take critical path activities and try to start them in parallel with the resources from the alternative path that has slack.

this can't always be accomplished because it is depended on the types of resources available and critical path tasks that could potetially run in parallel at least partially.

Scope Reduction: if crashing and fast tracking a project are not an option then the PM can discuss with the sponsor about reducing the scope of work, by removing non-critical activities from the critical path the project delivery date can be hastened. it is very important to remove non critical activities as not to degrade the performance or quality of the end product.

by removing activities we in turn will be reducing deliverables or potentially even dropping some, any reduction of scope must then be captured in all appropriate project documentation.

• WBS
• Scope Statement 
• Requirements documentation
• Project Charter

There can come a project that cannot be crashed, fast tracked and the sponsor with  management will not agree to a scope reduction, this is an over-constrained project. This is where softskills come into play it is the PM's job to demonstrate to the sponsor and management that the project is high risk; it needs to be established which two of the three constraints are the most important to understand which one can be manipulated to give the project a chance of success.