Risk Management and QA for the Lone Wolf, Page 2
Now that you know what to worry about, can you do anything besides chew your fingernails? Fortunately, the answer to that question is "yes." This is where risk control comes in.
There really isn't any magic to risk control. Basically, it's just a method for systematically thinking about how you'll deal with risks. Notice that I didn't say "react to risks." The idea of risk control is to avoid being in emergency mode, reacting to risks when they pop up as though you're in a giant game of Whack-A-Mole. By thinking things through in advance, you can deal with risks in a more optimized fashion.
- Can you take steps to make sure that the risk never materializes?
- Can you take steps to lower the probability of the risk?
- Can you take steps to lower the cost of the risk if it does materialize?
- Can you take steps to speed recovery from the risk if it does materialize?
For example, if one of your top risks is that a particular control vendor, whose product you're using in beta, won't deliver a shipping version in time for you to meet your deadline, what can you do? You can't eliminate the risk entirely, or lower its probability. But you can lower the cost and speed recovery by writing your code in a manner that makes it easy to swap in an alternate control from another vendor, and by having an alternate vendor in mind. If you've planned from the start of the project to control this risk, you can execute your risk management steps quickly if, late in the game, you determine that the original control won't be available when you need it.
Living With Risk
After you've done your risk assessment and developed your risk management plan, don't forget about it. As you move forward through a development project and gather additional information, risks change. You might implement a tricky section of code (removing it from the risks list), or run into a serious bug during your testing (raising the spectre of a new risk). I recommend weekly reviews of your risk management plan at a regular time in your schedule. For me, mid-day Monday, after I've dealt with the glut of weekend e-mail, works well. Looking over project risks and thinking about whether there have been any changes serves as a good transition from paperwork to coding.
If you can keep the quality of your code high and the other risks to the project under control, you have a much better chance of delivering working software than the average developer using a random, chaotic process. None of this requires you to implement heavy amounts of paperwork or spend a huge chunk of your day doing things other than coding. Instead, you just need to apply the same discipline you use in writing code to thinking about the issues surrounding your code. If you try it, you'll be glad you did.
About the Author
Mike Gunderloy is the author of over 20 books and numerous articles on development topics, and the Senior Technology Partner for Adaptive Strategy, a Washington State consulting firm. When he's not writing code, Mike putters in the garden on his farm in eastern Washington state.
Page 2 of 2