The idea behind logging risks is to consciously identify where your project can go wrong so you do something about it before it actually goes wrong. Risk management is pertinent for all projects, regardless of your way of working. Not only are you lying to yourself and your stakeholders if you pretend risks don’t exist, but you are also setting your project up for failure. The best thing you can do for yourself, your team, your stakeholders, and your project is to manage risk from the outset.
Sidebar: Things can go wrong in all projects. You are setting your team, yourself and your project up for failure if you don’t plan for it.
Risk Culture
For risk management to really work, you need a culture where it is OK to talk openly about risk. In our risk case study, we had cultivated an environment where we could openly talk about risk at all levels, from the project team to our executive sponsors. This kind of open dialogue is something to strive for in your organization. But the reality is that many organizations are not comfortable talking about risk, which makes it very difficult to manage risk in your project.
If you are in a situation where discussing risk is controversial, don’t let that stop you. If you are in charge of a project, talking about risk is part of your job: if you don’t talk about the risks to your project, who will? You may end up spending nearly as much time educating your team, stakeholders and sponsors about risk as you do doing actual risk management, but you’ll end up far better off than if you simply ignore risks because nobody wants to talk about them.
Appetite?
In thinking about your organization’s cultural attitude toward risk, you will also want to understand their appetite for risk. Every organization has a different comfort level for risk taking, and that comfort will vary from project to project.
Some organizations will be totally OK with a “bull in a china shop” approach to push through a difficult change, happy to take a few lumps along the way so long as it gets the job done. And the same organization may have no tolerance for any kind of pain when it comes to a different project, where collateral damage may not be as easy to stomach.
So, before you begin thinking about individual risks for your project, establish first what the organization’s appetite for risk is on your particular project. Then, take it a step further and identify how sensitive the organization is to different kinds of potential risk impacts such as financial impacts, schedule, scope & quality impacts.
An effective exercise I’ve used to clarify risk appetite is to create post-it notes with each of the following categories of risk impact, then work with my project sponsors and stakeholders to stack-rank them in order of importance. This will then guide prioritization of risks by their areas of impacts, which may include:
- Financial impacts (cost, cash flow, ROI, revenue)
- Schedule impacts (milestones, completion deadlines)
- Scope impacts (what must be in scope vs what can wait for later projects)
- Quality (how good is good enough?)
- Resource (team capacity, potential for over-work, internal vs contract labor)
- Operational impacts (impact to ongoing production or business operations)
You can take this exercise further by establishing the specific risk tolerances in each area. For example, when it comes to schedule impacts, discuss how much schedule delay could be tolerated without severely impacting the value expected from the project – and how much schedule delay it would take to make the project not worth doing.
| Impact Category | Max Tolerable Impact |
| Operational | No impact to end users outside our change window on the weekends |
| Schedule | Customer service agents must be live July 1 before the old software agreement expires |
| Scope | Customer service agents must be able to at least create and update support tickets by go-live. Reporting can follow |
| Financial | +10% of budget |
Once you have a sound understanding of your organization’s appetite for risk on your project, you are then ready to proceed with identification and analysis of specific risks. As you do so, ensure that the time and effort you spend in risk management is appropriate for your project. If your organization is sensitive to the risks your project brings, then you should expect to spend a large amount of time finding ways to avoid or mitigate those risks. If the stakes are not that high, then you should be prudent about the amount of time spent. But even with projects that are perceived as lower risk, you should still take some time to identify and analyze the bigger risks.
Sidebar: Ensure that the time and effort you spend in risk management is appropriate for your project
Risk is Not an End in Itself
While a Risk log is an essential project tool, creating a long list of risks is not useful in itself. In fact, creating a Risk log is a complete waste of time if you don’t actually do something with it. What happens far too often is that project managers log dozens and dozens of risks at the beginning of a project because that is what they were taught to do as a PM, and they stop there. They don’t take action on them and seldom, if ever, look at the Risk log again. This is a mistake PMs everywhere make far too often, to the detriment of their projects.
Every risk you identify should result in one or more of the following actions:
- Respond by adjusting your project to reduce the likelihood of the risk happening or the impact if it does. Or, find a way to make it someone else’s problem
- Example: To manage the risk of materials arriving late, you can adjust your plan by placing your order early, looking for alternative suppliers, paying for expedited shipping or choosing different materials that are easier to acquire.
- Example: To make this problem someone else’s responsibility, you tell your contractors that they are responsible for acquiring all the materials while also committing to a schedule. Now, it’s the contractor’s problem to make sure the materials arrive on time.
- Create a contingency plan to execute in case the risk actually happens
- Example: In case your materials arrive late, you could have a plan ready for your team to perform other activities while waiting for the materials to arrive
- Deliberately accept that the risk can happen and simply leave it at that – provided that, with the risk, the project is still worth moving ahead with
- Example: Late arriving materials may actually not be that impactful – in which case you could simply plan to communicate to your team if the materials do arrive late and adjust the schedule accordingly.
