0 7 4 0 - 7 4 5 9 / 0 3 / $ 1 7 . 0 0 © 2 0 0 3 I E E E P u b l i s h e d b y t h e I E E E C o m p u t e r S o c i e t y I E E E S O F T W A R E 9 9

requirementsE d i t o r : S u z a n n e R o b e r t s o n ■ T h e A t l a n t i c S y s t e m s G u i l d ■ s u z a n n e @ s y s t e m s g u i l d . c o m

Risk management is project manage-ment for adults. This means the man-ager adopts an adult attitude towardthings that might go wrong during theproject, a marked difference from theprevailing can-do attitude. The risk

manager is obliged to do some can’t-do think-ing, to look problems—even potentially un-solvable ones—directly in the eye and ac-

knowledge that they could come to pass. Therisk-aware project manager will accept a luckybreak if it should happen but refuses to includeit in the plan.

At the heart of risk management is a public,continuing process of risk identification. Somerisks that will threaten your project are utterlyunique to your situation. But others are not.Over some 10 years of conducting risk identi-fication exercises in organizations, we havefound five risks that are so ubiquitous thatwe’ve dubbed them core risks:

■ Intrinsic schedule flaw: estimates that arewrong (undoable) from day one, often basedon nothing more than wishful thinking

■ Specification breakdown: failure to achievestakeholder consensus on what to build

■ Scope creep: additional requirements thatinflate the initially accepted set

■ Personnel loss: project members who leavebefore the project is done

■ Productivity variation: difference betweenassumed and actual performance

All five of these touch on the requirementsprocess, but the first two are deeply rootedthere. The third sometimes indicates naturallyoccurring change, but in other cases is a directindictment of how requirements were gath-ered in the first place. In other words, the so-called creep is not really change at all, but thecorrection of requirements that were misiden-tified to begin with.

We focus on the first two core risks and dis-cuss risk management as part of the require-ments process.

The schedule “requirement”A schedule flaw can result from an honest

mistake in sizing and projection. We estimate thisto be true of approximately one project per mil-lion. In all the others, something else is going on.That something is most often a de facto elevationof a fervent desire (“Wouldn’t it be nice if theproject were done by year-end?”) to requirementstatus. The elevation often goes one step further,

Risk Management duringRequirementsTom DeMarco and Tim Lister

We have heard a lot about the risk of not writing requirements, but little abouthow to profit from making risk management integral to the requirements process.Tom DeMarco and Tim Lister redress that imbalance by explaining the role thatrequirements must play in honest risk management.

—Suzanne Robertson

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 implyIEEE 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.

1 0 0 I E E E S O F T W A R E h t t p : / / c o m p u t e r. o r g / s o f t w a r e

DEPT TITLE

S e p t e m b e r / O c t o b e r 2 0 0 3 I E E E S O F T W A R E 1 0 0

REQUIREMENTS

to nonnegotiable demand. When all ormany of the other requirements are simi-larly nonnegotiable, the project becomesoverconstrained. An overconstrained setof nonnegotiable demands—surprise,surprise—ends negotiation. When notrade-offs are possible, when it’s not evenpermissible to discuss them, the projectteam is reduced to a single tactic: lying.

How can risk management help?Risk management deals with this

situation in two ways:

■ It imposes a rank-ordering of all re-quirements (no two can have thesame rank).

■ It expresses all outcomes in proba-bilistic terms.

Now, if schedule is indeed the highest-priority requirement (R1), the chances ofdelivering rank-ordered requirementsR2 thru Rn would be presented in agraphic such as that in Figure 1. The fig-ure suggests that completing V13 (con-taining R433 and all higher-ranked re-quirements) is only marginally probable,completing V10 (containing R368 andhigher) is about 50 percent probable,and completing V8 (R299 and higher) isapproximately 75 percent probable.

This risk diagram shows the proba-bility of delivering any given version onor before the dictated end date. It’s an-notated to show which Rs are includedin which versions. Completing an R im-plies satisfying all higher-priority (lower-number) Rs as well because rank-order-ing requirements naturally leads toincremental implementation. Occasion-

ally, a few lower-ranked requirementsmight be incorporated into a given ver-sion for convenience.

Vive la différenceWhen all parties agree to discuss suc-

cess in probabilistic terms, they implic-itly understand that no delivery proba-bility in the real world ever equals 1.0.This forces all participants to confrontrisk. They might question how muchrisk there is, but never whether there isrisk. Rank-order prioritization ensuresthat, however the project performs, thehighest-priority requirements have thehighest likelihood of being delivered.

Additionally, this approach helpsflush out some of the pathologies thatwe all know happen when schedulesare treated as absolute requirements.

