PM Articles > Kent McDonald > Risk Management Takes a Village

Risk Management Takes a Village

(Including that IT guy up on Third and Main)

In my current endeavors I have the wonderful opportunity to work with a wide variety of project teams, coaching them on such diverse topics as leadership, collaboration, decision making, and of course risk management. One comment I have heard in every risk management interaction never ceases to surprise me. In my sessions, I discuss the various ways teams can manage risks by considering the approach they use and the decisions they make. Without fail, as soon as we finish these discussions a developer, tester, or business analyst will say something like, "That's great Kent, but I don't see how risk management applies to me."


Maybe the project management community has done such a great job of claiming project risk management as their domain that all other professions have gladly washed their hands of that responsibility. Trouble is, risk management is not very effective if the people in the best position to identify potential risks and affect their impact or probability aren't paying any attention. What's even scarier is that I often hear these comments in financial services and insurance organizations, two industries that make a majority of their income from properly managing risks.

Or perhaps the coverage of risk management has just focused too much on the mechanics and not enough on the underlying premise, leading team members to believe that it's "not their job" to initiate discussion and track project risks. Even if that's true, they are still responsible for getting involved in the discussion. The really interesting thing is that most experienced project team members have all the knowledge and perspective needed to be very effective risk managers, they just don't realize it.

Here's a case in point. Recently I was working on a development project that was introducing configurable data access settings. This meant that any reasonably intelligent administrator (or at least any with the appropriate access rights) could change field-level permissions in the application without changing the code: A feature that is quite powerful, and potentially quite risky. We were discussing whether we needed to create a new role in the application to handle a particular requirement for a group of users to have write access to one specific field. As we considered the options, a developer who had been working with the application for several years spoke the language of risk, without realizing he was doing it.

"Well, we could just assign the people that need to edit this field to this role here, but then they would be able to edit all these other fields, which could be fairly bad. Or, we could take this role here which already has fairly similar rights and just open up that field, which could also have some consequences. I suppose we should just create a new role. That may be creating a precedence resulting in having to great a bunch of new roles for similar situations, but the chances of that happening are fairly low, given past history."

He covered probability, impact, and options for addressing the situation, all without throwing all the risk management speak around. It didn't matter how we defined the approach to dealing with the risk, just as long as we had one. The true purpose behind risk management is not to identify risks, but to guide project actions and ensure that the level of risk facing a team is acceptable. Not too much risk, meaning the project is doomed to a ghastly death, and not so little risk that there is no corresponding reward. As Lister and Demarco said in Waltzing with Bears, if you are doing a project with absolutely no risk, it is most likely not worth doing.

Once you strip all of the risk management language away, risk management is pretty simple. It's about thinking "What could happen?" and deciding what actions the team should take. The goal is to make sure that the good things do happen and their impact is magnified, and that bad things don't happen (and if they do their impact is minimized). It's the team members -- developers, testers, business analysts, subject matter experts, people who live the process every day -- who know what those good and bad things are, and who usually have a fairly good idea how to address them. Make it easy for them to identify those things. Don't get bogged down into the terminology of risk management.

Although teams don't need to know all the risk management terminology, it certainly helps to give them some thought starters if you are trying to identify what risks may exist. I encourage the team I'm working with to think of three types of risk, primarily because thinking of it in this manner helps to make sure that you've considered most of the key risks. The three types of risk are delivery risks, business case risks, and collateral damage risks.

Delivery risks are the ones that project teams most often think about. These are the things that prevent the project from finishing; all those nasty things that could cause the project to be late, go spiraling over budget, or fail to deliver the agreed upon scope. "Ah ha!" the team members say at this. "See, it's that iron triangle thing. That's a PM's job!" Yes ... but any PM worth their salt will tell you that they have no hope of knowing what all those nasty things are without the input from the team. Their role is to facilitate the discussion that identifies those risks, determines whether the team should care about them, and decides what to do if they do care. The PM understands the concepts of probability and impact, and can categorize mitigation strategies. Project team members know what the probability and impacts are, and are the ones that will come up with the strategies, regardless of how they are classified.

The second type of risk is to the business case. This means that the project delivered, but it delivered the wrong thing, or didn't deliver sufficient value. This is the risk that the team is not working on the right things. Product owners typically have the biggest impact on this one, but the team knows when the stuff they are working on doesn't make sense. They have the advantage of looking at things from a more objective view point than the product owner, who frequently feels like the project is their baby and would be the last to call it ugly. It's up to the team members to question why the project is being done, understand what problem it was trying to solve, and identify the risks of delivering the wrong thing or solving the wrong problem.

The third type of risk is collateral damage. This is where the project delivers value but unintentionally causes harm to some other part of the organization, perhaps by introducing extra work for other parts of the organization, or by introducing a new product that unintentionally steals market share from an existing product. As with risks related to the business case, team members often have the most insight into potential collateral damage, especially the ways that a project could impact another part of the organization. As soon as one of those concerns occurs to a team member, they have a responsibility to bring it up to the entire team to discuss whether it stands a good chance of happening and, if so, what should be done about it.

So the next time you are getting ready to work on risk management, resist the temptation to fill your project team up with the theory of risk mitigation approaches and impact and probability ratings. Instead, remember that the answers are in your organization, remind them of the different types of risks that I mentioned earlier, and ask them what could go terribly wrong (or fantastically right) with your project, and what they think the team should do about it. You'll get to the same point, and may have more buy-in in the process.

Related Links
Our Risk Checklist is another way to be sure your risk assessment is covering all the bases. Use a Risk Strategy Selection Matrix to decide how to approach the risks that are worth worrying about. For more, see our Burning Questions on Risk Management.

Not all comments are posted. Posted comments are subject to editing for clarity and length.

Thanks for your article. In our South African context with its poverty transformation challenges and the inter-connectedness between the historical political conflict, poverty and sustainable development, risk management is crucial, because project management is an important tool to transform the historical conflict structure. Community Developmental Projects, are implemented within an environment with a high conflict risk - politicing projects and its implementation. Within this context, project management should also be seen as a conflict resolution and peace building tool. Courses focussing on the developing countries should take that into account.

The comments to this entry are closed.

©Copyright 2000-2017 Emprend, Inc. All Rights Reserved.
About us   Site Map   View current sponsorship opportunities (PDF)
Contact us for more information or e-mail
Terms of Service and Privacy Policy

Stay Connected
Get our latest content delivered to your inbox, every other week. New case studies, articles, templates, online courses, and more. Check out our Newsletter Archive for past issues. Sign Up Now

Got a Question?
Drop us an email or call us toll free:
7am-5pm Pacific
Monday - Friday
We'd love to talk to you.

Learn more about ProjectConnections and who writes our content. Want to learn more? Compare our membership levels.