Risk Management Is Project Management for Adults
Read Waltzing with Bears: Managing Risk on Software Projects and more than 24,000 other books and videos on Safari Books Online. Start a free trial today.
This chapter is from the book
This chapter is from the book
This chapter is from the book
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
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.