Are you assessing risk effectively?

The Scout Motto is “Be prepared”. I don’t know if a study has ever been done to determine whether former scouts make better project managers, but it wouldn’t surprise me if there was a correlation.

The most successful project managers I know are prepared for almost anything. Over the years, the most successful way I’ve found to be prepared is to have a formal risk assessment process, in which risks are addressed early and often.

The “early” part is the most common, but it is often given limited attention as a means of checking a task off of a list of PM activities. In reality, assessing risk is one of the most important activities a project manager can do at the beginning of a project.

Assessing risk should be done in the following ways:

What could happen?

As early as possible after a team has been developed, the PM should meet with the team members to determine their biggest concerns. While it’s almost always good to maintain a positive attitude, this is the time to think pessimistically. Ask each team member, “What do you worry about?” Make a list of everything you can think of that could possibly go wrong.

“What if the servers we order don’t come in on time?”

“What if the software vendor we’ve partnered with goes out of business?”

“What if several of our team members quit in the middle of the project?”

This is not meant to alarm anyone or create a sense of defeatism with the team. It’s just that it is difficult to be prepared if you don’t know what to be prepared for. This exercise is intended to identify as many things as possible to be prepared for.

Related post: Project Risk and the FedEx Truck

Assess the Impact

Once a comprehensive list has been identified with input from a wide swath of team members, the PM should solicit input from the team on the impact of the risk.

Impact is usually assessed in levels, such as 1-5 where 1 represents Minimal and 5 represents Severe. It is important for the team to agree on the definitions of the severity levels prior to assignment. The levels I use are:

1 Minimal: Little or no impact to the project outcome.

2 Minor: If the risk occurs, it will have minor impact to the project objectives or date targets.

3 Moderate: If the risk occurs, one or more stated objectives could result in falling behind its stated objectives.

4 Significant: If the risk occurs, one or more stated objectives of the project will fall well behind the goals of the project and place the outcome of the project at risk.

5 Severe: If the risk occurs it will have severe impact on the project, causing a significant delay, an objective not being achieved, or both.

An assignment of the impact on the project along with comments describing potential impact should be made for each risk.

For more information, check out Project Management Planning Considerations.

Assess the Likelihood

The likelihood of servers being delayed could be relatively high.  The likelihood of a suicide bomber driving into your building and blowing it up would hopefully be much lower.

Some project managers assess risk likelihood with complex algorithms such as probability distributions, expected values, and modeling techniques such as Monte Carlo assessments.

In the end, it’s always a judgment call. I prefer a much simpler approach of obtaining the consolidated opinion of key people. The assessment I usually use is also a five-level range:

1 Rare – Highly unlikely but still possible in the right situation.

2 Unlikely – Not expected, but need to be prepared.

3 Possible – History shows that this can occasionally happen.

4 Likely – Strong possibility that this could occur sometime during the project.

5 Almost certain – This happens regularly on projects.

Develop a matrix of Impact vs. Likelihood

Once the team has assessed the impact and likelihood of a risk, I put them together in a matrix with Impact on one axis and likelihood on the other.

For each combination of Impact and likelihood, I determine a Red-Yellow-Green assessment of each. Risk averse organizations may designate more cells in the red area. The point is to determine the seriousness of each combination and then determine which risks fall in which cell intersections.

Determine Mitigation – By category

Once all risks have been determined and assessed for impact and likelihood, it is time to determine how the team will deal with the risk, should it actually occur and become an issue.

There are many approaches to categorize risk mitigation strategies. I prefer to focus on three.

Risk Acceptance: If the combined impact and likelihood of a risk is low, the team may be comfortable just accepting the risk. If it occurs, it will be more of an irritant that we will learn to deal with on a day-to-day basis.

Risk Avoidance: There are activities the project can perform to make sure a risk doesn’t occur. If there is a risk that the quality of software code will be low, perhaps more resources can be assigned for quality assurance to avoid deploying poor quality into a production environment.

Risk Transferal: If the risk is considered to have a high impact on the project, the organization may opt to invest in the additional cost of transferring the risk to a specialty group. This could include purchasing an insurance policy on property or hiring expert consultants to transfer the risk of a knowledge deficiency on the project.

A team may decide to exercise risk acceptance for risks that fall in green cells, risk avoidance for risks in yellow, and invest in risk transferal for any risks residing in red cells.  Some project teams identify multiple strategies for the same risk to provide multiple options in the case where there are multiple variations of how a risk could occur.

Assessing risk often

Once a project manager performs the initial risk assessment at the beginning of the project, he or she may have a tendency to file it away assuming risk assessment responsibilities have been met. Project situations change on a daily basis. The risk assessment created today may change significantly by next week.

On a weekly basis, the PM should review the risk log to determine whether any impacts or likelihoods have changed. The PM should try to identify if any mitigation strategies should be modified.  Finally, the PM should try to determine if any new risks should be added to the log.

Ideally, the project manager always has her radar on for new risks. If a discussion in a meeting reveals a new risk, she immediately identifies it, adds it to the log and performs the analysis to assess its impact, likelihood and determine appropriate mitigation strategies.

Every experienced project manager will tell you that issues happen on projects all the time. Even the best project managers can’t be ready for every possible issue. A good project manager, however, like a good scout, is prepared for as many issues as possible. The best way for a PM to be prepared is to assess risks early and often.

How do you ensure that you are assessing risk effectively?

If you would like to learn more about a career in Project Management, get Lew’s book Project Management 101: 101 Tips for Success in Project Management on Amazon.

Please feel free to provide feedback in the comments section below.