When to cry wolf

Abstract

Excellent risk management is a key component to ensuring the realization of your project goals. This paper will illuminate certain best practices in the art and science of risk management. By utilizing these methodologies projects stand a better chance of staying on track. Your team members will feel empowered and included as a critical part of the group. Your senior management will value the transparency. Your customers will appreciate on-time deliveries. Your project leadership will be noted.

Detailed topics addressed include when and how often you should conduct risk analysis, ways to identify comprehensive risk possibilities utilizing the “5Ws and the H,” rarely evaluated areas with potential high impact, risk urgency, and how to keep risk assessments fresh. Additionally, included is how to communicate risks so that senior management doesn't assume risks disappear if there are mitigation plans. Is it ever ok to “cry wolf”?

The Basics

Even some of the most experienced project managers do not understand the difference between a risk and an issue. To ensure common understanding, the following is one of the basic premises of this paper – a risk is an event or a situation that may happen, and an issue is an event or a situation that is happening. If an identified risk becomes an issue, then it ceases to be a risk. If you keep separate risk and issue logs, the risk should be transferred. Issues may contain many additional risks, but are not themselves risks. Additionally, “risk management is the systematic process of identifying, analyzing, and responding to project risks” (PMI, 2008, p. 127).

An additional premise of this paper is proposed: risk management is a time waster. It amazes some that a project manager should claim that – but it's true. Think about it: if you expend a lot of effort in identifying and mitigating risks and they never happen and they never would have happened – you have just wasted your time. But, even if risk management is a time waster, it is invaluable and a key factor in the greater success of your project. These two statements seem contradictory.

Continuing with the theme: risk management is proactive. The efforts in identifying and mitigating risks happen during project time that doesn't impact other key events. You schedule risk management at a time that is convenient for you and the project. Conversely, issue management is reactive. The efforts to understand, contain, and resolve issues impacts the scheduled work of the project. Typically, while handling issues, other project work is delayed.

For example, a project manager may spend five hours identifying and mitigating 10 risks at convenient times in the project. Let's say that nine of the identified risks would never have happened. That means most of the effort has been for naught – risk management is a time waster. But, due to mitigation efforts the final risk never becomes an issue. If it had of developed into an issue the team would have spent 25 person-hours in resolution and delayed the project by four days. Risk management may be a time waster, but it is critical to ensure risks do not become issues and ultimately saves your team's valuable time.

Risk Management – The Process

To understand the concept of managing risks, you will need to understand many factors – who, what, where, when, why, and how. Consider answering all the following questions to ensure thorough risk management on your project:

• What are the best ways to comprehend risks?
• What are the best ways to document risks?
• What level of risk rating should management be privy to?
• What are your stakeholders, customers, and team members concerned about?
• What is the best venue for reporting risks?

• How can you find risks?
• How do you run a risk analysis?
• How do you best mitigate risks?
• How do you and the team prioritize risks?
• How do you lead risk assessments?
• How do you ensure buy-in of mitigation strategies?
• How should you evaluate probability and impact?
• How do you evaluate changes to risks?
• How do you normalize individuals’ evaluation of probability and impact?

• When should you add other factors to the risk rating (quality)?
• When should you look for risks?
• When should you mitigate the risks?
• When should people be informed of the risks; changes to the risks?

• Where should you conduct the risk analysis?
• Where should you store and share the risks?

• Who should have the information?
• Who is the owner of the risk log?
• Who should you utilize to ensure your risks are thorough?
• Who should you inform of the changes to risks?

• Why is it a risk – does it score high enough to report?
• Why do you need risk analysis at all (training the team)?

Notice all of these questions do not address evaluating individual risks, but are focused on the overall management of risks. All of these questions should be answered by you and your team to manage risks well.

Writing a Risk

Poor communication is widely believed to be the overriding reason why projects fail (Harrison, 2013, ¶13). One of the many ways communication techniques overlap with risk management is how well the risk is written. Many risks are too succinct. A typical example: “Bad weather delays the plane.” Unfortunately, this example doesn't tell us much about what the impact may be. Therefore the following is a better example: “If bad weather delays the plane, then it will impact arrival time by one day.” But that statement does not tell us what will happen to our activities on the project. An even better example might be: “If bad weather delays the plane, then it will impact the arrival time by one day and we may lose one day of scheduled tours on our vacation.” This risk is now well stated, but you should consider that there may be additional impacts that will require additional risks to be documented (e.g., “If bad weather delays the plane, then it will impact the arrival time by one day and we will lose the hotel reservation.”). Notice the definition starts out as one risk, but due to different impacts different mitigation strategies are needed.

Risk Assessment Participants

