Time to Read 3 min
Risk management! Why should you impose this on yourself in your projects as well?
In my eyes, risk management is the most underestimated component of project management. Or as DeMarco/ Lister say:
„Risk Management is Project Management for Adults”
Maybe the reason is that many managers enjoy crisis management more and because crisis management generates more project heroes than wrestling with "risk accounting": Risk Management vs. Crisis Management.
Yet risk management is pretty simple, at least the "accounting part", and can be explained in five minutes. It is better, in my opinion, to actually use this simple model rather than to have a much "better" model but not to use it.
For this model, you generate a list of risks. In it, you describe the risks and, most importantly, the respective effects that arise when the risk occurs. Then you rate these risks with their probability of occurrence and the damage that their occurrence generates. To avoid discussions about the emperor's beard, it has proven useful to use a relatively rough probability scale, for example: 1 % (probably does not occur, but should not be forgotten), 10 %, 30 %, 50 %, 70 %. The probability of occurrence multiplied by the damage then gives the size of the risk.
This then looks like this (excerpt from a risk list, Ph are person hours):
Risk | Description | Effect | Probability | Damage/ Ph | Risk/ Ph |
---|---|---|---|---|---|
USB Stack | the purchased USB software does not work | evaluation new stack | 0.30 | 100 | 30 |
GUI Specification | additional requests GUI | more development effort, possibly architecture adaptation | 0.10 | 1000 | 100 |
IC Bug | the processor has a hidden bug | troubleshooting, discussions with manufacturer | 0.10 | 500 | 50 |
Total Risk | 180 |
For a quick start with this method, you can download and use our template. All fields are explained in the template with "notes". It already goes a bit further in that the damage is divided into "additional work", "third party costs" and "additional delay".
The total risk of the project then is the sum of all risks. Why does it work this way? Imagine that a project has exactly 20 risks, all with 10% probability of occurrence and all with 50 hours of additional effort ("damage"). On average, 2 of the 20 risks will occur, each with 50 hours of damage, i.e. 100 hours total. This is exactly the sum of all 20 risks (5 hours each = 10% probability of occurrence * 50 hours).
The five minutes was just a sales trick, because now follows the harder part. Once you have a risk list, the next step is to move forward with risk mitigation, which means deciding and doing something.
As a project manage, you think that your hands are tied ? Then you can at least do one thing: communicate the risks, especially the overall risk sum. This often triggers decisions...
From your risk assessment you now get e.g. 500 hours of total risk. What do you do with these hours?
These hours have to be planned and budgeted as a kind of reserve in the project. Because where else are they going to come from during the project when the risks occur? And occur they will...
Risk management also includes regular updating of the risk assessment, since risks may not occur or new ones may be added. Probabilities and effects may change with more experience in the course of the project (see also the more complex template in the appendix).
Much success with your risk management!
It makes sense to divide risks into classes according to their size for the purpose of allocating decision responsibility. For this purpose, this template divides them into three classes: "Program" (decision by company), "Project" (decision by project) and "Task" (decision by developer).
In addition, the template allows to document a history of the risk sums by saving a copy of the risk sheet for each period. The graph on the first page is then automatically updated. As a simple rule, it would be good if the trend of the graph over time showed a decreasing amount of risk....
Andreas Stucki
Do you want me to write a more detailed tutorial on this? Would this help you? Do you have additional questions? Do you have a different opinion? If so, email me or comment your thoughts below!
is Dipl. Ingenieur ETHZ, co-founder and managing director. He is committed to clean technical results, meaningful processes and leadership as empowerment and development. In former life he was a high frequency engineer, project manager and technical salesman. Andreas bikes, paraglides and has been doing karate since he was 52. "The journey is the reward"
Projects? Ideas? Questions? Let's do a free initial workshop!
No Comments