4squareviews

In monitoring risks, you are not only monitoring the existing risks in the risk register, but you are seeing if there are new risks out there to be added to that register.   The tools and techniques listed under “Data Analysis” below are part of that process.   This is what might be considered the analogy of “quality control” when it comes to risk management.  The analogy of “quality assurance” comes with “Risk Audits”, another tool and technique listed below.

And since risk is such a multi-faceted phenomenon, it requires a large set of eyes and differing perspectives that come with them in order to get a handle on it.   This is where the final tool and technique comes in, that of “Meetings”, which should be a familiar tool and technique because it happens with a lot of processes that cover a lot of complex territory.

11.7.2  Monitor Risks:  Tools and Techniques

11.7.2.1  Data Analysis

• Technical performance analysis–technical performance measures such as weight of the item being produced, transaction times, number of delivered defects, storage capacity, etc. (depending on the type of project) can be analyzed to see if there is deviation, which can indicate the possible existence of underlying risk.
• Reserve analysis–reserve analysis compares the amount of contingency reserves remaining to the amount of risk remaining at any time in the project in order to determine if the remaining reserve is adequate.   So this is monitoring risk not directly, but indirectly through the contingency reserves which are used to pay for risk responses.   If risks do not occur, then the contingency reserves which were meant to pay for those risks can go back into the “pool” of reserves and strengthen this ratio.

11.7.2.2  Risk Audits

Risk audits consider the effectiveness of the risk management process.    Although the project manager is responsible for ensuring that risk audits are performed, PMI suggests that risk audit meetings be held separately from the risk review meetings in order to separate the “quality control” (focusing on the results) vs. the “quality assurance” (focusing on the process) aspects of risk management.   The format for the risk audit needs to be defined in the risk management plan before the audit is conducted.    The “quality control” part of the risk review is reviewing the effectiveness of the risk responses themselves, and this is done as part of the risk review meetings (see paragraph below).

11.7.2.3  Meetings

Risk reviews are scheduled meetings and, although PMI prefers to have risk review meetings separate from the periodic status meetings, they can be combined if this is specified in the risk management plan.   However, PMI does consider it imperative that risks be reviewed periodically in such meetings whether they are separate or combined with other meetings, and these meetings should discuss the following topics:

• Documenting the effectiveness of risk responses in dealing with overall project risk and identified individual project risks
• Identification of new individual project risks (including secondary risks that arise from agreed-upon risk responses)
• Reassessment of current risks (are they are any risks on the watch list, for example, that have increased in either probability and/or impact such that they now merit a risk response)
• Closing of risks that are outdated (and return of the contingency funds for the associated risk responses to the overall contingency reserve)
• Issues that have arisen as the result of risks that have occurred
• Identification of lessons to be learned for implementation in ongoing phases of hte current project

In the next post, I will cover the outputs for this process.

Filed under: Uncategorized | Leave a comment »

The last process was in the executing process group, as we implemented the risk responses that we had planned in a previous process.   Now we switch to the monitoring and controlling process group.    Here the process is not just monitoring risk responses, but monitoring risks in general, and if necessary, making changes (the controlling part of the process) to the risk register, and to any other documents that are necessary.

This post will cover the inputs to the process.

11.7.1  Monitor Risks:  Inputs

11.7.1.1  Project Management Plan

The risk management plan is the component that is mainly used as an input.   This will give guidance on

• how often risks should be reviewed
• which policies and procedures for the organization should be followed when doing the review
• the roles and responsibilities of the people doing the monitoring process
• formats for reporting the results of the process (with risk reports)

11.7.1.2  Project Documents

Here are the project documents considered as inputs for the process.

• Issue log–this will be used to see if there are any open issues that have been updated which may affect the risk register
• Lessons learned register–lessons related to risk that were recorded earlier in the project will be reviewed to see if they apply to later phases in the project.
• Risk register–the key inputs will include
  • identified individual project risks
  • risk owners
  • agreed-upon risk responses
  • specific risk response implementation actions
  • control actions for assessing the effectiveness of the risk respones plans
  • symptoms and warning signs of risk
  • residual and secondary risks
  • watch-list of low-priority risks
• Risk report–assessment of the current overall project risk exposure as well as the agreed-upon risk response strategy, as well as the major individual risks with planned responses and risk owners.

11.7.1.3  Work Performance Data

This contains data related to risk such as:

