How to handle real project risks, while filing gaps in the risk theory literature
R. Glass
DOI: https://doi.org/10.1145/513264.513268
2002-06-01
Abstract:Who would have thought research projects could make forinteresting books? This is my second recent column about a researchproject that led to a book. I still find myself scratching my headabout that as a concept.
Nevertheless, here again is a book based entirely on a singleresearch project. In this case, the research was conducted by theauthor, Tony Moynihan, in his role of Professor of ComputerApplications at Dublin City University in Ireland. The topic? Thetechniques used by experienced software project managers foraddressing and managing risks on their projects.
You might expect that would make for a boring book. But, infact, it isn't! This is probably one of the most real, useful, andentertaining books I have ever read on project management. (You mayknow that project management isn't my favorite software engineeringtopic!).
What was the research project, and what is so real about it? Theauthor interviewed a collection of 30-odd IS/IT project managers,from the point of view of project risks they had experienced. Heasked them to discuss and rank risks on projects they had managed,and then on hypothetical projects he presented to them, all thewhile eliciting comments on how they did or would handle thoserisks. The result came through as the most real collection ofthoughts on project management I have ever read, in that they werestraight from the horse's mouth (that is, from experienced softwareproject managers).
Having elicited all those opinions, the author then aggregatedthem into perhaps the most useful chapter of the book, the one thatpresents "some strategies/recipes" for handling specific risks.There's even a chapter on "when to walk away" from a project thatlooks like a disaster-in-the-making.
Now, an important question is "Who's the target audience forthis book?" The author says it's for "IS/IT software projectmanagers." Well, I suppose that makes sense. But there's a wholelot of researchy stuff - methods and approaches - that the averagepractitioner would want to move swiftly over, but the averageresearcher might gobble up. There's a chapter on linking thefindings to risk theory that also would be eminently skippable formany practitioners, but would be the heart of the book for aresearcher. In fact, as I read this, I found myself wishing itcould be required reading for IS/IT academics! The reality of thefindings would help immensely in getting those academics to movedown to earth in their consideration of what's important in IS/ITand software. As a particular example, there's even a researchfinding that identifies gaps in the traditional risk theoreticalliterature, issues that arose during the interviews that are notpresent in that literature.
As a further example, the problem that kept recurring as themost serious one to worry about was variously called either"control" (issues over which you haven't much control are realpotential project pitfalls), or "customer people problems" (that'swhere many of those control issues were categorized). And theresolution of those control problems was most frequently found in asubject the author considered only in passing, contractualapproaches.I think most academics, especially those who tend todeal largely in technical matters, would be surprised at howunimportant such issues really are to people in the field!As anexample of that, the author noted that "requirements uncertainty,"a matter of high concern in most academic textbooks, was simply notmuch of a concern in practice. Why? Because practitioners have "arich mixture of strategies" for dealing with that.
What didn't I like about this book? It leaped precipitously intothe interview results without setting sufficient context for them.Tables of fascinating data were often difficult to read becausethey weren't sufficiently well captioned. Discussions of interviewafter interview tended to get repetitious. Odd discrepancies, likesaying there were 30 project manager subjects when there wereapparently really 34, and saying the study analyzed 32 "constructs"when the tables contained 34.Non-American expressions (they added anice Irish context, however!) like "carry the can," and "sussingout," and "horses for courses.
And two perhaps more serious weaknesses. The managers werediscussing a collection of projects which ranged in size from oneto six people, too close to "toy" projects to be terribly useful inthe larger-project world.And the managers were all positioned withcompanies in Ireland (the author makes a nice argument for why thatmay not be terribly important, however).
On balance, do I like this book? Yes, strongly. This is one ofthose "and now for something completely different" books thatreally adds a worthwhile dimension to the (often boring!) IS/ITproject management literature.