According to PMI's A Guide to the Project Management Body of Knowledge (PMBOK® Guide) - Sixth Edition, every project is “a temporary endeavor undertaken to create a unique product, service or result.” It goes on to say, “the end is reached when the project’s objectives have been achieved …”1 Since the endeavor is unique and has, by definition, never been done before, there is an element of uncertainty, and in that uncertainty, there is risk.
Free PDU Class on Organizational Readiness. Learn to Manage Change in a Project Setting.
Additionally, the PMBOK® Guide states: “A risk is an uncertain event or condition that, if it occurs, has an effect on at least one project objective.”2 So, if we put these all together, we have a temporary unique endeavor with uncertainty which may influence project objectives. And since the project is complete only when the project’s objectives have been reached, doesn’t it make sense to address and perhaps reduce the amount of uncertainty in the project?
So how do we accomplish this? We do it by looking at the project systematically to figure out where risk is, when could it occur, and how we deal with it proactively. Remember, risk is something that might happen, not something which has already happened or definitely will happen. So, we are to some extent gazing into a crystal ball. There isn’t enough space in this brief post to address all facets of risk management, so we’ll discuss the most important items.
Typically planning for risk management should begin, as the PMBOK® Guide says, when the “project is conceived.”3 Your sponsor should be considering – at least at a high level – risks inherent in the project based on their experience. Not only does this get the project team thinking about risk from the beginning, but it also helps establish the risk appetite of the organization for this project. Risk appetite is defined as “the degree of uncertainty an organization or individual is willing to accept in anticipation of a reward.”4
Once the schedule and budget are developed, it is crucial to get the team into a room and perform risk identification. In this process, you want to have the broadest possible input – team members, subject matter experts, customers, senior executives, etc.
Using brainstorming - and with reference to project artifacts such as schedule and budget estimates - the goal is to identify, without judgment, as many risks as possible. So, for example, on an IT cloud project, a risk may occur where the cloud services are not available or there might be a hacking event.
Typically, the best way to identify risk is to consider what might go wrong and, if you are together in a room, put sticky notes up on a board. (This can be accomplished working virtually as well by sharing screens, taking pictures, etc.) No risk suggestion – unless it is totally outlandish like being hit by an asteroid – should be overlooked. (You can also look for opportunities as well, such as sooner time-to-market.)
Once the team has considered all risks, the next thing is to prioritize them. This is extremely important as not all risks should be treated the same. Ideally, you want to be dealing with the high probability, high impact risks first. Lower probability, lower impact ones can be monitored.
When establishing a risk probability, it is simply a matter of stating – or having the subject matter expert state – what the probability is of the risk happening. So, to revisit our previous cloud service example, what is the probability of a hacking event?
The impact can be quantified by estimating the impact on the overall project or to a specific objective such as quality – low, high, medium. Even better is to provide numbers such as 1 for low impact, 2 for medium impact, and 3 for high impact. Then you can multiply the probability by the impact and give each risk a score. Although it is a subjective score, it is a score nonetheless. I would maintain the more the team has been together and worked on similar projects, the better their guesstimating will be.
You now have the information you need to prioritize the risks. So, let’s say the risk of a hacking event is your highest score, while the risk of your cloud services not being available may be lower. (This is illustrative - in all likelihood, you will have quite a few.)
Once you have prioritized all the risks, you can decide how to mitigate them. (There are a few options such as avoid, accept, escalate, and transfer - we’ll stay with mitigate for now.) So how do you mitigate a hacking event? Well, you can perform something called penetration testing in advance. This is where you hire someone to see how easy or hard it is to hack into your network. You can also make sure all the security holes are plugged such as, no easily guessed passwords on any of the devices.
At the end of the day, or even in a few hours, the team should have a fully fleshed out risk register which lays out what might happen, what the probability and impact are of each risk, and how the team would respond should the risks occur. (In the worst-case scenario, the sponsor may decide the project is too risky and cancel it.)
Once you have a risk register – typically in a spreadsheet – it should become a living document used at all your project status meetings. Risk should be a topic at every meeting, and the team should be risk aware. They should not only be looking for ways to handle risk but also ways to identify new risks which may occur. Do not put the risk register in a drawer and forget about it. This is risk management in action.
You should understand having a risk register and applying risk management are not guarantees of project success. But managing risk will help you see what’s happening “around the corner” and will certainly increase your chances of project success.
References: