Last night was poker night. We had the usual poker accessories: felt tabletop; clay chips; cards from Binion's Casino; and the mandatory beer, scotch, and cigars. What more can a guy ask for?
A straight flush would have been nice. My buddy Mick crushed me with his straight flush (I did, at least, have the flush).

NOTE

     Five cards are in the community in Texas Hold 'Em, so Mick and I could share up to five cards.

     You're familiar with Texas Hold 'Em poker, right? I'm sure you've seen the recent poker trend: oddballs with goofy glasses, good luck charms, and pre-game rituals. Whatever. The cards are just going to fall the way they're going to fall. Nothing, from your lucky rabbit foot to your favorite T-shirt, is going to change that.

Risk and the Poker-Playing Project Manager

     The risk, the point of this article, is how much you're willing to wager based on what's in your hand. The more you wager, that is, the more you risk—the more you could win or lose. Your willingness to accept risk is called your utility function.

     Not to be a nerd (I know, too late), but utility function is a microeconomics terms related to Bernoulli's curve. Basically it describes your comfort of investment in relation to how much you're willing to risk for your return.

     Your winnings as a result of the risk you've taken is called the reward. What you risk is always in proportion to your reward. You experience risk and reward all the time, not just in poker and project management:

• We all take risks when we drive on any highway, but we consider the risk low, so we accept the odds that we'll arrive safely. The reward is that driving is faster than walking.
• Play golf? Do you take the risk and shoot over water, or do you play it safe and lay up and shoot again? The risk is that your ball may go swimming, but if you clear the hazard you're up a stroke. Brilliant!
• Invest some cash in the stock market? You can put lots of cash in IPOs that may make you a bazillionaire or leave you broke.

     In business, as in life, there are two big umbrellas of risk: pure risk and business risk.

• Pure risk is not good. Pure risks are things like fire, loss of life or limb, and dangerous types of work. For these risks, we usually take extra precautions to ensure safety: fire hydrants, hard hats, OSHA rules, and so on. Pure risks typically only have a downside.
• Business risk is where most of our projects are concerned. Business risks can have an upside or a downside. For example, we may identify a risk in our project that we need two software developers to complete the work within three months. The cost to hire a third developer to hit the deadline is $75,000. We predict that we'll be late by two weeks and our penalty for being late is $10,000. We decide to accept the risk that our two developers will not be later than two weeks and drop the $10,000 rather than spend the additional $75,000.

Betting on Project Risk Management

     Okay, I think you've got the risk-and-reward concept. But how does all this relate to project management? Have you ever worked on a project that failed because of lack of planning? Have you ever had a vendor promise to deliver the goods on time, only to be late and screw up your entire project? Have you ever managed a project that was dependent on another project—which was late, and you caught the heat?

     That's risk.

     When it comes to your role as a project manager, you must always—and I do mean always—be on the lookout for any risks that can cause the project to fail. And not just the project manager, but the whole project team.

     Risk identification is an iterative, active process. Risk identification doesn't live between launch and execution, but from project launch to project closure. The project manager must stress, must perform risk identification.

     But how exactly does this work? Glad you asked.

     Most organizations have some risk management procedures in play—even if they're not formally identified. A risk management methodology, in its purest form, has procedures for risk identification and classification, the organization's utility function, and the process for risk analysis.

     What?! Your company doesn't have this? Don't worry—I've worked with lots of organizations that don't. Let's take a look at how you can establish a risk management approach.

Ante Up for Risk Identification

     First we need risk identification. Initial risk identification may take place over lunch for smaller projects, or over a series of meetings for larger projects. The goal of risk identification is—no big surprise—to identify any potential risk. Stress the word any. Anything goes in risk identification: weather, asteroids, vendors, lack of experience, technical challenges, and so on. Technically, you'll encounter four precise categories of risk during risk identification:

• Technical, quality, or performance risks. These risks are things like working with new technology, unrealistic expectations from stakeholders, and technological advances during your project (think service packs, new versions, faster hardware).
• Organizational risks. These suck. Organizational risks are things like inconsistent goals; changing priorities on time, cost, and scope; team member allocation; and general work mayhem.
• External risks. These risks are anything outside of your project, such as vendors, new laws that affect your projects, labor issues (think labor unions), organizational buyouts, and market conditions.
• Project management risks. Yep, you may be a risk. Your inexperience, poor allocation of time and resources, lack of leadership, poor execution of project management processes: All may contribute to your project's failure. But if you acknowledge these risks before they actually happen, you can take measures to prevent the risks from affecting the project's success.

Fold 'Em, Check, or Raise: Risk Analysis

     Once you've identified your risks, it's time for qualitative risk analysis. Qualitative risk analysis qualifies the risks for in-depth analysis. Basically, you and the project team discuss the identified risks, the probabilities of those risks occurring, and their impact if the risks actually do occur.

     The most common approach to this process is to create a risk rating matrix. Here's a quick sample of a risk rating matrix using an ordinal scale:

     Within your project, you have to determine which of these risks deserve additional analysis. Typically you'd say the risks with a medium score or higher should be taken seriously and are promoted to quantitative risk analysis.