Many times we do not take the time to conduct a thorough risk assessment. Sometimes it may be due to the belief that the analysis takes too much time, or the project team will not be receptive. Sometimes it is due to not knowing the best methodologies. Other times it can be due to arrogance. The project manager may evaluate risks without much input from others due to a sense of responsibility or the belief that they have enough experience to identify certainly the big risks and most all of the rest. There are disadvantages of being the main risk identifier – the list of risks is probably incomplete as the vast experience and knowledge of the team has not been tapped into. Additionally, the data becomes biased – based on one person's experience which hinders the type, amount, and variety of inputs. It may also lead to skewed actions – less creative, incomplete, and fewer mitigations, and the probabilities and impacts may be biased. Whatever the reasons, not conducting a thorough risk assessment with the right participants leads to a greater chance of unidentified or even identified risks becoming issues.

Conducting a Formal Risk Assessment

There are many ways to perform group risk assessments. The following process has had excellent results for many groups. The recommendation is that a lengthy assessment is completed during planning, and then monthly assessments continue depending on the length of your project. Analysis of your risk logs (Exhibit 2. Example Risk Log) should happen continuously.

The Process

First, gather the entire group or team in one room. Face to face interaction leads to better accumulation of, and agreement on, risks. How to modify this activity for non-co-located teams will be addressed later in this paper. Train the team in the best practices of how to write a risk (Writing a Risk above). Then establish the directive parameter – what this risk assessment will cover. Sometimes it can be very general: “What can go wrong with this project?” Unfortunately, holding many formal assessments on this topic alone will not likely be well received. Therefore, use documents (e.g. requirements, charter, schedule, communication plan) or have leading questions (addressed in the Continuous Risk Management section) to keep the interest level up while adding to your risk log.

Once the directive is stated, the group will complete a focused response. Using sticky notes, the individuals write as many risks that they can think of in a five minute period (placing their initials on the paper so that if there are questions, the author is known). The reason to have a written response versus working as a group verbally stating and discussing risks is that people in the group may be swayed by the direction of the responses and some members may not participate. When written, this activity allows for all to participate without their ideas being influenced, and possibly hampered, by others.

After the five minute risk generation, this next part of the activity should be completed in silence. Ask one team member to put their sticky notes on a white board, large butcher paper, or even an empty table – categorizing and grouping them into ‘types’ of risk without stating what those types are. Then that person stays and reads risks as the process continues, but doesn't interfere. The second person reads the first risks and adds his risks to the categories he perceives his align with or starts more categories. If there are two very similar risks, they can attach their risk onto the other. The third person does the same, but is allowed to ‘re-categorize’ groups of risks if a new category makes more sense to him. This continues until the entire team has had a chance to evaluate all the risks and categorize them.

At this point, the team can start to discuss the categories and risks. During the discussion, many times it sparks even more risks and additional categories, or the team comes up with slightly different risks that fit into categories (new sticky notes). Additionally, during the discussions if someone has written a risk that is not clear – feel free to clarify it for everyone and re-write it. Once the team has agreed upon the categories, write each of those on a sticky note above that grouping. One critical rule is that there is no miscellaneous category – you must create a classification. Try to never have a category with only one risk.

Now that there are many risks in separate categories – it is time to capture the data. Don't rely on sticky notes to remain sticky! The best practice is to take a picture and eventually transcribe the details into a risk log (see Exhibit 2).

Timing and Results

The process of training the team to write risks well may take 10 minutes. The risk generation will take five minutes. Most people can write at least 10 risks in 5 minutes; with a team of 8 people this would result in at least 80 risks. There will probably be 10 risks that are duplicates in some manner, but there will also be additional risks created from the subsequent discussion. To categorize and discuss the risks usually takes about 30 minutes. Therefore, at the end of 45 minutes, there will be approximately 75 categorized risks to transcribe into the risk log, evaluate and manage. Another great result of this process is the team buy-in and awareness of all the risks.

Teams that Aren't Co-located

If you have a non-co-located team the process is similar. The adjustments necessary are to use a phone call to discuss the process requesting immediate feedback to ensure all understand their role. Instead of sticky notes, use the risk log but they only fill out the risk, verbal impact, and category sections. Determine and communicate the directive (topic), request that no one is in contact with one another, and set a date to return the risk log (usually no more than a week). There is additional work for the project manager to collate the information and align the categories. On a subsequent call, the team reviews the details and discusses any necessary clarifications, categories, probabilities, impacts, mitigations, etc.

Managing the Details

Sometimes the project manager may try to complete this follow-on activity first and run it by the team. This works well if the team is inexperienced or not willing to stand up to conflicting points of view. If not, it is recommended to complete this activity during core team meetings for additional insight and buy-in.

