One day, my friend Christoph Görn told me something about risk estimation. I think he learned it at IBM or so. It is a keep it simple stupid technique for tech projects and you get a quick result. I used it in my recent years as a technical program manager to judge my projects and it never failed.
tl;dr: There are three simple criteria to assess the risk of a project in a quick & easy way.
How does it work? There are three main criteria:
- Does it involve technology which is new to you?
- Does the project involve a partner/supplier/team you have no experience with?
- Does the project has a volume which is relatively high for you?
If you can answer a question with yes, it gets an A. Next, sum the A’s: if you answer every question with yes you get a triple A project. If your project has just one A it is a critical project. Every additional A makes it even more riskier. If you take it the other way around, you do a project with an understood technology, with a partner you know he is capable to do it and a budget you are used to, you have a project with manageable risk.
The details about the risk assessment
Technology is always complex. Today we have a better understanding of the technology from yesterday. But it took some time to learn it, understand it. Using it gives us experience to judge if it is applicable to a certain problem and how long it will take. So it is a risk driver, because if you use unknown, not understood technology, you can’t plan it. You have a learning curve and can’t estimate accurate. Pro-Tipp: Use agile techniques like Scrum for this kind of projects.
You rarely do projects on your own. You do it with a group of people from your company (known as team), a supplier or partner. As always it plays good, if you are already in a steady state with them. But to get there it needs at least some tuning. If you have a completely new partner, you start at zero. You don’t know how they communicate, how transparent they are. Do they deliver what promised at the times negotiated? In worst case they promised you to have something and you find out, that there is nothing. Sad but true: from my experience you should never trust new partners/suppliers. If you have worked with them six months, you can start to trust them for critical projects.
Of course it is has some impact if the supplier has experience with the technology.
The question about budget is maybe not that obvious. It is not only about the risk of loss of the money. But the higher the budget, the more things you have to care about. For example, in 100k$ projects you don’t need a budget controlling like you need in 1M$ projects. So it is more or less about the skill level of the project management.
Conclusion: how can you use this risk assessment
So now we know about how to assess the risk of a project. But how to use? Does it make a PMI© like risk management superfluous? No. During the project you still need to mitigate risk in a proper manner. But before starting the project you can use it to value time plans. If you have a AAA risk, you should add appropriate buffers and so on. You should set a target date, but you shouldn’t communicate it as the release date. Maybe you should change the technology or the supplier to reduce the risk. You should add an expert, an experienced project manager. Of course you can say no to the project.
As you could see, the quick & easy risk assessment can help you to fix some variables before kicking off the project.