A blog by Dr. Uwe-Klaus Jarosch, October 2025
According to many statements, we live in a VUCA world.
VUCA is the acronym for volatility, uncertainty, complexity, and ambiguity.
This applies to society as a whole, with its political and social interdependencies.
When it comes to technical systems, we must distinguish between complicated and complex.
But first, we need to clarify what complexity is.
Almost 10 years ago, I had the opportunity to attend a lecture entitled “Complexity – the great FMEA challenge.” It dealt with the consideration of technical systems, primarily in automotive development.
The core of the lecture was the definition of complex products and their impact on FMEA work.
This graphic and other images did not give me a clear understanding of the difference between complicated and complex.
Almost 10 years later, I came across a very catchy description of the difference in a lecture by Prof. Harald Lesch:
Complicated :
The one-way street system in Florence is complicated. But if you spend a few days there, you know how it works and you know how to drive, how to get out of the city if you want to.
Complex:
This one-way street system would become complex if the permitted direction of travel became dependent on the number of participants. So at 2 a.m. they meet and say: No one else is allowed in here today. So that means it would be unpredictable. The system begins because the actors themselves change the characteristics of the system.
And that is the system we are in the middle of.
According to this, the difference essentially arises from the loss of simple predictability of behavior. Laws still apply, but there are several system partners involved, each with its own reaction pattern. This makes things confusing.
The following comparison list is somewhat more detailed than Prof. Lesch’s one-way street example:
| Complicated | Complex |
Structur: | Many individual parts, but clearly defined | Many parts with dynamic interactions |
Comprehensibility: | Transparent with sufficient time and knowledge | Not fully Comprehensibility predictable or controllable |
Behavior: | Deterministic *
| Nonlinear, emergent **
|
Development approach | Analytical, step by step Complicated systems require expert knowledge to understand the structure and then examine it systematically. | Adaptive, often with simulation or AI. Complex systems also require flexibility, learning ability, and tools for dynamic interactions to deal with the expanded solution space. |
Examples: | A mechanical watch A jet engine – many parts, but everything is predictable. | A modern transportation network,
|
Terms used | * Predictable according to rules | ** The term “emergent” describes phenomena or properties that arise when many simple elements interact with each other – in such a way that the result cannot be directly derived from the individual parts. |
With this understanding of complexity, it becomes clearer to distinguish between conventional but “complicated” and “complex” development objects that work systemically.
Even if the development object is “only” complicated, it may be necessary to make simplifying assumptions in order to complete certain tasks within a given time frame.
However, this simplification can be tested, as the cause-and-effect relationship only occurs within this system.
Every simplification, every model, every similarity analysis carries the risk of overlooking details. But with regard to the main functions of a development object, this can be left to subsequent optimization.
However, if the system is complexly networked, testing is not possible. The result of the dynamic chain of causes and effects is usually unknown and therefore cannot be evaluated as “fulfilled” or “not fulfilled.”
Even if a test is carried out and evaluated as “fulfilled,” this is no guarantee that slightly different test parameters in a complex system will not lead to completely different results.
“Complex” is a buzzword and is therefore used in appropriate, but mostly also in inappropriate contexts. Anything that is not immediately understood is complex. The term VUCA suggests that all tasks meet the four criteria, i.e., are also complex.
It sounds much better to say that you have solved “complex problems,” even if they were merely complicated or involved numerous constraints or variables. This leads to a dramatization of tasks or solutions.
This raises the question of which risk assessment and which problem-solving method can be used.
In my experience, some risk assessments can be omitted if one is not prepared to look at the details.
One viable approach is to set priorities based on a delta analysis of the predecessor. Which tasks in the product or process are unchanged from the predecessor and have been tested? -> Check.
Where are the operating principles identical to the predecessor, but new constraints or goals have been specified? -> Consideration based on the available knowledge and focus on the evidence for achieving the goals.
Where are new tasks required, new solutions planned? -> Fundamental consideration of goals, causes and effects, and new ways to achieve the goal.
Where have previous developments failed because the product was not intended to be used alone, but in a complex interaction?
This will illustrate the difference between complicated and complex.
In terms of solution strategies, I see related approaches, but for complex systems with the need to set the system boundaries in such a way that the essential influences of the system environment can be taken into account. This does not make the task any easier, but it does make the result of the consideration more reliable. This requires tools that can reveal such system behavior.
Here, too, it is necessary to understand how the relationships work.
Conclusions:
Final tip: Even more in detail as in this blog I was able to write down the preparation of actions in my book „Vorausplanen“ in chapters 7.6.5, 7.9.5 und 7.9.6 . There you find lists of examples for PAs and DAs in design and process.
Stay curious
Uwe Jarosch