Refocusing from “compliance” to “project effectiveness”: When projects get stuck, CORE SPICE gets them moving.

There has been considerable pushback against relying on assessment models as a solution to automotive industry woes—a topic that has been a buzz for some time. Condemning such standards has become a good source of clickbait, but there is a grain of truth in that continuous buzz. The German assessment model, Automotive SPICE (also known as ASPICE), is a VDA standard that has gained popularity as an alternative to the failed CMMI appraisal model. ASPICE is a helpful tool tied to the V-model, thus eliminating the need to invent an industry-specific project lifecycle (CMMI did not postulate any specific model like V). Its primary purpose is to assess suppliers’ “worthiness” in terms of risk management, structured approach, and the complex traceability requirements, so that the OEM can contract the most suitable supplier. Since the “software crisis” was proclaimed (see the 1968 NATO Conference [1]), capability models like CMM, CMMI, and ASPICE have played a role in addressing the challenge of software complexity in systems parts development (see [2] for a broader context).

Assessment models can be used as an indicator of compliance, with the expectation that demanding specific compliance elements can be directly translated into efficient processes. However, the high number of failed ASPICE process improvement projects points to an efficiency gap. The root cause of this problem likely lies in the expectation that ASPICE could be “implemented” as a development process. Yet assessment models are not process templates. The fundamental challenge is that ASPICE does not provide a systemic resolution of its expectations. ASPICE is an analytical, highly rational approach to evaluating compliance. In contrast, designing an efficient, well-thought-out systems development process is a systemic task that requires a deep understanding of the organizational context and all reference processes described in ASPICE. Using assessment models as project improvement goals is a risky proposition. In fact, analytical assessments should not be the starting point for process development, as such a strategy is rational rather than systemic.

Russell Ackoff, renowned for his “systems thinking,” emphasized the distinction between analytical thinking (which breaks a system down into its parts and optimizes them individually) and systemic thinking (which focuses on the whole and the interactions between its parts), using the example of an automobile. In analytical thinking, one might assume that assembling the “best” individual components would result in a perfect whole—but Ackoff argued this is flawed because the system’s performance depends on how the parts interact, not just their separate qualities (a recording of the speech is available here). In his remarks, Ackoff explains:

The NY Times reported that there are 457 automobiles available in the U.S. If you had engineers find the best part from each car, the best motor from say a Rolls Royce, the best transmission from a Mercedes, etc., and have engineers take the best parts from each car and instruct them to assemble them. Do we get the best automobile? Of course not, we don’t even get an automobile. Because the parts don’t fit together.

He further explains:

Divide and conquer is the basic principle of Western management. Manage each department separately, and in turn, the whole will be run as well as possible. But this is absolutely false. (…) A system is not the sum of its parts; it’s the product of their interactions.

Assessment models are not process blueprints.

ASPICE is the best V-based assessment model specifically tailored to the needs of the European automotive industry. It can provide valuable insights into weaknesses that help make product development run more smoothly and efficiently. It is, however, not a proper process “blueprint.” I have witnessed dozens of auto part suppliers “implementing ASPICE” literally. In ASPICE, there are several “processes,” including SYS.1, SYS.2, SWE.1, SUP.10, and others—all of which operate within their own siloed organizational structures when such a process blueprint is followed. BPs (base practices) are cleanly sorted in separate chapters. This often leads to team roles and activities that are redundant and poorly integrated into the development practice. For example:

• Once a process “MAN.3” is defined, the team tends to view MAN.3 as a job of the project lead. The other project team members took a “hands-off” approach. “It’s MAN.3—So I am not responsible.”
• If SUP.8 is viewed as a process, other aspects, such as release planning, continuous integration, traceability management, etc., become the responsibility of “SUP.8”—usually the Configuration Manager, which creates a bottleneck within a project organization. For instance, creating a “baseline” seems to be a proverbial fifth wheel; the Configuration Manager often must chase the deliveries instead of collecting and delivering them in the upcoming release package.
• Treating SYS.3 (System Architectural Design) as the architect’s isolated responsibility leads to designs that lack input from integration or test engineers, resulting in architectures that look good. Still, the practical value of the complex SysML model may be viewed as overrated (sometimes referred to as “ivory tower design”).
• SUP.1 (Quality Assurance) is often implemented as a standalone process. The only person who embodies this role is the QA Manager alone. This typically results in a disconnect, where developers and engineers adopt a “throw it over the wall” mentality. Quality issues are deferred until SOP, where an assessment adds to the stressful strain that only increases the risk of losing key engineers and can even lead to health issues and the oft-dreaded “burnout.”

