Software Risk Management Software Risk Management

. guest editors’ introduction Software Risk Management Barry W. Boehm, University of Southern California Tom DeMarco, The Atlantic Systems Guild n mature engineering disciplines, risk management has been de rigeur for centuries. When Michelangelo set out to raise the dome of St. Peters in 1547, he was well aware of the potential collapse zones under the staging, the possibility of materials failure, and the human capacity for error. For each of these major risks he prepared a mitigation plan: a fallback, a safety factor, or an alternative. Today, we routinely practice risk management in our stewardship of the environment, in planning financial strategy, in construction engineering, and in medicine. But how do we apply it to the ultimate risky busi- ness, software development? IEEE SOFTWARE I 0740-7459/97/$10.00 © 1997 IEEE 17 . guest editors’ introduction RISK VS. “CAN-DO” FOCUS ON ESSENTIALS these strategies can make an organization not only more competitive in a high- Software development’s risky nature The key concepts of risk management turnover marketplace, but also a more is easy enough to acknowledge in the ab- can help software managers assess prob- satisfying place to work. stract, but sadly, harder to acknowledge lem situations and formulate proactive in real-world situations. Our culture has solutions. A good example is the key risk evolved such that owning up to risks is management concept of risk exposure. RISK MANAGEMENT’S DIRTY often confused with defeatism. Thus, a For each source of problems causing a LITTLE SECRET manager faced with a nearly impossible potential loss to the project, the exposure schedule may deliberately ignore risks to is defined as the product of the probabil- Software managers would be more in- project a confident, “can-do” attitude. ity of the potential loss, Prob(Loss), mul- clined to acknowledge and manage their Or is that assessment too severe? After tiplied by the size of the loss, Size(Loss): risks if they were more aware of compa- all, you wouldn’t ignore risks on your pro- rable organizations that had already cho- ject. Or would you? To understand how Risk Exposure = Prob(Loss) × Size(Loss). sen to move in that direction. Although risks get ignored, we must look beyond there is evidence that software risk man- the kinds of risk that are subject to easy, A recent gathering of Indian software agement is beginning to affect many obvious mitigation, such as: “If we don’t managers revealed that they perceived companies and government agencies, add two folks to the test team right away, personnel turnover as their biggest published word of that experience re- we are never going to complete accep- source of risk. Huge demand for experi- mains minimal. There is a reason why tance testing in time for a June 1 deliv- enced software people—as in the US and this has been and will probably continue ery.” Any manager capable of staying elsewhere—confronted the typical soft- to be true: Doing software risk manage- awake during the work day will leap at ware project manager in India with the ment makes good sense, but talking solving this one; ignoring it means miss- likely departure of one or more key peo- about it can expose you to legal liabili- ing a chance to take early and efficient ple, which would potentially result in a ties. If a software product fails, the exis- corrective action. substantial and costly disruption of the tence of a formal risk plan that acknowl- Fatal risks, on the other hand, offer project’s schedule. edges the possibility of such a failure an entirely different challenge. These The notion of risk exposure helped could complicate and even compromise risks are either beyond effective mitiga- focus these managers on reducing both the producer’s legal position. There is tion or unacceptably costly to mitigate. Prob(Loss) and Size(Loss). Prob(Loss) reason to suspect that most risk manage- An example of fatal risk is: “We can now can be reduced by assessing, addressing, ment practitioners have adopted a “don’t see that the June 1 estimate was hope- and monitoring the annual turnover rate. ask, don’t tell” attitude toward publica- Good strategies for this include empow- tion of their successes. Our culture has ering performers, teambuilding, estab- Given this tendency, we feel particu- lishing significant incentive bonuses for larly lucky to have a lively “Point/ evolved such that successful project completion, recogniz- Counterpoint” and eight fine articles on ing outstanding efforts, and structuring risk management in this issue. A ninth owning up to risks career paths around an organization’s risk management article appears in the is often confused product lines. May issue of our sister publication, Size(Loss) can be reduced signifi- Computer. Together, these 10 pieces es- with defeatism. cantly too. Software inspections not only tablish a coherent baseline for how risk find defects, they also spread information management is and should be practiced lessly flawed; we have no chance of mak- on the software product’s components in software organizations. ing that date, we never had a chance of across the organization, as do other ap- making it, and most actions we might proaches such as egoless programming now take (such as adding more people) and Cleanroom techniques. Modular THE ARTICLES can only lengthen the time it will take us software architectures and encapsulation to eventually deliver the product.” Fatal confine the effects of personnel turnover If you are new to risk management risks are often ignored by the can-do to small parts of the system. Software de- and wondering if you should get involved manager. An attitude that would be ob- velopment files and good configuration with it—or at least feel guilty about not viously stupid in the presence of small management make it easier for new re- yet being involved—start by reading Tim risks is somehow considered less stupid placements to master existing software Lister’s “Point,” which maintains that for large ones. modules. In combination, a focus on risk management is project management 18 MAY/JUNE 1997 . for adults. Next, look into Marvin Carr’s Institute’s Ray C. Williams, Julie A. used in this way include risk-focused pro- cautionary “Counterpoint,” which as- Walker, and Audrey J. Dorofee use an totyping, specifying, testing, formal veri- serts that risk management can itself be SEI-designed road map as a guide to dis- fication and validation, configuration risky, particularly if it’s not done on an cussing effective and ineffective risk man- management, and quality assurance. institutional basis. agement methods in software-intensive The promising benefits of risk man- Moving on to the theme articles, Department of Defense programs. agement are evident in the articles “The RAMP Architecture for Assessing Finally, in “Implementing Risk Manage- we’ve gathered here. We hope they’ll and Managing Risk” by Paul Garvey, ment” Edmund Conrow and Patty inspire you to think of how you your- Douglas Phair, and John Wilson de- Shishido provide experience-based risk self might contribute to further pro- scribes a Web-based risk management management guidelines from a highly gress in this area. ◆ information system used to capture and apply corporate experience in risk man- Carr says risk agement across a wide variety of projects. Tony Moynihan’s “How Experienced management itself Project Managers Assess Risk” summa- Barry W. Boehm is the rizes how several managers in medium- can be risky. TRW Professor of sized commercial projects assess the risk Software Engineering and Director of the Center for implications of a project’s situational fac- successful distributed command-and- Software Engineering at tors. (He also provides an intriguing par- control project that uses several innova- the University of Southern tial confirmation of the SEI’s risk taxon- tive risk management practices. And in California. His current omy.) Robert Charette, Kevin Adams, the May issue of Computer, Art research involves the and Mary White explore the application Gemmer’s “Risk Management: Moving WinWin groupware system for software require- of risk management techniques to the Beyond Process” examines how one or- ments negotiation, archi- world of legacy software in “Managing ganization approached risk management tecture-based models of software quality attributes, Risk in Software Maintenance.” from the perspective of functional be- and the Cocomo 2.0 cost-estimation model. Three articles address the interaction havior, specifically “how to communicate Boehm received a BA in mathematics from Harvard University and an MS and a PhD in math- of risk management with cost and sched- risk more effectively.” ematics from the University of California, Los ule estimation. Raymond Madachy’s Angeles. He is a fellow of the IEEE and the AIAA, “Heuristic Risk Assessment Using Cost and a member of the National Academy of Factors” describes an operational expert- s reported in this special issue, soft- Engineering. system tool that analyzes patterns of cost- A ware risk management is quickly driver ratings submitted for a Cocomo becoming a mature discipline. To cost estimate to determine and rank as- achieve the promise of fully effective soft- sociated sources of project risk. Kari ware risk management, the software in- Känsälä’s “Integrating Risk Assessment dustry still must address several contin- Tom DeMarco is a princi- pal of The Atlantic with Cost Estimation” describes the uing challenges. Systems Guild. He is au- checklist-based RiskMethod and corre- ♦ Achieve commitment of all key thor of Why Does Software sponding RiskTool used to generate stakeholders (developers, customers, Cost So Much? (Dorset both cost and risk estimates, which have users, maintainers, and others) to a risk House, 1995), an editor of Software State of the Art been used successfully in several Finnish management approach.

Load more