Time to Read 5 min
Risk management has a bad reputation: too complicated, too tedious, pointless, only for pessimists etc. Even if you are not forced to do it by regulation, I believe that risk management makes sense, especially in (development) projects and start-ups. Of course, this only applies if risk management is implemented in a lean manner and if its results also lead to decisions.
In line with deMarco / Lister:
“Risk management is project management for adults.”
“If a project has no risk, don't do it.”
Feel free to contact me if you have additional questions or would like more details!
Depending on the industry and context, there are two basic interpretations of risk:
In safety-critical industries, and especially in product development, risk always means risk as hazard, as a hazard to people and, in some cases, property.
In a more general context, risk means the possibility of loss, as damage to business results or project results. This risk then contrasts with opportunity, as in ISO 9001 and in SWOT analysis (Strengths – Weaknesses – Opportunities – Threats: Threats are risks).
This page deals mainly with the second interpretation; the first is related to critical systems. See also our blog on critical systems and functional safety.
There are very complicated risk management processes and tools. For organizations and projects where regulations do not require anything more complicated, a simple risk list is sufficient. This list includes the risks, their effects, the probability of occurrence, and the damage (excerpt from a risk list, Ph is 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 |
You can find more details on this in our blog on simple risk management.
This list can be used for initial risk identification and then for risk monitoring during the project, for example every month. The total risk is a key parameter that indicates the risk in a single number. If the total risk in the project increases, it quickly becomes clear that measures are necessary...
The damage caused by risks of the “loss” type can always be represented in monetary terms.
On the one hand, there are expenses with the underlying hourly rates (OPEX: OPerational EXpenditures), direct third-party costs (CAPEX: CAPital EXpenditures), and time/delays, e.g., in the form of lost sales.
Once the risk list has been compiled, the question naturally arises: how can I mitigate the risks?
In the simplest case, this can be done by sorting the risk list according to risk (damage multiplied by probability of occurrence) and then starting with the highest risks. Note that „doing nothing” can also be a possible measure!
If you want to take a slightly more sophisticated approach, you can introduce risk classes, which then also specify which functions (e.g., management, project management, project staff) are responsible for risk mitigation. You can find the extended template in the Risk Management Blog.
You should do both.
Creating a risk list is a good start, but risk management only has its full effect when the list is updated regularly, e.g., in a monthly brainstorming and review workshop. New risks are added, mitigated risks disappear, and risks are reassessed.
If you plot the history of the total risk over time, this curve provides a good overview of the project or company situation. Normally, of course, you should aim to reduce the risks over time.
Risk management only deals with „Known Unknowns,” with damages that can be expected to occur. What about the „Unknown Unknowns,” the „Black Swans” that take us by surprise?
By definition, these can only be identified too late. However, they are one of the reasons why risk management is an ongoing process during which we continuously update risks.
There are risks that would cause so much damage that I cannot deal with them in my area, „killer risks” or „showstoppers.” I cannot „manage” this category of risks.
What can be done with them is to document them as „project assumptions” or „startup assumptions”, so that a higher level can deal with them, e.g. management or investors.
Once you have a list of quantified risks, prioritizing project and implementation plans becomes almost child's play.
First, you plan the work packages that mitigate the greatest risks, either by addressing the risks or clarifying them. Then the results can be evaluated in planned milestones according to (also planned) criteria, and a decision can be made on how to proceed.
And: the risk sum (sum of expenses, sum of costs: see the instructions for risk management) should be included in the plan as a reserve/buffer. Where else would the time and money for the risks that will arise come from?
If the startup is not forced into a more complicated system by regulation, then a risk list based on our template is a simple and flexible solution.
When assessing risks, i.e. damage and, above all, probabilities of occurrence, endless discussions should be avoided, but at the same time, the opinions of all experts in the organization should be taken into account.
These two goals are best achieved with Wideband Delphi, also known as Planning Poker. The fact that Planning Poker limits the number of options (e.g. 90%, 70%, 30%, 10%, 0%) has the advantage of avoiding pointless discussions („69% or 70%?”).
Not if you like flying blind...
We believe that lean risk management is worthwhile. It requires a few hours initially to identify risks, then an hour regularly for updates. And it makes planning more efficient.
The alternative is firefighting, which can be irresistible for some people: „…it [crisis management] is a lot more fun”...

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