Using ASPICE as a top-down process definition, rather than building a project development approach from the bottom up, typically creates an organizational liability: it becomes a detached entity within an engineering organization. Although it may not be obvious, ASPICE—while it abstractly emphasizes appropriate “resources” and mentions responsibilities and accountabilities—provides no guidance on a structured approach to effective team development. ASPICE features some 200 BPs but misses the forest for the trees: the fundamental intrinsic team motivation. A lack of personal “buy-in” from the team, which suffers from the inherent redundancy of “carbon copy” methodologies and a lack of focus on practical project contributions, is the Achilles’ heel of ASPICE-based projects. Misaligned responsibilities and accountabilities can lead to a leadership vacuum and a “not-my-job” mentality.

The lack of “buy-in” cannot be fixed by imposing ASPICE compliance through recurring, formal assessments; it is the proverbial “spanking that continues until morale improves.” Well-educated and trained engineers know what needs to be done. They must be allowed to do so to maintain the team’s intrinsic motivation and ensure a well-understood purpose for the system under development.

CORE SPICE’s effectiveness accelerators

Since R&D (research and development) projects have the flexibility to shape the project “triangle” of quality, speed, and scope (see, e.g., here), CORE SPICE primarily focuses on “Made-to-Order” (MtO) projects (see the article The Right Genes for Your Project for the explanation of the project typology). CORE SPICE helps prepare a transition from R&D to the MtO stage, but this transition is not the focus of this article. The CORE SPICE coaching approach emphasizes strong team involvement. The team is encouraged to take ownership of their work, a critical factor in the success of MtO projects. The Team Capability Coach (TCC) plays a central role in the CORE SPICE MtO framework. It emphasizes a shared sense of urgency and a quality-focused mindset. Through hands-on coaching, CORE SPICE addresses the “buy-in” challenge directly, making quality and development speed everyone’s responsibility. By following CORE SPICE’s clear principles, teams stay focused and energized, which supports efficient and cohesive project delivery.

The following measures for project speed and quality help the team to focus on effective project velocity:

1. “No task left behind”—own your task
2. Maintain the sense of urgency—there is no time like “now.”
3. Establish the principle of “end-to-end responsibility”
4. Constantly assess the team
5. Automate everything

Measure 1: “No Task Left Behind.”
Whenever a project member identifies a critical risk (e.g., a missing requirement or a design flaw), it automatically becomes a task “owned” by the task creator until the issue is resolved or effectively assigned to the engineer who can address it more efficiently and effectively. This must always involve an explicit “handover” agreed upon bilaterally to avoid the “throwing the problem over the fence” syndrome. While risks must be taken in fast-paced automotive projects, those risks should be either resolved or reduced, so that such problems won’t “blow up in our faces” at a critical project phase.

Corollary to Measure 1: Creating a task in the issue management system (e.g., JIRA) alone does not resolve the issue; instead, it adds to the overall workload—an ever-growing “backlog” of owner-less (or even entirely redundant or abandoned) tasks. It initiates a sequence of steps that must be tracked, managed, resolved, reviewed, and closed. Managing tasks in an issue management system is expensive; creating a “ticket” must have the consequence of monitoring and reviewing the final result for the ticket creator. A good rule is to establish the “what goes around, comes around” principle: when users create new tasks, they will eventually have to deal with them. That negative cybernetic loop helps reduce the number of tickets that otherwise mushroom to an unmanageable dimension during the project lifecycle.

Measure 2: Maintain the sense of urgency.

The phenomenon of work that was initially planned optimistically but then fills out the time buffer and eventually causes schedule overruns is a pattern well-documented in the planning fallacy literature (see Kahneman and Tversky [3]).

Once the “buffer” is established, it is primarily consumed by other activities. Thus, the task is being delayed, and when it is finally addressed, unexpected obstacles arise, which naturally delay the entire task and result in missing the original deadlines.

This conundrum cannot be resolved by “better planning”—it is simply unrealistic to have a waterfall planning approach where the project scope is a stable figure from project start to SOP. However, it also cannot be resolved by just being “agile,” either, which, in reality, frequently means a mindset in which the project scope is subject to arbitrary changes. This is never acceptable in the automotive business (see the “CAR IT Reloaded” [2], Chapter 5 and 6, for more details on this issue).

In our industry’s experience, delayed tasks are addressed by raising the level of urgency, usually facilitated by calling for a joint “surge,” also called “task force” or “bootcamp,” which enforces pragmatic measures to resolve late tasks.

CORE SPICE philosophy is that every MtO development project is already a “task force” without being called that. TCC’s task, among other responsibilities, is to ensure that this high level of urgency is upheld as long as substantial project risks remain unmitigated or poorly addressed, which usually means that it remains in this state until SOP.

Measure 3: Establish the principle of “end-to-end responsibility”

Team fragmentation and silo thinking are typical project anti-patterns, which are exacerbated by naively implemented ASPICE-induced processes. In such settings, different persons handle tasks throughout an implementation cycle. This might be inevitable or even desirable, as it is a good practice for a requirement not to be implemented and verified by the same engineer. However, it can also lead to an exponential multiplication and fragmentation of tasks in the issue management system (like JIRA). For instance, separate tasks may be created for customer requirements approval, another for systems-level requirements, and for systems architecture, as well as further tasks to handle software requirements approval, software architecture approval, and software implementation. In extreme cases, different tasks are created and maintained by other engineers to identify, analyze, review, and approve the exact requirement. On the right side of V, those tasks are often duplicated at least. Thus, for one customer requirement, dozens of tickets (tasks) are created, maintained, and resolved by multiple engineers, which poses “friction” costs that can lead to significant financial “waste”—not to mention the cost of demotivating the team due to the resulting “process management.”

To minimize the “handover” and reduce responsibility fragmentation in the project, a “feature-oriented” approach should be established. In such cases, a chunk of customer functionality is defined as a “feature.” A “feature owner” is a cross-functional person responsible for ensuring that a portion of customer requirements (“feature”) is managed by the same person from inception until its final verification (thus “end-to-end”). Each feature owner acts as a project lead for a specific portion of the functionality, e.g., “active steering safety manager,” and reports to the Project Lead within the project organization. This reduces responsibility fragmentation. For instance, in a feature-owner approach, it is not crucial whether an engineer is a “software” or a “system” engineer. Such an engineer is responsible for supporting the implementation of the feature across all disciplines, rather than focusing on “discipline-bound” tasks.

Measure 4: Constantly assess the team

This measure is as easy to grasp as it is “politically” difficult to enforce. The Project Lead and TCC must constantly monitor team activities to ensure everyone contributes to the project’s success. If the Project Lead and TCC agree that a project member proves to be ineffective in relation to the project’s mission, a swift replacement is necessary. Keeping unhappy and ineffective team members on the team demotivates the rest; thus, such a situation must be addressed immediately. A “pooling” principle, as described in our book “CAR IT Reloaded” ([2], Chapter 5) may be the organizational solution to this issue.

Measure 5: Automate everything

In every project, the team must perform repetitive tasks that, at least after the initial stage, become tedious, monotonous, and frustrating. Every project activity must therefore be automated as effectively as possible. Examples of such repetitive activities could be:

• Creating a peer review for a software component
• Creating links between different elements across the V, like links between software components and software units or test cases.
• Generating standardized project status reports
• Compiling and updating traceability reports
• Running routine regression tests
• Compiling and archiving documentation for compliance audits

Those activities are often mechanical and intellectually unappealing to highly trained engineers. The “Project Tool Engineer” role (as described in CORE SPICE) must be established from the very beginning of the project, which will automate such tasks and reduce the burden on the development team.

These measures are a substantial part of the CORE SPICE mindset. Their advantage lies in acknowledging that automotive product development (particularly MtO projects) is inherently non-deterministic. The project “triangle” is exceedingly inflexible in our industry for several reasons (see Chapter 6 of our book, CAR IT Reloaded [2], Chapters 4, 5, and 6). It can rarely be controlled by negotiating a modified project scope (as the customer seldom accepts it), and it cannot be tamed by enforcing dogmatic obedience to assessment models. Only a systemic approach like CORE SPICE addresses the essential aspects and challenges in complex automotive MtO projects (see the 12 CORE SPICE Principles and ECST—effective critical systems thinking for details).

Applying these five coaching measures revitalizes a project, significantly increasing the likelihood of its success.

Make it happen

CORE SPICE is a straightforward coaching concept inspired by industry needs for compliance, such as ASPICE, ISO 26262, and ISO 21434. There are hundreds of other regulations and standard specifications that an automotive product development team is expected to follow. Most of them are contractual obligations that should be taken seriously—not for the “standard’s” sake, but for the safety and security of the product in development.

The automotive industry has little need for further and more complex regulations and mandatory standards. Time is running out as the electric vehicle breakthrough has intensified competition, demanding rapid innovation. CORE SPICE is a coaching concept that emphasizes the actions required to deliver high-quality products efficiently. Its measures enhance development velocity and product quality, supported by the critical role of the Team Capability Coach. We believe that only true leaders will retain a competitive edge in this fast-paced industry. Those who succeed will shape the future of automotive innovation, and CORE SPICE empowers to lead that transformation.

---

[1] NATO SOFTWARE ENGINEERING CONFERENCE 1968
http://homepages.cs.ncl.ac.uk/brian.randell/NATO/nato1968.PDF

[2] Car IT Reloaded, 2025
Springer Vieweg Wiesbaden, https://link.springer.com/book/9783658476908

[3] “Intuitive Prediction: Biases and Corrective Procedures.”
TIMSS Studies in the Management Sciences, D. Kahneman & A. Tversky

---

Let’s start a conversation on LinkedIn or X.com (formerly Twitter).