Have you ever had a challenging time trying to get a manager or coworker to recognize a potentially project-stalling issue? Risk is inherent when creating something valuable and complex (like software), but sometimes it's hard to analyze and explain in a productive way. Here Johanna Rothman shares her method for addressing risks.
Setting: Our tester, Tim, is verifying load performance of a server. He has been waiting for his chance to use the server to run his tests. While he's waiting for the developers to finish, he realizes that if the server dies, he can't verify the load performance of the application. Tim makes a beeline for Pam the project manager's office.
Tim: "Hey, did you know this server is critical to our ability to load test?"
Pam: "Hmm, no, I didn't realize that." (Pam goes back to reviewing the schedule.)
Tim: "Well, I want to get another one, okay?"
Pam: "What?! No, you can't have another server. If you get another server, other people will want more servers, and then our budget will be shot."
Tim: "But if we don't have the server at all, I won't be able to test."
Pam: "Hmm, then our bug counts will go down. That's not bad."
(Tim glares at Pam.)
Pam: "Okay, then it's your job to tell me how likely the equipment is to break and how much it will cost to fix."
Ever had a conversation like this with a project manager? I hope not. But if you had, you probably walked away furious and disgusted. You knew that the project manager really didn't care what your answer was. However, you know that you somehow have to bring this information to the project manager's attention, so that she can take a more responsible approach to managing the potential issue.
Potential issues are risks. Formal risk analysis is what happens when you consider the likelihood that a potential issue will occur, and take into account the severity of it happening, giving you the exposure. Then you create a mitigation plan to deal with the problem. Testing is one form of risk mitigation, by looking for defects before the customers find them. But that's not the only form of risk mitigation you're likely to need.
Sometimes mapping out the risk can be helpful. I use a table like this one to explain risks:
|
Risk |
Probability of occurrence |
Risk severity |
Exposure |
Trigger date |
Mitigation plan |
|
Define this in words |
How likely is this risk to occur? Use high, |
How severe a problem is this risk if it occurs? Use |
Multiply probability and severity together, to derive a joint value |
The date by which you will set the mitigation plan in place |
What are you going to do about this risk? |
|
Load server may not be available in time to test |
High (it was in use by other groups for the last release) |
High (we can't test performance under load without the |
(High, High ) |
2/1 |
Buy a new server, install it by 2/15, up and running by 3/1, in time |
First, I define the risk in words people can understand. Here, we're talking about a particular server's availability. Then, I define the probability that this problem could occur. If you have historical information, use it. If you don't have any previous knowledge, then guess. In my example, we know that in the previous release, other groups also needed to use the load server.
Then, define the severity of the risk. How bad a problem is this, if it
occurs? In this case, the potential problem is very bad, assuming we need to test the product under load. Once you've defined the probability and severity, you can multiply them together. Some people use numbers to quantify risk, so they can easily multiply and get a number. I find that having managers see ( High, High
About the author
Johanna Rothman, known as the “Pragmatic Manager,” helps organizational leaders see problems and risks in their product development. She helps them recognize potential “gotchas,” seize opportunities, and remove impediments. Johanna was the Agile 2009 conference chair. She is the technical editor for Agile Connection and the author of these books:
- Manage Your Job Search
- Hiring Geeks That Fit
- Manage Your Project Portfolio: Increase Your Capacity and Finish More Projects
- The 2008 Jolt Productivity award-winning Manage It! Your Guide to Modern, Pragmatic Project Management
- Behind Closed Doors: Secrets of Great Management
- Hiring the Best Knowledge Workers, Techies & Nerds: The Secrets and Science of Hiring Technical People
Johanna is working on a book about agile program management. She writes columns for Stickyminds.com and projectmanagementcom and blogs on her website, jrothman.com, as well on createadaptablelife.com.
