The problem with project risk management

If Risk Management is not well done then the argument to not bother doing it is true. The problem is actually that Risk Management is not well done. Risk identification and analysis (likelihood and consequence) are only part of the story. The important part is the Evaluation - what is my risk appetite or what is tolerable. If likelihood and/or consequence are high enough then the risk will not be tolerable and I will take steps to improve it. However, if the risk is deemed as tolerable then I won't take any further action. The other point is that  Risk Plans makes sure that ALL actions to deal with risk are documented, part of the work of the project and understood by all stakeholders.

My experience with Risk Management is that the risks that actually occur are quite often not the ones considered in the RM plan. However, being risk aware (not risk averse), having an active Risk Management Plan with documented responses for the risks that had been considered usually makes it possible to take some action when one of these unknown unknowns occurs. 

What I believe is essential is to get the management of risks into perspective: be constantly aware of things that might go wrong but don't get obsessive about it. So often Risk Management is seen as a bureaucratic exercise to get a tick in the box. In the UK many people and organisations talk about "Risk Assessment" which is only part of the exercise. I've even been told by a student organising an X Factor event in school "don't worry about the Risk Assessment, the office is doing this" - in other words the organisers weren't considering risks! I pointed out the risk in this approach!

I've started running simple workshops for volunteer organisations to get them to adopt simple management techniques including Risk Management - see www.dmharris.com

Michelle; your article raises many good points and identifies the inability or ineffectiveness of traditional Risk Management in identifying the unknown risks. But with regards to the known risks, whether "canned" or not, what you've described is only a component of Risk Management, which is the identification and assessment.

To your point, once there is an understanding of the significant Risks, their relative likelihood of occurring and their potential impacts to cost or scope or schedule (among other items), the next step is to plan and execute risk mitigation - what are the things that need to be done to reduce the likelihood or impact of the risk. It's this last step that is often ignored, which is where the value of Risk Management is obtained.

I'd agree that "risk management" as it's commonly practiced is largely a waste of effort, other than to prepare excuses for the inevitable issues that will arise.

To those who say it’s better to have a plan vs. no plan, and that it’s better to have risk management than not, who can’t agree?Of course, a literacy vs. illiteracy frame offers little room for debate on just what the risk management processes and content are, which is the point of the article.

The problem with project risk management is that it adds its own risks:

-The illusion that risks are quantified and mitigated.

-An implicit de-emphasis on learning throughout the project, as replaced by risk management.

-The diffusion of responsibility from the PM and upper management.

-The replacement of issue escalation / resolution with risk management, especially from an upper management bandwidth and accountability perspectives.

Templated risk management, often done by a content-free PM as a check-the-box activity and passed off as something more, will never replace true shareholder discussion and deep understanding, regardless of how many 3 or 4 character accreditations appear after their author.  Upper management should not be looking at the risk management plan, but should firstly be questioning the biggest risk: the PM, about their project plan, the approach, what they've learned, and what they need.  Far too often "risk management" ends up being a discussion about the wrong things (wasting upper management's and everyone's time), giving the illusion that the major risks are quantified and mitigated.  Unfortunately, project results don't support this. 

Our company recently started using risk management on larger, more complex projects.  The biggest benefit I've seen is that reviewing it weekly or montly gives visibility to all stakeholders of the risks and their proximity. Previously only the people most intimate with the project knew about them until they turned into issues and it was too late to recover gracefully.

The only heartburn I have here is that the article assumes that project teams are doing a half-hearted effort at the risk management process, ergo, we should abandon it altogether.  I don't believe that's the case for many of my clients and in many organizations.  The "same risks" that are identified over and over have a different impact on each project.  The sample risk statements identified here are incomplete...including only the event.  For many organizations the simplest, fastest way to improve their risk process is just to start stating risks as full sentences including both cause and effect.  And just because organizations fail to heed risk admonitions doesn't make the admonitions any less valuable.  Doctors tell many patients, "Your blood pressure is high, increasing the probability of a fatal heart attack."  Since we know that's part of their mantra, should they drop the admonition?  I think not. 

Alex I like your mention of "real risk". This is a term used by one of my clients to describe exactly the unknow-unknown risks that might crop up during the project. These are often hidden from the view of the view of the project manager and the team. The fist part of any risk review is the open up the Johari window do that we can see the project from the perspective of other stakeholders. Often this need research and exploring the project from different perspectives and ass you say the support of all the key stakeholders. To often it it just a matter of getting the risk review done so that we can move on to the next task.

I have to agree with the author that if you identify risks, you should consider those risks in your plan. I used to be one of those PMs that produced detailed project plans that spelled out everything to the Nth degree. I spent more time updating those plans as the project went on than managing the project. Now I'm managing  an Agile software development project that has more risks that you can shake a stick at. Sure, we fill out the top risks forms, but, for us, the top risk is stakeholder involvement and buy-in. Everything revolves around that.

I like this thread. The issue with risk management is that often the risk being managed is project risk. The real risk is the risk of the project on the organisation, its people and customers. Risk is too often though of as the risk of not meeting the original specification, financial constraints and timescales. Real risk management in defense, health care and banking are far more complex. Projects need to manage risk with full buy in by all participating stakeholders.

To say that Risk Plan is only a way to obtain project approval, means that you do it only once and forget about it. Risk planning, like all other project planning processes is a continuous affair. So the risks which were not apparent at the time of project approval would become clearer now. It is also not correct to say that just because you can identify a risk, the probability of its occurring is high. In a continuous risk planning process, the probability value may increase or decrease at a later stage and so also the risk impact value. The picture is dynamic and hence has to be updated regularly. It is project manager's job to scan environment both for opportunities and risks.

And to argue that unknown risks do occur inspite of risk planning and therefore risk planning should not be done, is like abandoning entire project planning because projects do deviate from plans. Any such events of unanticipated risks materialising, should make project manager think as to why he/she could not read the risk warning signals in time and should be better educated for the next projects. This is how project manager's skills and competence increase with every project.

Good comments one and all. I like that PM is risk management - yes. In the IT field we seldom have Disasters but Disaster Recovery Planning makes any disaster much easier to face and overcome - as Adam stated  - anybody with a plan is better off than anybody without one. 

The building of a risk assessment often starts by looking at previous risk assessments and using many of the same risks.  But just because they are copied does not mean they are not legitimate and it is the exercise of risk assessment as a part of a larger planning process (risk in conjunction with communications, change management, schedule and cost control) that is beneficial.  Simply put, anybody with a plan (including a risk management plan) is better off than anybody without one.  

The PMP version of risk management is pure feel good.  Any project manager using the PMP version of risk management just hasn't matured.  The public (the PMP 'canned' risks) is one list, and there then is the Project Manager's risk assessment (that includes the risks imposed by management/sponsors/customers/team members and the thought processes associated with the mitigation of those issues).  

Of course it's the 'unknown/unknown' risks that impact the project by surprise.  Duh.  The more risk assessment you do in your project, the more exploration of potential mitigation strategies you've undertaken and the more prepared you are for any type of risk/issue materialization.  

Project management is risk management.  What do you think created the evolution of the project manager in the first place?   Project managers themselves are a risk mitigation.   

Anybody that thinks doing continuous risk assessment is for a novice project manager is either deluded or self-aggrandized.  

Thanks for being another voice in the wind articulating important points that I’ve been emphasizing to my consulting clients and seminar students for years.Risk has to involve uncertainty.I contend that much of what shows up on the standard project risk templates is ineffective management which is certain to happen, and thus not a risk, but unfortunately seldom is addressed as ‘risk’ or otherwise.That does not mean that risk management is a total waste of time (although often much of it is perfunctory paper shuffling), because it often can identify and hopefully address other causes of project risk.

Typical project risk is only part of the story.Testing also deals with risks, but a different type—risks that the project’s products will not provide necessary value.Thus, testing involves identifying potential product risks and determining appropriate testing techniques to detect said risks that occur and give confidence that said risks are not present.My Proactive Testing™ methodology uses a number of special techniques that identify many ordinarily-overlooked (unknown unknowns) large, medium, and small product risks.

Oh I like this. What you say is common sense and a breath of fresh air. Having said that, I'm sure I'll continue adding a "risk assessment" section to my project definitions, but perhaps with a few added phrases based on your article.

In general I value IT risk management and believe it really can help protect an organisation. (I've written about it - see http://www.techrepublic.com/blog/smb-technologist/smb-it-risk-management-in-action/.) But you're absolutely right that we're fooling ourselves to think we can plan for everything.

Interesting post Michelle! 

When we analyze with a company their risks, we always try to explain them that "zero risk is just a tale" and after define different controls for a risk, you can reduce their impact or probability but is difficult to think that you eliminate it. Risk Management help you to have a better strategic vision of your company but doesn't work miracles.