Projects can turn into failures quickly.
Even yours.
But there’s one method that can almost guarantee your success. It’s called project risk assessment. In this article I’ll show you how it is done.
Managing project risks depends 3 things:
- Your ability to spot risks
- Your ability to communicate issues and withstand general optimism
- Your ability to implement preventive measures
The risk assessment roadmap
Here’s what you’ll learn in this article:
- The right mindset
- How to do a risk assessment
- Documenting a risk assessment
- The most common project risks
- How to prevent bad things from happening
3 rules that will instantly make you a better risk manager
Mindset 1: Resist overconfidence
Optimism is contagious. Resist the temptation to believe “everything’s gonna be alright” if that’s what people around you keep telling you BUT your gut tells you the opposite.
Mindset 2: A good surprise is better than a bad one
It’s better to expect a negative outcome and be wrong about it than to assume everything will be OK and then having to deal a disaster you didn’t see coming.
Mindset 3: Trust only what you see
Let’s say you’re building a house in another town. Will you only come for an acceptance after construction is completed? No. You’ll be constantly checking the progress. You wanted 8 windows on the ground floor. So, are there really 8 windows or did the builder forget one? That’s what you want to know.
It’s good to be informed via phone or email about what has been achieved. But it’s another story to see the result in front of your eyes: Is this really what I wanted? Does it meet my expectations in terms of quality?
Whatever information you get make sure to check it personally.
How to perform a risk assessment
I recommend you do the risk analysis in a team. Having more people will generate more ideas for potential risks.
Then, start by carefully looking at each task in your project plan.
Ask yourself “what could possibly go wrong here?”
Is it that the software may not be ready by end of October? Or that the customer will make lots of change requests because no proper requirements analysis was done?
If this is your first project, get help: talk to experts who’ve managed similar projects or who have been on similar projects. And by similar I don’t just mean the type of project. A big factor in terms of risk is the project environment.
Here’s what I mean: Assume you are an experienced PM who has run dozens of IT projects in the US. Now your company wants you to lead an IT project in China. Is the environment going to affect project risk? Absolutely. Think of the language barrier.
Documenting your risk assessment
The results of a risk assessment are recorded in what’s called a risk register. That’s a simple Excel file which looks like this:
The next step is to qualify each risk. As you can imagine, now every risk is the same. Some problems cause more damage than others (high impact). And some risks are huge but also very unlikely to happen (low probability).
Qualify each risk by its impact and probability of occurrence:
- impact: how much damage will it cause?
- probability: how likely is this problem going to happen?
Enter a number for the level of impact, with 1 being low impact and 5 being high.
How can you gauge the impact?
[table id=3 /]
For the probability assign a value for the expected likelihood of the event, with 1 = low probability and 5 = very high probability.
What next?
We now have gauged the impact as well as the probability of a negative event. Now you determine the overall risk number which is calculated by:
overall risk number = impact x probability
Enter the result in the appropriate column:
The overall risk value is the only number you need to focus on. The higher its value, the more significant and potentially damaging is the associated risk.
Naturally, you want to focus on the big risks only. That’s because you can only concentrate on so many things at a time. If your airplane is running out of fuel while some passenger complains about the taste of the food, which of these problems are you going to care about? This example is kind of extreme but you get the idea.
Typical project risks
If you look at the most common risk categories, it wil be much easier for you to spot risks specific to your project.
Here are the most common types of risk:
[table id=4 /]
How to prepare for failure
So, you’ve got your list of risk ready?
Your next step is to develop ideas for countering those risks. Again this is done in a brainstorming session. Try to answer these questions:
- What can we do to make sure this doesn’t happen?
- What can we do to limit this risk?
- What can we do to reduce the impact of this risk?
Let’s look at some strategies to mitigate risk:
Better Planning
Many project issues are caused by poor planning. They could have been avoided. So it definitely pays off to spend more time on planning each step carefully. Also, get someone else’s opinion on your plan: Is it realistic? Did you miss any important constraints? I always review the project plan with each of my team. The more review rounds I do the more reliable the plan becomes. And the smaller the risk of us exceeding deadlines.
Here’s another approach to make sure you don’t run out of time:
Starting earlier
Some activities are more likely to take longer as planned than others. I’m talking about stuff that your team is doing for the first time.
For those tasks, ask yourself: What’s the earliest time we can start work? If you can’t move the entire task forward, check if at least parts of it could be taken forward. Concept work or organizational work for example.
I was once responsible for a software rollout in India. And India is a complicated market with peculiar legal and tax rules. Our biggest worry was that we wouldn’t understand the tax rules, and thus face the risk of our software system not being 100% tax compliant. That would have been a huge disaster.
It was clear for me that this was our biggest project risk. So I told my team on the FIRST DAY of the project to start learning about Indian tax rules. To read everything about it and document our findings. By the time IT had to configure our software, we had a clear understanding of the tax rules. And we were able to fully comply by them.
Close monitoring
By adding more check points in your project you’ll be able to detect issues early on before they become bigger problems.
Check in with your team every second day and ask for a status update: Is your work making progress? Are there any problems I can help solve? Will we meet the deadline?
And if your colleague does face an issue you can take appropriate measures right away.
What I’m suggesting is get more involved in project activities:
Join project meetings as an observer, just to see if things are moving forward.
Make frequent visits to your team’s work space
Make high-level checks on work results: do the specs look ok etc.
Testing
Testing things on a small scale is a great strategy to avoid trouble.
In software development it is common to have users play with a new software long before it is being rolled out.
Car manufacturers put their latest models into tests under extreme conditions. This way they are able to detect issues that could lead to expensive recall actions.
You can even test processes to see if they will run as smooth as expected.
Resource risk: how to ensure you don’t run out of manpower
It’s common for staff to be assigned to non-project work, creating a resource gap that can become problematic for your project. There may be an operational issue which needs to be fixed urgently. Or a supervisor suddenly orders his team to go on a team event.
How can you avoid running into resource shortage?
- Get written resource agreements from supervisors, stating how many days per week a team member should dedicate to the project
- Nominate backups for your most important team members
- Hire external resources during peak phases
A surprising lesson from big disasters
There’s a lesson we can draw from past disasters, whether it’s plane crashes, company bankruptcies or the last banking crisis:
Big catastrophes occur when several smaller problems coincide.
Take the crash of Air France Flight 447: Due to unusual weather conditions, the speed measuring tubes failed, giving false airspeed information. At the same time, an inexperienced co-pilot was flying the plane. It was dark outside so he could not have any visual reference to safely steer the plane. On top of that, the experienced captain was taking a nap. The plane crashed on June 1st 2009 causing 228 fatalities.
Here’s the typical plot of big disasters:
- A small issue occurs
- Someone notices the issue but does not report it (or reports late)
- Another smaller issue occurs, but again it is not given enough attention
- A series of other, smaller issues occur
- The two smaller issues lead to a bigger failure, but the team is completely overwhelmed and does not take the right action.
What can you learn from this?
Establish a rule that major issues should be reported to you immediately.
For junior team members in critical roles, get them a seasoned colleague on the side that they can talk to when getting stuck.
Establish a no blame culture: employees are allowed to make mistakes as long as they learn from them.
Set up a project communication plan which defines how often the project team meets or shares updates with stakeholders. Remember that 50% of your time should be devoted to communication! This includes checking in with your team and keeping stakeholders up to date. Communication is the best vaccine against project issues!
What’s your #1 takeaway from this article?
I’ve shown you the process of a project risk assessment. Admittedly it’s been a lot of information to digest. But I’m curious:
What is one thing that you learned?
Leave a comment below!
