How to handle real project risks, while filing gaps in the risk theory literature
Authors: Glass Robert L. 
Published: October 2004

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.