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
danger of overconstraining the project.
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
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.
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 firstname.lastname@example.org and email@example.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 firstname.lastname@example.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)
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
Next Board Meeting: 22 Nov. 2003, Tampa, FL E-mail: email@example.com
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: firstname.lastname@example.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
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