Plans are only perfect until they meet reality. No plan survives contact with the real world.

Experienced project teams understand this reality and prepare for deviations in advance, enabling quick course corrections through targeted countermeasures.

The method for doing this is risk management, and it's actually not that difficult.

Nevertheless, I regularly observe how projects get into trouble because risk management is inadequate, as it costs time and is exhausting.

As Chief of Overall Vehicle Development, I made it a priority to regularly review project risk portfolios, always ensuring that all project managers were present to share their assessments with me and their colleagues.

This demonstrates just how critical I believe risk management is.

I gained valuable experience during this time, which I'd like to share with you here.

The Difference Between Risk and Problem

A problem is an unwanted deviation of the current actual state from the necessary target state that prevents the project from achieving its goals.

Every problem requires a solution.

Basically, there are two alternatives for how problems can be solved:

* The goals will be adjusted so that they are achievable again based on the current actual state.

* A new plan will be developed based on the current actual state that leads back to the agreed-upon goals. This usually requires additional activities and resources, which may impact project costs and timeline. This alternative typically requires buffers to be built into the project goals to absorb these additional efforts.

A problem is therefore characterized by the fact that it has occurred and the project team must deal with the consequences, and that the consequences are always unpleasant.

A risk is a potential problem that could occur in the future.

Here too, there are two alternatives for dealing with risks:

* Monitor the risk to see if it occurs and becomes a problem, while preparing a plan for how the problem would then be solved. This reduces the time delay caused by the problem, as the problem analysis time is brought forward and takes place in parallel to the project timeline. A risk buffer is established on the budget side to ensure that funding for the solution is available if the problem potentially occurs.

* Measures are identified and implemented to minimize the probability of the risk materializing.

With so many alternatives available, we need to examine how risk management works in detail to ensure we always choose the right approach.

Identifying Risks

Risk management always starts with identifying the risks.

Since risks represent potential problems, they must be formulated as problem.

This brings me to the first challenge that must be mastered.

A typical error is describing risks not as problems, but rather recording potential causes or corrective measures as risks.

What do I mean by this? Let me illustrate this with an example:

"I don't have enough time to develop the bracket." - This is not a problem description, but a possible cause of a problem.

"I need more time to develop the bracket." - This is not a problem description, but a possible countermeasure.

"The bracket breaks before it has reached the required service life." - This is a problem description.

It is extremely important to describe the problem correctly because confusing the problem, cause, and measure makes evaluation more difficult and restricts the solution space.

Please make sure that the risk is always described as a problem!

But how do you find the potential problems?

The answer may surprise you now:

By actively searching for the risks!

This is where the project management team, especially the project manager, comes into play.

The project manager must strive to identify all risks in their project, requiring the entire team to systematically search for potential risks.

This includes:

* Analysis of lessons learned from past projects

* Interviews with subject matter experts

* Risk workshops in which the project team reflects on the project plan and examines it for risks

* The use of quality management methods (e.g., FMEA)

* And of course, the experience and expertise of the project team itself

Do you have other alternatives for how risks can be found? Then please write them in the comments!

Evaluating Risks

Once risks are identified, they must be evaluated to determine appropriate response strategies.

The evaluation takes place in a portfolio with two dimensions.

One dimension is the Probability of Occurrence.

Is it likely that the risk will become a problem, or is it rather unlikely?

To classify this, experience is often used.

Risks that have frequently actually become a problem in the past naturally have a higher probability of occurring in the current project than risks that have never occurred in the past.

Especially with technical matters, the probability of occurrence is often objectively assessable.

For example, if the stresses in a component are close to the load capacity of the material, the probability of occurrence of a fracture is significantly greater than if there is a large distance between load and load capacity.

The second dimension is the Severity of Impact.

How bad is the damage caused by the occurrence of the risk?

Is there danger to personal safety or great economic damage? Or are the effects marginal and do not cause great damage?

In this context, it is also important to find out which risks may not be risks at all.

It may be that the plan does not really proceed as intended, but this does not result in consequences for the project goals. In this case, it is then a potential plan deviation but not a risk, and this can be acceptable.

I recommend using Low, Medium, and High categories. More granular risk classifications exist, but they tend to complicate the process without offering substantial benefits.

Each identified risk is entered into one or, for the sake of clarity, into several risk portfolio representations.

A risk's position in the portfolio indicates the appropriate response strategy.

* If the probability of occurrence and the impact are low, then this risk is usually monitored further without initiating concrete activities.