• risk responses that have been implemented
• risks that have occurred
• risks that are active
• risks that have been closed out (because the risks associated with certain project activities did not occur)

11.7.1.4  Work Performance Reports

Information from performance measurements can be analyzed to provide project work performance information such as:

• Variance analysis
• Earned value data
• Forecasting data

This information could be relevant when monitoring performance-related risks (such as missing an intermediate milestone, etc.).

The next process will be the tools and techniques associated with this process.

Filed under: Uncategorized | Leave a comment »

This post covers the output of the process 11.6 Implement Risk Responses, which is part of the executing process group for risk management.

In this process, the risk responses that were planned in process 11.5 Plan Risk Responses   are actually implemented if the underlying risk is triggered.   If that risk response requires resources and/or time to implement, you must make a change to the cost and schedule baselines to reflect the additional time and/or cost incurred (see paragraph 11.6.3.1 below).

Of course, there are some risk responses which require additional time and/or cost incurred even if the risk does not occur, mainly because you are trying to reduce the probability of a risk occurring and/or the impact of that risk if it were to occur.   An example is:   if the data you have from a client is valuable and should not be lost, then you may want to pay the expense of having a mirror server which will take that data at the end of each day and copy it onto a server which is not in the same location.   When I was working for an insurance company that was in Los Angeles, this was done to prevent data loss in case of an earthquake.   It would not make sense to send the data to a server that is merely in another building across the street, so we sent it to a remote site that would not be effected if the local area had an earthquake.   Although this was an expense that we incurred even if an earthquake did not occur, it was considered a good idea to implement this risk response beforehand in order to mitigate the damage if one were to occur.

If there are any issues encountered in the implementation of the risk, or if there are any changes made to the risk response in the course of implementing it, you also need to update the appropriate project documents (see paragraph 11.6.3.2 below).

11.6.3  Implement Risk Responses:   Tools and Techniques

11.6.3.1  Change Requests

If a risk response is implemented because the underlying risk has been triggered and it is a contingent risk response (meaning that it is only implemented if the risk occurs), then a change request may need to be done to update the cost and schedule baselines of the project management plan in order to account for the additional cost and/or expense.   The scope management plan, particular the Work Breakdown Structure, may also have to be amended to account for the additional activities required in the risk response.

11.6.3.2  Project Document Updates

• Issue log–if issues are uncovered in the implementation of risk responses, then these issues are recorded in the issue log.
• Lessons learned register–if challenges are encountered when implementing risk responses, then information is added to the lessons learned register on how to avoid those challenges or on approaches that worked well when confronting them.
• Project team assignments–the resources associated with the risk response are allocated, including the personnel required to implement them.
• Risk register–if there are any changes to the risk responses made in the course of implementing them, these changes are recorded in the risk register used by the project team.
• Risk report–if there are any changes to the risk responses made in the course of implementing them, these changes are recorded in the risk report that is send to stakeholders.

The next process group is monitoring and controlling, which in the case of risk management gives us the next and final process 11.7 Monitor Risks.   It not only is used for monitoring the implementation of agreed-upon risk responses plans, but for tracking identified risks (whether they occur or not), and periodically reviewing the risks on the project to see if there are any new risks that need to be added to the register.   Also, the effectiveness of the risk process is evaluated during the process.

The inputs to this process 11.7 Monitor Risks will be discussed in the next post.

Filed under: Uncategorized | Leave a comment »

The risk responses should have been all planned at this point in the previous process 11.5 Plan Risk Responses.    This process is one of carrying them out in the most efficient and effective manner, and  to validate them once they are done.

As opposed to the planning process which requires some special tools and techniques unique to the process, implementing the risk response just requires what I call “generic” tools and techniques, ones that are used in quite a lot of different processes.

11.6.2  Implement Risk Responses:  Tools and Techniques

11.6.2.1  Expert Judgment

You should consider expertise from individuals who have specialized knowledge in how to carry out the risk responses in an efficient (doing things right) and effective (doing the right things) manner.   Hopefully you will have already chosen that person as the risk owner.

11.6.2.2  Interpersonal and Team Skills

Since you cannot as a project manager be everywhere on a project, that is why you assign risk owners to the various risks.   You need to use your influencing skill to encourage risk owners to take the necessary actions needed, and you may need to facilitate the risk process.   This is really no different than the influencing skill you need for people to get the underlying work done on the project for the process 4.3 Direct and Manage Project Work