First determine how you will report probability. There are an infinite number of ways to do this. Many use “High, Medium, and Low.” Others use a number scale. One option for a number scale is “1, 3, and 9” – which cause the final risk values to be more extreme. Another possibility is a scale of more than three options – which allows for many categories of risk values, however it may be confusing for the team. More complex options don't necessarily generate better management or mitigations. This author's recommendation is to keep it simple – use numbers but just “1, 2, and 3” as teams more easily comprehend the end results.

Next, determine what “probable” means. Ask your team “If a risk has a high probability of happening (3 on our scale) – what percentage does that equate to for you?” Some will say – 90% (a virtual certainty), some will say 66% (2/3 of the time), even others may say 51% (more likely than not). You must agree as a team as to the definition of “1 (low), 2 (medium), and 3 (high).” The preceding is another example of communication affecting project success.

Now evaluate impact in two forms – quantitatively (numbers) and qualitatively (verbiage). Just as probability was evaluated, “impact” should be defined by the team for “1 (low impact), 2 (medium impact), and 3 (high impact).” The definition can be attributed to impact of budget, schedule, scope, or other details. Consider though, if you are allowed a contingency or buffer of 10% for the overall project, one risk that takes up the entire contingency is outrageously high. Example, a “high impact” definition may be a risk impact that exceeds a 5% contingency.

Then determine the impact verbally: if a risk happens, what will be the impact – in words? It cannot be stressed enough that this is a powerful tool in communicating with management to truly understand the risk. If possible, the impact should contain topics that are of interest to upper management (e.g., customer satisfaction, financials, quality). Additionally, consider if there will be multiple different impacts for the same risk. If you have a risk with different impacts, you may want to create separate risks in the risk log to allow for diverse mitigation activities.

At this point it is time to determine the risk rating – probability multiplied by impact (Exhibit 1).

Exhibit 1 – Simple Probability / Impact Matrix

The overall Risk Rating of a 9 is unacceptable, 6 = high, 4 and 3 = medium, 2 and 1 = low. Note that two medium ratings have a higher overall risk rating than a high multiplied by a low and should be managed as such. If you have a large team or have a lot of identified risks, the expectation is that you won't spend a lot of time on 1s and 2s. The recommendation is that the low risks are at least reviewed occasionally for increases to those probabilities and impacts. For all 9s and 6s, mitigation activities should be added to your schedule.

Many teams have important considerations handed down by management and are asked to add additional categories – such as quality (probability x impact x quality). Realize that by adding more measurement categories you may be diluting and complicating the results rather than adding a focus.

The next activity is to determine if a trigger exists. A trigger is an event that, if it occurs, usually increases the probability of a risk happening (advanced warning). Establishing triggers can be helpful to enact plans without wasting time. An example of a trigger using the example above: three days before the flight you schedule to check the weather forecast that may indicate approaching bad weather. Many triggers have actions associated with them – and may need to be added to the schedule. Because all risks may not have a trigger, spending time assessing triggers should be saved for the high overall risks.

Determining a response plan is the next step. There are four response categories – avoid, accept, transfer, or mitigate. Avoid means to completely circumvent the risk. One way you can do this is to cancel the project or as in the example above – don't go on vacation. Accepting the risk means that you understand the probability and impact and agree that there is nothing that can be done, but the project continues. One note, if this is the case and it is a high risk, leadership must truly understand and agree to this course of action – otherwise you and the team are accountable if it becomes an issue. To transfer a risk is to make the risk less probable or impactful by assigning it to a group outside the team. For example, your team doesn't have the experience to create a module and you decide to use a vendor that has this proven capability. The last category – and most used, is to mitigate the risk – to create plans to decrease or eliminate the probability and/or impact of the risk. There may be multiple mitigation strategies for a single risk. Each of these strategies must have a due date and an owner. The owner is typically someone on the team. The best practice is to assign mitigation strategies only to team members, as they have the accountability to project success. Within the mitigation details the team member may be accountable to work with critical personnel that have specific knowledge or expertise and report back to the team.

Senior management may hear of a “high” risk with a mitigation plan. Unfortunately, many times they assume that the mitigation plan has eradicated the risk. Therefore, another item to add to your risk log to enhance communication is Current (or Mitigated) Risk Rating. If you have determined that a risk has a probability of occurring at a 3, and an impact of a 3 – the Risk Rating is a 9 – unacceptable. If you create a mitigation strategy that moves the impact of the risk to a 2 – then the Current (or Mitigated) Risk Rating is a 6. This final risk rating is critical for senior management to comprehend – it is a 6 (still high) – not gone! Sometimes, even with the best mitigation strategies the risk remains high.

