These are the Basics of Implementing Risk Responses

Every time I have worked on a successful project, I can point back to commonsense, practical actions and methods that were used to undergird that success. It’s the same with implementing risk responses on any project.

In my previous article, “How to Create an Ideal Environment to Implement Risk Responses,” I discussed establishing a project environment that is conducive to successfully implementing risk responses. I described several tried and true actions to take in creating this atmosphere:

• establish executive support
• maintain excellent documentation
• be vigilant
• keep subject matter experts on speed dial
• involve team members
• monitor implementation of risk responses
• develop flexibility within the project team
• foster communication and collaboration across the teams
• develop a culture of problem-solving
• instill an attitude of expectation

Having now created a project environment that is equipped to handle risk responses effectively, I will now review some practical tips to doing so. While PMI’s PMBOK® Guide is useful in conceptualizing processes, the practical application is almost always left to the practitioner.

These commonsense basics have worked well for me over the years. In fact, you may read this article and think, “well, duh …”. However, I challenge you to look at your organization’s projects to see how many of these are being used. In consulting with project teams on developing the people aspects of project management (I argue that implementing risk responses is more a people-oriented activity than a process-related activity), I am often surprised to discover that even the most basic of the following tips are not being used:

• Risks must be prioritized. Priority for each risk item is derived from the urgency and potential disruption to timeline and budget. Review your current risk register. Is your team currently working on replacing a developer who is resigning in six months to move, and not paying attention to the required lead time for the infrastructure to begin System Test in six weeks?

  Every risk in the register must be reviewed in terms of its priority. The most insignificant risk may be the highest priority right now if its resolution is required immediately, while the most costly disruptive risk that everyone is concerned about may be lower priority if it has no chance of occurring in the near future.

• Every risk needs an owner. Specifically, every risk needs an appropriate owner. You’ve heard the old adage. “What gets measured, gets done.” Similarly, what is owned gets done.

  Look at your project’s risk register. Has every identified risk been assigned to an appropriate owner? I’ve often seen risks without owners assigned that languish until they become an issue. I’ve also seen risks assigned to owners who are not experienced to handle them, and no action taken until the risks become issues.

  If a risk is identified as a priority and assigned an owner, it needs to be followed up (see next bullet). If it is not assigned correctly, it needs to be escalated to be assigned to the appropriate owner, transferred out of the project to the appropriate entity, or re-assigned within the project for mitigation.

• Risks need to be reviewed at every status meeting. Urgent risks may need to be reviewed even more frequently. Think back to your weekly status meetings. Does the agenda item for risk review appear at the bottom, only to be skipped as the allotted meeting time runs out? This is a sure bet that risks will become issues. If meeting time runs out, an email status must be requested to be reviewed by project management.

  Some identified risks that have a lower probability of occurring, or have a high probability of occurring but not in the near future, can be parked on a watchlist. They do not need to be reviewed in every status meeting, but they do need to be reviewed occasionally to determine if their status should be changed.

• Not every risk requires a risk response. My personal preference when adding a risk to the register is to brainstorm and document one or more possible risk responses. These risk responses may change as the project progresses, but some thought will have been given to managing each risk event.

  At the same time, some identified risks may not have a risk response when it is identified. For example, on one of my projects the federal government implemented new rules after we had completed system design. We had known that a change was coming as early as the planning stage, but there was no indication as to the extent of the legislation. We documented the risk without a risk response initially and waited until we could analyze the proposed changes. Several months later, during the rulemaking commentary period, we fleshed out a risk response that allowed us to estimate the budget and schedule changes.

• Not every risk needs to be mitigated. Sometimes it’s prudent to accept the risk as-is and provide for a contingency. As a simple example, in assisting several organizations with their large procurements, I advised them that the risk of project changes was inevitable. These were multi-year, multi-million-dollar projects that would take several years to complete. We didn’t want the risk of budget overruns to jeopardize the projects.

  It was not possible to predict the extent of any changes up front, so we added contingency to the project budget. How did we estimate the contingency amount? We surveyed similar projects that had been recently completed and asked for their change order costs. We then developed estimates based on our projects’ specific circumstances.

• Risk needs to be balanced with cost and schedule. Risk registers can become long and intimidating with the sheer number of identified risks, especially for multi-year projects. Conscientious Project Managers may be tempted to ensure that every risk event has a corresponding risk response, even if preliminarily. This need not be.

  Not all risks are priority. Some are clearly in the distant future and do not need to be constantly reviewed. Some should be moved to the watchlist and not actively worked. Some should be escalated to senior management or transferred outside of the project rather than consume project resources on risks for which they are not responsible.

  Some risks may be imminent, but the cost and time to mitigate them may be more detrimental than allowing them to remain. For example, on one of my projects a developer discovered a significant defect in an already tested module just as we were about to freeze the code for implementation. The risk to the project was twofold: delay implementation at significant cost to the organization or implement on time with a known defect. We implemented with the known defect having determined that the functionality in question affected very few of the organizations’ clients.

• Risks mitigation should be delegated as far down the organization as possible. This seems contrary to what a Project Manager might think. However, any risk that is the responsibility of the project team should be assigned to the team member who is best equipped to handle it.

  For example, a risk of equipment arriving late may be better handled by the project accountant who has a good relationship with the supplier, than by the Project Manager who the supplier views as threatening. Or, a risk of inaccurately defined requirements in a complex functional area may be better handled by the system analyst who is steeped in the client’s policy than by the team lead who is less familiar with the rules.

  Besides, what better training for project team members than to be assigned risk mitigation responsibilities and succeeding at them?

• Risk mitigation requires root cause analysis and corrective action plans. Risk events are not always one-off situations. If they occurred on your project they probably occurred on others, and will undoubtedly occur again. It can be tempting when pressured by project deadlines to mitigate the risk in a “quick and dirty” fashion.

  Yes, the risk itself should be handled as quickly and efficiently as possible, even if the corrective action plan is initially rudimentary; however, the team must always circle back to complete a detailed root cause analysis to prevent such risks from recurring. Additionally, the lessons learned documentation should be updated with the findings.

• Risk mitigation should be governed by the project’s change control process. As noted previously, the temptation may be to mitigate risks in a “quick and dirty” fashion. Succumbing to shortcuts may fix the current problem, but it sets the project up for more and larger problems down the line.

  An emergency code patch? Fine. But a hastily implemented emergency patch without adequate documentation guarantees issues later on. Adding a new feature for a better end-user experience? Fine. But without change control, resources are diverted from the main project objectives.

  Every risk event that is mitigated with project resource requires a review of all affected project tasks and associated costs. Without a thorough analysis to determine the effect on timelines and budgets, as required by the change control process, the entire project is at risk of not being completed on time and within budget.

These are but a few of the basics that every Project Manager should adhere to when implementing risk responses on his or her project. No doubt there are many more, but these are commonsense items that can be deployed on any project immediately.

Get Your Free Guidebook

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