
Automotive Software Process Improvement and Capability Determination – ASPICE for short – is much more than a dry maturity model for software and systems development. In this interview, two experts clear up common misconceptions and explain why ASPICE is not a bureaucratic monster, but a way of thinking that provides orientation. They show why “catching up later” is a risky approach, how structure actually takes pressure off teams, and why lived processes ultimately deliver what everyone is aiming for: calmer projects, better decisions, and measurably higher quality.
Dr. Barbara Buth-Lhotzky:
Because many experience their first encounter with ASPICE as a form of control. More documents, more rules, more reviews. At first, that feels like an additional burden rather than support. This often happens when ASPICE is introduced separately from day-to-day project work and reduced to the assessment alone.
Björn Balecke:
Exactly. That’s when the standard gets labeled as bureaucratic. But the real issue isn’t ASPICE itself – it’s how people work with it. If processes are merely “checked off,” the underlying purpose is lost, along with any real added value.
Dr. Barbara Buth-Lhotzky:
As soon as responsibility comes into play – for example, in reviews. Without clear criteria, reviews differ every time, discussions become subjective, and results are hard to grasp. With structure, it becomes clear: these aren’t rigid rules, but decision-making aids. That’s the point where ASPICE starts to show its strengths.
Björn Balecke:
ASPICE isn’t a rulebook – it’s a mindset. At its core, it always asks the same questions: Have we thought this through? Is it traceable? Can we explain it? Once teams understand this, their perspective changes completely.
Björn Balecke:
Because ASPICE evaluates the project history, not just a snapshot. Decisions, tests, and reviews need to happen when they are actually required. Trying to document everything shortly before an assessment creates stress, costs, and uncertainty.
Dr. Barbara Buth-Lhotzky:
And that stress is then wrongly attributed to the process itself. In reality, it results from starting too late. Projects that take ASPICE into account from the very beginning work more calmly, more clearly – and ultimately more successfully.
Björn Balecke:
With a clearly defined, ASPICE-compliant standard process that has proven itself in daily project work. Supported by tools that create transparency and provide guidance – not just for assessments, but for everyday tasks.
Dr. Barbara Buth-Lhotzky:
We work in very different contexts: sometimes strictly according to OEM requirements, sometimes with full responsibility for process design. The key principle is always the same: processes are lived alongside the project – not documented afterwards.
Björn Balecke:
You notice it immediately. Teams can explain why they do things – not just that they do them. Connections are clear, decisions are traceable. Documents support the discussion; they don’t replace it.
Dr. Barbara Buth-Lhotzky:
That’s when an assessment becomes a mirror instead of a stress factor. It shows where processes help – and where adjustments are needed.
Dr. Barbara Buth-Lhotzky:
ASPICE isn’t about having processes – it’s about making projects more successful, with fewer surprises and better quality.
![]() | ![]() |
| Dr. Barbara Buth-Lhotzky | Björn Balecke |