Quantitative risk analysis is fun, fun, fun! Not really. Quantitative risk analysis requires the project manager; the project team; and, in some cases, business analysts and subject matter experts to quantify the risk exposure. This can be accomplished in a bunch of different ways:

• Interviews with stakeholders. Discussing the risk with stakeholders can help you to capture the true risk impact.
• Prototypes. A prototype can test the project's deliverable before it goes into production. Obviously, this isn't always feasible with IT projects, construction, and other scenarios where there's no such thing as a pristine environment.
• Simulations. Simulations and experiments are ideal for "what if" scenarios. With scenarios, you can monkey around with conditions, delays, and sequencing of events to capture the true risk of conditions within your project.
• Expert judgment. Expert judgment is one of the best tools in project management. It means that the project manager is relying on someone with more experience to help make the best decision.
• Monte Carlo simulations. Monte Carlo, named after the world-famous city for games of chance (really, it is) allows the project manager to enter all of the different conditions into a computer program to see the most probable outcome of events.

     Quantitative risk analysis can also use a risk rating matrix, but it usually uses a cardinal scale rather than ordinal. A cardinal scale is simply hard numbers based on your analysis.

Build Your Bankroll: Contingency Reserve

     Now we need cash money. Cash money? Yes, cash money. Chances are very good that if these risk events happen, it'll cost the project something in the form of dollars. This is finding the contingency reserve.

     The contingency reserve is a pool of funds that will "cover" the costs of any risk events that do happen. To complete the matrix, you enter the risks in one column, and in contiguous columns enter the financial impact if the risk happens and the probability of the risk. Then you calculate the risk event value by multiplying the probability by the impact. The sum of the risk event values is the amount that should be added to your project budget—specifically for risk events.

     Here's a sample of calculating the contingency reserve:

Knowing When To Fold and When To Call

     While having some cash in the contingency reserve is great, you still need to take precautions to ensure that risk events don't actually happen. No one wants the project to fail because the project manager stuck his head in the sand.
Risk response planning centers on four risk responses:

• Avoidance. This is the most obvious risk response; you change your project plan to prevent the risk from occurring. While it's ideal, it's not always feasible.
• Transference. This technique lets you say with all honesty, "It's not my problem." Transference doesn't eliminate the risk, but transfers the ownership of the risk. The most accessible example is insurance: errors and omissions insurance, safety insurance, even weather insurance. Another example is when you hire an expert, such as an electrician, to complete that portion of the project to ensure that the work is done properly. A fee is usually associated with transference.
• Mitigation. Mitigation is anything that you do to reduce the impact of the probability of a risk event. This can be anything from changing the sequence of project activities to assigning different skilled workers to training the project team. It's anything you do to lower the overall risk probability or impact if it does happen.
• Acceptance. Some risks you just have to accept—travel delays, weather concerns, the nature of the project work—because there's very little you can do to change them. (Sorry.) Risk acceptance can also mean that the risk impact is so minimal that you just decide to accept the identified risk.

     Unfortunately, some of these responses may create two additional types of risks that you have to consider:

• Residual risks. These smaller risks remain after one of your risk responses. You may have to address these with another response, but the most common is just acceptance. For example, suppose you respond to a risk by outsourcing the server install to an integrator. Your risk response creates the new residual risk that the integrator may be slightly late or be difficult to work with.
• Secondary risks. Uh oh. Secondary risks are new risks created as a result of a risk response. This is the classic domino effect: By solving one problem, you create another; and when you solve the new problem you create another; and on and on it goes.

Pay the Dealer - and Pay Attention

     All of this business should be documented in a risk management plan. This plan defines the risk management approach, the qualitative/quantitative analysis, risk responses, the risk registry or database of risks, and scheduling for additional risk identification and planning.

     As the project moves toward completion, the project manager and the project team must monitor and control the risks within the project. No one wants a project to fail because no one wanted to discuss a newly identified risk.
Sometimes a sense of dread arises within the project team because the project manager hasn't stressed the importance of iterative risk identification. The dread is that the person who speaks up about the risk may fear retribution for bringing bad news to the table. We need to know about risks in order to respond to them.

Poker and Project Management

     Project risk management requires analysis of the risk and a determination whether the identified risk is worth accepting or requires a response. Of course, if we accept the risk, we want some type of return for our acceptance. Just as in poker, if we risk something, we expect something in return.
Poker, on the other hand, requires some luck, some skill, and a willingness to accept the risk. Mick, when you're ready to go again, I'll shuffle the cards and deal first. I'll be wearing my lucky T-shirt.