The last section for evaluating risks is the contingency plan – a plan created for when a risk becomes an issue. Contingency plans are usually generated for at least the highest probable risks. Determine the required actions ahead of time so there is less time lost and those involved are aware of their roles and responsibilities and the intended plans. Implementing a predetermined plan takes much less time than scrambling to solve, gain buy-in, and communicate expectations and actions to many stakeholders.

Exhibit 2 – Example Risk Log

The last and constant activity is communication – when, how, who to, and how often. Communication strategies must be considered habitually. Your risk management plan dovetails into your communication plan. Ensure all are aware of and agree to the risk communication strategies.

Continuous Risk Management

The initial risks have been collected and evaluated. How best to continue to collect and review risks? You can change directives to utilize different documents – the project charter, requirements document, communication plan, etc. But how can you possibly do this on a regular basis while keeping the team engaged and getting valuable additional data? While formal risk assessments are a great tool, additional risks can be collected in other forums such as core team meetings or via email as they are identified by team members.

Another best practice is to utilize leading questions to make the assessments even more thought-provoking. Some of the examples below can be used for a full 45-minute formal risk assessment (toward the top), while the rest may be better suited to a 20-minute meeting or quick conversations during an established meeting:

• Impacts to cost/schedule/quality
• Objectives/business goals
• Requirements
• Risk categories
• Assumptions
• SWOT – strengths, weaknesses, opportunities, threats
• Positive risks (opportunities) – improving the outcome of the project (scope, schedule, budget)
• Other projects impacting this one
• High probability risks
• High impact risks
• Coverage of different mitigations
• Mitigations not working
• Unplanned work
• Process maturity
• Disruptors
• Lost information, ignored or misunderstood email
• Critical resource personnel availability
• Different motivations – for being on the team, for not participating, etc.
• Non-human resources not functioning
• Poor documentation
• Organizational barriers
• Leadership not buying into proposed solutions or mitigations
• Multitasking during core team meetings
• Non-participation of core team members

One of the most productive leading question assessments utilized in a core team meeting was the last topic – non-participation of core team members. A critical team member had been reluctant to participate in discussions and finding solutions. When the risk assessment was completed, that person heard from the team members how valuable he was to the team, that his opinion was important, and he was a key factor in the success of the project. After that risk assessment, he participated fully (although it was never recorded in the risk log).

Another consideration is who to incorporate into your assessments. Consider utilizing non-team members, subject matter experts, stakeholders, project sponsors, executives, or even customers in your various risk assessments. Customers may actually state risks that are their underlying concerns which they may not have voiced otherwise. This allows you to address them openly and gives them security that you have the project under control.

Why continually review risks? Project details change creating new risks. Issues arise creating new risks. Risks themselves change in their impacts and probabilities. If you only perform an initial risk assessment and work those risks, you will be missing an abundance of new or altered risks. Once you have collected the risks, created mitigation strategies, risks should continually be evaluated for clarity, changes in probability, impact, overall and mitigated risk ratings, status, triggers, ownership, timeframe, mitigation activities, etc.

When to Cry Wolf

What is “crying wolf”? Is it ever a good idea to exaggerate? Or tell management something is happening (or may happen) when it isn't? Should a risk rating be increased to get the attention of senior management? The answer is – it depends. It is not a good idea to be inaccurate, as you may end up with a reputation that you do not manage risks well. But, if you are working in a culture where management doesn't review risks unless they are high – is it ever reasonable to take a level four risk and increase it to a six? The best course is to help management understand that a level four can easily turn into a high risk in certain circumstances and help them understand the need for their review and support. Only in truly rare situations after attempting to educate management, more support is needed, and there is no change in their actions, should you even consider altering risk ratings. Note that you must be able to justify your reasoning with sound data as to why you need the additional attention. Remember the fable, like the boy that cried “wolf” too often, management may learn not to pay attention to high risks because they have been trained that “high” many times is not.

Conclusion

So why do so much work, especially if it wastes time? Because the act of gathering, assessing and managing risks results in decreased probability of risks turning into issues and diminishes the impacts of risks that do turn into issues. Additionally, not having to allow for additional reactive work when issues arise creates more time for team members to produce quality work, and increases project efficiency, profitability and customer satisfaction. You, as the project manager, will be known as a leader that can keep the project on track.

Excellent risk management will make you more successful. Your projects stand a better chance to stay on track. Your team members will feel empowered and included as a critical part of the team. Your senior management will value the transparency. Your customers will appreciate on-time deliveries. Your project leadership will be noted.