11.6.2.3  Project Management Information System (PMIS)

This is the computer software program, like Microsoft Project, used to monitor the schedule, cost and resources on a project.   In the case of this process, it is to ensure that the risk response plans and their associated activities that have been agreed upon are integrated into the project alongside the other activities.

The next post covers the outputs of the process.

Filed under: Uncategorized | Leave a comment »

Okay, for risk management we are now going from the first five processes, which were in the planning process group, and moving on to the executing process group.   In case of this risk management process, it means when the project has started, actually implementing the risk responses we planned in process 11.5 Plan Risk Responses.

Here are the inputs to this process:

11.6.1  Implement Risk Responses:  Inputs

11.6.1.1  Project Management Plan

The particular component of the project management plan that is an input is, of course, the risk management plan.   This should list the roles and responsibilities of project team members and other stakeholders who are involved in implementing risk responses.

The risk management plan also specifies the risk thresholds for the project, which define the acceptable target that the implementation of risk responses is supposed to achieve.

11.6.1.2  Project Documents

• Lessons learned register–lessons learned during this process of implementing risk responses will be put into the register so that they can be applied in later phases of the project.
• Risk register–the risk register will contain the agreed-upon risk response strategy for the overall project, as well as for major individual project risks.
• Risk report–this contains an assessment of the current overall project risk exposure as well as the agreed-upon risk strategy, as well as for major individual project risks.

11.6.1.3  Organizational Process Assets

The lessons learned repository from similar completed projects can be used to indicate the effectiveness of particular risk responses.

The next post covers the tools and techniques of this process.   As opposed to the specialized tools and techniques of setting up the risk response plan in the previous process, this process is pretty straightforward and uses “generic” tools and techniques used in other processes as well:  expert judgment, interpersonal and team skills, and the Project Management Information System (PMIS) like Microsoft Project.

Filed under: Uncategorized | Leave a comment »

In the last post, I described the changes that must be made to the components of the project management plan as a result of planning risk responses, these components being the management plans that cover various knowledge areas such as the schedule management plan, cost management plan, quality management plan, etc., but also the baselines for the main three constraints:  the scope baseline, cost baseline, and schedule baseline.

All of these changes require change requests since they amend the project plan.   With these changes to the project documents that I describe below, there is no need to create a change request.

11.5.3.3  Project Document Updates

• Assumption log–if during the plan risk response process, new assumptions are uncovered, or new constraints identified, the assumption log is updated to include them.
• Cost forecasts–planned risk responses may require changes in the cost forecasts because the contingency reserve needed to fund those responses needs to be taken into account
• Lessons learned register–the lessons learned register is updated with information about risk responses that may be useful for later phases of the project.
• Project schedule–activities relating to agreed-upon risk responses may be added to the project schedule
• Project team assignments–the necessary resources need to be allocated to the risk responses, including personnel (usually within the project team) to implement the agreed-upon action.   The project team assignments are updated to these new roles related to the risk responses.
• Risk register–to the risks identified and analyzed in earlier processes, the following information is added as a result of this process:
  • Agreed-upon risk responses strategies
  • Specific actions to implement the chosen response strategy
  • Trigger conditions, symptoms, and warning signs of a risk occurrence (for contingent risk responses), along with contingency plans if the risk is triggered
  • Budget and schedule activities required to implement the chosen risk responses
  • Fallback plans when the primary response proves to be inadequate
  • Secondary risks that arise as a direct outcome of implementing a risk response
  • Residual risks that are expected to remain after planned responses have been taken
• Risk report–in the case of high-priority risks, presentation of agreed-upon risk responses and a list of current project risk owners, together with the expected changes that may be expected as a result of implementing these risk responses.

Now that the risk responses have been planned, it is time to move on to the executing phase of the project, where risk responses are implemented.   This means moving on to the next process, process 11.6 Implement Risk Responses, which will be discussed in the next post.

Filed under: Uncategorized | Leave a comment »

The outputs for the process 11.5 Plan Risk Responses mainly consist of changes to the project management plan or to project documents to incorporate those risk responses.

Since there are a lot of these changes to consider, I will split the post into two.   Today I will cover the Change Requests and Project Management Plan Updates.

11.5.2  Plan Risk Responses:  Outputs

11.5.2.1  Change Requests

