Not the engineers: when the process model becomes a bottleneck

A Starship mission is expected to cost around 10 million dollars (once it is completed). A launch of Artemis (or officially Space Launch System, SLS) costs NASA around 4.1 billion. That's a factor of 410, in the same country, with graduates from the same universities and some of the same suppliers. The difference is certainly not due to better engineers. The difference lies in the speed at which the respective organization learns. This is an uncomfortable diagnosis for systems engineering, because this speed is not in the minds of those involved, but in the process model. Oops!

The V-model reckons with known problems

The V-model, whether according to VDI 2206 or as V-Model XT, organizes the development according to a clear logic. On the left is the decomposition: Requirements, system architecture, detailed design. On the right is integration with module testing, system integration, verification and validation. The underlying assumption is that the requirements can be defined at the beginning and that a few iterations are sufficient. Under this assumption, the model is rational. In the case of safety-critical hardware with high change costs, early definition pays off.

The assumption is only valid as long as the uncertainty remains low. When switching to electromobility, with new vehicle software or when markets are unclear, it becomes unworkable. Then it only becomes clear far to the right in the V, during integration and validation, whether the specification on the left has worked. This is exactly where a change is most expensive. The model serializes learning. A single complete loop runs per program.

The figures from the automotive industry illustrate this. BYD develops a vehicle in around 18 months, Volkswagen in around 40 after its own efficiency programs. Porsche committed six billion euros to electric drives in 2018, later corrected the course again and thus turned around ten billion euros in circles. Xiaomi, a smartphone manufacturer, sold more sedans in China with the SU7 than Porsche did with the Taycan. No one will claim that Xiaomi's engineers are the better ones.

Learning is the real bottleneck

In the case of high uncertainty, the binding restriction is not the quality of an individual design, but the rate at which an organization converts assumptions into reliable knowledge. Each pass from requirement to design to validation is a learning cycle. If you go through the V once from top left to top right, you get exactly one large learning cycle per program. This is the structural brake.

Fast organizations shorten this cycle instead of perfecting it. Saab develops the Gripen E with 2,000 to 4,000 participants in over 100 teams. A technical blocker escalates from a morning stand-up to a decision at management level within an hour. The relevant key figure is not the team size, but the latency of a decision. A V-model with a release loop over quarters has this latency built into its structure.

Architecture decides what can be learned in parallel

The architecture determines how many learning cycles can run simultaneously. Modular systems with stable interfaces allow teams to learn independently of each other. Tightly coupled systems force the opposite. If a subsystem shares hidden dependencies with three others, every change triggers a renegotiation across teams. Development work becomes coordination work, and integration builds up long before the first release is due.

This makes the interface the actual lever of systems engineering. A stable interface is a contract that shortens the right branch of the V because integration becomes predictable. It enables subsystems to be used as Black Box can be dealt with. Teams can develop without having to fear that changes will have unexpected consequences, without change requests being stuck in committees for months.

Conway's law has a double effect here. The architecture shapes the organization, and the organization freezes the architecture. If you want to learn in parallel, you have to consciously define the dividing lines between the subsystems before the organization defines them by chance.

Pull verification to the left

The right branch of the V is expensive because it comes late. Integration, verification, validation and certification are required when hardware exists and changes cost money. Model-Based Systems Engineering shifts part of this test forward. Properties can be verified against a model before the first sheet is bent. In this way, verification moves to where learning is cheap.

Certification does not have to remain an endgame. The fire protection specialist Wagner continuously carries out safety-related safeguarding with and maintains TÜV conformity throughout the entire development process instead of proving it in one big step at the end. A safety case according to ISO 26262 can be a living artifact that grows with each iteration. Set-based concurrent engineering goes in the same direction. Several solution variants remain open until measurement data rules out one of them, instead of committing to a single point early on and having to make expensive changes later. Traceability is retained. It then provides quick feedback instead of just material for the audit.

Conclusion

Germany's lag in development speed is not a talent problem. It is due to the interplay between the process model and the organization, and both are constructed, i.e. changeable. The discipline that created the V-model can also redefine it. The right branch can be shortened without giving up the rigor that safety-critical products demand.

To achieve this, the key question must change. It is no longer whether the specification is complete and verified. It is how many validated learning cycles an organization creates before the market moves on. The Product Velocity approach describes this shift with four principles: Value Orientation, Architecture for Flow, Pull Learning Left, and Delivery as the Start of Learning. Engineers are rarely the problem. The system they work in usually is.