■ Pathology 1. The schedule is not re-ally a requirement at all; it has beenelevated to that status as a politicalstatement. This is often clear fromthe fact that there is nothing partic-ularly magical about the stated date(other than it being dear to the heartof some bigwig).

■ Pathology 2. The schedule could bean overly precise statement of a re-quirement’s result: “We need this re-ally fast because we just heard ourmajor competitor is going to have thisin their next release and we think that1 November just might be possible.”

■ Pathology 3. It could be an indirectstatement of a constraint: “We wantthis, but we don’t want to pay toomuch for it, so we figure that we canlimit the team’s spending if we give

them only until 1 November.”

When rank-order prioritization be-comes the accepted way to establish eachrequirement’s importance, there is littledanger of overconstraining the project.Treating schedule as one of n priority-ranked requirements lessens the possibil-ity of intrinsic schedule flaw. It also side-steps the tendency to use schedule as a defacto cost reduction tactic. This ap-proach alone won’t make schedule flawsdisappear, but it should help reduce theirincidence to those that are honest sizingand projection errors.

Failure to concurIn the past, IT projects were most of-

ten tasked to satisfy a single user’s re-quirements. They were relatively easy,but sadly we finished all such projectsyears ago. Today a new IT project islikely to affect several different stake-holders from different parts of the orga-nization, in different locations, with dif-ferent interests, and little or no commonstake. Perhaps the biggest core risk is thatthese stakeholders will fail to concur onproject goals. Our data leads us to expectthis to happen to a disruptive extent onapproximately one project out of seven.

Failure to achieve total concurrencewould be no more than an annoyance ifall could agree to disagree. We wouldend up delivering products that satisfieddifferent stakeholders to differing de-grees, with no one left completely out.Unfortunately, nonconcurring projectsseldom play out this way.

The problem is that organizationalculture might require all the stakehold-ers to cooperate, or at least seem to co-operate. This does not make dissent goaway, but forces it underground. Anddissent always exists—count on it.New IT products introduce changeinto organizations, and change is neveruniform in its impact on different con-stituencies. Our basic rule is

Every time an IT product is deliv-ered, somebody gains power andsomebody else loses power.

Both the power gainers and the powerlosers are, by definition, stakeholders.

100%

50%

0%V13 V12 V11Versions: V10 V9 V7V8 V6

Prob

abili

ty

R433 delivered as part of Version 13R368 delivered as part of Version 10

R299 delivered as part of Version 8

Figure 1. Risk diagram for a project with a fixed delivery date.

DEPT TITLE

You can expect some stakeholderson any complex project to be adver-saries. They might not be allowed toact adversarially, but many other possi-bilities are open to them. For example:

■ Overloading: adding excessive func-tionality to burden the project

■ Power broking: forcing prioritybased on clout rather than need

■ Withholding: refusing to sign off onfunctionality that benefits others

■ Unavailability: being too busy to at-tend to project needs

Disguising nonconcurrenceA common tactic requirements gath-

erers use is to avoid confronting stake-holder nonconcurrence: They writedown the requirements so vaguely thatall the stakeholders can sign off on them.We usually categorize this as a simplewriting problem (Gee, I wish those guyscould write better!), but it isn’t. Produc-ing a specification that is vague enough

to get everyone to sign but still looks likea specification requires huge talent. Peo-ple who can pull this off are geniuses. It’stoo bad that their genius doesn’t help theproject. It just defers the real problem un-til implementation time, when it becomesfatal. You can specify a product vaguely,but you can’t implement it vaguely.

Managing the risk of nonconcurrenceFailure to concur is clearly a politi-

cal matter, not a technical matter. Thetechnicians who make up much of ourrequirements engineering force are notnaturally endowed with the skills andtalents to deal with this.

Risk management cannot assure a so-lution to nonconcurrence either, but it canhelp detect it. The simplest way is to lookfor signoff on the boundary characteristicof the project’s product—a complete cen-sus of inputs and outputs across the sys-tem boundary, defined down to the dataelement level. When this census becomesintegral to the requirement, the parties

cannot sign off without truly agreeing.Because the boundary characteristic

foils the most common defense againstnonconcurrence (using a vague state-ment of requirements to gain signoff),you can expect all participants in a non-concurring project to rail against its in-clusion as a milestone. Expect them tosay that it is a matter that should be leftuntil detailed design or to the program-mers. The risk manager must stand firmon this matter. Projects that can’t achievea signoff on the boundary census by theapproximate 15 percent point probablyneed to be cancelled.

Risk management doesn’t make any ofthe requirements-related risks go away.What it does is let us deal with these mat-

ters in a clear-headed, adult fashion.

