Distributed Risk Register and Facilitation of Risk-Based / -Aware Thinking

Question

Over here, it was aksed how to overcome reticence to use RAID logs (with A referring to actions, not assumptions). The general approach, already suggested by the OP, would be to rid the (in this case agile) team of the docuemnt formats and aspects which don't fit into their world, and let the PM take care of the coordination between the two worlds of different mindsets and docuemnts to be maintained.

In this answer to the above question, it was suggested to keep the PM's Risk Register short and have the agile team maintain their own, with them either finding the document useful and maintaining it by themselves, or being encouraged to do so:

Your logs should contain only your top five or six items. Maybe seven. These are the highest priority items that you need to track, the most expensive, the most impactful. The rest fall off and are delegated to the teams, who themselves likely maintain their own logs...or should be encouraged to do so. By doing so, the logs remain truly relevant and important and even a SCRUM team will look at them and find them useful, I suspect.

In my view, this suggesting triggers the following questions:

1. What are your experiences with a distributed Risk Register regarding a) maintenance, b) presentation, c) when the event materialises?
2. How do you deal with a culture of non-risk-based thinking and widely accepted excuses to remain in that comfort zone a) in general and b) in particular when the team is supposed to maintain its own risk register?

Answer 1

As always, @DavidEspina's answer is excellent. On the other hand, since this problem presented itself in my environment this morning, I thought I'd share.

I keep a Risk Breakdown Structure, which tracks risks at a fairly granular level - we use a different structure, but effectively I track at the L2 of the WBS (L1 is the end deliverable, L2 is the work packages needed to create that deliverable). I produce daily charts of risk and change in risk.

My colleague keeps the risk registry, which is our repository of actionable risk. We only escalate risks to the registry if:

• Mitigation involves cooperation by multiple coordinated actors.
• We have no mitigation strategy and need to escalate to stakeholders for consultation
• The risks in the RBS demonstrate a pattern. (There is a cluster of risks that keep recurring over and over. I can manage each of them, but by escalating, I can get the stakeholders to change the inputs and thereby avoid the risk.)

Your question is extremely perceptive. It is an axiom of PMBOK that the PM is an autocrat able to cancel the project if everyone does not follow correct process. That is an academic assumption to portray effective project management.

We all want to work on process mature projects in which everyone understands that working together leads to more successful outcomes. But the truth is that in most of our environments WIFM is stronger than PMBOK. The truth is that most PM's labor away in isolation working models to enable them to predict project impact and only reveal the products of the model. (After months of work, I finally got my project mature enough to work with EVM; I put up the graph and before I finished the first sentence, my boss said, "You've already bored me." EVM is a fantastic tool; the effort to impose EVM is valuable for it's own sake. But all the boss wants to hear is, "I've studied the problem; team 2 is late 80% of the time by at least 33% of their estimate; either we reschedule the project based on how they act, or we assign most of their work to another team."

Risk Management is most valuable for the discussions it generates. Nobody cares whether the risk is a 2 or a 3; the value is when somebody says, "I think that will happen less often if we buy a thicker pin, or fire Ted, or involve QC earlier, or ...." Unfortunately, I know of no way to drive people up that hill of risk management maturity.

One of my teachers in high school said that "everything begins as art, becomes science then engineering, then ends as craft." In PM, everything begins as tribal knowledge, then a private model, escalates to a badly managed project, then a skunk work, then operations. You're at the backroom model stage. Ain't no way but up.

(WIFM- What's In It For Me?)

Answer 2

On projects that I have overseen, I have not had perfect success in delivering my vision of how a risk log should look at the project level, in that it should contain the highest six or seven threats facing the project and that lower level logs can and should be used by the various teams. The project level log quickly grows into a highly controlled deliverable as the original RAID question conveyed.

At the project level, I would have an individual assigned as the project's risk manager, who will over additional risk management roles at the task level. That person would encourage or cause the lower level risk managers to maintain their own risk logs and would "audit" them as necessary to ensure or facilitate compliance and reasonable efforts in this task. If the logs are poorly maintained, that becomes an action for the teams to cure, and that action would be overseen by the PMO. Also, based on the risk analysis at the lower levels, the project risk manager would have the authority of escalating an identified threat to the project level log and then managing that threat occurs at the highest level.

All this said, the culture of non risk based thinking, or what I refer to as risk management resistance, prevails, seems to be systemic across all projects, and is terribly hard to overcome.

If you were to survey your teams, I would suspect 100% of them would agree risk management is an important--maybe the most important--task to do on every project. However, we seem to want to avoid it, both folks who raise threats and those who need to hear them.

People prefer guarantees; we seem to be uncomfortable with uncertainty; and our eyes glaze over when we start talking statistics, probabilistic distributions, confiden..... Fell asleep, sorry.

We don't want to raise threats on projects we're delivering because it comes across as if we are not in control, it airs our dirty laundry, it transfers ownership of its mitigation to the risk escalator when, if not raise, we can blame force majeur or other stakeholders, and on and on. We are told there is no try but do, failure is not an option, pessimists are negative people with whom no one wants to work, etc. All of these are risk management killers.

On the other side, for those who need to hear the threats, we consequence those who raises them. We tell them to fix it because "this is why I hired you." And then we end up making them report to us on this threat several times a week, micro managing every step. And if the threat materializes, we blame the risk escalator no matter how hard and how rigorous the mitigating activities were while we reward the firefighter who made no attempts to predict and avoid rough waters ahead. In all, there are serious consequences raising threats.

For a solid, mature, and capable risk process, everything above needs to be the opposite of what occurs. Raising and mitigating risks need to be rewarded, even if mitigation fails; while surprises and the heroic fire fighting need to be "punished," even after successful recovery. The opposite seems to occur right now.

All of the solutions I have tried seems to run counter to how we sort of naturally respond with threats. I think the solution here is more about human psychology than it is around processes, tools, logs, etc. This is more of a rant than an answer but this is really a complex issue.