How to Plan Risk Responses

This meter shows that risks come in all levels of severity, from minimum to maximumOK, so you’ve done the groundwork for risk management on your project. You’ve developed your Risk Management Plan. You’ve identified potential risks. You’ve performed a qualitative risk analysis (Jersak, 2020).

Now what?

It’s now time to plan your risk responses. No doubt, if yours is a fairly large and/or complex project, your risk register is already populated with numerous risk events that you must manage.

Keep in mind that not all risk events in the register require a full risk response plan. As you review each event, ask yourself the following questions:

  • Is this risk significant enough to be monitored throughout the project, or should it be put on a watchlist for occasional review?
  • Should this risk be tracked and monitored according to the regular project cadence, though it may not require a response plan to be developed at this time?
  • Does the significance of this risk warrant the additional effort to develop a risk response plan, and potentially a contingency plan if the selected strategy is ineffective? Additionally, what are the triggering conditions for the implementation of this plan?

Having identified those risk events that warrant a risk response plan, an optimal strategy to manage the risk should also be documented. The PMBOK® Guide (Project Management Institute, 2017, pp. 442 – 444) offers five strategies for managing threats and five for handling opportunities. This article illustrates the five strategies for managing threats. Managing opportunities is less often addressed on projects; however, I will cover this is in my next article.

Notice that I use the term “managing” threats rather than what is often described as “mitigating” threats. In dealing with threats, mitigation is but one of five strategies for managing threats. It, therefore, should not be used to reference overall risk management.

Five strategies according to the PMBOK® Guide

1. Escalate – This strategy should be used when the threat is outside the scope of the Project Manager’s responsibility. Clearly, it is a threat to the project, and should therefore be escalated to the relevant part of the organization that can deal with it. Once escalated, the threat remains outside the scope of the project.

For example, on a project for which I was providing oversight, a major functional requirement was the exchange of data with a sister organization’s computer system. From a business perspective, the data to be shared across the electronic interface would keep both systems in sync when dealing with clients who were being assisted by both organizations. The data exchange was intended to maintain accuracy within both systems, while saving much time and effort by the end-users of both organizations as they managed their common client base.

It became evident early on in the project that the sister organization was less interested in making the system modifications on its side that were required to implement the data exchange. The threat to our organization was the loss of benefit of this functionality; but the responsibility to manage this risk was outside the scope of our project. I escalated the threat to the senior executive of our organization, who then worked with her counterpart in the sister organization to ensure the functionality was in place on both sides.

2. Avoid – This strategy seeks to eliminate the threat altogether. The Project Manager has several options available to her. She could modify the Project Management Plan or eliminate the threat entirely by changing the project objective being threatened.

On more than one project on which I worked, our client organizations included functional requirements in their Requests for Proposals (RFP) that proved to be extraordinarily difficult to define for a variety of reasons. In each of these situations, we were able to make the case to our client to de-scope the nebulous requirements rather than waste valuable time, effort, and resources to implement functionality that was not easily defined nor necessarily required. De-scoping was the appropriate strategy of avoidance in many of these situations.

3. Transfer – This strategy shifts the ownership of the threat to a third-party.

Probably the best examples from my contracting experience of transferring risk came from the RFP and contracting process itself. The client organization would request a fixed price, turnkey bid from an IT provider, and require that the provider be completely responsible for the development and implementation of the entire system. Thus, threat of a project failure, or of not meeting all the project’s objectives, was transferred entirely to the IT provider.

4. Mitigate – As referenced earlier, risk mitigation is often incorrectly used when describing risk management. Mitigation is probably the most used risk management strategy, and involves taking action to reduce the probability of a risk’s occurrence or to reduce its impact on the project. Good risk management planning attempts to mitigate threats early in the project lifecycle rather than having to deal with the setback should the threat actually occur.

In my own project management experience, it seemed as though most of my time (aside from far and too many meetings) was spent in mitigating the risks that threatened the progress of the project.

For example, on one project my executive manager promised the client a solution based on technology that was largely still in beta. I documented it as a risk in the risk register with high probability/high impact. To mitigate this risk, I convinced her and our client to allow us to do a proof-of-concept, with the understanding that the resulting code, if successful, would not be abandoned, but would be integrated into the overall system.

On another project we fell behind schedule. In reviewing the work plan, we discovered that one of our most technically competent resources was being used to develop repetitive functionality that could have easily been handled by a more junior staff member. We mitigated this risk by training our project secretary to code these relatively simple modules, thus freeing up the experienced team member for more complex tasks.

On a government project that I was overseeing, a senior member of the client’s team was about to be named the User Acceptance Test manager solely because of seniority. Having worked directly with the client’s staff on the project, I knew she was not capable of performing the job. However, another staff member of less seniority had the skills to handle the required rigor. I met with the senior sponsor from the client organization to explain my reasoning, and the switch was made immediately. My intervention mitigated a potential disaster.

These are just some very basic examples of creative approaches that were used to mitigate threats and their potential impact to the project.

5. Accept – There are some risk events for which no proactive action is planned or taken, either because it’s not feasible or cost-effective to address the potential threat. Naturally, a contingency reserve should be planned for these events, assuming they will happen with a high probability, but for which no other strategy to handle the threat is practical at the time.

For example, on most of the large projects on which I worked, we contracted out most of the development positions to “body shops.” By nature of our working relationships with the “body shops,” we knew that we would get their best and brightest developers. However, by nature of the “body shop” staffing process, we also knew that we would be removing some developers for non-performance, and losing some who would jump ship for opportunities elsewhere. This was a risk that we accepted and planned contingency dollars for. We also transferred some of the risk to the “body shopping” firms themselves.

Notice that in many of the examples above, communication is a large part of the risk management strategy. Ongoing communication is necessary as risk tracking and monitoring become significant to the management of the project. The risk register and response plans must be actively worked by the risk owners and communicated regularly to the appropriate stakeholders.

Additionally, the project plan, budgets, project scope, resource management plans, assumptions and constraints, and the myriad of subsidiary plans must be reviewed as appropriate for potential updates. Changes must go through the change control process (which will be the subject of an upcoming article).

Planning risk responses seems like a lot of work. It is. Most Project Managers consign this effort to process. However, the expert judgment involved, the past experience involved, and the creative problem-solving required all focus on the people aspects of project management.

Staying on top of potential risk events that can threaten the objectives of the project is well worth the additional required effort, and this activity may be one of the most important to be undertaken to prevent project failure.

Footnotes

Previous articles on the topic of Risk Management:

Project Management Institute. A Guide to the Project Management Body of Knowledge (PMBOK® Guide) – Sixth Edition. Newton Square, PA: PMI Publications, 2017, Print.

 

Get Your Free Guidebook

Subscribe and receive your free guidebook,
5 Ways to Master the Art of Managing People, Projects and Profits.