6th Edition PMBOK® Guide: Process 11.7 Monitor Risks: Tools and Techniques

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  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.  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).  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.


6th Edition PMBOK® Guide: Process 11.7 Monitor Risks: Inputs

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  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)  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.  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)  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.

6th Edition PMBOK® Guide: Process 11.6 Implement Risk Responses: Outputs

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 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 below).

11.6.3  Implement Risk Responses:   Tools and Techniques  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.  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.


6th Edition PMBOK® Guide: Process 11.6 Implement Risk Responses: Tools and Techniques

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  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.  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  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.

6th Edition PMBOK® Guide: Process 11.6 Implement Risk Responses: Inputs

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  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.  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.  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.

6th Edition PMBOK® Guide: Process 11.5 Plan Risk Responses: Outputs (2)

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.  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.

6th Edition PMBOK® Guide: Process 11.5 Plan Risk Responses: Outputs (1)

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  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.  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.