TrainingConferencesAbout UsContact UsAdvertiseSQE.comRSS Feed

StickyMinds.com: brain food for building better software

Log In
 Clarify Your Search Criteria

Tips on Using Our Search Feature(s)
 
StickyMinds.com Home
ResourcesTopicsCommunityPowerPassBlogs
Home  >  Detail: Taking a Risk


A StickyMinds.com Original
Article Picture
Taking a Risk
How to Make Risk Conversations More Effective

By Johanna Rothman

Send This Content to a FriendGet a Short Link to This ContentPrint This ContentSee User Comments About This Content

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.


Ranorex
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 <x> 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
Johanna Rothman observes and consults on managing high-technology product development, looking for the leverage points that will make her clients more successful. Johanna was the Conference Chair for the Software Management (SM) Conference in February, where she conducted a management-improv tutorial and participated in a panel discussion of mentoring and manager making. She recently co-moderated a RoundTable discussion “Making the Transition to Management” with Esther Derby. You can reach Johanna at jr@jrothman.com or by visiting www.jrothman.com. For more information about analyzing job candidates, you can refer to Johanna’s upcoming book Hiring Technical People.

Back to Top
 

StickyMinds.com Weekly Column From 5/27/02 

Member Comments
Add Your CommentExpand Comments
 
Comment:    
by royston almeida 11/7/2004

Hi johanna, well i read your article and it was really nice, well i just came across this saying in a company that, "we want people to take risks. we dont want them to make mistakes but we want them to take risks". well i understood what it was trying to say but i still cant get a clear picture on that. can you please elaborate. Thanks

Author's Response:
4/8/2005    
Royston, if people aren't supposed to make mistakes, they can't take risks. I'm not sure what the company is trying to do, but they are certainly not taking risks, not if I understand what you're saying.

 
 
Comment:    
by Kelly Keene 6/5/2002

Great Article. I sent it to my entire team. I think we have a good process for dealing with the risk that are raised, but that some people are not comfortable raising them. Already people have said that this would help them talk to their PM about project risks. Anything to make the tester's job easier. I also use the cross-functional approach to assessing a risk and developing a plan and have found that everyone is happier when they have had their say. Definately cuts down on the post-implementation blame game. Thanks!

Author's Response:
4/8/2005    
Kelly, thank you!

 
 
Comment:    
by Kevin Krabbenhoft 5/31/2002

It was like 1 year of free therapy after reading this article. It was very reassuring to hear that other people out there feel the same way inside about the difficulties in relaying "vital information" to their product managers. It never occurred to me that other testers out there were experiencing the same hurdles and frustrations when trying to relay their finds and concerns to their Product Managers.

Author's Response:
6/3/2002    
Kevin, I'm glad you found this article helpful. I find that although each of our work experiences and environments is unique, the people-parts of our jobs are surprisingly similar. Let me know what happens, if you try one of these ideas.

 
 
Comment:    
by Jan Scott 5/28/2002

As a project manager, I've found that testers often have good insight into risks but do not really understand how to evaluate them. On any project and especially on a large one, there are many, many risks. It is usually impossible to deal with all of them. Testers are especially valuable if they can understand the business implications of the bugs they are finding; then it is possible evaluate the consequences of not fixing these bugs. On my last project, we had a bug report that not only described each bug, but also listed the business implication of not fixing it. We were then able to get the users (this was software developed for...Read On

Author's Response:
5/29/2002    
Jan, aside from the impossiblity of dealing with all the risks, there are risks that are not worth your time considering how to manage them. It sounds as if you've thought through the implications of open defects when you manage projects. I generally use a cross-functional team to evaluate each individual defect during periodic meetings (more frequently towards the end of the release). You're right, sometimes the testers don't know the business implications of each defect, but few people understand all the implications, which is why I try to use a cross-functional team. I have also found that I have to watch out for each stakeholder's interest in this meeting. Otherwise, we end up with defect promotion/demotion ("It's a 1." "No, it's a 2."). As long as we stay focused on the customer, and the customer or business implication, we're ok.

 
 
Comment:    
by John Loney 5/28/2002

A nice article, which sums up the 'tester's dilemma' - to be the bearer of (documented) bad news. My suggestion - to state as an entry criteria to the testing phase - project risk management! I propound that any project manager who does not embrace risk management and alleviation, is not a true project manager! John Loney an ancient tester............