If a risk response has been planned as a result of this process, it may require changes to cost, schedule, or scope baselines, or to other components of the project management plan.   These all have to be done through the change request procedure, which involves process 4.6 Perform Integrated Change Control.   All of those change requests which are approved will go into updates to  the project management plan.   Changes in project documents do not such approval–these changes will be discussed in the next post.

11.5.2.2  Project Management Plan Updates

Remember, the “project management plan” is not a single plan, but a collection of management plans from all the knowledge areas, a series of supplemental management plans (covering change, configuration, and requirements management), and the various baselines for the main constraints of scope, time and cost.

• Schedule management plan–because of the time required to implement risk responses, there may be updates to the schedule.
• Cost management plan–because of the cost required to implement risk responses, there may be updates to the budget, especially when it comes to adding contingency reserves.
• Quality management plan–any changes to quality management approaches or quality control processes suggested as a risk response are incorporated into the quality management plan.
• Resource management plan–if there are any changes to resource allocation due to risk responses, these changes are added to the resource management plan.
• Procurement management plan–if there are any alterations in the make-or-buy decision or procurement contract types as a result of the risk responses, these changes are made to the procurement management plan.
• Scope baseline–any agreed-upon risk responses need to be added to the scope baseline.   For example, risk response activities need to be added to the WBS, either if there are done in anticipation of a risk in order to mitigate them, or if they are to be done as a contingent risk response, i.e., only if the risk is triggered.   In that case, there will have to be some color-coding or other means of showing that the activities are only to be done if the risk is triggered.
• Schedule baseline–any changes in the schedule estimate required as a result of incorporating risk responses are including in the updates to the schedule baseline.
• Cost baseline–any changes in the cost estimate required as a result of incorporating risk responses are including in the updates to the cost baseline.

As mentioned in the previous paragraph, any changes to the project management plan made as a result of planning risk responses will have to be approved by the change request process.

The next post will cover those changes to the project documents made as a result of the risk planning process–these do not require formal change request approval, but are important to be done nonetheless to track not only the risk responses, but how they will impact the project.

Filed under: Uncategorized | 1 Comment »

In the last post, I discussed the “generic” tools and techniques used in this planning process.   By “generic” I mean the tools and techniques that are used not just in this planning process, but in many project management planning processes in general, such as expert judgment, data gathering (interview techniques), interpersonal and team skills (facilitation techniques), and decision-making techniques.

In this post I will discuss those tools and techniques used specifically for this process.

There are strategies for threats, that is negative risks, and there are strategies for opportunities, that is positive risks.   Remember that PMI considers “risks” in a wider context than normally used in everyday life.   Risk is an event or condition that can occur that has a positive or negative impact on the outcome of a project.    You obviously want positive risks to occur, and so the strategy for dealing with them is how to exploit them when they do occur, and how to enhance the probability of their occurring.   On the other hand, you do not want negative risks to occur, so the strategy for dealing with them is the mirror opposite of what you do with positive risks:   you try to avoid them to prevent them from occurring altogether, or how to mitigate the probability of their occurring.

There is also the concept of sharing a positive risk with another company, or transferring a portion of a negative risk to another company (like when you buy insurance)  And you can always accept a positive or negative risk that has little probability of occurring.   To these four basic strategies for dealing with risk that were previously discussed in the 5th Edition of the PMBOK® Guide, there is a fifth basic strategy added for the 6th Edition of the Guide, and that is the strategy of escalating a risk.   This means that there is a risk threshold which is set at the beginning of the project.   If a risk response occurs which requires the expenditure of over a set amount of money, the risk threshold, then the project sponsor needs to get involved to get approval of this from management.

This is similar to what happens in many projects with regards to change management.   The project manager has authority to implement changes that go up to a certain threshold in terms of expenditure, but anything over that amount may require approval from the project sponsor.

With that brief introduction, let’s go into more detail regarding the tools and techniques for this process.   (The numbering of the tools and techniques does not start with 11.5.2.1 because the missing numbers are those tools and techniques which were discussed in the last post as “generic”.)

11.5.2.4  Strategies for Threats (Negative Risks)

