• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Risk Management During Requirements
 

Risk Management During Requirements

on

  • 755 views

 

Statistics

Views

Total Views
755
Views on SlideShare
755
Embed Views
0

Actions

Likes
0
Downloads
23
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Risk Management During Requirements Risk Management During Requirements Document Transcript

    • Editor: Suzanne Robertson requirements ■ The Atlantic Systems Guild ■ suzanne@systemsguild.com Copyright © 2003 IEEE. Reprinted from IEEE Software, vol. 20, no. 5, Sept./Oct, 2003. This material is posted here with permission of the IEEE. Such permission of the IEEE does not in any way imply IEEE endorsement of any mentioned products or services. Internal or personal use of this material is permitted. However, permission to reprint/republish this material for advertising or promotional pur- poses or for creating new collective works for resale or redistribution must be obtained from the IEEE by sending a blank email message to pubs-permissions@ieee.org. Risk Management during Requirements Tom DeMarco and Tim Lister We have heard a lot about the risk of not writing requirements, but little about how to profit from making risk management integral to the requirements process. Tom DeMarco and Tim Lister redress that imbalance by explaining the role that requirements must play in honest risk management. —Suzanne Robertson R isk management is project manage- ■ Intrinsic schedule flaw: estimates that are ment for adults. This means the man- wrong (undoable) from day one, often based ager adopts an adult attitude toward on nothing more than wishful thinking things that might go wrong during the ■ Specification breakdown: failure to achieve project, a marked difference from the stakeholder consensus on what to build prevailing can-do attitude. The risk ■ Scope creep: additional requirements that manager is obliged to do some can’t-do think- inflate the initially accepted set ing, to look problems—even potentially un- ■ Personnel loss: project members who leave solvable ones—directly in the eye and ac- before the project is done ■ Productivity variation: difference between assumed and actual performance All five of these touch on the requirements process, but the first two are deeply rooted there. The third sometimes indicates naturally occurring change, but in other cases is a direct indictment of how requirements were gath- ered in the first place. In other words, the so- called creep is not really change at all, but the correction of requirements that were misiden- tified to begin with. We focus on the first two core risks and dis- knowledge that they could come to pass. The cuss risk management as part of the require- risk-aware project manager will accept a lucky ments process. break if it should happen but refuses to include it in the plan. The schedule “requirement” At the heart of risk management is a public, A schedule flaw can result from an honest continuing process of risk identification. Some mistake in sizing and projection. We estimate this risks that will threaten your project are utterly to be true of approximately one project per mil- unique to your situation. But others are not. lion. In all the others, something else is going on. Over some 10 years of conducting risk identi- That something is most often a de facto elevation fication exercises in organizations, we have of a fervent desire (“Wouldn’t it be nice if the found five risks that are so ubiquitous that project were done by year-end?”) to requirement we’ve dubbed them core risks: status. The elevation often goes one step further, 0740-7459/03/$17.00 © 2003 IEEE Published by the IEEE Computer Society IEEE SOFTWARE 99
    • REQUIREMENTS DEPT TITLE R368 delivered as part of Version 10 them only until 1 November.” R433 delivered as part of Version 13 R299 delivered as part of Version 8 100% When rank-order prioritization be- comes the accepted way to establish each requirement’s importance, there is little Probability danger of overconstraining the project. 50% Treating schedule as one of n priority- ranked requirements lessens the possibil- ity of intrinsic schedule flaw. It also side- 0% steps the tendency to use schedule as a de Versions: V13 V12 V11 V10 V9 V8 V7 V6 facto cost reduction tactic. This ap- proach alone won’t make schedule flaws Figure 1. Risk diagram for a project with a fixed delivery date. disappear, but it should help reduce their incidence to those that are honest sizing to nonnegotiable demand. When all or ally, a few lower-ranked requirements and projection errors. many of the other requirements are simi- might be incorporated into a given ver- larly nonnegotiable, the project becomes sion for convenience. Failure to concur overconstrained. An overconstrained set In the past, IT projects were most of- of nonnegotiable demands—surprise, Vive la différence ten tasked to satisfy a single user’s re- surprise—ends negotiation. When no When all parties agree to discuss suc- quirements. They were relatively easy, trade-offs are possible, when it’s not even cess in probabilistic terms, they implic- but sadly we finished all such projects permissible to discuss them, the project itly understand that no delivery proba- years ago. Today a new IT project is team is reduced to a single tactic: lying. bility in the real world ever equals 1.0. likely to affect several different stake- This forces all participants to confront holders from different parts of the orga- How can risk management help? risk. They might question how much nization, in different locations, with dif- Risk management deals with this risk there is, but never whether there is ferent interests, and little or no common situation in two ways: risk. Rank-order prioritization ensures stake. Perhaps the biggest core risk is that that, however the project performs, the these stakeholders will fail to concur on ■ It imposes a rank-ordering of all re- highest-priority requirements have the project goals. Our data leads us to expect quirements (no two can have the highest likelihood of being delivered. this to happen to a disruptive extent on same rank). Additionally, this approach helps approximately one project out of seven. ■ It expresses all outcomes in proba- flush out some of the pathologies that Failure to achieve total concurrence bilistic terms. we all know happen when schedules would be no more than an annoyance if are treated as absolute requirements. all could agree to disagree. We would Now, if schedule is indeed the highest- end up delivering products that satisfied priority requirement (R1), the chances of ■ Pathology 1. The schedule is not re- different stakeholders to differing de- delivering rank-ordered requirements ally a requirement at all; it has been grees, with no one left completely out. R2 thru Rn would be presented in a elevated to that status as a political Unfortunately, nonconcurring projects graphic such as that in Figure 1. The fig- statement. This is often clear from seldom play out this way. ure suggests that completing V13 (con- the fact that there is nothing partic- The problem is that organizational taining R433 and all higher-ranked re- ularly magical about the stated date culture might require all the stakehold- quirements) is only marginally probable, (other than it being dear to the heart ers to cooperate, or at least seem to co- completing V10 (containing R368 and of some bigwig). operate. This does not make dissent go higher) is about 50 percent probable, ■ Pathology 2. The schedule could be away, but forces it underground. And and completing V8 (R299 and higher) is an overly precise statement of a re- dissent always exists—count on it. approximately 75 percent probable. quirement’s result: “We need this re- New IT products introduce change This risk diagram shows the proba- ally fast because we just heard our into organizations, and change is never bility of delivering any given version on major competitor is going to have this uniform in its impact on different con- or before the dictated end date. It’s an- in their next release and we think that stituencies. Our basic rule is notated to show which Rs are included 1 November just might be possible.” Every time an IT product is deliv- in which versions. Completing an R im- ■ Pathology 3. It could be an indirect ered, somebody gains power and plies satisfying all higher-priority (lower- statement of a constraint: “We want somebody else loses power. number) Rs as well because rank-order- this, but we don’t want to pay too ing requirements naturally leads to much for it, so we figure that we can Both the power gainers and the power incremental implementation. Occasion- limit the team’s spending if we give losers are, by definition, stakeholders. 100 IEEE SOFTWARE h t t p : / / c o m p u t e r. o r g / s o f t w a r e September/October 2003 IEEE SOFTWARE 100
    • REQUIREMENTS DEPT TITLE You can expect some stakeholders to get everyone to sign but still looks like cannot sign off without truly agreeing. on any complex project to be adver- a specification requires huge talent. Peo- Because the boundary characteristic saries. They might not be allowed to ple who can pull this off are geniuses. It’s foils the most common defense against act adversarially, but many other possi- too bad that their genius doesn’t help the nonconcurrence (using a vague state- bilities are open to them. For example: project. It just defers the real problem un- ment of requirements to gain signoff), til implementation time, when it becomes you can expect all participants in a non- ■ Overloading: adding excessive func- fatal. You can specify a product vaguely, concurring project to rail against its in- tionality to burden the project but you can’t implement it vaguely. clusion as a milestone. Expect them to ■ Power broking: forcing priority say that it is a matter that should be left based on clout rather than need Managing the risk of nonconcurrence until detailed design or to the program- ■ Withholding: refusing to sign off on Failure to concur is clearly a politi- mers. The risk manager must stand firm functionality that benefits others cal matter, not a technical matter. The on this matter. Projects that can’t achieve ■ Unavailability: being too busy to at- technicians who make up much of our a signoff on the boundary census by the tend to project needs requirements engineering force are not approximate 15 percent point probably naturally endowed with the skills and need to be cancelled. Disguising nonconcurrence talents to deal with this. R A common tactic requirements gath- Risk management cannot assure a so- isk management doesn’t make any of erers use is to avoid confronting stake- lution to nonconcurrence either, but it can the requirements-related risks go away. holder nonconcurrence: They write help detect it. The simplest way is to look What it does is let us deal with these mat- down the requirements so vaguely that for signoff on the boundary characteristic ters in a clear-headed, adult fashion. all the stakeholders can sign off on them. of the project’s product—a complete cen- We usually categorize this as a simple sus of inputs and outputs across the sys- Tom DeMarco and Tim Lister are Principals of the At- writing problem (Gee, I wish those guys tem boundary, defined down to the data lantic Systems Guild and coauthors of Waltzing with Bears: Managing Risk on Software Projects (Dorset House, 2003) and Peopleware: Pro- could write better!), but it isn’t. Produc- element level. When this census becomes ductive Projects and Teams, (Dorset House, 1987 and 1999). Contact ing a specification that is vague enough integral to the requirement, the parties them at tdemarco@systemsguild.com and tlister@systemsguild.com PU RPOSE The IEEE Computer Society is the EXECUTIVE COMMITTEE world’s largest association of computing profes- President: sionals, and is the leading provider of technical STEPHEN L. DIAMOND* information in the field. Picosoft, Inc. MEMBERSHIP Members receive the P.O.Box 5032 monthly magazine COM PUTER, discounts, and San Mateo, CA 94402 opportunities to serve (all activities are led by Phone: +1 650 570 6060 volunteer members). Membership is open to all Fax: +1 650 345 1254 IEEE members, affiliate society members, and s.diamond@computer.org others interested in the computer field. President-Elect: CARL K. CHANG* COMPUTER SOCIETY WEB SITE The IEEE Computer Society’s Web site, at Past President: WILLIS. K. KING* http://computer.org, offers information and VP, Educational Activities: DEBORAH K. SCHERRER samples from the society’s publications and con- (1ST VP)* ferences, as well as a broad range of information VP, Conferences and Tutorials: CHRISTINA about technical committees, standards, student SCHOBER* activities, and more. COMPUTER SOCIETY OFFICES VP, Chapters Activities: MURALI VARANASI† Headquarters Office VP, Publications: RANGACHAR KASTURI † BOARD OF GOVERNORS 1730 Massachusetts Ave. NW VP, Standards Activities: JAMES W. MOORE† Term Expiring 2003: Fiorenza C. Albert- Washington, DC 20036-1992 VP, Technical Activities: YERVANT ZORIAN† Howard, Manfred Broy, Alan Clements, Richard A. Secretary: OSCAR N. GARCIA* Kemmerer, Susan A. Mengel, James W. Moore, Phone: +1 202 371 0101 • Fax: +1 202 728 9614 Christina M. Schober Treasurer:WOLFGANG K. GILOI* (2ND VP) E-mail: hq.ofc@computer.org Term Expiring 2004: Jean M. Bacon, Ricardo 2002–2003 IEEE Division VIII Director: JAMES D. Baeza-Yates, Deborah M. Cooper, George V. Cybenko, Publications Office ISAAK† Haruhisha Ichikawa, Lowell G. Johnson, Thomas W. 10662 Los Vaqueros Cir., PO Box 3014 Williams 2003–2004 IEEE Division V Director: GUYLAINE M. Term Expiring 2005: Oscar N. Garcia, Mark A Los Alamitos, CA 90720-1314 POLLOCK† Grant, Michel Israel, Stephen B. Seidman, Kathleen 2003 IEEE Division V Director-Elect: GENE H. HOFF- M. Swigger, Makoto Takizawa, Michael R. Williams Phone:+1 714 821 8380 NAGLE Next Board Meeting: 22 Nov. 2003, Tampa, FL E-mail: help@computer.org Computer Editor in Chief: DORIS L. CARVER† Membership and Publication Orders: Executive Director: DAVID W. HENNAGE† IEEE OFFICERS Phone: +1 800 272 6657 Fax: +1 714 821 4641 President: MICHAEL S. ADLER * voting member of the Board of Governors E-mail: help@computer.org † nonvoting member of the Board of Governors President-Elect: ARTHUR W. WINSTON Past President: RAYMOND D. FINDLAY Asia/Pacific Office Executive Director: DANIEL J. SENESE Watanabe Building EXECUTIVE STAFF Secretary: LEVENT ONURAL 1-4-2 Minami-Aoyama,Minato-ku, Executive Director: DAVID W. HENNAGE Treasurer: PEDRO A. RAY Tokyo107-0062, Japan Assoc. Executive Director: VP, Educational Activities: JAMES M. TIEN Phone: +81 3 3408 3118 • Fax: +81 3 3408 3553 ANNE MARIE KELLY VP, Publications Activities:MICHAEL R. LIGHTNER Publisher: ANGELA BURGESS E-mail: tokyo.ofc@computer.org VP, Regional Activities: W. CLEON ANDERSON Assistant Publisher: DICK PRICE VP, Standards Association: GERALD H. PETERSON Director, Administration: VIOLET S. DOAN VP, Technical Activities: RALPH W. WYNDRUM JR. Director, Information Technology & Services: IEEE Division VIII Director JAMES D. ISAAK ROBERT CARE President, IEEE-USA: JAMES V. LEONARD Manager, Research & Planning: JOHN C. KEATON