Search:

ProjectConnections Print View


Got a Question?
Drop us an email, or call us toll free:
888-722-5235
7am-5pm Pacific
Monday - Friday
We'd love to talk to you.


Learn more about ProjectConnections and who writes our content. Want to learn more? Take a site tour.


PM Articles > Brian Irwin > Proactive Risk Management Prevents a Lot of Fan Cleaning

Proactive Risk Management Prevents a Lot of Fan Cleaning

by Brian Irwin

While I'm passionate about many topics, risk management is at, or near, the top. This is because I've seen it work and, more importantly, I've seen and lived the results of poor risk management. On one instance, I was leading a project that experienced a $250,000 cost impact as a direct result of a completely avoidable risk. These are lessons you want to learn through someone else, not through experiencing them yourself.

Standard risk lists are filled with items like "not enough resources" or "aggressive timeline." Are these actually risks? NOW HEAR THIS...More than likely, you're never going to have enough resources and timelines will always be aggressive. Get used to it. These are certainties, not risks. This is, in general, the nature of the modern project environment.

But beyond their obviousness, risks like these fail to provide the project manager or the team any useful direction. As an example, consider the statement "not enough resources." What does that mean in the context of the project? Is it the cause of something else? Is it a statement of what your project is experiencing at this moment? There is simply no way to know from the description provided.

A good risk statement will articulate the cause, identify the risk, and communicate the result or impact of the risk becoming an issue. Statements such as the ones above do not clearly articulate anything. Instead, consider stating your risks in this format:

"As a result of , a may occur, leading to ."

To do this properly, you'll have to identify the trigger most likely to turn your risk into an issue. For example, the "not enough resources" statement could be rewritten as, "As a result of slips in other projects, the resources required for project completion may not be available, leading to missed deadlines, poor quality, or both." Stated in this verbose manner, the risk communicates many vital pieces of information.

  • What's the cause? Slips in other projects are the cause which now becomes your trigger.
  • What's the risk? The resulting lack of resource availability is your risk, which will become your issue if it's realized.
  • What's the result of the risk being realized? Should the risk become an issue, the missed deadlines and/or poor quality will be the result. These will have to be lessened in severity should this risk become an issue.

Another alternative for risk statements is an IF-THEN structure. Following this format, the resource availability risk above would be written as, "IF other projects currently in progress slip, THEN the resources required for project completion will be unavailable, leading to missed deadlines, poor quality, or both." I've found that this method works especially well when trying to get a group of software developers to discuss project risk. This risk statement method also helps to connect with a development team, since you're speaking to them using their language.

With the risks properly stated, we may now move toward determining the probability of occurrence, the severity of the impact, and identifying an owner for the risk.

The probability of occurrence is, admittedly, subjective. My suggestion is to assign a range of possibilities to the probability of occurrence. As an example, you could state your probability using the following four categories:

Remote 25% or under
Slight 26 – 50%
Medium 51 – 75%
Almost Certain Over 75%

This is often referred to as a range estimate. I find these ranges far more useful than "point" estimates for both probability and impact values. You can be much more confident of an estimate when providing a range than when providing a single number.

Try it: Without looking at the internet or in a book, estimate the radius of the sun in kilometers using a single number. How confident are you in your answer? Would you feel more confident if you were allowed to give a range, perhaps somewhere between 300,000 and 900,000 kilometers? Of course!

The point is that you can enhance your ability to effectively manage risk by acknowledging that your guess is just that—a guess. You can increase your confidence level in both probability of occurrence and magnitude of impact. You can increase it further by performing a Monte Carlo analysis, but that's a topic for another time.

The magnitude of the impact is determined in a similar way. Assume the risk has occurred. What would be the impact to your project? You can categorize the impact in a consistent manner by simply providing a HIGH/MED/LOW rating, or you could provide an actual schedule or cost impact such as three months or $10,000. There are advantages and disadvantages of both approaches. The point remains the same as in the probability of occurrence example. You can estimate a range of possibilities much more confidently than you can a single point estimate.

Once the probability of occurrence and the magnitude of impact has been determined, you can consider exactly who should own the risk. Ask yourself who is in a position to do something about the risk. To become the risk owner, you should be in a position to be able to either lessen the probability of it occurring or reduce the severity of the impact. At face value, my first recommendation would be that the project manager should own the risk of not being able to obtain the required resources. This ownership would include monitoring ongoing projects your resources are currently assigned to. If the projects slip, you can work to find other available resources capable of performing the work on your project or escalate this issue.

So how many risks should you manage? It depends on the criticality and stakes of the project, the size of the project team, the aggressiveness of the schedule, and the support (or lack of support) provided by executives and sponsors. I always try to perform an entire risk assessment with the team prior to beginning the next phase of a project. It pays dividends to review your top risks during each project team meeting. You can use this time to get an update on status from the risk owner, review the priority of the risk, or provide assistance to the risk owner should they need help with mitigation activities.

This is a quick and easy overview of simple and dirty risk management. Taking some time up front using a proactive approach will save you countless hours of effort and elbow grease cleaning fan blades. I've spent some time cleaning those fan blades and I suspect you have too. It's much more enjoyable to savor the results of being proactive than it is being a fan janitor.

(And, in case you were wondering, the actual radius of the sun is 695,500 kilometers.)



Related Links
Keep track of your project's risks using a Risk Assessment Table that includes guidelines for identifying risks from many different categories. For another view on estimating how—or how much—a risk could impact your project, try calculating the Expected Monetary Value (EMV). Once your risks become issues, keep your stakeholders updated on progress with our Issue Resolution Status Report.



Comments
Not all comments are posted. Posted comments are subject to editing for clarity and length.

Excellent article on risk. Everyone involved in a project should read this one.


Nice article. I'm a believer that a good risk statement (cause, risk, result) is the critical first step in doing effective risk management at any level of rigor. The one topic I would have liked to see included is prioritizing risks once identified, and not in the way PMBOK suggests.


Thank you for being the second person to recognize what I’ve been saying for years in my requirements, project management, and quality/testing writings and seminars: most of the commonly-stated standard project risks are certainties, not risks. Risks require some degree of statistical uncertainty. Ironically, risk checklist usual suspects, such as, not enough resources and late delivery of necessary items, are all caused by another non-risk certainty--poor management practices, starting with failure to know to or how to discover the REAL, business requirements that provide value when satisfied by the project deliverables.


Todd, Berne, Robin -

Thank you all for the nice comments. For several years now I've been working on not allowing project managers to play ostrich by burying their heads in the sand. After all, in the end isn't project management really just one big risk management effort?


In my experience a difficult part of project risk management is to share updated information about project risks. In particularly the status of implementation of risk mitigations needs to be kept accurate. Using an online risk register like MediumRisk ensures that risk reduction efforts are monitored and tracked so project management and team members can get a current view of the project risk status and the actions to be performed to reduce the risk.


Thanks Nice Article!!

In fact Risk mitigation area need to assess properly and to be reviewed residual risks over a frequent time with Risk Owner and ways to establish for improve/disseminate the risk and ensure the same risk is not leading as a factor for other risk generation. RAM Chart / Boston Square would be the better graphical way to report the risk to stakeholders to live with identified risk of the project...


Post a comment




(Not displayed with comment.)









©Copyright 2000-2014 Emprend, Inc. All Rights Reserved.
About us   Site Map   View current sponsorship opportunities (PDF)
Contact us for more information or e-mail [email protected]
Terms of Service and Privacy Policy