Setting Thresholds

Carl Pritchard writes for www.ework.com – a Ms.Money partner.

In establishing project plans (and more specifically, risk plans), project managers need to recognize the importance of elements that go beyond basic risk identification and assessment. One critical issue we often miss out on is the notion of the risk threshold. How much can we stand? How much of a schedule delay is too much? How much of a cost overrun can the organization tolerate? The formal, pat answer is often “no overruns are acceptable.” But that’s not realistic. Most projects can withstand some small overruns in terms of schedule or cost, or some small shortcomings in terms of requirements. Those represent our thresholds.

Projects need risk thresholds. Normally, however, they remain unspoken. They’re unspoken out of a fear of sharing information that others might take advantage of. They’re unspoken because some people dread the notion that they might find themselves in a position where they exceed those limits. Fear should not be a driving force in our reasoning behind risk practice. Risk practice is, by its very nature, a study of those things of which we are fearful. Thus, what we need to do it to face those fears and establish, communicate and promote those thresholds.

We need to share them so that we know what is acceptable in terms of impact. What constitutes a high impact? What constitutes a “moderate” impact? Without the thresholds, we cannot intelligently answer those very fundamental questions. And without the answers to those questions, we cannot effectively prioritize project risk.

The process by which we accomplish this is relatively simple. For cost and schedule, we identify “how far is too far.” It can be done by asking how many days are tolerable and how much in overruns is tolerable. For requirements, we need to ask where we can afford to give ground, and where we can’t. In addition to these rather fundamental thresholds, we should also set the thresholds for politics. How much escalation can the project withstand? How far up the chain of command can complaints or concerns go without creating too much grief? How many calls from the customer are too many? If we establish the answers to these questions at the outset of the project, we clarify the level of risk impact. And we enable the risk process.

This starts at the project level. Project by project, we establish these thresholds. As we build a database of understanding on where these thresholds are at the project level, we can begin to identify organizational risk tolerances. While that’s a longer-term effort, it’s a critical step toward overall project management maturity. In the ideal, the project office will help project managers establish where they should begin to look at those thresholds and when individual project tolerances exceed organizational tolerance. That’s important information, since the project has to function in the greater organizational context.

But first, we start small. We start with the incremental step of setting risk tolerance at the project level and generate documentation and history. That documentation should capture the tolerances, how close the project came to the tolerances, and the relative impact of any risks that affected the tolerances. That information will build the organization’s capability to assess risk, and in the long term–manage risk.

ProjectConnections.com is the leading Web-based resource for people who manage projects and teams. It provides access to practical information about project and team management skills and processes; forums where participants can interact with peers and experts; and comprehensive guides to tools and other project management resources.