Waltzing with Bears by Tom Demarco and Timothy Lister
Demarco and Lister need: a) error bars for their probability estimates, b) post-mortems for projects, and c) to organize projects by similar actions. The more similar actions, the more we can see where we were over- or under-confident about our probability estimates.
Most software project managers do a reasonable job of predicting the tasks that have to be done and a poor job of predicting the tasks that might have to be done.
They provide a risk-discovery worksheet at the end of the book; it's a good start.
Q7: Wasn't lateness of the ABHS software seen as a potential risk? Only after it happened. Before that, the software was placed on an aggressive schedule and managed for success. Q8: Haven't software projects been late before? Yes, but this one was supposed to be different. Q9: Was there any history of prior projects building similar systems? Yes. The Franz Josef Strauss Airport in Munich had installed a pilot ABHS, designed along the lines of the DIA version. QlO: Did the DIA team visit the Munich project, and if so, what did it learn? Members of DIA's ABHS project did visit Munich. The Munich software team had allowed a full two years for testing and six months of 24-hour operation to tune the system before cut-over. They told the DIA folk to allow that much or more. Q l l : Did DZA management follow this advice? Since there wasn't time for such extensive testing and tuning, they elected not to.