Introduction | Book Structure | What We Liked
Small Projects and Support Work | Downside | Summary

What We Liked

Unlike the myriad of other project risk management books on the market that provide long shopping lists to choose from, this book provides a select number of common project risk issues culled from the authors' personal experience in Information Technology. More importantly, as we described under Book Structure, each Issue is discussed in some detail explaining how it may come about, its impacts and how it may be detected. The authors then describe what you have to do about each, or what you can do to avoid them in the first place.

But at the outset, the authors set out to show how IT Differs from Other Types of Business Work, and do so by presenting the following Table to prove it:[8]

Figure 1: Some Key Differences Between IT and Business Work

Some of the authors' comments on this Table include:

"A business unit employee typically shows up and starts work. During the day the person completes groups of transactions. Each transaction is a single task. The transactions often are not related. In IT the staff member can be interrupted by questions, crises, and issues. In IT the work is more variable ... For business staff the work tends to be routine, ..."[9]

Well, we are not sure that "business staff" would necessarily quite agree with all of that, but you get the general point.

As an engineer, we always like things that are methodical, and this book is very methodical as we showed in describing the structure of the book's contents. With "Over 150 Issues" to choose from, most of which will be familiar to IT people, this book does not have to be read progressively from cover to cover. Instead, you can pick and choose today's particular area of interest, and dive right in. You can even open the book at random and start by reading the "Discussion" of the Issue on that page.

To prove this point, we've just opened the book at random (Yes, honestly!), and the Issue happens to be "Team Members or Departments That Do Not Get Along with One Another". The Discussion of this topic starts out with:

"Some people see themselves in competition with other IT staff. As such, they do not want to share knowledge. Another factor that contributes to this problem is that through training and culture, the individual is favored over the group. Also, some organizations have no significant turnover of staff. For example, at a university with tenure, the same faculty work (or do not work) together for decades. In these situations it is not surprising to find personality conflicts and even hatred."[10]

This section then goes on to describe typical examples under varying conditions.

We couldn't wait to get to the Actions and Preventions section, to see what the authors' recommended. These recommendations offer five different approaches - but you'll have to read the book to find out what they are. Interestingly, the one recommendation that is not included, and that we would have been inclined to add, is: "Fire the recalcitrant combatants or, at least, get them transferred to someone else's project!"

Book Structure

Small Projects and Support Work

Home | Issacons | PM Glossary | Papers & Books | Max's Musings
Guest Articles | Contact Info | Search My Site | Site Map | Top of Page