Why Systems Engineering Struggles to Prove Its Value

A few months ago, I was working with a medical engineering client. There were no sophisticated tools in the room. No MBSE platform, no complex diagrams, no digital twin. Just a wall, and a stack of sticky notes.

We started mapping the system. Stakeholders. Functions. Constraints. Interfaces. One note at a time. And within a few hours, something changed.

People who had been misaligned for weeks were suddenly converging. Questions that had lingered in the background became visible. Decisions that were previously delayed started moving.

Nothing about the system itself had changed. But the perception of the system had.

That experience came back to me recently during a discussion with Systems Engineering experts in Germany. The topic was simple on the surface, but uncomfortable in its implications:

Why does Systems Engineering, especially MBSE, struggle to prove its value?

What emerged from that conversation was not a critique of Systems Engineering as a discipline, but rather a reflection of its economic reality.

At its core, the problem is not that Systems Engineering lacks value. It’s that its value often arrives too late.

Most SE activities happen early in the lifecycle, on the left side of the V-model. They deal with abstraction, structure, and prediction. The outputs are essential, but they are not immediately tangible.

And in a business environment where budgets are tied to visible outcomes, this creates a disconnect. Cost is immediate. Value is delayed.

And in that gap, perception starts to erode.

A comparison that came up during the discussion made this particularly clear.

When working with CAD, the relationship between effort and outcome is tight. You design something, and you see it. The feedback loop is short, and the value is obvious.

With MBSE, the dynamic is different. You model something, and then you explain it. The result is not a physical artifact, but a structured understanding. That difference may seem subtle, but economically, it is significant.

Because the further the activity is from something tangible, the harder it becomes to justify its cost.

Another important point surfaced around the role of requirements. Despite all the advancements in MBSE, requirements engineering remains the most economically defensible part of Systems Engineering.

Not because it is simpler, but because it is directly tied to contracts.

Requirements define what is being delivered. They anchor scope, responsibility, and ultimately payment. They are the language that decision-makers understand.

And this is where many MBSE initiatives lose traction.

They introduce new abstractions, new tools, and new ways of thinking, but often fail to connect back to the contractual reality of the business. If a model cannot be linked to what a client is paying for, its perceived value becomes fragile. There is also a human dimension to this.

One comment from the discussion has stayed with me:

“Building an MBSE model is hard… but explaining it is easy.”

At first, that sounds reassuring. But it actually highlights a deeper issue. The challenge is not just building the model. It is deciding how much of it to expose, to whom, and when.

Without careful depth management, MBSE can quickly become overwhelming. Too many views. Too much information. Too much abstraction. And when that happens, resistance is almost inevitable.

Not because stakeholders reject the value, but because they cannot access it.

AI is now entering this space, and it brings both promise and risk.

On one hand, it has the potential to accelerate decision-making, enable earlier validation, and reduce the time between modelling and insight.

On the other hand, it can amplify the very problem Systems Engineering already faces, by generating more information, faster than teams can process it.

Without structure, AI doesn’t solve complexity. It scales it.

Which makes the role of Systems Engineering even more critical, not as a producer of models, but as a curator of clarity.

So what does all of this mean in practice?

Going back to that workshop with sticky notes, what made it effective was not the simplicity of the tool. It was the immediacy of the value.

There was no delay between activity and understanding. No translation needed between model and decision. Everyone in the room could engage, contribute, and most importantly, act.

That is the benchmark Systems Engineering should be aiming for.

Not necessarily simpler tools, but shorter distances between effort and impact.

If Systems Engineering is to remain economically viable, especially in an environment shaped by AI and increasing cost pressure, it needs to evolve in how it presents and delivers value.

It needs to move closer to decisions. Closer to contracts. Closer to outcomes. And it needs to do so earlier.

Because in the end, value is not just about what Systems Engineering enables, it is about when and how that value becomes visible.

I’m curious to hear your perspective.

Where have you seen Systems Engineering struggle to justify its cost?Have you experienced MBSE being too abstract for decision-makers?And what’s the closest thing to “sticky notes” in your environment that actually works?

Let’s discuss.