News

Book Review: Managing risk on software projects

How much risk can your project take? You run down a checklist and everyone agrees there are no “showstoppers.” But deadlines, people power, requirements... they often merge in a mesh that comes to haunt you when the night is late and it is time to rest. Perhaps a book on risk and software might be what the doctor ordered. And such a tome comes this way from Messrs. Tom DeMarco and Timothy Lister.

DeMarco and Lister have long been at the forefront of software engineering. Their 1987 book, “Peopleware: Productive Projects and Teams,” one of the must-reads of software development, took a look at why software projects fail, and came to the now famous conclusion that the work culture of organizations pursuing development was more likely to influence project outcomes than the amount of technology employed, or the size of the labor force directed at the task.

In their latest effort, “Waltzing with Bears: Managing Risk on Software Projects,” DeMarco and Lister look at the role of risk in software development, concluding that it is at least as important a factor in project success as are software development processes.

“The business of believing only what you have a right to believe is called risk management,” the authors tell us. Risk can’t be avoided, they point out; if something is innovative, and can offer great reward, it will be worth doing, and it will entail risk. In days when risk avoidance, and cost cutting, seem the only recipes offered for technologists, their words come as something of a tonic. DeMarco and Lister advise readers, “If a project has no risks, don’t do it.”

Among the core risks in software projects they cite are: inherent schedule flaws, requirements creep, poor productivity and “specification breakdown.” This last risk refers to the collapse of the negotiation process that is at the heart of requirement setting. Never seen that happen, have you?

The book is a quick read, and the authors’ established storytelling skills are on display, and that is a good thing. But some readers may feel the concept of risk, as well as its application to software development, at times seems to get short shrift.

There are enough worthwhile insights, however, for you to consider adding it to a development literature collection.

The Denver International Airport automated baggage system software fiasco of 1993 comes in for analysis and it is an example of the authors’ refined sense of skeptical examination. The project planners failed at risk management there, but, DeMarco and Lister suggest, the software development part of the operation may have been a mere cog in the overall crumbling mechanism of misplaced risk aversion.

The possibility of overall system failure -- if the critical-path auto-bag handler did not operate, the airport could not meet a publicized opening date -- could have been mitigated by non-software alternatives, the kind of traditional “peopleware-based” bag handling operations that were well understood, if several parameters in the airport’s overall design had left some leeway. Software seemed to be the only suspect that investigators pursued here, the writers suggest.

Readers who want a deeper study of risk outside the software realm may find interest in Peter Bernstein’s “Against the Gods: The Remarkable Story of Risk.” But “Waltzing with Bears” (its name taken from a Dr. Seuss song) is worth a read by workers at any stage of the software risk chain. The authors even offer a free downloadable Monte Carlo risk calculator from their Web site for those who want to run their risks through a clever software grinder.

Links:

For more on “Waltzing with Bears” go to www.dorsethouse.com

For Tom and Tim’s MonteCarlo Risk simulator, go to www.systemsguild.com/riskology

For other Programmers Report articles, please go to www.adtmag.com/article.asp?id=6265

About the Author

Jack Vaughan is former Editor-at-Large at Application Development Trends magazine.

Featured

Upcoming Events

AppTrends

Sign up for our newsletter.

I agree to this site's Privacy Policy.