2. Risk Management Is Project Management for Adults
,Team Leader: We’re having a meeting about this tomorrow, but I think it will get worse.
Project Manager: Don’t have the meeting.
This chapter of definitions pertinent to risk management begins with a definition (right in the title) of risk management itself: project management for adults.
This is not meant to be snide. (Okay, it’s meant to be a little snide, but there is also truth in it.) An almost-defining characteristic of adulthood is a willingness to confront the unpleasantness of life, from the niggling to the cataclysmic. A little child is excused from thinking about nuclear war, the rape of the environment, kidnapping, heartless exploitation, and rampant injustice. But as that child’s parent, you are obliged to keep such matters in your mind, at least enough to make sure that the child’s temporary ignorance of them doesn’t lead to tragedy. You have to face up to unpleasant realities. That’s what it means to be a grown-up.
Taking explicit note of bad things that can happen (risks) and planning for them accordingly is a mark of maturity. But that’s not the way we tend to use the word maturity in the IT industry. We software people tend to equate maturity with technical proficiency. We even have a five-level scheme for measuring such maturity, the Capability Maturity Model (CMM).1
1 All we need now is a twelve-step program to help us wean ourselves from measuring maturity in a five-level scheme.
But the word maturity in standard English has nothing to do with technical proficiency. It is, rather, a quality of grown-up-ness, an indication that a person or organism has reached its adult state.
In retrospect, when we as project managers did not explicitly manage our risks, we were being childlike. Our whole industry has been childlike in this respect. Our infatuation with positive thinking and a can-do attitude has fixated us on the best outcomes as we ignored the various realities that could make such outcomes impossible. (See in particular the case study in Chapter 3 for an example of this.)
Considering only the rosy scenario and building it into the project plan is real kid stuff. Yet we do that all the time. While we’ve been doing these immature things, we’ve been positively trumpeting our increased “maturity” due to improvements in our technical proficiency.
What’s needed now is maturity in the other, more traditional, sense. We need to grow up, take explicit note of our risks, and plan accordingly. That’s what risk management is all about.
But all of this has put the cart slightly before the horse, defining risk management without first defining the component word, risk. So, what is a risk?
Risk: The Temporary Definition
Our concept of risk in software projects is derived from watching numbers of such projects go awry. Much of our consulting work these days is supporting litigation, the aftermath of projects that came a cropper. This has helped us compile an extensive set of data points about failure. The risks of those failed projects, in retrospect, were the factors that led to the undesirable outcomes. So, too, for future projects: Their risks are the things that might lead to an undesirable outcome. That leads us to the following temporary definition of risk:
risk n 1: a possible future event that will lead to an undesirable outcome 2: the undesirable outcome itself
The first of these is the cause and the second is the effect. Both are important, but don’t gull yourself into thinking that you can manage both. The business of risk management is all about managing the causal risks. Those are the ones you can manage. (The justification for risk management in the first place, however, is all about the outcomes.)
Our definition is a temporary one because it assumes a binary character to each risk, treating it as something that can either happen or not. There are, of course, many risks that don’t work this way; they occur partially and have a proportional adverse effect on the project. To take account of these nonbinary risks, we shall have to revisit this definition in a later chapter. For now, though, the temporary definition will serve us well.
Risks and Problems
As an alternative, consider the following circular definition of risk: A risk is a problem that has yet to occur, and a problem is a risk that has already materialized.
Before it happens, a risk is just an abstraction. It’s something that may affect your project, but it also may not. There is a possibility that ignoring it will not come back to bite you. Even so, you’re not innocent of management malpractice for not having considered the risk. In William Clifford’s words, you’re just—“not found out.”
Risk management is the process of thinking out corrective actions before a problem occurs, while it’s still an abstraction. The opposite of risk management is crisis management, trying to figure out what to do about the problem after it happens.
Risk Transitions and Transition Indicators
Imagine the moment when something that used to be a risk suddenly becomes a problem. It used to be an abstraction, a mere possibility, and now it is not abstract at all. It has happened. This is the point at which the risk is said to materialize. It is the moment of risk transition.
Transition is a key concept for the risk manager—it is the triggering event for whatever is planned to deal with the risk. Well, almost. The actual transition may be invisible to you (for example, Saddam Hussein decides to invade Kuwait). What you do see is a transition indicator (the massing of troops at the border). For every risk you need to manage, there is some kind of transition indicator. Some indicators are more useful than others, though. More about that in a moment.
Mitigation
The reason you care about the transition is that when the indicator fires, you intend to take some action. Before the transition, it’s too early to take the action—it may be expensive and time-consuming—so you are justified in hoping that it won’t be necessary. However, while you may be able to defer some of the corrective action, other parts may not be deferrable. There may be some steps you have to take before the transition, in order to keep your options open and to make correction possible afterward. That work is called mitigation.
Consider an example of mitigation from a domain outside our own: the U.S. court system. Realizing that a juror might become sick, drop out, die, or become otherwise unfit to continue, the courts appoint a number of alternate jurors to each jury case. If the original slate is able to finish, the alternates have no role; if a spare juror is required, however, an alternate—fully versed in the proceeding by virtue of having been present throughout—steps in and completes the requirement for a full jury. The risk here is the loss of a juror, leading to an aborted case, a retrial, and all the attendant expense and delay. The mitigating action is to carry one or more alternate jurors from day one. If and when the risk materializes, it can be contained at minimal cost.
The IT project analog to loss of a juror is personnel turnover, one of the core risks on all software projects. And the counterpart to appointment of alternate jurors would be to overstaff slightly from the beginning, with the fully qualified extra hands temporarily filling apprentice and support roles. When turnover occurs, the manager doesn’t have to hire new staff. One of the extras can move up from the apprentice role to assume the duties of the person departing, with minimal time lost to ramp-up.
Mitigation costs both time and money. Yet in the rosiest of rosy scenarios, that expenditure of time and money turns out to have been unnecessary. We’ll come back to this point, because it leads to a kind of pathology that can make risk management virtually impossible.
Example: Risk Management in a School
For some exercise in the use of all of these newly defined terms, imagine yourself practicing risk management in a school. Suppose that you are principal of the operation, a glitzy private boarding school for boys and girls in grades 5 through 8.
Since you are a professional in your field, you are well aware that there are certain awful things (risks) that might happen to the children left in your care. You don’t just think about these matters from time to time; they are on your mind constantly. After all, these are other people’s children you’re looking out for, and you can’t take that responsibility lightly.
Some of the bad things that might happen can be safely handled by you and your staff with nothing more than a little quick thinking at the moment of transition. For example, there is no need to have an elaborate plan in place for how to deal with a pillow fight. Any teacher worth his or her salt will figure out how to handle that one and act accordingly.
But, you realize, there is a class of graver risks that require you to have done at least some serious planning in advance. Fire in one of the dorms, for example, is such a risk. You would be disgraced should it be proved after a fire that you hadn’t done certain homework before the fire broke out. The homework (mitigation) needed before the event includes the placement of fire extinguishers, the installation of alarms, fire drills, an investment in sprinklers, and so forth.
The actual occurrence (transition) of this particular risk will probably be invisible to you when it happens, so you have to put in place and monitor some kind of mechanism (transition indicator) to spot it when it begins. You have a choice of several mechanisms. You might just ask the janitor to take a moment every few hours to poke about the facility looking for smoke or flame. Or you might install smoke alarms. In making your choice, you decide that you should try for the earliest practical indicator of the transition, so the smoke alarm is clearly preferable.
Realizing that fire is only one of the risks requiring advance homework, you call together your teachers and staff and pose the problem to them. You suggest, Let’s have an exploratory session (a risk-discovery brainstorm), and make up a definitive list (a risk census) of all the risks for which advance preparation is needed.
“What are the risks requiring advance preparation?” you ask them. They call out such things as fire, sports injury, food-poisoning, sexual abuse by a teacher or staff member or outside stranger, sexual experimentation by students, drugs, guns, depression leading to suicide, attacks on teachers or children, and so on.
Included among the suggestions are some that aren’t worth managing (“meteor hits school and blows it to smithereens with loss of all staff and students”). There are others for which the extent of your responsibility is not so obvious. For example, “some aspect of a science lesson shakes a student’s religious faith.” Is this a risk you need to manage? You note it down and press on with the brainstorm. Afterward, you’re going to have to go back over the list and do some further work on the risks (risk analysis). You’ll have to decide which ones to manage and which ones not (risk triage). For those you elect to manage, you will need, at the very least, to figure out your best trigger (transition indicator), plan your pretransition actions (mitigation), and assess the relative importance of the risk (exposure analysis).
When the brainstorm bogs down, that doesn’t mean you’re done. You will want to put some kind of persistent mechanism in place (an ongoing risk-discovery process) to pick up new risks that require management. You may want to appoint one person to be especially responsible for this (a risk officer).
Component Activities of Risk Management
Abstracting backward from this single example, we see five main activities that make up the practice of risk management:
• risk discovery: your initial risk brainstorm and subsequent triage, plus whatever mechanism you put in place to keep the process going
• exposure analysis: quantification of each risk in terms of its probability of materializing and its potential impact
• contingency planning: what you expect to do if and when the risk materializes
• mitigation: steps that must be taken before transition in order to make the planned contingency actions possible and effective when required
• ongoing transition monitoring: tracking of managed risks, looking for materialization
The first of these is an overall activity, while all the others are done on a per-risk basis.
Once More Over the Same Ground
Risk management is something that most of us practice all the time—everywhere except the office. In our personal lives, we face up to such risks as sickness and early death. We mitigate by buying life and health insurance and by making arrangements for who will look out for the kids if something bad happens. We don’t pretend to be immortal or that our earning capacity can never be harmed by bad luck. Each time we take on a new responsibility—say, a mortgage—we go over all the awful things that we hope won’t happen and force ourselves to think, What if they do?
Risk management is not rocket science. But as we’ll see, practicing it in the office involves a few special challenges.
The Special Challenge of Unthinkable Risk
Some of the risks confronting a project may be fatal. By this, we mean fatal to the hopes and aspirations of those who engendered the project in the first place. These risks are the most essential to manage, but managing them sensibly may bring you into conflict with established cultural norms. Your project may have been placed on a fixed schedule by the CEO’s public announcement—carried in all the press—that the product would be delivered on a certain date. By going very public with the date, the CEO has attempted to make schedule slip unthinkable.
Declaring an unwanted outcome unthinkable does not make it impossible, as we all know. But it may make risk management nearly impossible. Consider the example in the very next chapter. . . .