Taking a Risk

[article]
How to Make Risk Conversations More Effective
Summary:

Project managers may be reluctant, even unwilling, to discuss problems that testers discover in a project. In this week’s column, management expert Johanna Rothman gives tips on how best to tell management that "the sky is falling," and how to respond if they don't want to hear about potential problems before they occur.

On a recent project, Sally, the test manager, said to me, "How can I talk about risks with my project manager? He says I’m being overly negative and that all I’m talking about is bad news when I mention risks. Then he says I’m not being a team player. But at the end of the project, he blames us, the entire test group, for not finding and fixing all the problems. How can I win?"

Sally can’t win in her current organization. Not without changing something. Unfortunately, Sally’s project manager is part of what needs changing. And we’re all aware of how easy it is to change other people!

In More Secrets of Consulting, Jerry Weinberg says, "The ability to act on calm and correct assessments of risks and rewards is the first of human qualities because it is the quality that guarantees all others." Sally is exercising this human quality. Can Sally bring up risks in a way so that her boss can also exercise this quality?

Can we have a conversation about risks?
First, Sally needs more information. Why doesn’t Sally’s project manager want to discuss project risks? Here are some potential reasons:

  1. Other people in the organization react in an incongruous way to project risks. For example, Sally’s project manager might receive blame from his boss if the project’s risks were written down and managed, and still the project was late.
  2. Sally’s project manager is concerned that acknowledging risks of any kind will discourage people from working hard to complete the project.
  3. Sally’s project manager doesn’t know what to do about the risks and so pretends that they don’t exist.

Sally can take the bull by the horns and say, "Project Manager, I can see that a discussion about risks is not a conversation you want to have. However, I’m not sure how else to bring these problems to your attention. Do you want to know about potential problems?"

For the moment, let’s assume that your project manager does want to know about problems before they start. Now, Sally can ask her project manager how to have that conversation about risk.

How do we have that conversation?
Sally needs to talk with her manager about how to present risks. Here are some questions Sally can use to understand how her manager wants to learn about risk:

  1. "If I can, should I discuss a few solutions along with risks?" Many project managers are already overwhelmed with project problems. If you are helpful with three possible solutions, your project manager may be more likely to hear about your risks. Every problem has three potential solutions, even if the thought of at least one of them turns your stomach. For example, if you are concerned about a particular defect not being fixed in time, you can say, "I’m concerned about our ability to fix defect. We have these possible solutions: fix it, and schedule be damned; fix it in a branch, so that we contain our risk and can manage the testing; ship without fixing it. I prefer fixing it in a branch, but I’d like to know what you think." Of course, if you think shipping with this defect will cause significant corporate liability, then say so, but otherwise, shipping even with this insidious defect is a possible solution.
  2. "Do you want to hear about risks as early as possible, or do you want me to see if I can manage the potential problems? If you want me to handle things, when do you want to know about them? The first week we see them? The second? The third?" Sometimes, project managers want their technical staff to work on problems first. Only then, when the technical staff can’t solve the problems, do the PMs want to be involved.
  3. "Would you like us to create a parking lot of risks?" A parking lot is a list of risks that you can’t deal with now, but you don’t want to lose track of.
  4. "What kinds of consequences do you want to know about with risks? Are there some consequences you’re not as concerned about as others?" Risk evaluation is about consequences. Some consequences are more important than others, so understanding which consequences worry your PM is helpful.

The Pathological Case
If your project manager says that knowing about potential problems before they start is not important, you can try to elicit more information: "Oh, I’m surprised. Can you tell me more about that?"

Your project manager may not want to discuss this with you because you’re a tester. If your role is a problem, then your project manager doesn’t understand the role of testers. Explain that testers are the best risk identifiers the project manager has—that testers illuminate product and project risk with testing.

You have another alternative, especially if you want to stay in your current job. You can write the risks in a memorandum for the record. When risks become problems and the organization suffers, you can show that you acted responsibly on behalf of the organization.

If your project manager still can’t or won’t hear about risks from you, choose whether it’s time for a new project manager, or a new organization. Project managers and organizations that don’t actively manage risks don’t last long, but working on their projects can feel eternal.

Summing It Up
Conversations about risks tend to be difficult. You don’t want to be perceived as a "Chicken Little," but you also don’t want to ignore potential problems. Learn how your PM wants to discuss risks, and then help your PM learn about risks. And don’t be afraid to walk if your PM ignores risks.

Acknowledgements
I thank the following people for their helpful reviews and comments: Dwayne Phillips and Brian Lawrence.

About the author

AgileConnection is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.