Bringing You the Latest Trends in Project Management and Business Analysis

ESIHorizons Newsletter

May 2004 Volume #5• Issue #5

Table of Contents | Archive

La Lingua Risk: Translating Risk for Clarity, Understanding and Action

By Carl Pritchard, PMP

At some point or another, we've all been in a conversation where someone has launched into "techno-speak" or some other jargon that was completely foreign to us. Just recently, I was on the phone with the technical help desk for my desktop PC when the technician on the other end began asking questions about my router set-up. (The fact that I was able to set up the router on my own was a personal miracle). As she fired away questions about the Ethernet cable, I was proud to know the language, but when she started talking about the nuances of establishing a VPN, I was lost.

When placed in those types of situations, we have two options: pretend we know what's being discussed and remain silent, or risk the possibility of looking less than intelligent and ask for clarification. In situations when we don't believe we are responsible for being an information repository (as in the example above), it's perfectly reasonable to ask for clarification. But for situations when we believe we should have the answers and the insight, asking for clarification can become remarkably awkward.

As project managers and managers of project managers, we have a responsibility to communicate information as clearly and efficiently as possible. When it comes to risk and risk management, there are frequently significant communication breakdowns. Why? Risk is a language of the individual. Different perspectives, experiences and capabilities drive differences in the language of risk. There are three specific areas where risk language comes directly into play: the definition of risk events, the definition of probability and impact, and the definitions of strategies.

The Translation of Risk Events

A client sent me an e-mail recently to say that she and her team had identified the number-one risk on their software development project as "the tests." That's not a risk event. Risk events are the bad things that may happen to us, the details. Tests aren't bad things that happen to us. Failing the tests might be a bad thing. Passing the tests but missing a bug might be a bad thing. Conducting the wrong tests might be a bad thing. Look at the differences! Those are radically different risk events. And, they are still not terribly well defined. Failing the tests and having to conduct extensive re-programming is a wildly different risk from failing the tests and having to move the launch date. The impact of the risk is part of the definition.

One project manager has a clever solution for the wide range of possible risk events with common impacts (which can lead to dozens or hundreds of permutations of possible risks). He lists the risk events in a left-hand column and the impacts in a right-hand column. It may seem simple, but he's ensuring that his team members are aware of the specifics of the bad things that may happen and their potential outcomes. Ultimately, for each combination, there is a different probability and impact listing.

The key here is to avoid forcing individuals to guess about what we mean when we say "risk." We don't want to allow for individual interpretation, or the critical risk or risks we are trying to identify might be missed altogether. The important issue is to get others to focus on the same thing we're talking about. The issue is one of language.

How do we develop a common language for risk events? We can do so by creating a format. Structure can be everything. Anyone who speaks French and English knows the frustration of trying to flip from one language to the other. Sentences are structured differently. The use of adjectives and other modifiers is often reversed. Some things that can be assumed in one language cannot be assumed in the other. For risk events, this means that we should be working to ensure that we create a syntax that everyone understands, such as the following:

[SOMETHING BAD THAT MAY HAPPEN] may occur, causing [IMPACT, POSSIBLY MODIFIED BY ITS SEVERITY].

For example, "a meteorite may crash through the ceiling, crushing Bob like a grape and delaying the launch date." That's a far cry from simply listing "a meteorite" as a risk.

By defining the risk even more clearly, we have the opportunity to manage more effectively. We can put Bob under a meteorite-proof house. We can push out the launch date prophylactically. We can launch missiles into space to destroy the meteor before it enters the atmosphere. The range of possible responses increases with the level of detail and clarity. Perhaps even more importantly, team members have a shared understanding of the range of possible outcomes and what they really should be worried about. We're not really worried about meteorites. We're worried about Bob being vaporized.

Risk Language for Probability and Impact

Risk qualification is born out of the notion of clear, consistent application of probability and impact terminology. In many organizations, however, the terms high, medium and low are used without any guidance or instruction as to what they mean and how they are properly applied. In some instances, the distinction between probability and impact isn't clarified. Proper application of risk language means clarifying those terms and how they will be interpreted. Low probability - does that mean it "could happen" or that it's "happened once" or that "it doesn't happen too often"? Those disparate interpretations will put a different number of risks in that category. High impact - does that mean "$45,000 or more if it happens" or "a two-week delay" or "management will be calling me in for more meetings"? These definitions are critical, as different team members have different levels of paranoia. Some consider everything a high risk. Some consider nothing a high risk. Without clarification of terms and terminology, team members may start talking to each other using the same words, but not using the same language. That creates confusion, and it almost guarantees that risk information will not be effectively shared.

As project managers, we often decry our relative lack of empowerment and our inability to truly "manage" anything. This is a wonderful instance where the antithesis is true. We can control our destiny and our language. Language is largely the arbiter of culture, and when it comes to probability and impact for risk, the language chosen determines the risk culture. We can be phobic or relaxed. We can express intense paranoia (with low thresholds for high probability) or we can take it easy (by labeling high impact only those things that are truly catastrophic).

The key, however, is to communicate it. Project managers should challenge their team members when they utter the words "high risk." Do they mean high impact? High probability? Both? And, what do they mean when they say high probability? Do they mean that it almost always happens? Or, do they mean that it's been a part of their personal experience? We need to work with team members to define those terms and to ensure they're using them appropriately. Otherwise, their "dialect" of risk may confuse everyone else on the team.

The Translation of Strategies

PMI® has done project management a huge service with its emphasis on the appropriate use of risk strategy terms. Even so, many project managers don't employ PMI's terminology properly and misconstrue the strategies and what they mean. Take the simplest of all risk strategies-acceptance. Acceptance means to accept the risk as possible and take no direct action to modify its probability or impact in advance of the risk's occurrence. That italicized phrase is significant. It doesn't mean we won't react or respond. It means that we won't take any direct action ahead of time. Some team members interpret this different ways. For some, acceptance means "forget about it." They interpret acceptance as a license to ignore the risk altogether. This is a potentially dangerous interpretation of the language. For others, acceptance means "take no action, unless we get close." Again, unless this interpretation is agreed upon by the team, accepting this view can cause many knee-jerk responses as risk events shift in probability and/or impact.

Similarly, if there's no common understanding of what we mean when we say we'll avoid a risk, some may misinterpret such action to be acceptance. What is the key to success? Define, define, define. Know what the language is and make sure the team has a common understanding. Otherwise, when you explain that you need to avoid a risk, it may easily be mistaken for mitigation or acceptance.

Your Risk Language

The influence of your choice of language and the translation thereof has an inestimable effect on risk and its resolution. By enabling more effective risk management through consistent language, we take a simple, personal and powerful step toward better project management practice.

PMI is a service mark and trademark of the Project Management Institute, Inc., and is registered in the United States and other nations.

Carl Pritchard, PMP, is a senior instructor with ESI International. He is the author of Risk Management: Concepts & Guidance (ESI International, 2001). With J. LeRoy Ward, he co-produced the CD audio series The Portable PMP Prep-Conversations on Passing the PMP Exam. Carl offers his support in implementing these practices by e-mail at carl@carlpritchard.com.

Submit an Article to ESI Horizons

To inquire about contributing articles to ESI Horizons, contact the Horizons editor at horizons@esi-intl.com. Please review our submission guidelines.