3

When creating a Risk Analysis document, what qualifies as a reasonable risk? As a rule of thumb we expect 5 risks to be tracked. Is it reasonable to include risks such as the building burning down or major storm knocks out power for 6 weeks? While the probability of these events is low, their severity is extremely high, making them seem like candidates for the risk log.

Wouldn't it be more useful to expect the PM to come up with project-specific risks, as opposed to company- or country-wide risks? Does anybody have a good rule of thumb for deciding what is a reasonable risk to be included and tracked?

  • 1
    "Reasonable risk" sounds a lot like "acceptable risk" rather than what I assume is your intended meaning of "a risk worth tracking." I edited your question slightly to make that more clear, but didn't want to drift too far from your original intent. Please continue to edit to make the distinction, if necessary. – Todd A. Jacobs Mar 3 '16 at 0:32
  • Thanks, @CodeGnome - your edit makes the question clearer, and is appreciated. – Danny Schoemann Mar 3 '16 at 9:05
4

Q: What qualifies as a trackable risk? A: Anything that anybody thinks is a risk to the project goals (usually time, cost, scope and quality)

As a Project Manager I try really hard to persuade anyone and everyone that has an interest in the project, to raise any risks they see fit. At the same time I encourage a culture of openness to risk and especially that no-one should judge or belittle a risk raised by anyone. If someone can foresee a problem I want to know about it. Maybe we'll investigate the risk, find that it is not relevant, and close it down pretty quickly... Or maybe we'll find that someone just uncovered the most serious risk to my project- Never pre-judge!

Having a "rule of thumb" about how many risks should be managed is pointless in my opinion. If there are no risks then all that does is waste time forcing a PM to construct risks just to tick the risk management box, which in turn devalues active risk management for all concerned. And setting a notional limit means that people will stop looking for risks when they have "enough" risks on the books. The risk log should have all the risks that anyone perceives on it and if the risk profile of the project is such that there are 20 open risks then so be it. Equally, if there is only one open risk against a project, but evidence of a solid risk management process, then again, so be it!

So, what to do with enterprise-level risks? This is my own philosophy:

  • If there is an identifiable risk, but there is nothing I can do to mitigate the risk on the project, then I log it and forget it. If there is literally nothing you can do about it, make sure you tell your project board that it exists, but don't waste time trying to do anything about it. The project board may find that there is something that can be done about it and they will soon tell you

  • If it is a true enterprise-level risk, but one of a class of risks that are common to all projects in all enterprises (i.e. the building might burn down), then use judgement. Everyone knows that all buildings may burn down and everyone knows that if that happens all projects are on-hold. The company should mitigate these kinds of risk at a company-level using Disaster Recovery. Re-stating such risks on a project risk log, particularly to pad it out, will make the PM look a little foolish. BUT, if the project is business-critical, and you find that Disaster Recovery will not handle the situation, then you have a real risk that you need to notify. Probably no-one will be able to mitigate it if it is a large-scale risk, but you need to show that you have thought about it and all members of the project board understand the risk, its likelihood and impact, and the fact that no-one can really avoid or mitigate the consequences if it hits

  • Don't put sensitive risks on the open risk log. You might feel that there is a risk that a key person is about to leave, with disastrous consequences to your project. You need to raise this kind of thing directly and in person with key steering group members- no-one will thank you for making it an official open risk on the log (which is somewhat counter-intuitive but is where politics overlaps with risk management)

  • Don't be afraid to close risks where you have determined that the impact, likelihood or consequences are no longer relevant. There is no value in keeping a risk log full of things that have been investigated and found to be not currently relevant. Close them. This allows the entire team to focus on what is relevant. You can always re-open or re-raise risks. Be active in your review and management of the current ever-changing risk profile of a project. Allowing the risk profile to go stale is, arguably, more dangerous than not having a risk log in the first place

  • 1
    Good point to keep in mind: sensitive risks on the open risk log – Danny Schoemann Mar 1 '16 at 8:58
2

Model-Based Risk Assessments

Does anybody have a good rule of thumb for deciding what is a reasonable risk to be included and tracked?

Your risks are driven by your threat model. The filter that you use to identify meaningful risks should be part of your project plan, and is often baked into your project assumptions. For example, it may be reasonable to assume that a software project is not placed at great risk by spontaneous human combustion, so you would probably leave that type of risk out of your threat model. On the other hand, staffing turn-over, schedule risk, or intellectual property issues might be germane to such a project.

Stakeholders and Senior Management Own the Risk

The truly important thing is that your risk log is a project artifact that should contain whatever risks that the organization has thought about and agreed were relevant. The risk log should also clearly identify whether those risks will be accepted, transferred, or controlled.

You aren't expected to plan for every eventuality; a project manager's role is to capture, document, and communicate risks identified by the project to its stakeholders. After that, the responsibility belongs to them.

  • as PjM I've always been expected to add alternate solutions and/or workarounds to the Risk Document. Not only to capture, document, and communicate them. Is that not SOP? – Danny Schoemann Mar 3 '16 at 9:09
  • 2
    @DannySchoemann Project managers often have responsibility without authority. Who's funding these alternative solutions? Who has approved the work-arounds? It's probably not you, so why accept responsibility for it unless the authority has been delegated to you as part of the project charter? Don't fall into the political trap of "taking ownership" of someone else's responsibilities, especially those that properly belong to senior management or the stakeholders. Recommending alternatives or suggesting controls is fine, but the risk and responsibility still belong elsewhere. – Todd A. Jacobs Mar 3 '16 at 21:01
  • @CodeGnome +1 on your comment. very wise words. As ever. – Marv Mills Mar 4 '16 at 15:12
1

By "qualify", I assume you mean captured in your risk log. Although used this way, I don't think the log was ever intended to capture the universe of risks threatening a given project. I think you focusing on five--although I would not have a rule of five--is a good way to focus the team on what matters.

The general rule I use is to capture a risk in a formal way--risk log, documented risk assessments, mitigation plans, etc.--for those threats that 1) require formal communication/escalation to some stakeholder group; 2) require formal approvals for allocating resources to mitigate the threat(s) and/or create contingency reserves; 3) the threat is such you need/want to monitor mitigation progress; or 4) CYA when you cannot get anyone to listen.

Organic risks, such as weather, typically would not meet one of these criteria. I define organic risks as naturally produced by the project or by nature, everyone knows them inherently, and mitigation is often "built-in" the project plans anyway. I have, however, documented a few organic risks from time to time because of something rather unique about the organic threat. For example, on one project, we had a ton of work to do over the holidays during the winter and most of the workers traveled in. It seemed everyone was optimistically ignoring the possibility of no travel caused by weather and the fact the most people like to take vacation during the holidays. Therefore, since everyone was on the happy path, I escalated this risk because it met my criterion #4.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.