•  Escalate–if a threat is outside the scope of a project or if the proposed risk response would exceed the project manager’s authority.   Escalated risks are dealt with at the program or portfolio level of the organization’s project management structure (whether there is a PMO or not), and are not dealt with further by the project team after escalation, although they may be recorded in the risk register for information purposes.
• Avoid–This strategy is appropriate for high-probability, high-impact risks.  It may involve the following in order to reduce the probability of occurrence to zero:
  • changing some aspect of the project management plan
  • changing the objective that is in jeopardy or reducing scope
  • removing the cause of the threat
  • clarifying requirements, obtaining information, improving communication
• Transfer–This strategy is appropriate for low-probability, high-impact risks.   For example, the probability that you will be in a auto accident is low, but the impact could be high (no pun intended), so that is why you must by auto insurance.  Transfer may be achieve by the following means:
  • use of insurance (payment of a risk premium to the party taking on the threat)
  • performance bonds
  • warranties, guarantees
  • agreements to transfer ownership and liability for specific risks to another party

An example of the last bullet point is when I was working for an automobile manufacturing company.   The air bag module is an especially dangerous component to manufacture because it involves an explosive device (which causes the airbag to inflate in such a short period of time).   Our company did not have the expertise to manufacture this component, but another company did and we had them manufacture the air bag module for us to put into our cars.   However, if there was an accident where there was an injury caused by a defective air bag module, then there was an agreement that this company would pay for the cost of the claim or lawsuit if it came to that.   This is a perfect example of a “transfer” strategy when it comes to risk.

• Mitigate–This strategy is appropriate for high-probability, low-impact risks or if the impact is not high, but moderate.   This reduces the probability of the risk occurring or the impact if it does occur.   You mitigate the risk of it raining by taking along an umbrella.   It won’t do much for the probability of it raining, but it will reduce the impact on your clothes.   Here are some actions that use the mitigation strategy:
  • Prototype development (reduces probability of risk occurring)
  • Designing redundancy into a system (reduces impact if risk occurs)
• Accept–This strategy is appropriate for low-probability, low-impact risks.   This is where there is no proactive action taken.  It may be appropriate for low-priority threats, or where a risk response is not cost-effective (i.e., it costs more to implement a risk response than the impact of the risk if it occurs).     Some typical acceptance strategies are:
  • Establishing a contingency reserve to handle the threat if it does occur
  • Putting risk on a “watch list” for monitoring periodically

11.5.2.5  Strategies for Opportunities (Positive Risks)

Remember that these strategies are the mirror opposite of strategies to deal with threats or negative risks.

• Escalate–if an opportunity is outside the scope of a project or the opportunity would exceed the project manager’s authority.   Escalated opportuities are dealt with at the program or portfolio level of the organization’s project management structure (whether there is a PMO or not), and are not dealt with further by the project team after escalation, although they may be recorded in the risk register for information purposes.
• Exploit–This is a strategy for dealing with high-priority opportunities where the organization wants to ensure (i.e., make the probability 100%) that the opportunity is realized.   Examples of this strategy are:
  • Assigning an organization’s most talented resources to the project
  • Using new technologies or new technology upgrades to reduce cost and duration of a project
• Share–This is a strategy for transferring ownership to a third party so that it shares some of the benefit if the opportunity occurs, especially if that third party has expertise to best be able to capture the opportunity for the benefit of the project.  Examples of this strategy are:
  • Payment of a risk premium to the party taking on the opportunity
  • Forming risk-sharing partnerships or joint ventures
• Enhance–This is a strategy for increasing the probability and/or impact of an opportunity.   Early action taken to enhance the probability of an occurrence of an opportunity may be more effective than trying to improve the benefit of an opportunity after it has occurred.   Examples of this strategy are:
  • Adding more resources to an activity to finish early
  • Taking advantage of a sale of needed resources that occurs before they are actually used on a project
• Accept–just like its counterpart for negative risks, this is where no proactive action is taken, but simply acknowledging the existence of an opportunity.  Examples of this strategy are:
  • Establishing a contingency reserve to take advantage of the opportunity if it occurs (active strategy)
  • Putting the risk on a “watch list” and reviewing it periodically to ensure that it does not change significantly in terms of probability or impact (passive strategy).

11.5.2.6  Contingent Response Strategies

Certain risk responses are implemented only if certain events occur.   A risk response can be implemented in this case if there is sufficient warning that the risk may be triggered.    Risk responses so identified are called contingency plans, and include the triggering events that set the plans in effect.   Examples of such contingent risk responses

• Dealing with missing intermediate milestones
• Gaining higher priority with a seller

