"Bessemer converter (iron into steel) Allegheny Ludlum Steel e Corp Brackenridge, Pa (LOC)" [crop]. Ca. 1940. Alfred T. Palmer via Library of Congress

Risk Taking, Risk Management and Software Project Management

E. Forrest Christian Computers/IT, Project Management, Reviews - Articles, Reviews - Books, Risk Management Leave a Comment

In a recent article in the Harvard Business Review entitled “Delusions of Success: How Optimism Undermines Executives’ Decisions”, Dan Lovallo and Nobel-laureate Daniel Kahneman discussed their findings that executives treat risky propositions with too much optimism, especially when they have put something into the work. The executives needed optimism to take on risky projects, yet they also needed someone who was the devil’s advocate to point out real risk levels.

If the most successful business people (high-level executives and entrepreneurs) do not rightly handle risk, how can we expect that their subordinate coworkers can do so? Project risk, a topic I have spent more than my fair share on, is demanded to be handled, yet PMs who leave a risk open for more than a week don’t get promoted. Do they not understand project risk or is it simply that they believe that a project should be risk free? At minimum, handling risk within a project context is problematic.

One problem is that no one seems capable of pulling the plug. Managers and teams, even whole companies, become increasingly more committed to failing causes. They look at the sunk costs and fear the loss if they simply pull the project. Even though they could make more money or simply avoid losing money by putting the funds and resources elsewhere, the idea that the sunk costs are too high to walk away from haunts their decisions. Runaway projects actually create an escalation of commitment to a failing cause.

Since IT projects are particularly prone to this, reviewing some of the research on how we make decisions will benefit any IT manager or PM.

Gustavo Dimello has an interesting summary (“To Pull or Not To Pull the Plug: When Managers Commit Themselves to Failure”) of some of the recent research in managers’ continuing to fund product development projects that have little chance of success. Since most IT projects are really about producing a new product (albeit an internal one), these have direct implications for us.

In “Cutting Your Losses: Extricating Your Organization When a Big Project Goes Awry“, (Sloan Management Review, Spring, 2000) Mark Keil & Ramiro Montealegre provide a good managers’-level overview of the escalation phenomenom, especially how it applies to technology-heavy projects. It’s a good starting point to see the process of de-escalating commitment so that you can leave the project. De-escalation is a relatively unexamined part of this organizational problem.

Although I’ve mentioned it previously, Helga Drummond had a very worthwhile article in Organization Studies (“Is Escalation Always Irrational?”, Mid-Winter, 1998) in which she argues that escalation of commitment is not a result of the failure of logical decision-making. Instead, escalation results because of the logic of the decision-making. As a contrary view, it is worth taking a look at, especially for those of us concerned with reducing the likelihood of escalation in our projects.

Other Recommended Materials On Risk Management for Managers

Taking Risks by Kenneth MacCrimmon & Donald Wehrung.

One of the very best books in the field. MacCrimmon and Wehrung interviewed real live executives and managers to discover how they would handle certain risks. Using a series of role-playing scenarios, they were able to get at how the managers would really react to different types of risks. One of their surprising findings was that those that we normally assume are risk-averse (e.g., older workers in banking) really are. Sometimes the results are not counterintuitive, it seems.

Project and Program Risk Management: A Guide to Managing Project Risks and Opportunities (PMBOK Handbooks) by R. Max Wideman & Rodney J. Dawson.

PMI Project Management Professionals recognize this book and will be comfortable with many of the concepts herein. It has much to say for itself but it’s getting more than a bit long in the tooth. For the money, there are many much better books to look at. However, since many PMPs expect to follow PMI’s processes, especially as outlined in the PMBOK, anyone who wishes to install working systems would be advised to know the contents of either this or the PMBOK chapter on risk.

Managing Risk: Methods for Software Systems Development by Elaine M. Hall

The Software Engineering Institute (SEI) has done extensive work on risk management. Although they focus on very large programs, their Software Risk Evaluation (SRE) Methodology 2.0 has much than can be used by smaller projects. SEI developed a risk taxonomy and a methodology for getting to the known risks that no one will talk about.

I prefer these processes for risk management to anything that I’ve seen out of PMI. I have adjusted these processes for smaller projects and for less astute management with great success. You don’t have to implement the full SRE methodology to see great benefits. Managing Risk: Methods for Software Systems Development presents the SEI SRE with a more thorough treatment of risk. If you have to choose between the PMI books and the SEI’s, choose the latter.

Waltzing with Bears: Managing Risk on Software Projects by Tom DeMarco & Timothy Lister.

Lister and DeMarco are well known in the computer industry: their Peopleware: Productive Projects and Teams (3rd Edition) is the standard management text at Microsoft, who follow their prescriptions fastidiously. The Cubicle Challenge, where they offered US$10,000 to anyone who could show one peer-reviewed study that showed that people work better in cubicles, has not had a bite yet.

Waltzing With Bears brings the same clear, common-sense attitude to project risk. Although some of the material may be familiar (pieces of their argument appear in Slack: Getting Past Burnout, Busywork, and the Myth of Total Efficiency and other works) this is the one place where they put it all together. Lister and DeMarco argue that IT projects are often simply set up to fail because their due date is the earliest possible date for completion. They recommend a more rational approach using probabilities: “We will have a 50% probability of completing the project on May 1, and 75% probability of getting done by Oct 1.” I liked the book so much that my copy is currently at BIG with an old client. I don’t lend books to clients too often, especially when I risk giving away something from my consultant’s bag of tools.

If you have to get one book on project risk management in IT, buy this one.

Risk Taking: A Managerial Perspective by Zur Shapira

Similar to the similarly named book by MacCrimmon and Wehrung, Risk Taking deals with how real live executives handle risk. Shapira is one of new risk experts and he proves his mettle in this academic publication. He asked executives how they would handle certain situations and where they would take risks. Read along with Taking Risks, Risk Taking provides a complete picture of understanding how executives handle risks. This lets the project risk manager develop scenarios in such a way that risks will be handled rather than stifled and understand unacceptable risk levels within his or her own organization.

Judgment under Uncertainty: Heuristics and Biases, edited by Daniel Kahneman, Paul Slovic and Amos Tversky

For a more thorough treatment of the basics of risk, this classic provides great coverage of a variety of theories. They are definitely academic, but I still find their work readable.

Image Credit: “Bessemer converter (iron into steel) Allegheny Ludlum Steel e Corp Brackenridge, Pa (LOC)” [crop]. Ca. 1940. By Alfred T. Palmer. Library of Congress

About the Author

Forrest Christian

Twitter Google+

E. Forrest Christian is a consultant, coach, author, trainer and speaker at The Manasclerk Company who helps managers and experts find insight and solutions to what seem like insolvable problems. Cited for his "unique ability and insight" by his clients, Forrest has worked with people from almost every background, from artists to programmers to executives to global consultants. Forrest lives and works plain view of North Carolina's Mount Baker.  [contact]

Tell Forrest how wrong he is: