Saving Your Project with CORE SPICE

Automotive systems development projects often need help as teams sometimes deviate from the fundamental industry values. CORE SPICE offers a way to address these challenges by integrating proven industrial principles with a hybrid agile-traditional approach. This “back to the roots” strategy helps teams navigate automotive systems and software development complexities in troubled projects. While CORE SPICE isn’t primarily designed to restructure development processes, it ultimately allows turnarounds and helps teams get back on track.

Automotive systems development in our industry is becoming an increasingly complex mixture of software, hardware, mechanical, chemical, and electrical components, further complicated by integrating various advanced technologies and the increasing demands for safety, security, connectivity, and environmental sustainability. This complexity is amplified by the rapid pace of innovation and the fluctuations within global supply chains, requiring development teams to adapt quickly to new standards and regulations while managing cross-functional and cross-cultural collaborations. Introducing new materials and manufacturing processes and shifting towards electrification and autonomous driving technologies adds complexity and risk to projects. In this context, it is unsurprising that automotive systems development projects frequently get in trouble.

A “troubled project” is characterized by significantly deviating from its planned scope, timeline, or budget, leading to challenges in delivery and quality. Poor planning, unrealistic expectations, lack of clear objectives, insufficient resources and training, or miscommunication within the team are common root causes of distressed projects. These problems can lead to project failures. To prevent that, the project requires an immediate and effective intervention to steer it back on course and ensure its objectives are achieved.

Quantifying the number of troubled projects is difficult because of the notoriously secretive nature of the industry and because disclosing such numbers could (and would) likely be used against any auto supplier involved in such a study during a project bidding process. Thus, we can only guess, based on experience, that the number of troubled auto part development projects is high–probably well over 70%.

In such a dynamic environment, project objectives are often moving targets in the increasingly hyper-agile automotive industry. Original project goals and specifications are thus just the first step towards achieving a successful auto part delivery. At the peril of appearing overly dramatic, it is safe to assume that the original goals are usually not achieved. That’s because, during such development, which often takes 4 or 5 years to be delivered, the system requirements keep changing–sometimes quite dramatically. Thus, the road to SOP (start of production) is usually not a straight line from A to B. Instead, the project is often significantly altered during a project lifecycle.

One could visualize the typical course of a project auto systems development path as a line that follows the goals over the project lifecycle. The original target (a) would remain steady and unchanged in a perfect world. At the end of a project development period, the project would deliver such a product according to the original goals initially mutually agreed upon with the customer (x).

Such an ideal trajectory, however, is unrealistic. In the real world of automotive development, soon after the project kick-off, the project starts drifting due to new insights, including novel technologies, different-than-expected skills of the development teams, new customer requirements, and frequent complacency or even plain ignorance that befalls projects in their early stages. After initial complacency, where everything is seemingly under control, it gradually becomes apparent that original project goals may not be achieved. After several delays and failures to demonstrate a tangible project’s progress, the customer realizes that the project is not “on track” (b).  The customer pressures the project team to introduce and implement corrective actions. Frequently, a so-called “task force” is installed (c) – a joined team consisting of customer and project representatives. The task force begins implementing corrective actions that bear the initially relatively easy-to-achieve results – the “low-hanging fruits,” as they are often called in management jargon. However, once those low-hanging fruits have been earned in the form of specific deliverables and reports, the task force realizes that the tougher-to-earn (but essential) project “fruits” cannot be earned without significant changes in the way the project is run (d).

That’s the proverbial “day of reckoning” – the moment of truth, where the customer must decide either to cancel the project and cut the losses or to ramp up the project budget – a bitter medicine typically unevenly divided between the customer and the supplier. In addition, project requirements usually change, and a new project scope is defined (e). With such scope modifications, typically resulting in more realistic project goals, the project continues. As part of the agreement between the customer and the supplier, additional engineers are often thrown into the project following the customer’s demand. It is a well-meant effort which, unfortunately, usually results in further delays – a phenomenon accurately described in the famous book by Fred Brooks, “The Mythical Man-Month.” Unsurprisingly, regardless of all corrective measures, the project still doesn’t deliver the required product in the expected time frame defined in the modified project contract. At this point, the project becomes too important to become a failure because it is now visible on senior management levels of the customer’s organization. The product has often already been published in industry journals, and advertisement procures. In such cases, eventually, a “conditional road approval” is declared (f) – a product delivery in which the final project goals differ (sometimes significantly) from the initially planned project goals, especially in quality, safety, or security categories. When the SOP is near (g), the customer and the supplier jointly declare a successful product delivery. The resulting project’s shortcomings are quietly accepted.

This is the product development “project hell,” to paraphrase Elon Musk’s “production hell” he experienced while rolling out a new project platform, during which he was reportedly seen sleeping on the factory floor to ensure a successful rollout. This “project hell” occurs so frequently that it is astonishing that most of us, who have spent decades in this business, still seem to be often caught off-guard. It’s like being surprised that it snows in December in the northern hemisphere.

Why we won’t learn from the “project hell,” even if we wanted to

The dynamics of the product development of complex auto systems, especially ones involving all disciplines, particularly systems with many software features, should not be surprising – but they are perceived to be. To add insult to injury, it often occurs purposefully because it seems to be a general assumption that projects become postponed or fail altogether unless the OEMs relentlessly and continuously put high pressure on their suppliers’ project development teams.

The occasionally observed perception that the customer is a villain trying to outmaneuver their suppliers doesn’t help much because the root cause for projects getting in trouble is as different as it is rationally explainable. Two phenomena offer a rationale for such unrealistic expectations:

• Planning fallacy, and
• Parkinson’s Law.

The planning fallacy is a systematic cognitive bias first observed by the psychologists Daniel Kahneman and Amos Tversky in 1979. According to this observation, we notoriously underestimate our tasks. In other words, we tend to be overly optimistic regarding our plans.

(As a side note: This realization has led to the establishment of the “agile” movement, according to which our rational, systematic planning is likely fundamentally flawed. Thus, following this logic, planning may be generally a waste of time. Despite this fundamental discrepancy, OEMs continue insisting on detailed long-term planning, mostly for lack of better alternatives.)

The second psychological phenomenon, Parkison’s Law, states that work expands to fill the time available for completion. If you allocate more time to a task than necessary, it will likely take up that entire period, even if it could have been completed sooner. Thus, detailed effort estimation may be just as questionable as long-term planning.

At the same time, according to the pertinent literature, customers, especially purchasing managers in automotive OEM organizations, are trained to understand the psychology of these dynamics and use them to deflate the prices for a potential new auto component until the price for the respective project development drops to such a level that a lower price would be too meager to appear credible. In such an environment, while suppliers often struggle to maintain their profitability, they have no choice but to give in to such often unrealistic demands. Otherwise, they will likely soon go out of business or be acquired by a rival auto supplier.

The phenomena of “Planning Fallacy” and “Parkinson’s Law” explain why distressed projects at auto suppliers have become a norm. In all fairness, not every auto part development project gets in trouble during a project lifecycle, but the trend is apparent. It is the nature of the auto business and the core reason some engineers, especially software engineers, flee the industry.

Possible options

A distressed project calls for higher-level management attention and needs project scope adjustments. The therefore essential variables include:

1. Project timeline
2. Project requirements (requirements scope)
3. Project budget
4. Process and product quality

Modifying the project timeline is the most difficult option in the automotive industry. Usually, automotive part development is embedded in the overall platform development plan of the customer (OEM). Because of the dependencies with other vehicle components, postponing a critical project milestone may induce a domino effect in which different components cannot be delivered on time.

The second option – modifying the product requirements – can be more realistic. If other critical systems features – those pertinent to the customer’s market strategy – remain unchanged, requirements may be modified. Those requirements may be complex and include complicated features and innovative aspects of novel technologies that would lead to a high implementation effort. Thus, negotiating with the customer about those requirements should result in a modified project plan.

The third option – increasing the project budget – is easy to grasp but sometimes hard to agree upon. The already mentioned profitability challenges of auto suppliers can induce significant existential anxiety. Justifying additional funding may be problematic if the project or the OEM is not strategically important to the supplier. To the supplier, it is essential to ensure that, in case of project failure or inability to provide crucial project aspects, the supplier doesn’t get punished by being put on a “black list” by the customer purchasing manager. The budget increase is usually agreed upon if the supplier requires a successful delivery to a customer for such strategic reasons.

The last alternative – adjusting product and process quality – is the most flexible option. Although quality and safety come first in their official statements, the ground reality often differs from this ideal view.  The term “quality” is a pretty diffuse term that may be divided into two large blocks:

• product quality, and
• process quality.

In theory, well-defined process quality and a fully formulated, detailed development process definition on the third level of the Automotive SPICE maturity ladder should automatically lead to better product quality. However, no known hard evidence from an independent source could quantify this claim. In other words, higher process quality should lead to better outcomes, but the correlation coefficient of process quality vs. product quality is the proverbial “unknown unknown.”  

From our practice, if a development process is fully implemented pragmatically, and the right experts are actively involved in shaping a process, it would be a perfect fundament to ensure product quality, especially the safety and security of the product. However, process quality is often among the first victims in distressed automotive projects. Facing the tough choice between complete project failure (usually very costly project cancellation) and cutting the edges of the project scope, especially in the later stage of a project lifecycle, the least visible aspects are frequently postponed, leading to the phenomenon of so-called “technical debt” which keeps piling up during a project lifecycle. “Technical debt” is documentation such as unit test cases, inspections on all levels of the V-model, integration test reports, proper configuration management, traceability between requirements, design and test artifacts, comprehensive code reviews, and refactoring efforts, etc. As a project progresses without addressing these issues, the technical debt accumulates, potentially leading to increased maintenance costs, decreased system reliability, and non-compliance with critical safety and quality standards, ultimately impacting long-term product safety and amplifying product risks.

The inconvenient but frequently discarded truth is that the often scorned “documentation” is crucial in ISO 26262 (functional safety-related) projects and is indispensable for road approvals. In other words, such “documentation” must be part of a standard delivery to the customer. This compliance is non-negotiable.

The process quality must cover the ISO 26262 (a.k.a. “FuSa” for functional safety) process aspects. At the same time, other components specified by the Automotive SPICE (also commonly abbreviated as “ASPICE”) are potential – at least to a certain extent – negotiable.

While ISO 26262 requires a “state-of-the-art” development process, which often defaults to Automotive SPICE, the development process can be implemented as part of a proprietary defined QMS (quality management system). Such QMS must be ISO 26262 compliant and can be used as an argument in the ISO 26262 safety case. Justifying a process that is not fully Automotive SPICE compliant is potentially a bumpy road, but if going that road is the only way to SOP, it should be discussed in good faith.

CORE SPICE approach to turning projects around

The sweet spot on the Automotive SPICE compliance scale lies between levels 1 and 2 of the process maturity (in the former VDA scope of ASPICE, as outlined in our book “Car IT kompakt Reloaded”). Those aspects align with the principles described in the CORE SPICE Approaches. For instance, the goals required in the CORE SPICE Configuration Management Approach (CM Approach) are specifically emphasized.

The other thirteen CORE SPICE approaches are also needed for FuSa compliance purposes, such as the VVT (Verification and Validation Approach), the QA Approach, and the most fundamental approach, the Project Approach.

Using the process-simplifying CORE SPICE strategy significantly reduces the complexity often desperately needed in the wake of project distress while allowing to focus on the substantial FuSa compliance, which is indispensable to make the new car platform safe.

However, such arguably controversial simplification by “cutting some edges” regarding ASPICE compliance while helping streamline the development process is insufficient to save a project. A fundamental change in the mythical “mindset” is required. This expectation is summarized in the CORE SPICE “Fundamentals” (outlined in our previous article, Unlock Efficiency with CORE SPICE:

• 12 CORE SPICE Principles
• 5 CORE SPICE Common Sense Practices
• CORE SPICE outcomes
• ECST (Effective Critical System Thinking)

Setting the right goals in a distressed project is only possible if those principles are integrated into the project’s saving process.

Ten steps to healing a project with CORE SPICE

The procedure of turning a project around using CORE SPICE involves the following ten corrective actions:

1. Project Assessment: Conduct a comprehensive review to understand the current project status, identifying key issues affecting the project’s progress.
2. Stakeholder Engagement: Involve all stakeholders to ensure alignment and commitment towards the project recovery plan. In particular, the senior managers who can make strategic and financial decisions must be fully integrated into the turnaround process.
3. CORE SPICE Integration: Employ CORE SPICE methodologies tailored to address specific project challenges, leveraging its hybrid agile-traditional approach.
4. Scope Reevaluation: Reassess and adjust the project scope, objectives, and deliverables to reflect realistic expectations and current project realities.
5. Timeline and Budget Adjustment: Review and revise the project timeline and budget to accommodate necessary changes and additional resources for project recovery.
6. Team Reorganization: Enhance team structure and roles based on CORE SPICE principles, ensuring clear responsibilities and improved collaboration. The project roles must be aligned with the standard CORE SPICE Team Chart. In particular, process architects or designers are typically redundant as part of the team saving a distressed project. Instead, they should be involved in the subsequent lessons learned project following the SOP.
7. Quality and Compliance Focus: Prioritize the essential quality requirements, aligning with ISO 26262 to ensure safety and security.
8. Risk Reduction Strategy: Implement a risk-based approach to proactively identify and mitigate potential issues throughout the project lifecycle, relentlessly focusing on reducing risks.
9. Continuous Monitoring and Adaptation: Establish regular review cycles to monitor progress, adjusting as needed to stay on course towards project goals. This could be implemented as unbureaucratic release reviews, which help collect and subsequently implement the release lessons learned.
10. Stakeholder Communication: Maintain transparent and continuous communication with all stakeholders to manage expectations and progress reports. One of the critical measures should be growth charts, e.g., burn-up charts, based on low-granularity features or feature tasks planned for a project. Creating and maintaining a full schedule for SOP is a way to keep tabs on the risk of failing the SOP deadline.

These rules must be supported by the right “mindset” of key project stakeholders, such as customers, senior management, and critical suppliers involved in delivering crucial product components needed in the project. Examples of these “mindset” elements required for a turnaround to be successful include:

• Recognize the problem with the project. An honest recognition from all stakeholders that the project is in distress and needs intervention.
• Ensure commitment from decision-makers. A unified commitment from the project team and stakeholders to undertake necessary changes for recovery. Since CORE SPICE turnaround is usually performed by consultants who are not insiders in an organization, a credible commitment from the top management is necessary to enable the CORE SPICE experts to operate effectively.
• Appoint a strong leadership team with well-defined roles and responsibilities to guide the turnaround process.
• Be realistic. An honest and comprehensive reassessment of project goals, scope, and deliverables to ensure they are achievable within the new constraints is only possible if there are no organizational taboos.
• Sufficient resources. Ensuring that the necessary resources—budget, personnel, and technology—are available or can be made available to implement the turnaround strategy.
• Open Communication. Clear, transparent communication channels among all project members and stakeholders are crucial to an effective and trustworthy project turnaround.
• Adapt relentlessly. The willingness to adapt plans and processes based on ongoing evaluations and the dynamic nature of project recovery is a must-have.

Those aspects sound like proverbial common sense. Still, praxis proves that some of these principles are sometimes intentionally or unintentionally violated, and such violations often lead to confusing and fruitless discussions, which, in turn, put the turnaround at risk.

An example of a CORE SPICE project turnaround plan timeline involves the “Seven Golden Steps” to saving projects. This plan could be structured as follows:

1. Day of Reckoning: Decision point where it’s determined whether to cancel or continue the project. That includes the decision to use the CORE SPICE coaching model for recovery.
2. Weeks 1-4: Project assessment and stakeholder engagement: Immediate assessment of the project’s current state and engagement with all stakeholders to align on recovery efforts. Create a long-term CORE SPICE coaching plan.
3. Weeks 5-8: Scope reevaluation and plan adjustment: Reassess project scope, objectives, and deliverables; adjust timeline and budget accordingly.
4. Weeks 9-12: Team reorganization and quality Focus Implementation: Reorganize the project team based on CORE SPICE principles and define the necessary quality and compliance measures.
5. Weeks 13-16: Risk management and continuous monitoring Setup: Establish a risk-based approach and continuous monitoring mechanisms to keep the project on track (e.g., burn-up charts and real-time charts of key tasks).
6. Weeks 17-20: Implement adjustments and continuous review: Make necessary adjustments based on ongoing (release) reviews and monitoring, ensuring alignment with project goals.
7. Starting from week 21: start organizing tasks for the SOP. Outline strategies for delivering all project components, particularly tangible items like ECUs and electronic and mechanical parts, ensuring compliance with all quality and other standards required for the SOP. That includes preparations of the production line and ensuring all regulatory approvals. This phase can take 12-18 months until the road approval is achieved and SOP is secured.

Project turnarounds are tough. They bear organizational and personal risks and are generally unpleasant. They can be likened to surgery–often painful, but after the initial dark moments, the wounds begin to heal, and the prospects of finishing the project become brighter.

When it is too late

Despite the general expectation that everything should be possible in software-driven automotive product development, the price of saving a project can be so high, and the risks can be so outrageously unpredictable, while a project is in such a late phase that it can only be rated as “hopeless.” Indeed, some projects cannot be saved even with all ten preconditions met. There are a few fundamental situations where a successful project’s turnaround is unlikely. Examples may include aspects or events, such as:

• Key stakeholders or partners (e.g., sub-suppliers critical to project completion) withdraw their support, critically undermining the project’s feasibility.
• Loss of key personnel: Similar to the previous point, when essential project members or leaders leave, it significantly impacts project continuation. For instance, if the chief architect quits, it’s sometimes impossible to timely find an expert of the same caliber.
• Inadequate new resources: An attempt to throw “best cost” (read: cheap and inexperienced) development resources at a troubled project is a recipe for a project disaster.
• Missed unrecoverable deadlines. Some approvals–especially regulatory requirements–must be obtained on time. It is sometimes simply not possible anymore to turn back the clock.
• The project budget is fully depleted, with no possibility of additional funding.
• Unproven, novel technologies that are unlikely to deliver on their promise.
• New regulations or legal challenges that make the project’s completion impossible.
• Acute legal risks to any stakeholder. If there is a realistic risk or an assumption of legal action against any project stakeholder, a project is a “no-go.”

Finally, an organization that experiences a troubled project must learn from its mistakes. It often involves an executive-level lessons-learned session that identifies the critical aspect that must be implemented before the next project begins to prevent a frustrating project Deja Vu.  

Where to go from here

In its essence, CORE SPICE is a project management coaching concept aiming to pave the way to ISO 26262 compliance. Its primary function is to structure a project in the early stages of an automotive development project. The ability of CORE SPICE to be used as a project turnaround strategy adds to its value as a pragmatic approach in hybrid (agile and V-model) projects. Turning a project around is always a difficult task that requires industry experience, an understanding of good project management practices, acceptance of methodological diversity, and a willingness to break into corporate silos that are otherwise often perceived as impenetrable. CORE SPICE offers a way to meet these challenges with a systematic approach. This approach can turn distressed projects from “challenged projects” to “good performers.” Moreover, a turn-around project using CORE SPICE offers a stepping stone towards lowering project risks and higher customer satisfaction in future projects.

As an additional option, CORE SPICE can be an intermediate step to achieving full ASPICE compliance. CORE SPICE is a project coaching concept, while ASPICE is an assessment model to ensure that “edges” that were cut while saving a project can gradually be mitigated. No CORE SPICE aspect contradicts Automotive SPICE compliance, making it a good intermediate step to achieve full ASPICE compliance. If Automotive SPICE compliance is a strategic goal, CORE SPICE enables a two-phase process improvement strategy that saves projects and leads to subsequent ASPICE adaptation, making it easier to ensure ISO 26262 compliance.

---

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