How to handle real project risks, while filing gaps in the risk theory literature (2002)

Who would have thought research projects could make for interesting books? This is my second recent column about a research project that led to a book. I still find myself scratching my head about that as a concept. Nevertheless, here again is a book based entirely on a single research project. In this case, the research was conducted by the author, Tony Moynihan, in his role of Professor of Computer Applications at Dublin City University in Ireland. The topic? The techniques used by experienced software project managers for addressing and managing risks on their projects. You might expect that would make for a boring book. But, in fact, it isn't! This is probably one of the most real, useful, and entertaining books I have ever read on project management. (You may know that project management isn't my favorite software engineering topic!). What was the research project, and what is so real about it? The author interviewed a collection of 30-odd IS/IT project managers, from the point of view of project risks they had experienced. He asked them to discuss and rank risks on projects they had managed, and then on hypothetical projects he presented to them, all the while eliciting comments on how they did or would handle those risks. The result came through as the most real collection of thoughts on project management I have ever read, in that they were straight from the horse's mouth (that is, from experienced software project managers). Having elicited all those opinions, the author then aggregated them into perhaps the most useful chapter of the book, the one that presents "some strategies/recipes" for handling specific risks. There's even a chapter on "when to walk away" from a project that looks like a disaster-in-the-making. Now, an important question is "Who's the target audience for this book?" The author says it's for "IS/IT software project managers." Well, I suppose that makes sense. But there's a whole lot of researchy stuff - methods and approaches - that the average practitioner would want to move swiftly over, but the average researcher might gobble up. There's a chapter on linking the findings to risk theory that also would be eminently skippable for many practitioners, but would be the heart of the book for a researcher. In fact, as I read this, I found myself wishing it could be required reading for IS/IT academics! The reality of the findings would help immensely in getting those academics to move down to earth in their consideration of what's important in IS/IT and software. As a particular example, there's even a research finding that identifies gaps in the traditional risk theoretical literature, issues that arose during the interviews that are not present in that literature. As a further example, the problem that kept recurring as the most serious one to worry about was variously called either "control" (issues over which you haven't much control are real potential project pitfalls), or "customer people problems" (that's where many of those control issues were categorized). And the resolution of those control problems was most frequently found in a subject the author considered only in passing, contractual approaches.I think most academics, especially those who tend to deal largely in technical matters, would be surprised at how unimportant such issues really are to people in the field!As an example of that, the author noted that "requirements uncertainty," a matter of high concern in most academic textbooks, was simply not much of a concern in practice. Why? Because practitioners have "a rich mixture of strategies" for dealing with that. What didn't I like about this book? It leaped precipitously into the interview results without setting sufficient context for them. Tables of fascinating data were often difficult to read because they weren't sufficiently well captioned. Discussions of interview after interview tended to get repetitious. Odd discrepancies, like saying there were 30 project manager subjects when there were apparently really 34, and saying the study analyzed 32 "constructs" when the tables contained 34.Non-American expressions (they added a nice Irish context, however!) like "carry the can," and "sussing out," and "horses for courses. And two perhaps more serious weaknesses. The managers were discussing a collection of projects which ranged in size from one to six people, too close to "toy" projects to be terribly useful in the larger-project world.And the managers were all positioned with companies in Ireland (the author makes a nice argument for why that may not be terribly important, however). On balance, do I like this book? Yes, strongly. This is one of those "and now for something completely different" books that really adds a worthwhile dimension to the (often boring!) IS/IT project management literature.