Risk Management: How do you overcome risk resistance?

Question

We know that risk management touches every PM process, from planning through execution through closing. It is taught in the most basic of PM classes and, if you were to ask, most would likely indicate its importance to project success. However, in implementation, I find there seems to be resistance in participation in the process. There is almost an implication that, if I were to raise threats about which I am worrying, then I must not be managing my work very well. There is an implication that escalating risks is 'airing your dirty laundry.' In a seller-buyer relationship, the seller seems to be hesitant in raising risks where the root cause may be the buyer. There is, of course, the resistance if the root cause was something the seller caused or should have handled better in the past.

There is ongoing confusion, I find, with folks truly understanding what a risk is and how to analyze their complex environment to discern the threats from current issues. That's an ongoing problem but my question really is about overcoming risk resistance. What techniques have you applied on your projects that seem to overcome this phenomenon?

Answer 1

That's a great question.

I think that one of the reasons for the attitude towards risk - washing your dirty laundry in public, if you like - is the way that risks are expressed. Typically, you will see risks in a risk register (if one exists) being expressed in terms such as: Lack of resources; Insufficient funding; Poor quality testing; Etc.

By deliberately phrasing the risk in a different way that has real meaning to the senior people around the project, I believe that the appetite for risk management (and hence the resistance to accepting risks) will change dramatically.

Try this: Start every risk statement with the term "There is a risk that... " then explain the risk in very specific business terms. For example: "There is a risk that the funding available to the project will be inadequate to purchase resilient hardware, thereby causing a reduction in sales and thus profit during any interruptions to service." The business can then make a decision based on the likelihood and impact of the risk, as well as an analysis of any mitigating factors.

In my experience, this does work, although it does sometimes take a while for the early resistance to subside.

Answer 2

I've found 2 ways to make it work...

1) Give each PM a budget to attack risks. If a project is estimated at 2000 mandays, the PM tacks on 200 of contingency and 100 of risk management. Then they estimate the likelihood and damage of risks, and assign people to work against the risks with the highest Expected Cost (probability * cost if incurred) out of the risk budget. In this case, it's a preventive form of spending contingency.

2) Create a culture of "Issues are bad if they could have been anticipated but weren't. You aren't punished for well documented risks with agreed upon contingencies." In the end it's a cultural thing. The only thing more painful to a culture than risk management is having to explain cost and schedule overages.

It isn't easy though!

Answer 3

Taking a stab at the kind of world you might be operating in... cost containment can be an effective way to position risk management. The project will be cheaper and more predictable if risks can be forecast, addressed and a risk response planned for, ahead of time. The earlier the cheaper.

Answer 4

Great question!

It seems people just want to start doing things to "Get things done" instead of first taking the time to 'Think things through"; they favor 'issues' because they can immediately jump at them to resolve them, instead of doing things to prevent something that might or might not happen in the future. I am often amazed at the short planning horizon some people seem to have.

Furthermore, I think people are already overwhelmed with the first part of a journey (or a challenging project), that they don't whish to think much of the second part that is still so far away, is still much of a black box and so it seems to frighten us even more. If there are any problems we will get to them then; right now I already have enough things to think of thank you very much.

So it is always like "we'll see how we get across the river when we get there", instead of "we'll cross the bridge when we get there" :-).

So it is a cultural thing: point 2) of MathAttacks answer was spot on. I also think it is inherent to some people's personality type; maybe MBTI or some other personality indicator can give some answers there.

As it is, to apply risk management well, it needs constant education of your stakeholders.

Here are some actions I apply:

• Once more, the WBS is my closest friend here. The visual aspect of the WBS helps eliciting and assigning potential risks more easily. People are much more likely to react wen they see individual elements that they are more familiar with. When they see some risks defined on other elements, they'll think about their own subjects more closely. Color-coding WBS elements in terms of risk-status is a positive trigger as well, and will often result in replies like: "why is there nothing on this thingy here, didn't you know that ..."
• Giving lots of examples and the way they were handled (or not) in the past.
• Explaining the consequences in a measure your target audience can understand . The answer of Iain9688 is key here. So for instance discuss the risk of incomplete data-conversion with your customer in terms of overall project delay and additional cost, and with your team in terms of the extra hours (possibly overtime) of manually correcting the data in the database ...
• Treat risk-review as a fixed topic on the agenda of your status/progress/steerco meetings the same way as you would manage your issue list. The point is to keep the risk-owners aware of their responsibility.
• Discuss risks during individual talks or one-on-ones with your team and stakeholders; not everybody wants to share possibly bad things in public.

I have a mantra I repeat sometimes when I feel people are reluctant to discuss possible risks and progress (it is not mine, but I don't know its origins):

     > No news = bad news
     > Bad news = good news
     > Good news = excellent news

The sooner a risk, lack of progress, possible roadblock is communicated, the sooner something can be done about it ...

Answer 5

One trick that can work is to provide the team with some risks about the PM processes and general project risks. For example, there is a risk that one or more key stakeholders aren't identified, or that resources could be taken away, or that product acceptance criteria change, or whatever. That helps to get the ball rolling and shows that you ask of yourself what you ask of your team.

What I find is actually more challenging than getting the initial risks listed is making sure there is regular follow up from the team to update/retire existing risks and add new ones as the project evolves. For that I use planned project review meetings with risk assessment as one of the agenda items - and then harp on it remorselessly in the three weeks before the review meeting.

Answer 6

Two critical insights will help create a culture where the identification and management of risks is a positive aspect of project management and not whining or "airing dirty laundry".

1. Properly phrase the risk. Lain has a good suggestion, but I've seen the the if/then format be just as effective. If/then formulates the risk as an event that might occur and the impact if it does, and it is more difficult to write overtly negative risks. For example:

   Our awesome webapp, which helps people easily post LOLCats to social networks, relies on an undocumented Facebook API. If Facebook deprecates or modifies the API then our service will be down until we can engineer a work-around.

   A poorly worded risk might focus on the limited funding that cause the developers to use a hacky backdoor or the lack of coding standards and is more likely to be taken as a personal attack by those involved in the original decision. If/then focuses the risk on factual statements and assessments of what could go wrong and the consequences.

2. Have a mitigation plan. The mitigation plan embodies the advice to have a solution when pointing problems. The mitigation plan describes the concrete steps that will either reduce the likelihood or the consequence of the risk, ideally quantitatively and with an estimated cost and schedule to implement. This approach diverts the focus away from the problem and focuses it on the solution, which is more productive and less about airing issues and more about proposing solutions.

   In our LOLCat example the obvious step is to not use the API, but just thinking through mitigation steps can lead in unexpected directions. For example, what if we expanded to Tumblr, G+ pages, and Twitter. This would mitigate the risk of this or any other Facebook issue completely taking down our service.

A well worded risk prevents people from immediately tuning out. A good mitigation plan helps to move the team away from dwelling on issues and towards focusing on solutions.

Answer 7

It was always a balancing act. I tended to work the portfolio manager to understand their point of view on the issue and reach a consensus with them as to whether or not to grant an exception. Otherwise, you would wind up escalating it to their manager or senior executives.