23. Test for Risk Management

Whether you are the one responsible for risk management or you are somewhere above that responsibility in the hierarchy, you need some objective way to understand whether or not the work is being done. But why is that? Why can’t you just assume that people responsible for managing projects will be naturally drawn to managing project risks? The reason is that there are powerful false-positive indicators at work in organizations. These false-positives tend to give an unwarranted pass to anything that calls itself management.

Imagine that you are managing above the project level and that risk management should be taking place at the project level (within the projects or peer to them). The false-positive indicator works like this: You reason, “Hey, my people are running risky endeavors, so of course they are managing the risks. What is management, after all, but anticipating and steering around the various obstacles that might sink the project? My managers are professionals—they certainly wouldn’t let themselves focus only on the easy stuff and ignore the real dangers.”

Sounds good. The only problem is that this line of thinking ignores all the disincentives built into or buried in the corporate culture. These include can-do thinking, an unwillingness to disappoint, the imperative to preserve the rosiness of the rosy scenario, the fear of expressing uncertainty, the need to appear in control (even when real control is illusive), the temptation to use political power to trump reality, and the kind of short-term thinking that plagues all human endeavors.

These are powerful forces. They can make apparently thoughtful people shy away from reasonable management and adopt instead reasonable-seeming management. There is a difference.

A set of objective tests to determine whether or not risk management is actually taking place can be of value not only to upper management, but also to risk managers themselves.

1. There is a census of risks. The risks in the census include all the core risks of software projects plus the risks that are unique to that project. The risks are causal in nature (things that will cause the dreaded outcomes rather than just the dreaded outcomes themselves).

2. There is an ongoing risk-discovery process in place. Risk discovery is open and welcoming to all participants. Specific steps are taken to make it safe during risk discovery to articulate unwelcome ideas. There may even be an anonymous channel open for people to convey bad news. This is a scheme that works well in some of our client companies. (It’s not used often, but when it is, it’s invaluable.)

3. There are uncertainty diagrams everywhere. They are used to quantify the causal risks and to convey aggregate risks and expectations. The corporate culture is beginning to think it unprofessional to make commitments without explicitly noted uncertainty.

4. There are both goals and estimates for the project, and they are never the same. Goals may be at or near the nano-percent performance level, but the estimates must be much more conservative. If the goal is a twelve-month delivery for a given project, the estimate should project that delivery will occur at least as far out as Month 18. In any event, the specific confidence level to be associated with any commitment is indicated by the uncertainty diagram.

5. Each risk has a designated transition indicator. There is ongoing transition monitoring to detect risk materialization.

6. Each risk has an associated contingency plan and a mitigation plan. Contingent actions are included in the work breakdown structure as possible activities. Mitigation actions are included as definite and are performed on a timely basis in advance of the earliest need for contingent actions.

7. Each risk is evaluated for exposure.

8. There are quantified value assessments for the project. There is a commitment to measure the value that is realized after the project. There is a value-based rank-ordering of system components, provided as input to version planning.

9. There is at least some degree of incrementalism built into the project plan. Some or all of the versions are actually delivered to stakeholders or are pseudo-delivered (representing all steps included up to but not including actual delivery). Time and effort and relativesize information is captured for each version completed, and used as a mid-to-late project closure metric.

If your organization can pass at least the first six of these tests, risk management is a factor in your projects and is serving you well. If not, you still have work to do.

If you can’t pass any of these tests, then we have to conclude that although your organization may talk a good game about risk management, it isn’t actually doing any. Don’t be too hard on yourself about this; most of our industry pays more lip service to risk management than it actually performs. But don’t be too easy on yourself either. The easy assertion, “Of course we’re doing risk management,” in the absence of any objective evidence, is part of the problem. It lets you feel good in the short term but provides no long-term protection.

Getting past this glib assertion is the first step in making risk management work for you. It’s the first step in growing up.