11.5.2.7  Strategies for Overall Project Risk

As you may recall from previous posts, Qualitative Risk Analysis focuses on individual project risks, but in projects of sufficient size and/or complexity, Quantitative Risk Analysis may calculate the overall project risk taken by summing the product of probability times potential impact for all of the individual project risks.

Risk responses should be planned for individual project risks (see paragraphs 11.5.2.5 Strategies for Threats and 11.5.2.6 Strategies for Opportunities), but this paragraph deals with risk responses to the overall project risk.

• Avoid–if the overall project risk is significantly negative or outside the agreed-upon risk thresholds for the project, an avoid strategy may be adopted.   If it is not possible to bring the project back within the thresholds, then the project may be cancelled.   This is the obviously the most extreme degree of risk avoidance.   Example of this strategy:
  • Removal of high-risk elements of scope from the project
• Exploit/share–if the overall project risk is significantly positive and outside the agreed-upon risk thresholds for the project, then an exploit strategy may be adopted (this is obviously the mirror opposite of the “avoid” strategy listed above).  Example of this strategy:
  • Addition of high-benefit elements of scope to the project (to add value or benefits to stakeholders).
  • Modification of risk thresholds to the project may be modified with the agreement of key stakeholders in order to embrace the opportunity
• Transfer/share–if the overall project risk is high but the organization is unable to address it effectively by itself, a third party may be involved to manage the risk on behalf of the organization.   Where overall project risk is negative, a transfer strategy is required; where overall project risk is positive, a shared ownership strategy is required.   Examples of this strategy include:
  • Setting up a collaborative business structure in which the buyer and the seller share the overall project risk
  • Launching a joint venture or special-purpose company
  • Subcontracting key elements of the project
• Mitigate/enhance–if the overall project risk needs to be changed in order to achieve the project’s objectives.   Mitigation strategy is used if the overall project risk is negative; enhancement strategy is used if the overall project risk is positive.  Examples of this strategy include:
  • Replanning the project
  • Changing the scope and boundaries of the project
  • Modifying project priority
  • Changing resource allocations
  • Adjusting delivery times
• Accept–where no proactive risk response strategy is possible to address overall project risk, the organization may choose to continue with the project as currently defined.   Examples of this strategy include:
  • Establishing an overall contingency reserve for the project to be used if the project exceeds its risk thresholds (active strategy)
  • Review of the level of overall project risk to ensure that it does not change significantly (passive strategy)

11.5.2.8   Data Analysis

• Alternatives analysis–if there is more than one risk response strategy identified to deal with individual project risks, alternatives analysis can help choose the most appropriate option.
• Cost-benefit analysis–if the impact of an individual project risk can be quantified in monetary terms using Earned Monetary Value (equal to the estimated probability of the risk occurring times the dollar amount of the potential impact on the objectives if the risk occurs), then the cost-effectiveness of alternative risk response strategies can be determined using cost-benefit analysis.   The effectiveness of the risk response strategy can be measured by the ratio of the change in impact level measured by EMV divided by the cost of the implementation of the risk response strategy.   For example, if the implementation of doing a prototype of a design reduces the risk of failure from 25% to 5%, the cost in the potential impact (the change of 20% in the probability of the risk of failure times the cost of such a failure) divided by the cost of doing the prototype would be a concrete example of such a calculation.   The higher the ratio, the more effective the risk response would be.

This concludes this section on risk response strategies.   It is the most complicated of the planning processes for risk management, but it is the heart of what risk management is about:   doing what you can to reduce risk during the project.   The next two risk management processes implement these risk response strategies that were developed during the planning phase of the project and then monitor & control them throughout the cost of the project.

But before we go on to those processes, let’s discuss the outputs of this process 11.5 Risk Responses.

Filed under: Uncategorized | Leave a comment »

This is the final planning process for risk management, and it is ultimately the most important because you plan on doing risk responses to mitigate individual project risks and thus ultimately reduce the overall project risk.

The tools and techniques, like those in the previous process 11.4 Quantitative Risk Analysis, are so numerous and complex that I am breaking up the post into two parts:  this post will cover the “generic” tools and techniques that are used in many planning processes, not just this one:  expert judgment, data gathering, interpersonal and team skills, and decision making.   The next post will cover those tools and techniques which are specific to this process.

11.5.2  Plan Risk Responses:  Tools and Techniques

11.5.2.1 Expert Judgment

