8 Essential Considerations for Successful Risk Management Planning

In my previous article, (“This is Why a Risk Management Plan is Important”), I posited that many projects fail or don’t achieve their full objectives because risk management was either not planned or was planned badly.

In this article I offer eight considerations for risk planning that will give Project Managers a head start for risk management planning, and set them up to manage risk well for the duration of the project.

1. Go Beyond Risk Policy and Checklists

Over the course of my IT career, I’ve had the opportunity of working on projects in 20 U.S. states and territories. Many of these projects were similar in the business processes to be automated, functional requirements, and legislative mandates. As the IT provider, we formulated risk policies to manage risk across the similar projects. To ease risk planning, we created templates and checklists for consistency across our projects.

Unfortunately, this approach also had a downside. What happens when busy IT staff are asked to do even more? They look for shortcuts. They employ the templates and checklists – but allow the tools to do their thinking for them. They recognize that many of the same risk events are similar from project to project and focus on these. They forget to consider risk events outside of the commonly occurring ones because, after all, they have established checklists.

One of the projects for which I provided advisory services requested that I help develop a Request for Proposals (RFP) for a new system. We became aware of new federal legislation on the horizon that would likely be enacted after our project was well under way. Because of the uncertainty of the timing of the legislation, the rules that would be enacted, and how the new policies might affect the project, we decided to move forward with the project rather than wait for the new rules.

This was a risk event that was not on our checklist. In our risk planning for this situation, we identified as many high-level business requirements as we could from the draft legislation and itemized those in the RFP. We also added language that would allow the IT provider to re-negotiate the details of the affected business areas once the new rules were promulgated.

By thinking outside of the established checklists, we were able to provide the winning bidder with some assurance that their fixed-price bid would have leeway for re-negotiation. Additionally, the client organization was able to secure contingency funds for the eventuality.

2. Develop Risks Categories

Risk planning is more comprehensive when the project team separates risk events into categories. Identifying the initial categories in the Risk Management Plan provides an avenue for managing risk throughout the project.

Some IT providers categorize risks according to project phases: initiation, planning, design and build, testing, training and implementation. Several of the projects I worked on used categories that could be identified and managed by the teams: policy and procedures (regulatory), contractors and suppliers, business requirements, technical infrastructure, design and build, system testing, user acceptance testing, training and deployment.

Over many projects and many years, we had identified a standard set of risks within these categories and documented them in checklists. In addition to using the checklists, our teams would brainstorm within their areas to determine if there were other potential threats or opportunities.

3. Consider Opportunities in Addition to Threats

The typical mindset when developing a Risk Management Plan is to focus on how negative risks (i.e. threats) will be managed over the course of the project. Little attention is paid to positive risks (i.e. opportunities). As Project Managers, we’re trained to manage risks to keep the project on schedule, within budget, and on track to meet its overall objectives. In considering project risks, we often overlook the possibility of positive events resulting from a risk event.

I was working with a large government organization in preparing a major procurement to replace its legacy system. One of the solution options we allowed for in the RFP was the transfer of a successfully implemented system of similar business requirements from another jurisdiction. We felt that modifying the code base of a proven system was a safer approach than building from scratch. We also felt that it would provide a positive risk when compared to the option of building new.

Not only did the winning bidder offer a provable system, but they proposed much of the same project team that had led the development of the donor system. They proposed the same team to mitigate their own risk; and in doing so, they passed additional positive risk on to the government organization. Our pre-bid opportunity planning was rewarded with additional opportunity once the winning bidder was selected.

4. Prepare to Estimate – Not Underestimate – the Impacts

I don’t know what it is, but on every new project I optimistically assumed that we would not make the mistakes of previous projects, we were in full control of whatever risk events might occur, our staff was top-notch, our client loved us, and we would implement on time and under budget. Surely this new project would be written about in college textbooks for years to come.

IT project teams are optimistic by their very nature. Just look at their estimates. Their estimates reflect their rose-colored confidence that requirements will be completely and unambiguously defined, end-user input will be flawless, system designs will be clean and structured, code will work first time, and testing will find few defects.

If project teams are that optimistic, and thus prone to underestimate effort for what is known, imagine how poorly they calculate the impacts of risk events which, by definition, are uncertainties. The earlier in the project, the more optimistic they are.

Although the Risk Management Plan itself does not identify the risks, it does set up the methodology. What will be the drivers to manage risk events: budget, scope, quality, or timelines? For example, in virtually every fixed-price project I worked on, the budget was the main driver in how we managed almost any given risk event.

If the project team’s unbridled enthusiasm carries forward into the risk identification and analysis process, then potential impacts will be understated. This will lead to skewed factor calculations and poorly analyzed prioritization – which leads to poorly managed project risk. The Risk Management Plan should set an expectation for thorough and realistic estimating processes.

5. Assign Responsibility for Managing Risk to the Teams

True, during risk planning, we may not be at the point in the project where individual risks are identified. However, risk categories should have been established.

When planning the responsibility for risk response, I’ve known Project Managers who like to assign responsibility “up the chain”, thinking that escalating to senior management will help manage most risk events more quickly. I’ve also worked with Project Managers who are poor at delegating, and therefore take the responsibility upon themselves, even though they have capable staff on their teams. Alternatively, I’ve worked with Project Managers who are so eager to keep responsibility for risk management off their own plate, that they delegate quickly – to the wrong staff member.

What makes the most sense to me is to document the responsibility for the risk categories to the teams best equipped to identify them early, develop response plans, monitor and report, and escalate them if they need assistance.

Earlier I had described a project situation where we decided to issue an RFP knowing that major legislation would be enacted sometime during project execution. The risk event was documented in the “regulatory” category and assigned to a group within the client organization that wasn’t even part of the project. That group monitored progress of the regulation and reported significant events to the Project Manager. When the legislation finally passed, our project had already been making adjustments such that the changes were absorbed almost seamlessly.

6. Plan Risk Responses Clearly

Appropriate responses for identified threats should be defined in anticipation of the types of negative risk events that are sure to occur:

  • Mitigation: plan to reduce the impact of a negative risk event.

    For example, on one project our Project Manager had become indispensable (I know, no one is truly indispensable). However, his work visa was expiring without possibility of extension.

    It was clear we needed to mitigate this risk event (even without referencing the Risk Management Plan, this was clear). We immediately applied for an extension pf his visa under the emergency provision of the legislation, and then worked with him on the possibility of becoming a permanent resident.

  • Avoidance: plan to remove the risk completely.

    Our team was invited to bid on a very aggressively scheduled project by an organization that had a reputation of treating vendors poorly. Although the bid was enticing, several of us were uneasy about the potential of winning and then becoming embroiled in a long, difficult project. We submitted a no-bid letter.

    Months later I spoke to the winning bidder. It seemed that our no-bid was a judicious (avoidance) response in light of the struggles they were having in dealing with the organization.

  • Transference: plan to shift the risk to another party. Note, shifting the risk doesn’t make it go away; it makes it another group’s responsibility group.

    The best example of this from my own experience is that of client organizations shifting the risk to the IT providers by requiring a firm fixed-price bid.

    At the same time, one of the poorest uses of this strategy is that of client organizations requiring their IT provider to prepare the user acceptance test (UAT) cases for execution by their end-users. This has never made sense to me. The IT provider, having conducted its own testing, would have a natural bias to developing UAT test cases from its own base of test cases.

  • Acceptance: plan to do nothing about the risk and develop a contingency plan if and when the risk event happens.

    In my earlier example that described beginning a large project even though there was new legislation on the horizon, we chose to accept the risk that the (unknown) new rules would cause rework. We assured the IT provider that they could negotiate the rework when the rules became known, and developed a contingency budget for the anticipated rework effort.

7. Define Contingency Planning in Concert with Risk Responses

The previous point described planning risk responses clearly. With each risk response, it is also advisable to develop a contingency plan to describe what actions will be taken if and when the risk event occurs.

For example, I was managing a medium sized project and observed that our Database Architect (DBA) was exhibiting some health-related issues. Losing our DBA as we were approaching the system design phase of the project would have been a huge setback. I documented the risk event and an appropriate risk response. I also documented a contingency plan to identify a substitute DBA, either from a similar project that was in maintenance or from an one of our contract vendors. Not all risk events need a contingency plan, but this one certainly did.

8. Plan Risk Management for the Duration of the Project

How many projects have you seen where the Risk Management Plan was developed during the project planning phase and then put on the shelf? After all, the Project Manager had the checklist and risk policy from previous projects. The risk categories from those previous projects seemed to fit this project perfectly. He may have even built out a risk register – again, copy/paste from a similar project. He reviewed a few Lessons Learned reports from past projects to see if additional risk events should be considered. Now just tweak a few line items, and risk planning is complete, right?

Unfortunately, risk management is often seen as a project planning activity that culminates in a contractual deliverable, the Risk Management Plan. With acceptance of the deliverable, risk management is considered complete. Filed away. Forgotten.

In fact, the opposite is true. The Risk Management Plan should detail ongoing tasks throughout the life of the project to monitor and report on risk events, the response actions that are taken, and any updates to project impacts. Similarly, any new risk events must be added to the risk register and managed.

Risk management doesn’t stop with the publishing of the Risk Management Plan. Risk never stops – either negative or positive.

Risk management planning is critical for any major IT project. While it is a necessary process exercise, it is also a people exercise. It involves critical people aspects of project management in that to do it well, it requires creative brainstorming, expert judgment, and cross-team cooperation to identify, monitor, and manage any and all risks that can affect a project.