Why Projects Succeed: Risk Assessment
By Roger Kastner
Why Projects Succeed is a blog series in which Slalom Business Architect Roger Kastner sheds light on key factors behind the art and science of successful project management and invites readers to discuss how they apply across different environments.
Recently I’ve written two articles about Risk Management:
Proactive Risk Management: I wrote that the value of risk management is in identifying and planning for the issues that may knock the project sideways specifically so you have the personal bandwidth to deal with those unforeseen elements that are going to knock you sideways despite your preparations.
Risk Identification: I wrote that the “Why this won’t work?” meeting is a great method for identifying risks that adds the benefit of garnering buy-in from team members on the feasibility of project success.
This time I want to focus on Risk Assessment. Risk Assessment is what they do in the movies when they discover that an asteroid is careening towards Earth; they determine the probability and severity of an impact, and then they shove Bruce Willis into a rocketship. (Ground Control to Major Chicken Little, right?)
Since not all risks are created equally, they should not be treated as such. Yes, this should not be like the movie “Armageddon,” it should be more like “Animal Farm;” two legs good, four legs bad. In other words, in Risk Assessment, the successful Project Manager will know how to rank the risks efficiently to ensure the focus is on what’s important and deserving of the team’s attention.
How does the successful Project Manager do this? It’s all in the Assessment process, which includes triaging the size and probability of the risk, then determining the appropriate response to each risk. By doing the assessment early and before the risk is realized, the successful Project Manager allows the team time to come up with clear-headed alternatives (i.e., a risk on paper is a lot less scary than one that is blocking out the sun).
Not All Risks Are Negative
“Did I just blow your mind?” - Ricky Bobby, Talladega Nights: The Ballard of Ricky Ballard
That’s right, there are risks that have a positive impact to a project. The definition of a risk is a potential occurrence that may cause a variance to your scope, schedule, and budget baselines. Therefore, a risk can have an unplanned positive impact on scope, schedule, and/or budget. Examples may include…
- Tasks not taking as long as expected,
Less resources are needed to accomplish a deliverable, or
Another project delivers functionality that can be repurposed,
…all of which are real-life examples of a positive risk that I’ve witnessed on projects that resulted in favorable variances.
If project management is all about increasing predictability in setting and managing project expectations, then the successful Project Manager should incorporate positive and negative risks in their risk management plans. So let’s discuss how to assess all risks, both positive and negative ones.
Not All Risks Should Be Treated The Same
Some identified risks are more likely to occur, and some, if realized, would have a bigger impact. Intuitively, this should make good sense. But when faced with a long list of risks, I’ve seen teams (and their leaders) have two reactions that sound like they’re from the Aesop’s vault of unreleased fables “The Ostrich and the Chicken.”
The Ostrich represents those who collectively put their heads in the sand, ignoring the risks and hoping that they don’t occur. The Chicken, as in “Chicken Little,” represents those who run around treating any identified risk as a major threat to the health of the project and expending a disproportionate amount of time and effort to plan for and address the outcome of a potential event. And in my experience, the Chicken’s over-reactive behavior can actually cause people to resort to the Ostrich behavior, as a way to avoid future Chicken panic attacks.
In both cases the reactions are caused by a feeling of being overwhelmed by the list of risks and the inability to rank and categorize the risks. And in the case of the Chicken, the project usually encounters an unintended consequence of the inappropriately run risk management process: team members do not identify or communicate new risks due to an extreme reaction to all previously identified risks.
So how does the successful Project Manager appropriately assess risks and create a sense of ranking or categorization amongst the list of risks? Let’s go back to the basic premise that some risks are more likely to occur and some will have a bigger impact if they do occur. If that is the case, then why not use probability and impact as the two dimensions for ranking risks?
Let’s take a quick quiz: Which of the following risks would you expect a successful Project Manager to focus on first:
- A risk with a $1M impact and a 10% probability of occurring?
A risk with a $200K impact and an 80% probability of occurring?
Both seem like significant risks, and I’d be interested in seeing the response chosen by any Project Manager for both. However, even though the first risk has a bigger impact ($1M), the second one is more deserving of attention because of the impact AND the probability. Let me tell you why: the Risk Score is bigger in the second scenario.
By identifying the probability and the impact of each risk, the successful Project Manager will take those two dimensions and multiply them together to generate a risk score. In doing so, the risks can easily be ranked and ordered, allowing for the team and sponsors to dialogue about how to respond to each risk.
In the above example, the first risk has a score of $100K and the second of $160K, thus, the second risk represents a bigger threat to the project’s baselines.
So, the Risk Score helps us determine a sense of priority amongst the risks, and now it’s time for the successful Project Manager to determine what type of response should be assigned to the various levels of risks.
The Risk Score will help the successful Project Manager prioritize the risks and to determine the appropriate Risk Response. The four types of responses are:
Mitigate the Risk – incorporate specific plans into the project scope to deal with the occurrence of, or to minimize the likelihood of, the risk occurring;
Avoid the Risk – remove scope that includes risk from the project;
Transfer the Risk – transfer ownership of scope to another party so they now have risk; and,
Accept the Risk – do nothing, run the chance of the risk occurring, deal with it if it does.
The successful Project Manager should lead a discussion amongst the team and sponsors to determine the high, medium, and low categories based on the Risk Scores, and assign responses to those categories. Using the above example, the successful Project Manager may determine that all risks with a score of $150K should be mitigated—meaning plans to actively address the impacts are adopted into project scope—and all risks with a score under $150K will be accepted—meaning the team watches for the risk trigger but does not change any scope to minimize the likelihood of the risk occurring. Therefore, the team would add scope to address the second risk, above, which scored $160K, but do nothing with the first risk, which scored only $100K.
In my experience Avoid and Transfer are used less frequently than Mitigate and Accept, but I’ll share an example for each.
- When determining scope for a project, sometimes the Avoid response is used, albeit not by name, when a sponsor chooses to not include a certain requirement or feature because the team is uncertain if it’s attainable within established timeframes or with existing technologies. The risk is typically a combination of poor quality, cost overruns, and/or missed dates, and the sponsor chooses to “defer” the requirement or feature until a later release when more is known. Since deferment removes the risk from the current scope, it is referred to as Risk Avoidance.
For the Transfer response, I’ve been on project teams that were uncertain of their abilities to develop and produce certain product functionalities, and therefore we chose to leverage existing technologies to support our new product. While we gave up some features and the flexibility to change the underlying solution on our timetable, however, we were able to deliver our product while hitting quality and feature expectations.
Real World Example
Unfortunately, there are projects where all risks are identified at DEFCON 1 levels. That’s unreasonable and a waste of time, energy, and money, and the successful Project Manager won’t let that happen. For instance, several years ago, I joined a mobile device product team where the stakeholders treated every risk as a meteor the size of Texas headed for the blue planet. The mobile industry is similar to the electronic gaming business, where competitive parity and speed to market are keys to survival, so frenetic energy and the loudest voices often rule the halls. When a new risk was identified, the product sponsors would demand immediate, “all hands on deck” attention to it. New meetings mushroomed-up onto people’s calendars, and PowerPoint decks proliferated in response. It was, technically speaking, “crazy.”
My solution to this mentality was to embrace transparency and distribute a simple Risk Matrix which included the following columns:
- Risk Name
As I added each new risk, I made sure that we identified and reviewed each of the columns, especially the Probability, Impact, and Score columns. We often had colorful debates about Probability, but Impact was often easy to agree upon. The next challenge would be deciding where we drew the line for our Risk Responses—which risks we mitigated and which risks we accepted. By drawing the line we were making a distinction between those risks we acted upon and those we didn’t. The very nature of having a line meant we didn’t have to react to all risks.
In addition to allowing for a prioritized and informed response to risks, this approach lowered the overall tension on the project, we actually increased the number of risks identified, and it boosted my credibility with the stakeholders.
Summary (or how I learned to stop being the Ostrich or the Chicken and embrace the Asteroid)
Risk Assessment is where, as Ricky Bobby might say, the rubber meets the road. The successful Project Manager has the Plan and has identified the risks. At that point all risks appear equal, however, the successful Project Manager will know that it’s not true. The Risk Assessment process will enable the appropriate triage and response for each risk, plus it will help the successful Project Manager gain buy-in amongst stakeholders on the appropriate response for each risk.
What Do You Think?
In the last couple of articles I’ve highlighted some key steps in the Proactive Risk Management process. First, developing and obtaining signoff on the Risk Management Plan. Then, using the “Why this won’t work” meeting to identify risks and gain buy-in on the feasibility of a project. Now we’ve gone through some key principles in the Risk Assessment phase. Of course, Risk Management is its own profession, so it would be insulting for me to pretend to cover the entire gamut of the discipline within a couple blog posts—I haven’t. I have covered what my experience has proven to be the basics for what’s required to successfully run a project. Now I’d love to hear what you think. Please join the conversation, post a comment, and share your experience.
Reprinted with permission from Slalom Consulting - © 2012 Slalom Consulting
Roger Kastner is a Business Architect with Slalom Consulting who is passionate about raising the caliber of project leadership within organizations to maximize the value of projects. You can read more articles from the series on “Why Projects Succeed” here.
No comments yet.