New Risk Practice? Did We Miss Something Before?

By Carl Pritchard

The PMBOK Guide®. Zzzzzzzzz. I just lost a few of you. It doesn't tend to be dramatic, high-intensity reading. It's the Sleep-Eze™ of project management. BUT, it's also setting the standards for what we do. As such, we need to look at how we need to examine our practices in its light.

PMI is on the verge of approving and circulating the first major update to the Guide to the PMBOK since 1996. It's a major update, and includes a lot of great new risk content. In fact, Risk Management has the distinction of having the entire old version discarded in favor of new content. Does this mean that we've been missing something as practicing risk managers? Had we overlooked some critical issues?

The reassuring words are "not really." In fact, what the updated PMBOK® Guideapproach to risk espouses is an enhancement of the practices that effective risk managers should already have had in place. Rather than supplant the old approaches with completely new content, the update simply reinforces some key components of best practice that were implicit in the older version of the Guide. The Guide looks at what we should have been doing all along.

Specifically, it calls for a consistent risk practice. The risk management plan section acknowledges that too frequently risk is an ad hoc sort of thing. It's not something that we manage exactly like our peers. But with risk management plans, we can begin to build the infrastructure necessary to make it part of our embedded, consistent practices, much like scheduling and budgeting. We can establish consistent thresholds, consistent processes and consistent interpretations of the data. That's the component of the new PMBOK Guide® we'll look at today.

As I drove my son to school the other day, he turned apoplectic as we approached the school's driveway. "Oh NO!," he shouted. His eyes darted left and right. "We have to go home." I turned, fully expecting to see blood spurting from a major artery. The urgency of his tone and the panic of the moment led me to assess the risk as "high probability/high impact". Pulling over and calming him, I inquired as to the cause of his distress. "I left my trumpet book on the counter. If I don't have it, I'll have to share, or borrow one from Mr. Player!"

What's wrong with this picture? Despite my explanation that it was not the end of life as we know it, he remained in despair. We had different standards as to what was worth worrying about and what wasn't. Because we had no standard for "This is what's worth screaming about in Dad's ear and this is what isn't", he took liberties and set the standard as he saw appropriate. His threshold of pain was, by his father's standards, set far too low.

Too frequently, organizationally, we don't know the thresholds of pain. We don't know when management will consider a problem "too big to manage" or what it would actually take to shut a project down (although many organizations are challenged by that notion altogether). And without that information, one of two conditions may arise. The first is what I now think of as the "trumpet book syndrome". An innocuous, non-threatening issue is elevated to unreasonable levels by virtue of the understanding and personal urgency experienced by a given team member. The other extreme is that team members don't know when it's time to escalate. They don't recognize that they have passed into dangerous territory and they're putting the organization at risk.

For some organizations, a 10% variance in cost is perfectly normal. For others, it would be catastrophic. In some recent business dealings with two clients, I saw this dichotomy all too well. A start-up Internet enterprise asked for some supplemental work. I quoted a cost of several hundred dollars. They balked, hemmed, hawed, discussed, analyzed and voted before approving it. Another organization I work with asked for a similar level of effort. When I quoted a similar price, the client contact said "no problem, just add it to your invoice." Note the difference in sensitivity. Note the difference in potential pain. We need to know those thresholds, and we need to set them for more than just cost. Risk thresholds need to be established metrically and organization-wide for:

  • Cost
  • Schedule
  • Quality
  • Politics
  • Customer Satisfaction
  • and any other issue that can potentially put the organization in harm's way.

If the values can't be set as dollars, days or percentages, then identify the triggers that indicate we may be in harm's way (or nearing it). But some clear, unambiguous markers have to be established.

And then, they need to be communicated. In the PMBOK Guide update, PMI's contributors have gone a long way in identifying the role of the organization in risk management. They have also acknowledged the need for consistency and continuity. We've known it all along. Now, it's just time to apply it.

©Copyright 2000-2018 Emprend, Inc. All Rights Reserved.
About us   Site Map   View current sponsorship opportunities (PDF)
Contact us for more information or e-mail info@projectconnections.com
Terms of Service and Privacy Policy