* If the probability of occurrence is low but the severity of the impact is high, or if the probability of occurrence is high but the impact is low, a mitigation plan is usually created for how the problem can be solved if it does occur, or what target deviation can be accepted.

* However, safety risks represent an exceptional case. Safety risks must be excluded from the outset, even if the probability of occurrence is low.

* If, on the other hand, the probability of occurrence and the severity of impact are high, measures are defined and immediately initiated to reduce the probability of occurrence and/or the severity of impact.

Defining Mitigation Measures

Once the risks are identified and evaluated, adequate risk mitigation measures must be determined.

To find targeted measures, it is necessary to first become clear about the potential problem causes.

Anyone who defines measures without identifying the root cause is shooting in the dark and cannot be sure that the measures will actually solve or prevent the problem.

I know it's not written like this in most textbooks, but the master teacher “Practice” has painfully taught me this lesson.

The search for potential root causes and the development of targeted countermeasures must be conducted with great methodical care. It helps if the Project Management Master is trained in this methodology and keeps a watchful eye on the process.

If the risk is to be mitigated, the measures must be immediately incorporated into the planning.

If they are only intended for emergency situations where the risk materializes, they remain in the risk management list.

Let's follow this through with an example.

We see here the risk that the tank mount of our new truck might not meet the test requirements.

Experience tells us that the tank mount of our new truck will probably not survive the tests.

The probability of occurrence is high because tank mounts have regularly failed to pass tests on the first attempt in previous projects.

The severity of impact is medium because the tank has multiple mounts, and there is a high probability that the workshop will detect any damage during routine inspections before the tank detaches from the vehicle. However, extended workshop visits are both inconvenient and expensive for customers, especially when trucks are kept off the road longer than necessary.

We have evaluated the risk and put the Risk Number in the corresponding field of the risk portfolio.

The field is red, suggesting, we should do something immediately.

But what do we do about it now?

To find effective countermeasures, we must investigate what the possible root causes of failing the test could be.

With some effort and research, we found out that there were two causes in the past.

* During the manufacturing process, the material properties deteriorate, weakening the part so that it fails to achieve the predicted durability.

* To minimize vehicle weight and material costs, this part is designed to operate right at the edge of its stress limits. In the past, however, the tolerances in the load capacity of the material have been so large that the durability requirement was not always reliably met.

Having identified the possible root causes of failure, we can now define appropriate countermeasures.

Let's assume there is no other way to determine if the part is weakened during production than to manufacture the parts and perform the test. Then the only remaining measure is to schedule the test so that, in case of failure, there is still time for another optimization loop before the entire project timeline is jeopardized. The part must therefore be prioritized in the development sequence and processed first.

Given the tight stress margins, using thicker material from the start makes sense. The added weight and cost of slightly thicker sheet metal are minimal compared to potential project delays and field repair costs. We'll therefore reduce the probability of occurrence of this failure mode by increasing material thickness.

We have now identified two possible causes for one risk and defined a countermeasure for each cause that should be implemented immediately. This allows us to reassess the risk and reclassify it in the risk portfolio.

The risk moved from the red box to a yellow box.

This is because we only addressed the probability, not the severity of impact. If the risk still occurs despite our measures, the consequences would be just as severe.

If we feel comfortable about this status, we would put the risk now on monitoring.

If not, we would need to identify additional measures to reduce impact severity, such as changing the design so that it can be repaired in no time and at no cost.

I hope these explanations have motivated you to put risk management high on your agenda as an important aspect of project management.

If you are a project manager or team member, please integrate risk management and risk workshops into your project planning. Take time to actively identify risks, evaluate them thoroughly, define effective measures, and ensure their implementation.

If you are a project sponsor, ensure you receive regular updates on high-risk issues and share accountability with the team for addressing them.

Eliminating all risks is impossible—we must be realistic about this.

Residual risks will always remain, requiring shared ownership between the project team and the company’s management.

Being assured that careful risk management has been applied makes this shared responsibility easier to bear.

What does risk management look like in your organization? I'd be fascinated to learn from your experience—please share in the comments, or let's have a chat about it.

I will provide more detailed articles on project management topics, transformation, and change in the future. Please subscribe to ensure you do not miss any updates.

If you found this helpful, don't forget to share it with others who might enjoy it too!

If my newsletter resonates with you, please consider sharing it with others.

Get full access to Uwe Mierisch at uwemierisch.substack.com/subscribe