Tom DeMarco and Tim Lister are Principals of the At-lantic Systems Guild and coauthors of Waltzing with Bears: ManagingRisk on Software Projects (Dorset House, 2003) and Peopleware: Pro-ductive Projects and Teams, (Dorset House, 1987 and 1999). Contactthem at tdemarco@systemsguild.com and tlister@systemsguild.com

REQUIREMENTS

EXECUTIVE STAFFExecutive Director: DAVID W.HENNAGEAssoc. Executive Director:ANNE MARIE KELLYPublisher: ANGELA BURGESSAssistant Publisher: DICK PRICEDirector, Administration: VIOLET S. DOANDirector, Information Technology & Services: ROBERT CAREManager, Research & Planning: JOHN C.KEATON

COMPUTER SOCIETY OFFICESHeadquarters Office1730 Massachusetts Ave. NW

Washington, DC 20036-1992

Phone: +1 202 371 0101 • Fax: +1 202 728 9614

E-mail: hq.ofc@computer.org

Publications Office10662 Los Vaqueros Cir., PO Box 3014

Los Alamitos, CA 90720-1314

Phone:+1 714 8218380

E-mail: help@computer.org

Membership and Publication Orders:

Phone: +1 800 272 6657 Fax: +1 714 821 4641

E-mail: help@computer.org

Asia/Pacific OfficeWatanabe Building

1-4-2 Minami-Aoyama,Minato-ku,

Tokyo107-0062, Japan

Phone: +81 3 3408 3118 • Fax: +81 3 3408 3553

E-mail: tokyo.ofc@computer.org

PURPOSE The IEEE Computer Society is theworld’s largest association of computing profes-sionals, and is the leading provider of technicalinformation in the field.

MEMBERSHIP Members receive themonthly magazine COMPUTER, discounts, andopportunities to serve (all activities are led byvolunteer members). Membership is open to allIEEE members, affiliate society members, andothers interested in the computer field.

BOARD OF GOVERNORSTerm Expiring 2003: Fiorenza C. Albert-Howard, Manfred Broy, Alan Clements, Richard A.Kemmerer, Susan A. Mengel, James W. Moore,Christina M. SchoberTerm Expiring 2004: Jean M. Bacon, RicardoBaeza-Yates, Deborah M. Cooper, George V. Cybenko,Haruhisha Ichikawa, Lowell G. Johnson, Thomas W.WilliamsTerm Expiring 2005: Oscar N. Garcia, Mark AGrant, Michel Israel, Stephen B. Seidman, KathleenM. Swigger, Makoto Takizawa, Michael R. Williams

Next Board Meeting: 22 Nov. 2003, Tampa, FL

IEEE OFFICERSPresident: MICHAEL S. ADLERPresident-Elect: ARTHUR W. WINSTONPast President: RAYMOND D. FINDLAYExecutive Director: DANIEL J. SENESESecretary: LEVENT ONURALTreasurer: PEDRO A. RAYVP, Educational Activities: JAMES M. TIENVP, Publications Activities:MICHAEL R. LIGHTNERVP, Regional Activities: W. CLEON ANDERSONVP, Standards Association: GERALD H. PETERSONVP, Technical Activities: RALPH W. WYNDRUM JR.IEEE Division VIII Director JAMES D. ISAAKPresident, IEEE-USA: JAMES V. LEONARD

EXECUTIVE COMMITTEEPresident:STEPHEN L. DIAMOND* Picosoft, Inc.P.O.Box 5032San Mateo, CA 94402Phone: +1 650 570 6060Fax: +1 650 345 1254s.diamond@computer.org

President-Elect: CARL K. CHANG*Past President: WILLIS. K. KING*VP, Educational Activities: DEBORAH K. SCHERRER(1ST VP)*VP, Conferences and Tutorials: CHRISTINASCHOBER*VP, Chapters Activities: MURALI VARANASI†VP, Publications: RANGACHAR KASTURI †VP, Standards Activities: JAMES W. MOORE†VP, Technical Activities: YERVANT ZORIAN†Secretary: OSCAR N. GARCIA*Treasurer:WOLFGANG K. GILOI* (2ND VP)2002–2003 IEEE Division VIII Director: JAMES D.ISAAK†2003–2004 IEEE Division V Director: GUYLAINE M.POLLOCK†2003 IEEE Division V Director-Elect: GENE H. HOFF-NAGLEComputer Editor in Chief: DORIS L. CARVER†Executive Director: DAVID W. HENNAGE†

* voting member of the Board of Governors† nonvoting member of the Board of Governors

COMPUTER SOCIETY WEB SITEThe IEEE Computer Society’s Web site, athttp://computer.org, offers information andsamples from the society’s publications and con-ferences, as well as a broad range of informationabout technical committees, standards, studentactivities, and more.