Email	Print Reprint
	add to:
	Del.icio.us Digg Google Furl	Slashdot Y! MyWeb Blink

Software Development
SD Best Practices 2004 / Show Daily /

Admitting Uncertainty

Tom DeMarco: "Waltzing with bears is a risky business.

On my first full day in Boston, I decided to go for a morning run along the Charles River toward Harvard. I hadn't intended to reach Harvard Square, but the gracious stone bridges passed by quickly in the gorgeous autumn glow, and the plethora of students giddy about their first days of class distracted me. Faced with a choice to retrace my steps and run several more miles then I'd planned, I instead studied a subway map and took a shortcut by following Massachusetts Avenue through Cambridge all the way back to the Hynes Convention Center. Getting lost was a risk—but running for two hours wasn't an option, given my busy day ahead at the SD Best Practices conference.

Unlike a runner who adapts her route to the circumstances at hand, many IT managers forge ahead on a single critical-path activity when all outward signs indicate that it's leading to massive schedule overruns or even outright failure.

"These are what I call risk management atrocities: You're blindsided by a risk that's happened a thousand times before; you have no infrastructure in place to deal with a risk when it materializes; and you don't have a useful transition indicator—something that tells you a risk is about to happen, explained Tom DeMarco in his September 20, 2004, keynote, covering themes found in his latest paper in the Cutter Business Technology Council Opinion.

A principal with the U.S.- and U.K.-based Atlantic Systems Guild and coauthor with Timothy Lister of the Jolt Award-winning Waltzing with Bears: Managing Risk on Software Projects (Dorset House, 2003), DeMarco talked about the importance of bounding our uncertainty. Displaying a graph of the relative probability of hitting a project deadline, he explained that a simple risk diagram can show explicitly how uncertain we are about delivery date.

"This graph tells the entire history of the software industry. Human endeavors all have this characteristic shape, where they rise fairly steeply and have a long tail at the end. After outlining the ways a simple curve could show size inflation, productivity variation, delivery date probability or flaws in size estimation, DeMarco outlined the five core risks for technology projects:

• Size inflation: The project grows beyond the basic set of functionality into the realm of impossibility.
• Original estimate flaw: Management sets a date that has no statistical relevance to reality.
• Personnel turnover: "This is your biggest risk if your project is anything over a year, according to DeMarco.
• Failure to concur: A breakdown among the interested parties, often culminating in litigation.
• Productivity variation: The difference between the assumed and the actual team performance.

"What are good sources of benchmarking data for comparing risks? one audience member asked. "Start with what you know, DeMarco replied. "Since losing staff is your biggest risk, there's got to be some data within your organization about your retention rate.

"What advice can you give for people who present this risk scenario and are told they're doomsayers or slackers? another queried. "This sort of culture will treat any deviation from the can-do mentality as excuses, DeMarco responded. "Start by managing all the risks except productivity variation—manage the true nonperformance risks first.

Finally, DeMarco presented a useful self-test for checking to see whether you're actually doing risk management:

1. Is there a census of risks with at least 10 to 20 risks on it?
2. Is each risk quantified as to probability and cost and schedule impact?
3. Is there at least one early transition indicator associated with each risk?
4. Does the census include the core risks as indicated by past industry experience?
5. Are risk diagrams used widely to specify both the causal risks as well as the net result (schedule and cost) risks?
6. Is the scheduled delivery date significantly different from the best-case scenario?

But above all, he said, IT professionals must realize that they're the harbingers of change in the organization: "Every time a system is installed, somebody gains and somebody loses power. The business of the IT person is to gain the assistance of both the power gainers and the power losers. And that process is the riskiest one of all.

Alexandra Weber Morales

RELATED ARTICLES No Related Articles		TOP 5 ARTICLES No Top Articles.