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.

Resource Optimization Techniques

now that we have our network diagram and from our activity list we are aware of which activities require what resources it's time to assign/allocate those resources throughout our project and identify any resource constraints we may have. up to now we haven't considered resources availability, we've just identified required resources but now that we have a network diagram of our project we can identify resource bottlenecks for example if two activities.

Our aim is to create a smooth resource distribution throughout the project as well as identify any resource over or under allocations.

Resource Smoothing
is a technique that is used to adjust activities within the constraint of the project duration to evenly distribute resources throughout the project it is done by establishing usage limits for each resource to ensure that resources are note over or under utilized. The float of non critical items is used to reschedule activities to smooth out the use of resources.

Resource Leveling 
is used when resource smoothing is not sufficient to distribute resources without elongating the project. It's a technique that involves adjusting the start and finish dates with the intent of balancing demand with availability of resources. leveling will defer activities until required resources are available, this may very well elongate the project. That is leveling doesn't factor in activity float.

in the event that resource smoothing is not enough and we need to utilize resource leveling odds are that we have to either adjust our project deliver date or we need to allocate more resources to the project, either way we must return to the sponsor and align either we add resources or increase the schedule. if we add resources we must ensure that these are captured in the resources activity list

Network Diagramming

Project scheduling often leverages a network diagram, this is the case because network diagrams provide two major benefits

• displays the critical path: activities that must be done end to end
• reveals flexibility: places we can optimize resources to increase delivery

this visual representation of all the activities that must be done in a particular order is invaluable to understand a project

insert diagram

Critical Path method
this method is used to map the shortest path possible to project completion, it also reveals the tasks that if delayed will ultimately delay the project delivery. The critical path is the longest path from project start to finish whereas the non-critical paths can be adjusted in duration within reason and not affect the project delivery date.

With the network diagram complete and our critical path identified we can look at our alternative paths and identify their slack or float value, that is the amount of time from the earliest start date for each activity that can be deferred or extended without pushing the projects delivery date.

To Identify our critical path

Forward pass analysis
is the process of moving through each path identifying the earliest start and end date for each activity.

• Earliest start date (ES) is the earliest date that an activity can begin with respect to it's predecessor relationships
• Earliest finish date (EF) is the earliest date that an activity can finish, (ES + duration)

insert diagram

float: is between paths is the difference between the duration of the critical path and all alternative paths, each alternative path has it's own float value, that value is how many days that path can be delayed without delaying the project

Backward pass analysis
The backward pass analysis is the process of moving from the end of our project back to the beginning to determine the latest start date and the latest finish date for each activity

• Latest start date (LS) is the latest date an activity can start without delaying the project delivery. (LF - Duration)
• Latest finish date (LF) is the latest date that an activity can finish without delaying the project delivery.

Activities who's ES & EF values are the same as their LS & LF values are on the critical path.

the difference between an activities LS and ES is the float

Reconciling Estimates

As we've mentioned before, when the developing the project charter it is common to use a top-down estimating approach, however once the charter is signed off at the end of the project initiation phase it's time to start the project planning phase. In the planning phase when building the work breakdown structure it is time to implement the more accurate estimation approach of bottom-up.

In the Planning phase when a bottom up estimation is completed it is common for the two estimations to be different, this is of course the result of the bottom up approach being more labor intensive, difficult and accurate than the top down approach. More often than not the bottom-up approach is generally higher than the top-down, this is usually because of political reasons or optimistic estimations or just during the charter the whole scope just wasn't evident.

When the bottom-up estimation is higher than the top-down estimation

• Ask the project sponsor for more budget to cover the difference in cost
• Modify the scope by removing or scaling down requirements 
• Negotiate with vendors to try to get better prices thus decreasing the budget required
• Some combination of the above

If the bottom-up estimation is lower than the initial top-down estimation:

• Settle with the project sponsor on the lower estimate
• Add requirements to the scope to user up the extra budget
• upgrade the current requirements
• Some combination of the above

Once the project budget is finalized and it's allocation to activities, all agreed changes must be updated in the:

• Project Charter
• Requirements document
• Scope Statement
• Work Breakdown Structure
• Activity List

All documents must reflect the agreed upon Resources, Scope, and Schedules and should always be kept in sync with the current agreement between the PM and Stakeholders.

When all reconciliation is complete and confirmed and the budget is aligned to the project scope, it's time to consider adding contingency funds based on the risks identified in the project. The contingency portion of the budget is additional money added to the budget to cover the cost of incurring potential risks that have been identified.