Like all planning processes, you should consider expertise from individuals or groups with expertise in the process you are planning to do.   In this case, that would be those who have expertise in the following:

• Threat and opportunity response strategies
• Contingent response strategies
• Overall project risk response strategies

These strategies are all tools and techniques that will be discussed in the following post.

11.5.2.2  Data-gathering

Interviews can be used to develop responses to individual project risks.   The interviews should be with team members who have expertise in developing risk responses or stakeholders who have knowledge about specific individual project risks, particularly risks which have been encountered before on previous, similar projects.

11.5.2.3  Interpersonal and Team Skills

The data-gathering technique listed above is for interviewing individuals regarding risks.  You can develop risk responses in a group by using facilitation methods, and it is these facilitation skills which are techniques which can help risk owners understand the risk, and identify and compare alternative risk response strategies.

11.5.2.9  Decision Making

In a group setting such as the facilitation mentioned above, it is important to use decision-making techniques to prioritize and finally decide upon which of the alternative risk response strategies that are developed in the facilitation.

The other tools and techniques are all specific to this process and will be discussed in tomorrow’s post.

Filed under: Uncategorized | Leave a comment »

“God grant me the serenity to accept the things I cannot change; courage to change the things I can; and wisdom to know the difference.”–the Serenity Prayer

In planning risk responses, you are enacting the spirit of the serenity prayer in doing what you can to change what you can, which is usually the probability or impact of a risk occurring.   Since you may not eliminate entirely the probability of its occurring, you need to accept it in the sense of preparing it for it so the impact isn’t so great once it occurs.   If there are risks that are small it may be okay to accept them in the sense of being willing to have a temporary workaround rather than preparing for a risk response ahead of time.   The wisdom to know the difference comes from the results of the previous two processes where you analyze the risks to see which ones matter the most to the outcomes of the project.

The inputs to this process are the following:

11.5.1  Plan Risk Responses:  Outputs

11.5.1.1  Project Management Plan

The project management plan contains the component management plans from the various knowledge areas and the baselines for the main three constraints of scope, schedule and cost.

• Resource management–once the risk responses in this process are agreed upon, how will resources, both physical and human resources, to allocated to implement them?
• Risk management plan–the roles and responsibilities for risk management, as well as the thresholds for risk management, are set out in the risk management plan.  The thresholds are important for the “escalate” response to a given risk, as we will see when we discuss the tools and techniques of this process.
• Cost baseline–the cost of risk responses will come from the “contingency fund”, and this needs to be allocated from the budget

11.5.1.2  Project Documents

• Lessons learned register–lessons learned about effective risk responses used in earlier phases of the project are reviewed to determine if similar responses might be useful during the remainder of the project.
• Project schedule–once the risk responses in this process are agreed upon, how will they be scheduled alongside other project activities?   Will risk response activities get added to the WBS but in a different color to show that they are only done if the risk is triggered?
• Project team assignments–who are the people that are assigned as risk owners who will carry out the risk responses?
• Resource calendars–what resources (both physical and human) can potentially be available to be allocated to risk responses that have been agreed upon?
• Risk register–for the individual project risks that have identified:
  • which risks require risk responses (those that don’t are put on the so-called “watch list”)
  • priority level for each risk to help guide the selection of risk responses
  • nominated risk owner for each risk
  • preliminary risk responses if identified during previous risk management processes
  • root causes of risks
  • risk triggers and warnings signs
  • risks requiring responses in the near term (urgent risks)
  • risks requiring additional analysis
• Risk report–should list the following:
  • current level of risk exposure of the project
  • individual project risks in priority order
  • additional analysis of individual project risks that may inform risk response selection
• Stakeholder register–may identify potential owners for risk responses.

11.5.1.3  Enterprise Environmental Factors

Risk appetite and risk thresholds of key stakeholders.

11.5.1.4  Organizational Process Assets

• Templates for risk management plan, risk register and risk report.
• Historical databases
• Lessons learned register from previous similar projects.

The next post will cover the tools and techniques of this process.   Since there are many, I will break them up into the generic tools and techniques used in many planning processes (expert judgment, data gathering, interpersonal and team skills, and decision-making), and those that are specific to this particular process (strategies for threats, strategies for opportunities, contingent response strategies, strategies for overall project risk, and data analysis of risk response strategies).

Filed under: Uncategorized | Leave a comment »