Author's Response:
5/28/2002    
John, you're in good company. Tim Lister says that risk management is project management for grown-ups. (And you don't have to be ancient to agree with Tim :-)

 
 
Comment:    
by Daniel Dresner 5/28/2002

Another excellent article from Johanna. Those of use involved in risk management (that is everyone) should have a personal policy of being known to praise and be positive because, like the bad hair cut, everyone remembers something that went wrong over and above a success (it's what sells newspapers). It's often a good idea to make it clear to people that this is your approach so that when you do announce the humdinger you can gently remind them that you don't sit around waiting for the 'woe and thrice woe' opportunity. It's hard; many managers (and this is up to board level) seem to have a genuine mental block over negative comments. If...Read On

Author's Response:
5/28/2002    
Daniel, thank you for your compliment, and good catch on saying something positive. I remember to do this when reviewing an author's work product, but I find that harder to do sometimes at the project level. There's a fifth possibility: "Hey PM, you handled the potential problem of blah-blah so well, I thought you'd like a heads-up for this potential problem." I'm concerned when I say things like that to make sure I sound genuine, otherwise, it sounds as if I'm brown-nosing the PM, or I'm sarcastic. BTW, you mean "cock-up" as a blunder or error, yes? In the USA, we might use FUBAR instead of cock-up. For those of you interested in how I got to this meaning, see http://www.quinion.com/words/index.htm for the different ways English words are used.

 
 
Comment:    
by Erik Petersen 5/27/2002

A test mgr should at least be able to have a weekly report and mention outstanding risks in that, and just send it the the project mgr, For Your Information. You could also suggest either having a one-on-one meeting at a set time, or incorporating it in a team meeting. Alternatively, lobby for a project risk register that every one can contribute to, but that would need a owner. The best project mgrs I have worked for have expected me to almost be a spy, collecting any piece of intelligence I could about possible upcoming risks. This is very important, expecially in multi-stakeholder, multi-company situations.

Author's Response:
5/28/2002    
Erik, I like the idea of spying on the project. The spying model acknowledges the testers' skepticism, and helps the rest of the project team understand the value the testers bring. As you said, even more important in multi-stakeholder situations.

 
 
Comment:    
by Gerold Keefer 5/27/2002

one advice from the "male corner": if risks are quantitatively identified with a structured risk management process, the likelihood that management will open its ears is increased from the situation where somebody just says "i feel that this might become a problem." are feelings important in a project? yes, definetly. are they a good basis for communication? hardly.

Author's Response:
5/28/2002    
Gerold, I agree with you that using a quantitatively structured risk identification and management process is A Good Thing. (I hope you read my previous column about risk identification.) However, there are times when all you have is your gut perception that something is wrong, and a difficult PM. If you have a way to discuss your perceived problems with your PM, you may end up with a better project. I tend to use the parking lot technique for the "gut" problems. That way, I can identify them, say something like: "I just have a bad feeling about this, but I don't know more yet", and I'm not bugging the whole project. I once used the parking lot technique on a project where we were working on a performance upgrade for the software. I couldn't specify why I thought our server was too slow for testing, but I put the potential risk on the parking lot list. The entire project team laughed at me at first, and after the developers performed their initial testing, one sheepishly came to me and said, "Um, you were right. We don't have enough processors to run this specific test, the test we need to run for our largest customer. You couldn't have known, because we didn't tell you how we rearchitected the product, but I guess you knew something." So for me, and for the project, listening to my gut and listing the potential problem without demanding a solution was helpful. You mentioned you were from the "male corner". If you and anyone else sees an gender focus to my writing, I'd appreciate hearing about it. BTW, I don't think of intuition as a particularly male or female thing, since I know people of both genders who are highly intuitive :-) Maybe we should have an open forum about this sometime!

 
Back to Top



 
Ads By Google
What's This?
 
 



Home   |   Resources   |   Topics   |   Community   |   PowerPass



© 2010 StickyMinds.com. All rights reserved.
StickyMinds.com is a division of Software Quality Engineering.
Privacy Policy    Terms & Conditions    Link to StickyMinds.com    Feedback


Avnet

HP Software




STAREAST 


Better Software Conference