Test plans frequently follow this unsettling pattern: forty pages on a standard skeleton—IEEE 829 in the old days, now ISO/IEC/IEEE 29119, an even bigger monster of a template. The result is endless pages of prose, and it is still not clear which test results must be delivered by Monday at 8:00.

Such documents usually contain no decisions. Instead, they contain musings—a description of the author’s feelings about the verification strategy. The actual doing—that seems to be someone else’s problem.

It is not really a test plan—it is a write-only document. A plan consists of a series of decisions.

A decision specifies options, approves or rejects them, and attaches specific names to each task. Amateurish business poetry such as “Testing shall be performed on representative hardware” is definitely not a decision. It is actually a decision not to make any decision at all.

Professional prose would read something like this:

“We test on the B2 sample, revision 3004. If the B2 slips past calendar week 38, we ship the qualification test report on the B1 sample and re-run the smoke set on the B2. Owner: System Test Manager. Delivery deadline: CW 40.”

That sounds like a professional who understands project constraints well.

I used to listen to Mark Horstman’s “Manager Tools” podcast (and his book, The Effective Manager, is a great read). He clearly defined the essence of effective decision-making: who does what by when. THAT is a DECISION. Spell out ten or fifteen of those actual decisions—and you have an effective test plan. No “War and Peace” epics. In some projects, two pages are sufficient. I have seen 120-page plans with fewer committed decisions than that.

Why is creating good test plans so hard? For one, we often write them for the assessor. If that is the main reason a plan exists, then we have wasted a nice bundle of money. Besides, a decision can be wrong, and no one wants to risk their name attached to a failed decision—so actual decisions are shunned. Musing, on the other hand, carries no such risk—nobody was ever blamed for “testing will follow a risk-based approach.” Thus, the safest document, career-wise, describes everything and commits to nothing.

Review checklists often don’t help, either: they ask whether chapter XY is filled, not whether chapter XY decides anything. While such checklists carry some practical value, the actual decisions get made eight months later, in a crisis meeting, by whoever talks loudest.

And, by the way, kicking the can down the road is the worst decision of them all.

Think about it: the role name actually defines the justification of this role’s existence: Test manager. The title means that this person is paid to make decisions. If your plan contains no decisions, the title is meaningless.

Can you handle decisions?

That is: what shall be done, by whom, and until when? Without those elements, a plan is frankly useless.

A test plan is a living document that stipulates the task sequence (“what”), staffing (“who”), and gates (“until when”).

And this rule applies to all “plans”: project plans, configuration management plans, quality management plans, etc.

In CORE SPICE, the “Approach” documents are templates that make it easy to develop a test plan, including its strategy. AI can be used for that. Please, don’t run for the exits yet. I agree that most of us are tired of LLMs generating tons of boring content, but some applications of them can be extremely helpful, after all. Developing a test plan, even based on a good template, is expensive, and we have less and less time to “write plans.” A language model now writes the descriptive part of any plan in an afternoon, in flawless English. So the prose has lost its magic. Nobody cares. What remains is the part the machine cannot own: the decisions. Who will do what, until when?

Next time, especially if you are under time pressure—skip the checklist. Instead, count the decisions. If your plan contains a substantial number of decisions, you have a test plan. If you can’t find them anywhere, you are more likely holding forty pages of a weather report.

In the first part of our article trilogy, I described the motivation for an accelerated development approach to keep up with the “China speed” phenomenon. Part 2 summarized the structural choices that must be in place before a vertical integration project can start. In that part, I described the first two “walls”: the handling of intellectual property and the commercial model of a DMZ (“demilitarized zone”).

In this article, I will introduce the program leadership concept, as well as the remaining “walls”: supporting the DMZ engineers’ careers and the security and workspace setup.

The project is run by the Project Lead and the TCC

A DMZ is designed for a specific OEM’s program, including a single budget, a single platform, and a common SOP date. Several suppliers contribute named engineers, but there is one principal. One critical aspect is that the OEM will most likely define the Project Lead. Consequently, the OEM’s Project Lead is partisan, and the other suppliers in the program read every decision the partisan lead makes as an act of OEM self-interest. So the Project Lead is usually not neutral. The solution to this challenge is to pair the lead with a second role that carries the balance: the Team Capability Coach.

The Project Lead, appointed by either the OEM or a superordinate stakeholder group (e.g., a “steering committee” or a consortium), holds the conventional accountabilities—scope, plan, budget, risk, stakeholders, compliance, etc.—on behalf of the project. The TCC works alongside the lead but has no command authority over the engineers, since the TCC is a coaching authority, rather than a line management authority, over people who do not report to either the lead or the coach on any organizational chart.

The TCC’s task is to provide the balance that the Project Lead cannot carry on their own. The first is transparency, which I come to in the next section. The second is fairness across company lines—ensuring that the engineers who participate in the DMZ are not disadvantaged by their participation. By contract, the TCC is bound to the CORE SPICE principles—critical systems thinking, cooperation over confrontation, merit over bureaucracy, transparency, and safety first.

This dual project leadership structure has its limits. Since the OEM funds the program, it also funds the TCC. That party can lean on a coach it pays for. The solution is a contract that binds it to the CORE SPICE principles rather than to instructions, plus a project lead who understands that a biased TCC is worthless to the program as a whole. The OEM must understand that this is the only way to achieve the expected program speed. Otherwise, the entire structure is pointless.

The dual leadership works because it separates two distinct tasks that a single partisan role cannot hold at once: drive the OEM’s outcome and keep the program fair enough that suppliers send their best people and keep them there. Suppliers do not need the Project Lead to be neutral. They need someone in the room whose job is to keep the balance. Together, the Project Lead and the TCC also run the continuous team assessment, which the named-engineers principle depends on—who is admitted by name, who is replaced, and when the right call is “no replacement, we must manage accordingly.”

Strong transparency rules are crucial

Transparency is the TCC’s essential duty. A DMZ falls apart if any key stakeholder is unpleasantly surprised with bad news. Stakeholders—the OEM above all, but also each supplier’s management—can absorb hard truths, but they never accept negligence or a hands-off approach to risk minimization. A hard truth delivered early proves that the program is managed professionally.

For that reason, DMZ reporting must be completely transparent and require minimal effort to maintain. Program status must flow to key stakeholders in near real time, daily, and be automated—pulled from the live toolchain rather than assembled by hand the night before a steering committee or a status meeting. The automation is a crucial tool that is actively set up and continuously managed by a project member (e.g., the Project Tool Engineer, as described in CORE SPICE).

The TCC oversees the setup of the status dashboards, ensuring all stakeholders are “in the loop” on project status.

In addition to the status, the velocity of the project deliverables must also be measured. The reporting must visualize the pace of development: how long cross-boundary changes take, the defect rate, testing velocity, and how quickly process gaps (e.g., unapproved requirements) are being resolved.

Wall 3: careers

Part 2 priced the named engineer commercially and gave the supplier its reasons to say yes. However, it is the engineers who, before joining the DMZ project, wonder about their professional futures. A DMZ assignment of two to three years is a long time for top-notch engineers, and they must meet the expectations of both the OEM and supplier sides.

The risk to those engineers is that they become less visible in their home corporate environments. While our vertically integrated, DMZ-driven program progresses, the home organization continues to promote, reorganize, and re-staff in the engineer’s absence. Out of sight, out of mind. The engineer on secondment may miss the informal moments that drive career advancement at home, such as corporate canteen chats, watercooler discussions, and technical workshops. That is also part of the “retention risk.” Engineers may look for other opportunities because the program has made them invisible to the company that determines their pay grade.

The good news is that three effective mechanisms can greatly reduce those risks and turn them into opportunities for the most capable engineers.

The first retention mechanism is a designated return path. Before the engineer enters the DMZ, the home organization commits in writing to the role band they return to—a level, not a specific desk—as a part of the home company contract.

The second mechanism is a home “anchor.” That is an associated senior colleague (or even a career mentor) whose role is to ensure the DMZ engineer receives proper performance ratings for DMZ work and to advocate for the DMZ engineer. Hence, the engineer remains visible, respected, and on every appropriate internal promotion list. That ensures reviews, advocacy, and visibility for the engineer while on assignment.

The third mechanism is dual visibility. The TCC assesses the engineer’s contribution inside the DMZ, and that assessment feeds the home company’s review cycle. DMZ program performance must be counted at home to prevent the engineer from spending years building a reputation that is not visible to the relevant decision-makers within the home company.

These arrangements offer unique advantages to the engineer. For the highly motivated, most capable engineer, the DMZ can be the assignment of a decade—returning with experience on a next-generation product integrated across an OEM’s full system platform, with cross-company relationships and a breadth of exposure a single-company role rarely offers.

Give an engineer a return path they can use as confirmation of their participation in a leading-edge technology project and a home anchor (or a mentor) who fights for their professional career’s advancement, and they have an excellent reason to return to their employer when the program ends. This is an attractive career strategy given the unique opportunity that a vertically integrated DMZ project offers.

Wall 4: security and workspace

A well-designed technical setup of a DMZ is one of the key enablers of a successful DMZ project.

NDAs offer limited protection to the entire zone; the IP framework also needs physical, IT-infrastructure-based boundaries. These boundaries must ensure a free flow of information within the DMZ. If the engineers participating in the vertically integrated project cannot effortlessly read each other’s specifications and commit code across the boundary, the DMZ becomes a liability. It degenerates into email chains and hermetic data silos that are wasteful and create redundancies, endangering both the project’s efficiency and data integrity.

There are a few possible approaches to the workspace of a DMZ-based project. I will rank the tiers from the lightest to the heaviest.

Tier 1: Virtual tenancy. The DMZ provides a dedicated engineering toolchain for this program, accessible from the engineer’s existing laptop. No new PC hardware is required. Instead, multiuser infrastructure is hosted in a dedicated environment. For example, a dedicated GitLab or GitHub Enterprise instance for source and CI; a dedicated Jira and Confluence site for issues and documentation; a dedicated ALM instance—codebeamer, Polarion, or DOORS Next—for requirements and traceability, all behind one program identity provider with its own SSO, so only a single login credential is required. The DMZ engineers keep their home laptops and access the program via a browser and a VPN or a zero-trust solution (such as Zscaler). In this way, everyone can keep using their favorite setups, while dedicated servers handle the rest. The typical team platform is the “usual suspect”: Microsoft 365, although some people prefer Google Workspace.

Tier 2: Managed program desktop. The engineer’s home laptop becomes a window into a separate, program-controlled PC that lives in the cloud. For instance, a virtual desktop using Azure Virtual Desktop, a Windows 365 Cloud PC, Amazon WorkSpaces, or a Citrix- or VMware-style VDI. The engineer opens a remote desktop client and works on a Windows desktop that the program administers—including program-installed tools, storage, policies, and so on. Program data is never stored on the home laptop’s disk, so if the laptop is lost or the engineer leaves the project, nothing program-related is on it. This tier is used when one company’s security rules prevent its toolchain from being accessed on another company’s hardware. In that way, the virtual desktop serves as neutral ground.

Tier 3: Program-issued hardware. This is the most hardware-intensive variant. The program procures, images, and hands out its own physical laptops, which are joined to the program’s domain and device management (Intune or JAMF for Macs) using program credentials. The engineer carries a second, physical laptop that belongs to the program (not to either employer). The physical workspace (in addition to remote workers) is the bricks-and-mortar office space: a floor or set of rooms with the program’s own badge access, where OEM and supplier engineers sit together, keep their desks clean, and do not use personal devices on the program network. Background IP stays declared and walled off, while the program-generated IP lives within the program environment. Granting and revoking access is run by the Project Lead and the TCC.

There are additional security considerations that must be part of a well-designed DMZ.

The first is government regulations. A cross-company, often cross-border program operates within a regulatory space that includes export controls and dual-use rules, data residency and sovereignty requirements, and data protection laws. Where the tenant is hosted can be a legal decision, including determining which tier to use, which region the tenant lives in, and who is permitted to hold which credentials.

The second sounds trivial, but in my experience, it can be critical. A DMZ team is usually mixed—some engineers on-site, some remote—and the mix changes week to week. A mixed team works only if all team members have the top-notch gear required for their everyday work. Everyone, including the on-site people, needs best-in-class audio and video gear: proper noise-canceling headsets, not laptop microphones, and multiple computer displays. It is a relatively small line in the budget, but it removes a daily source of corrosive friction.

Discussion

There are a few aspects of a DMZ that must be considered while designing a successful DMZ vertical integration program.

Cultural fit. Can completely different working cultures work in a DMZ? It can. The DMZ does not postulate that corporate and personal cultures must become a melting pot. It is asking named engineers to work under the norms of a single program for a limited period. A DMZ-driven program does not necessarily change anyone’s home culture; instead, for the duration of the program, the team forms a shared DMZ culture of its own.

Distributed teams. One could argue that joint engineering teams are hard to control. Part 2’s own VW-Rivian precedent—joint engineering teams in California and Germany—is the obvious example, and it may raise eyebrows. Can they—regardless of the geographical and cultural distribution—be one effective team? Distribution is a real cost, but it can be well managed. The DMZ does not make it worse, and the shared tenant from Wall 4 removes the tool-and-access friction that is what usually makes distributed work fail. Once the DMZ is implemented systematically and thoroughly in accordance with one of the aforementioned security tiers, it can operate without significant friction. Once the infrastructure works flawlessly, ideas and work items follow.

Poaching (one more time). As mentioned in Part 2, and also in the Wall 3 discussion, this is a valid concern. However, the non-poaching clause helps mitigate the issue. Also, the whole idea is that once set up and led by highly motivated engineers, vertically integrated teams offer so many advantages to the engineers and their home companies that the poaching risk—while always possible—becomes negligible.

Ending the DMZ

The DMZ is designed to eventually dissolve. Once the program has passed the SOP, the winding-down is carried out—it is typically already part of the project plan. Program-generated IP is returned in accordance with the Part 2 framework. The tenant is de-provisioned; the DNZ engineers return in line with the written career retention paths, with the knowledge they gathered transferred and retained to their career advantages. As with its inception, the DMZ project leadership owns the dissolution.

The bottom line

The three articles define the vertical integration approach, which enables the best-in-class development environment with excellent engineering, and this strategy gives the joint program a speed and knowledge advantage that would otherwise be impossible to achieve due to the multiple contractual boundaries typical of a multi-supplier setup with conventional contracts.

I want to emphasize that we are not discussing how to fight the dominance of Chinese companies. Instead, it is about matching the speed and learning from how that speed was built. The DMZ is one mechanism for closing the gap. The goal is a European or American program that moves at China’s pace—not more, but no less.

Moreover, nothing in it is specific to a Western OEM. From a Chinese perspective, the same DMZ approach could be initiated by a Chinese OEM that wants to develop a next-generation platform program, and Western suppliers, sensing the opportunity, bring their engineers to it. The DMZ is a way of organizing cross-company work. Whoever runs it well attracts the best engineers, wherever those engineers are employed.

In summary, the DMZ-centric vertical integration project, when well designed, does not just deliver a single program faster. It builds a capability—the ability to assemble a bounded, named, high-trust program around a hard problem, and to take it back down when the problem is solved. That is the prize—not one fast program, but the ability to run such complex projects even faster and more smoothly.

In our trilogy of articles, we have discussed all essential elements of a vertically integrated, DMZ-centric program, including the legal framework, the commercial model, the virtual tenancy, the return path, and the leadership pair. The reason vertically integrated programs are still rare is not a lack of capability, but a lack of willingness to staff named engineers across company lines and to put the right leadership pair in charge of them. You cannot buy your way to “China speed,” but you can run your way there—for one program, with dedicated top-notch engineers, inside a boundary you agree to dissolve when the work is done.

The programs we are called into are usually already paying the integration tax this series describes—the phone rings when SOP is in doubt. If you can see that tax in your own program, we are happy to discuss the options and schedule a short diagnostic call.

I use the German keyboard layout. No matter what shortcuts one tries, it won’t offer all the dashes and hyphens that are common in the English language. Fortunately, there is an easy fix for that that I want to share with you.

Why Hyphens and Dashes Exist

English has three horizontal marks of increasing length, each used for different purposes.

“-“
hyphen (the shortest)

“–”
en dash (medium length)

“—”
em dash (the longest)

Here is a cheat sheet that explains how to use them.

The hyphen (-) joins words and breaks long words across lines.

• State-of-the-art process.
• Well-trained engineer.

Every keyboard has a hyphen key, so I will skip past it.

The en dash “–”is the medium one. It connects ranges and pairs.

• Pages 12–18. The Berlin–Munich line.
• The 2024–2026 program.

Typographers call it the N-dash because its width matches a capital N in the font being used.

The em dash “—” is the long one. It interrupts a sentence the way a parenthesis or a colon does, but with more emphasis.

• He left the office—the door was still swinging—and called his lawyer.
• The cause was obvious—failed integration testing.

The convention I usually follow in my writing (projectcrunch.com, books) is unspaced em dashes—the dash sits directly against the words on either side, with no surrounding whitespace. Some style guides put spaces around them; I prefer the version without spaces because the dash reads as part of the sentence rather than a separator, but it’s just my personal preference.

The problem: my keyboard does not have all of the dashes I need

Even on a US English keyboard, the en dash and em dash are not on any key. You can type them with Alt codes, with autocorrect rules, by holding the hyphen key on a Mac, or by digging through the Insert Special Character menu in Word.

On a German keyboard, the situation is worse. The German layout does not even offer the Alt-code shortcut for these on most setups, and the autocorrect-substitution behavior Word does in English (“convert two hyphens to an em dash”) does not produce the expected result.

The tool I have been running on my machines for years to fix this is AutoHotkey (https://www.autohotkey.com/, in short: AHK) on Windows (by the way, on Linux, there is a similar tool called AutoKey).

What it does for me

AHK is an automation tool that can, among other things, type any text content in the current editor when a predefined hotkey combination is pressed.

For my purposes, I use the hotkey pattern: Shift + Ctrl + Alt + one key. That combination is rarely claimed by any application, which means I can take it for myself without breaking anything.

That tool lets me comfortably customize my keyboard. My most frequently used functions include two hyphen shortcuts, five different date stamps, and a handful that focus or launch the applications I live in—Outlook, Word, OneNote, Edge, KeePass, and dict.cc.

Particularly practical are the hyphen shortcuts:

• Shift + Ctrl + –
  … inserts an en dash —
  
• Shift + Ctrl + Alt + –
  … inserts an em dash

After a few weeks, my fingers automatically select this combination without having to think about it. As with all my articles, it was typed using these two shortcuts.

The second useful feature of AHK shortcuts is date stamps. When I am writing meeting notes, naming a file, dating a draft, or timestamping any data, I don’t want to type it by hand. I press a hotkey:

• Shift + Ctrl + Alt + . for an English-format date such as 16-May-2026
• Shift + Ctrl + Alt + L for a German-format date such as 16.05.2026
• Shift + Ctrl + Alt + , for an English-format date plus time such as 16-May-2026, 14:32
• Shift + Ctrl + Alt + ü for a date followed by my Windows username and a colon, ready for me to type a comment
• Shift + Ctrl + Alt + # for an ISO-style date such as 2026-05-16—the one I use for folder names, file prefixes, and anything that needs to sort chronologically

The last one is particularly helpful because it generates an ISO-formatted date (like 2026-05-17) that can then be used when creating files with that prefix, enabling clean, unified timestamps that can be easily sorted.

The rest of the script is application-launching stuff. Outlook, Word, OneNote, Edge, and KeePass each have a three-modifier shortcut that focuses the window if it is already running, or starts the program if it is not. Two more shortcuts open a new Outlook task and a new Outlook mail directly, skipping the main Outlook UI.

Setting it up on Windows

AHK is a free, open-source tool.

1. Download AutoHotkey from https://www.autohotkey.com and run the installer. Choose v1.1 when the installer asks—the script below uses v1 syntax and will not run on v2.
2. Save the script somewhere stable.
   I keep mine in my user folder as AutoHotkey.ahk. Any standard text editor will do, and the .ahk extension makes the file directly launchable; double-clicking it runs the script and adds an icon to the system tray.
3. Set it to auto-start at login.
   Press Win + R, type shell:startup, hit Enter. Open a folder; drop a shortcut to your .ahk file into it. From the next sign-in, the script loads on its own, and the hotkeys are live.

My script

Here is my version of the script. You can use it as a starting point and extend it as you go. Remember to reload the script before your changes take place. Note that some paths (e.g., Outlook) may differ on your machine.

Download and unzip the file. Right-click the AutoHotkey tray icon and pick “Edit This Script” — your default script file opens in Notepad. Paste in the contents of AutoHotkey.ahk (or just save the unzipped file directly in place of your default script), Then right-click the tray icon again and pick Reload This Script. The hotkeys are live from that moment on.

Be faster, more efficient with AHK

Small pieces of waste compound.

If you have to look up today’s date every time you name a new file, the files end up with no date or inconsistent date formats. Little waste compounds into days and months of wasted time—and distracts you from the actual workflow.

If you write a lot on a keyboard that lacks the characters you need, install AutoHotkey, paste this script, and start with the two-hyphen shortcuts. Add the date stamps the next time you find yourself typing a date by hand twice in one day. Before long, you won’t want to miss this little efficiency hack.

In the first part of this series, I emphasized that the China-speed gap is caused by the OEM-supplier integration “tax,” and that the answer is to bridge this gap within a defined DMZ (figuratively “demilitarized zone”) for the duration of a single program rather than acquiring the supplier or using constructs such as joint ventures. After discussing the reasons for creating a DMZ, we are turning to the practical aspect: the success factors that make vertically integrated programs work.

I had hoped to create just one article, but I realized it won’t fit; it would be just too long. What follows in this article is, therefore, the first half of this second article of the series: the vertical integration architecture—the structural choices. Part 3 will be the operations: what happens after the contracts are signed.

Precedents

Cross-company integration examples are hard to spot because they are rarely publicly communicated. A few available examples, both positive and negative, are outlined below.

Boeing 787 Dreamliner. Boeing outsourced sixty to seventy percent of the 787’s design and manufacturing work to more than fifty international suppliers. The program ran three years late and billions of dollars over budget, with integration defects occurring for many years after the aircraft entered service. The many lessons learned from this crisis can be summarized in one key recommendation: “tightly integrated governance for critical components.”

A well-designed DMZ would have solved the Boeing 787 problem.

Tesla and Panasonic at Gigafactory Nevada. In this joint project, Tesla provided the technical facilities and utilities, while Panasonic provided the cell manufacturing equipment. This was a commercial “marriage made in heaven,” and the two companies jointly designed the 2170 battery cell, which has been shipped and integrated into millions of Tesla EVs. The overall investment was around $5 billion. Engineers from both companies worked successfully on the same site and program under integrated project leadership. By 2024, the integrated team had cumulatively produced over 10 million drive units.

Volkswagen and Rivian. The 2024 joint venture is a fifty-fifty structure with co-CEOs from each parent, joint engineering teams in California and Germany. The “software-defined vehicle” narrative inspired the initiative. The purpose is to develop the next-generation EV platform. Volkswagen also took an equity stake in Rivian during the process. It is an integrated endeavor comprising financial and operational/development components.

In this case, unlike Tesla and Panasonic, equity is part of the picture here as well. However, our DMZ concept does not assume any shared equity arrangement; it is just one possible option among many.

Who runs the DMZ

The DMZ stands or falls on the choice of an appropriate joint project leadership structure. Specifically, who picks the people and enforces the norms—across employer boundaries, with mandate from all parents in the program charter.

Such a role does not exist in the conventional OEM-supplier arrangement. The OEM’s program manager is too partisan; whatever they decide is read by suppliers as OEM partisanship. A partisan project manager (i.e., from either an OEM or a supplier) is unlikely to fill this gap. The other suppliers in the program will not accept their decisions as legitimate. The role must sit somewhere that all parents in the program charter recognize as neutral, and it must carry their mandate to act with cross-company authority.

I have written about a related pattern inside a single OEM—the T-Rex Company—which argues that the only way to get a high-tech program to move at speed is to give it project authority that is matrix-agnostic. The DMZ is the inter-company version of the same idea: a project leadership authority that cuts through all companies’ boundaries. Such authority is the only way to ensure trusted coordination among all involved organizations in a vertically integrated project. I will discuss this role in the last part of this article series.

A further decisive aspect is to focus on merit-based selection rather than delegate that question to the involved commercial organizations. The principle that separates a working DMZ from a Boeing-787 setup is named engineers. Team members must enter the DMZ by name. That is a critical aspect when commercial organizations collaborate on delivery. For instance, a typical outsourcing organization will “sell” a star developer but then deliver 10 more mediocre developers or entry-level programmers alongside, bloating the headcount and diluting responsibilities, often resulting in teams with overly mixed skill sets wasting each other’s time on coordination and internal peer-to-peer on-the-job training.

Instead, in our model, the central project leadership (rather than involved commercial entities) must have a decisive say in who joins the project, and those experts must be named explicitly (and not as placeholders or headcounts).

I want to re-emphasize this point because nothing is more important than the quality and motivation of each engineer in a critical DMZ project. Any senior engineer who has worked with large outsourcing programs will recognize the failure mode this is designed to prevent: one excellent engineer plus twenty-five warm bodies arriving under a single statement of work is a billing arrangement prone to waste, friction, and frustration.

Veto authority over replacements must be enforced.

If a named engineer leaves the program—for any reason (resignation, illness, family)—the program lead picks a named replacement from the available pool, with the option to choose no replacement. The involved supplier must not have the liberty to fill the gaps unilaterally.

The same role carries responsibility for the program’s norms—how disagreements are resolved, what gets escalated, and how decisions are made when they cross company lines.

Before we discuss the definition of such a project role in the subsequent article, let’s take a look at other aspects of a vertically integrated project. I will use the metaphor of a “wall” to enumerate the essential success criteria for a vertically integrated program:

• Intellectual property
• Commercial model
• Careers
• Security & workspace

In this part, we will discuss the first two walls.

Wall 1: intellectual property

Intellectual property is a critical aspect of an integrated project in which various legal entities and individuals work on cutting-edge technologies. IP attaches to named contributors and is resolved once, in a pre-program framework agreement. Trying to settle it mid-program is an unacceptable legal and commercial risk.

The framework agreement is prepared by specialized lawyers and signed before any engineer enters the DMZ. It determines, among other aspects: what background IP each party brings in, what carve-outs protect that background IP, who owns what is generated during the program, and what the licensing arrangement looks like after the program ends. The named engineers in the DMZ get usage rights to both parties’ background IP for the duration. That is what enables them to do integrated technical work—to read each other’s specifications, to debug across the commercial boundaries, to commit code that touches both sides’ libraries.

Many cross-company integration programs fail due to this challenge. The parties find IP negotiation slow and uncomfortable, so they postpone it. They start the program with the framework half-drafted and the assumption that it will be finished as the work progresses, but that’s a careless fantasy. The fight comes due when the team needs to ship a release, and the program freezes while lawyers do the work they should have done before anyone wrote a line of code.

Wall 2: commercial model

The default commercial model in the automotive industry—time-and-materials, billed by the hour—pays the supplier to keep working. That’s one source of inefficiency due to the fundamental misalignment with commercial incentives. Think about it for a minute: if developers’ key metric is to generate a lot of billable hours, then they will be eager to do just that. But if the incentive is to deliver value in the form of deliverables that align with safety and quality goals, they will be focused on delivering that kind of value.

Thus, the DMZ must ensure that project members are inclined to deliver value rather than just billing hours.

The replacement is an outcome-aligned commercial pool: suppliers’ compensation is tied to program milestones rather than to hours billed, and the rate for a named engineer’s contribution is set with reference to that engineer’s expected impact on the program, not to a market hourly rate. That may be easier said than done, but it can at least be a basic expectation to deliver according to plan instead of “just being there.”

As part of this effectiveness-centered approach, the premium rate is conditional on the named engineer being on the program. An attempt to substitute a “warm body” (or a weaker candidate) automatically cancels the rate, thereby enforcing the named-engineers principle both commercially and structurally.

Two more components must be in the contract.

• Re-baselining triggers—conditions under which the commercial arrangement re-opens, such as scope expansion beyond a threshold or milestone slip beyond a threshold. Such a situation must be codified in the contract to avoid bottlenecks and commercial deadlocks.
• A small risk-sharing pool—a kitty fund both “parents” contribute to, drawn down by the program lead’s authority, for the unbudgeted surprises that any complex program produces. Without it, every surprise becomes a renegotiation, and renegotiations pose a substantial risk to the program.

The reason cross-company programs most often fail at this wall is that the OEM contracts for deliverables, and the supplier contracts for hours, and the gap between those two framings produces an unsigned argument that runs throughout the program’s life. This aspect must be clarified and codified in writing at the beginning of the entire program.

Why a supplier says yes

The elephant in the room is now the question: “Why would I send my best engineers into a customer’s program for months or even years under named individual commitments, with all the retention risk that creates?”

The answer is that the alternatives are worse. The commercial model prices a named star engineer’s contribution to a program outcome, not a market hourly rate. Even at a lower price, up to 10x as many engineers are sometimes required to deliver what a “star engineer” can. The supplier captures margin on the people they should already have been pricing as premium. If not, the project’s performance suffers, and a supplier is forced to hire more mediocre people. The locked-in multi-year program revenue eliminates much of the supplier’s normal sales-cycle overhead—fewer RFPs, fewer demos, fewer rounds of competing for slots that low-cost-country competitors will eventually win on price anyway. Without this, the cost per dollar of revenue suffers, not to mention the supplier’s reputation, which now has nothing to demonstrate except the ability to sell more “best cost” placeholders. It is a lose-lose proposition that is fundamentally unacceptable in a high-stakes vertically integrated project.

An additional incentive for sending star developers to participate in such projects is that the named engineer returns from the program having worked on the next-generation, often cutting-edge and novel technology product, integrated with the OEM’s stack, with relationships and skills the supplier can monetize in every future bid. Suppliers selected for DMZ participation can market the selection—”named-pick for the OEM’s next-generation platform” is of extraordinary value to the supplier for years. Suppliers inside a DMZ see what the OEM is building next; suppliers outside it find out when the RFP arrives.

The structural advantage is what makes the case so attractive. Commodity time-and-materials competition is being won, on margin, by low-cost-country outsourcers whose model is the one-star-plus-twenty-five-warm-bodies arrangement the DMZ cannot and must not accept. Low-cost-country outsourcers cannot easily enter it, because they do not have the named engineering stars.

Also, OEM internalization cannot easily replicate this because the acquisition-related cultural integration cost is too high. Instead, suppliers who participate in the DMZ become the OEM’s preferred long-term partner. Suppliers who decline lose ground in both directions simultaneously.

Also, the poaching risk must be clearly addressed and mitigated in such arrangements. A non-poaching agreement with all involved parties must be clearly and contractually signed.

Summary and outlook

We have discussed the first two “walls” that must be overcome for an effective DMZ project:

• IP: The role of intellectual property
• Commercial model: How suppliers are compensated, with re-baselining triggers and a risk-sharing pool that aligns incentives with program outcomes

Two walls remain. Part 3 will be about what an engineer personally gains from spending many months on someone else’s program—and about where they sit while doing it, on which laptop, with what credentials.

In every distressed safety-critical program I have walked into over the decades, there is a moment of genuine insight. I sit down with the senior engineers and project leads—the people who actually know how the system works—and within twenty minutes, they tell me exactly what is wrong with the project and exactly what would fix it.

They are usually right.

Then I ask: why isn’t this happening? Why are we not just executing what everyone in the room knows needs to be done?

And the answer is: nobody is letting us. The policy won’t let us. The customer is unhappy and unreasonable. Management is panicked and focuses on corporate standards. Process people are demanding compliance. Everyone is drowning in meetings and committees. Decisions take weeks—sometimes forever. Trust between the team and key suppliers has collapsed. The team has been running overtime for months, and nobody is sure anymore what they are running toward.

The truth is that senior engineers know what to do, but they simply have no permission to do it. And after enough months of that, they begin to lose faith.

This is the moment when consultants get called in. And this is also where many consultants get the diagnosis wrong.

The Misdiagnosis

The default assumption—among process consultants, interim project managers, process compliance specialists—is that distressed projects are engineering or process failures. In such cases, “gaps” are being closed, one by one. The defect curve was incorrect, so we meticulously installed a better ticket-tracking system. The release scope keeps slipping, so we define a 10-page scope governance work instruction. The traceability is flawed, so we mandate that the matrix be filled in. Process gaps in, process gaps out.

Those measures sound rational and correct, but they are just “process patches.” Almost every distressed safety-critical project I have seen is a purpose failure first, and an engineering failure second. The symptoms are real, but they are symptoms, not the disease.

When a team has lost its sense of purpose—why it is worth doing well, why it is worth doing at all—the metrics, while often useful, are not the solution. That is not because those measures are wrong, but because processes do not motivate anyone except for the compliance guardians. As a result, defects get logged casually, specifications drift, reviews become rituals, and the traceability measures become nebulous. The team becomes even more frustrated. The senior engineers, who could see all of this clearly, either check out or shift into self-protection mode. They stop bringing their best to a project that—as everyone feels—no longer deserves it.

You can install all the processes you like into that situation, and nothing will improve. Process without purpose is just a checkbox ritual, and senior engineers see through it faster than anyone.

Russell Ackoff Saw This Coming

The systems-thinking pioneer Russell Ackoff distinguished between purposeful and purposive systems. A purposive system is goal-oriented in a mechanical sense—it simply moves toward a target in terms of schedule and milestones. A purposeful system, on the other hand, has a goal that its members understand, share, and choose. In such projects, team members can explain why the goal matters and why it should be pursued.

A distressed project almost always starts as a purposeful system. At its inception, someone, somewhere, articulated a real reason this product needed to exist—a car that would actually be safer, a medical device that would actually save lives, a rail signaling system that would actually let trains run on time. That is why engineers joined the project. The team felt they were part of something that mattered not just to management but to the organization and even to society as a whole. The senior engineers signed up because they wanted to build the thing, not just collect the paycheck.

But over time, the purpose slowly and quietly erodes. Customer politics, self-serving siloes, scope creep, leadership churn, restructuring initiatives, sustained pressure—these are the factors that wear down the connection between the daily work and the original reason why this project exists. The system becomes purposive without being purposeful. People hit milestones without knowing what those milestones really mean. They produce deliverables that nobody is sure anyone reads.

When that happens, process or method improvements won’t help because the product has lost its intrinsic meaning.

Not Every Project Deserves to Be Saved

Although it might sound a bit dramatic, I want to emphasize one important point. No one can save some projects, because they were never worth saving in the first place.

Let me use a real example to make this point clear.

I once consulted briefly on Fiscus, the German federal-state effort to build unified tax-office software. The entire endeavor was truly a project Odyssey. Thirteen years, nine hundred million euros, sixteen Länder with conflicting interests—that was the frame. There was no coherent ownership and no shared purpose at any level of the organization. Bavaria and the eastern Länder eventually quit and built their own systems. The central project died. By the time I arrived, the question of “how to recover this” was the wrong question. The right question was: should this project have existed at all, in this form, with this structure, with these politics? The honest answer was no.

Projects like Fiscus are purpose-dead from the start. They were never built with a real purpose in mind. They were built around a political compromise, or a budget line item, or a vague aspiration that nobody could believe in.

This anecdote matters because genuine purpose defines whether a project can be turned around and saved. A recovery is only possible if the project was once actually really worth doing. That holds when there is a genuine product underneath, a real problem to solve, a real customer who needs it, and a team that originally signed up to build it for all the right reasons. In that case, the purpose is still in there somewhere, dormant, recoverable. Bring it back, and the team comes back with it.

However, if the project was rotten at the root—wrong structure, wrong politics, wrong premise—no turnaround magician can save it, and trying only postpones the inevitable end.

In other words, a project worth saving is the project that was originally worth doing. Get the purpose right, and the project can heal.

Bring the Purpose Back

When the project is genuinely worth saving, the first job is not to install better metrics or tighter governance. It is to reconnect the team with a credible reason for delivering this project.

That sounds “soft”—but it is not. It is a concrete, genuine insight.

It often takes the form of a direct conversation with the senior engineers, in which I ask them to name, in plain language, what this project, properly executed, would actually mean to the world. I mean, not the marketing version or the numb steering committee version, but their version. What does it mean, for them, that this product ships well? What does it mean if it ships badly? What would they want to be able to say about it three years from now?

The answer is usually straightforward and plain. I want this car’s lane-keeping to actually save someone’s life on a wet road at night. I want this medical device to be the one clinicians trust. I want the next generation of engineers at this company to learn from a project that worked rather than one that failed. I want to look at this product, ten years from now, and be proud of what we did.

When senior engineers articulate purpose to themselves, in front of someone who takes it seriously, something shifts. They remember why they signed up. They remember that they are still allowed to care. The defensive posture dissolves, and the unholy spell is broken.

In such decisive moments, I am not trying to play the role of a motivational speaker or simply try to make them feel better. I am trying to think with them more clearly about what this project is actually about. What follows is often an insight that they are not alone in this. That is already healing. What follows, when done right, is the miracle of a project turnaround.

What Senior Engineers Need

The conventional view of distressed projects assumes the team is the problem and outside expertise is the solution. But that’s very rarely the case. The senior engineers are not the problem. They are the most capable, committed, and knowledgeable people in the organization. They are also the most beaten down.

These are people who spent years at university studying complex technical and scientific matters. Then they spend years getting genuinely good at their jobs. They went into this work because they wanted to build things—real, complex, challenging products—things that mattered. Many of them are still, underneath the exhaustion, the same people they were when they started.

What they need is not more abstract instruction or more methodical or “standards” preaching. They need three things they have been missing for months (or sometimes even years):

Permission to do their actual job. Most senior engineers in distressed projects have been pulled into endless coordination, escalation, and political work. They often cannot remember the last time they had a clear week to think technically. The first thing a recovery does is give them that week back.

Cover from the organizational chaos. Senior engineers cannot do their best work while also fielding panicked questions from a steering committee. The recovery installs someone—a Project Lead with real authority, or a coach in the room, or both—who absorbs the noise and lets them work.

Belief that recovery is possible. By the time a project is in real trouble, the senior engineers have usually privately concluded that it cannot be saved anyway. They have mentally “checked out.” You can literally see that in their eyes. Sometimes they are right, and the project is “Fiscus.” But more often, they are wrong, and what they are missing is someone in the room who has seen worse and pulled it through, and who is honest about what is and isn’t possible. Pretending things are fine destroys credibility. There are usually clean, simple measures to restructure the project. They need to be spelled out with confidence. Done that way, it works.

A Note on Senior Engineers

Senior engineers—such as chief engineers, principal engineers, technical fellows, the people who have spent many years getting genuinely good at building complex products—are the most underutilized asset in modern safety-critical development. They are also, in my experience, the most starved for honest advice that resonates with their way of thinking.

The corporate world has spent decades promoting its best technical minds into managers—and then wondering why projects keep failing. It has filled its leadership ranks with people who are good at compliance but have forgotten how to actually build things. It has surrounded its remaining senior engineers with process apparatus that was supposed to scale their judgment but instead replaces it with checklists.

The senior engineers know all of this. They feel it daily. They are not naive about their own situation. What they need is not motivation. What they need is recognition—from someone with technical credibility—that they are right about what is wrong, and that this person is willing to fight alongside them to fix it.

That is, I think, the actual job. Everything else—the frameworks, the dashboards, the process design, the coaching—must be the core service to senior engineers, restored to their craft, building things they can be proud of, on projects that remember what they are for.

That is what I mean by bringing purpose back. And that, in the end, is what every distressed project that is worth saving actually needs.

The framework I use for this kind of work—including the recovery dashboard discussed in earlier articles—is available here.

A guy I knew years ago was the best guitarist in his small town. Local gigs, people actually came to see him. He was charismatic and really good at his self-taught double-hand tapping.

Then he watched one episode of a talent show—some 12-year-old kid playing things he couldn’t even replicate on his guitar. That was a game-changer for him. He realized he would never be as good, and he gave up. The gap suddenly looked infinite.

Globalization suddenly discouraged people from excelling at their craft. Everyone wants to be “the best”—but if you can never, ever be the best: Why bother?

AI is doing the same thing, but at 100x speed.

You used to be able to sit down, write something decent, design something decent, code something decent—and feel you were getting somewhere with it. You could feel like a hero in your own little talent show. People noticed. It felt like yours. Now the machine spits out something better in 12 seconds, and half the audience already assumes anything good is probably AI anyway. So why bother getting good?

The quiet retreat has already started.

I see this phenomenon everywhere. Writers stopped spending weeks writing and refining their articles. Yes, skilled readers can still notice the difference, but that gap is shrinking fast. Once your “voice” (writing style) can be fully replicated, you are done.

Kids spent months designing an awesome animation in Blender, starting with a simple cube that eventually morphed into an entire space battle movie. Now, tools like Midjourney do that in no time.

People are giving up. Not because they’re lazy, but because the conventional reward system is broken. Globalization was an injury, but the AI wave has added insult to that injury.

Here is the thing, though: most of what AI is replacing was already the low-purpose stuff. For example, the “content-is-the-king” idea has led to a flood of meaningless web articles in the past. Boring stock photos were used because we needed pictures for a blog post, not because they were meant to say something meaningful. It had to be there because the blog post template demanded it. Repetitive work was only there because it was cheap (“best-cost”).

In other words, AI is just finishing the job globalization started.

A Survival Guide for the AI Era

I feel that three things will become the superpowers for anyone moving forward in the new AI era.

1. People who are already famous. The James Deans of their fields. They’re safe for now, but they’re also aging out—or dead. A key part from Dean’s wrecked Porsche sold for nearly $400,000. Stuff from known personalities that cannot be replicated becomes valuable.
2. The truly unique stuff. Example: Swiss watches. A walk through the town of Zürich reveals shops where watches can lighten your wallet by a million dollars. Swiss watchmakers spend 1,000–2,000+ hours hand-finishing a single watch, using techniques passed down over generations.
3. People who genuinely want to help, care about you, actually do help, and know how to do it in a genuine, honest, and authentic way. Not the fake “thought leadership” version. I mean that kind of help that really matters and offers value, including motivational aspects, thoughtful meaning, and genuineness. You can get generic answers from any LLMs. But an in-depth, sharp analysis, understanding the context in every specific case, and being willing and wanting to help with your personal and professional situation—that’s scarce. Everyone is thinking of themselves first; Someone who truly wants to help you is rare.

AI will increasingly keep getting better at the “best cost” version of everything—anything that AI generates becomes a cheap commodity, but it can never replace purpose.

Purpose is the only currency that remains in high demand. It won’t devalue the second it’s “AI-made.”

At the end of the day

The winners of the AI revolution won’t necessarily be the most talented. They’re the ones who still “give a damn.” We are about to find out how many of us are left in that category.

This is the real “abundance trap.” The peril is not that AI takes our jobs, but that it quietly takes our reason to try.

We must stop competing with the machine on its terms and start building things the machine can’t fake. Purpose is not a nice-to-have anymore—it’s the new Bitcoin.

References

• The AI Abundance Trap: Trillion-Dollar Valuations, AI Job Scare—And How We Can Still Grow the Pie

When BYD ships a new platform faster than its legacy competitors can complete a single ECU change request, the legacy OEMs struggle to explain why. The excuses are manifold, including cheaper labor, government subsidies, and lower safety standards.

The “China speed” advantage is not about just working harder. It is about working within a single, productive organizational environment. BYD produces around 75% of its vehicle components in-house. Tesla has pulled integration tasks back from its Tier-1s and runs them centrally. The engineers working on the battery, the motor controller, the e-drive software, and the vehicle architecture report into a single chain of command. There is no friction between OEM and supplier because there actually is no supplier.

Legacy OEMs cannot replicate this. They will not buy out Bosch, Continental, ZF, Magna, or Aptiv—and even if they wanted to, antitrust regulators and market caps would stop them. The vertical-integration option is structurally limited.

In this article, I introduce a concept to address this problem. I call it CORE SPICE Vertical Integration: an operating model that delivers the capital-efficiency and speed benefits of vertical integration without the ownership—by constructing a neutral development zone where individual experts, drawn from OEM and supplier organizations, work as one team on one program under a shared productive environment.

In the Embedded World Conference 2024, I presented this cooperation principle with Thomas Ziller and Franco Baiocchi under the name “Fusion”. We cemented it in our book “CAR IT Reloaded” in 2024/2025 (German/English editions). The principle was  now re-branded as “CORE SPICE Vertical Integration.”

The argument consists of two parts. This part 1 article explains why the conventional OEM-supplier construct is the real bottleneck and what happens when you stop trying to manage this natural friction and instead suspend it within a defined DMZ (demilitarized zone). Part 2 will discuss challenging questions of IP boundaries, commercial models, career risk for embedded engineers, project infrastructure, and security considerations.

The interface problem

Anyone who has lived through a distressed MtO (Make-to-Order, the conventional ECU car part development) project knows the challenges of cooperation with multiple suppliers and the OEM. It is a well-documented problem within the industry (e.g., see CAR IT Reloaded, chapter 1). The friction lies neither within the supplier nor within the OEM organization; rather, it is at the interface between them.

At those interfaces, OEM and supplier teams independently model the same vehicle subsystem, compete for resources, and live in constant commercial tension because neither can fully trust the other’s outcomes. It manifests as change requests, escalations, back-and-forth negotiations, etc., rather than constructive conversations, because the people who could resolve a clarification in five minutes do not sit in the same room and instead route it through contractual amendments. The fallout includes late defects, escalations, and failures at end-of-line integration, because integration testing occurs at the end of a contractual cycle rather than continuously across the system boundary. Incompatible development processes and tools that cannot interact with each other, except via e-mails and spreadsheets sent back and forth between the development parties, lead to a nightmare of inconsistency.

None of this friction exists at companies like BYD or Tesla. It cannot, because there are no boundaries that could create such friction.

Such friction is the regular situation at all OEM-supplier interfaces. Managing dozens of MtO projects within a single vehicle platform development easily explains why 4 or 5 years are needed to manage the entire car platform and deliver an SOP.

A legacy OEM does not lose to a Chinese OEM by being slower per engineer. It loses because it pays a coordination tax on every interface, while its Chinese competitor gets it “for free.”

Why the obvious answers do not work

The industry has been trying to close this gap for decades. The attempts fall into recognizable patterns.

The first pattern is mandating co-location through contracts. Some OEM-supplier contracts now require resident engineers, on-site presence at integration milestones, or co-located workshops at critical phases. These produce moments of collaboration but do not change the underlying program structure. Each side still reports to its own management, runs its own internal processes (sometimes contradictory), and tracks its own set of metrics.

The second is “preferred partner” or strategic-supplier programs. That includes long-term framework agreements, shared roadmaps, and sometimes joint innovation budgets. These measures help improve the OEM-supplier relationship, but they do not accelerate the design and implementation process. The procurement organizations on both sides maintain a separate commercial framework, regardless of their strategic intentions.

The third is the Toyota resident-engineer model—gesuto enjinia (see here)—which embeds supplier engineers in Toyota’s development offices for one- to three-year stays. It is the closest historical precedent for what I am proposing, and it has worked at Toyota for decades. It has not transferred to legacy automotive OEMs, and the reason is contractual. The Toyota model assumes a keiretsu-grade trust relationship with cross-shareholdings and decades of shared history. A German OEM and a Tier-1 with whom it competes for next-year RFQs cannot replicate that model.

The fourth is joint ventures and equity investments in critical suppliers. These solve specific bottlenecks—chip supply, battery cells, etc.—but they do not address the day-to-day engineering friction across the dozens of other interfaces in a program.

Those four patterns have the same fallout: each preserves the redundant program structure, where the OEM and supplier each run their own program in parallel and pretend the result is a single program. Such a conventional setup can never result in the much-envied “China speed.”

What CORE SPICE Vertical Integration changes

The shift is fundamental and conceptual. Instead of trying to manage the friction between two programs, you suspend it completely, structure the development venture within a well-defined systems development “zone,” and run it as a single program.

A useful metaphor is a commercial DMZ—a demilitarized zone in the original sense, where the normal rules of organizational territory are suspended in service of a larger purpose. In this DMZ, individual experts from the OEM and the relevant supplier or suppliers work as a team on a single program. Not “in close coordination” or “with regular alignment,” but as one team. That results in a single feature list, a shared backlog, a consistent development process, the same cadence, and a consistent body of test evidence. In such an environment, clearly defining the program’s purpose is paramount. One TCC (Team Capability Coach) is holding the team together. They retain their respective employers. However, within the zone, the dual-program coordination has no unproductive overhead that consumes most of their time today.

This is what I mean by CORE SPICE Vertical Integration. The supplier ecosystem remains intact; the commercial relationships continue to exist outside the zone. The “zone” integration removes the friction, scoped to the program where speed matters most.

It is not the same as resident engineers, because resident engineers participate in someone else’s program; they do not become an integrated part of the project. It is also not the same as co-location, because co-location is only a workspace decision, but the processes remain separate. It is also not the same as a joint venture, because there is no new legal entity.

Instead, a “Vertical Integration” program is a substitute for the integration most Chinese companies achieve through ownership. Legacy OEMs cannot just buy their Tier-1s, but they can build a zone where, for the duration of the program, the question of who owns whom becomes effectively irrelevant.

Why does this only work with a vertically integrated program

Simply putting people from three companies in one room does not yet make them a team. Anyone who has run a cross-company integration workshop knows what happens: tooling differences, divergent process languages, conflicting chains of command—that’s a natural outcome that results in two parallel worlds with extra meetings.

CORE SPICE Vertical Integration only works because CORE SPICE provides the operating system underneath it. There is one QA Triage team lead (not two). The Validation and Verification Testing Lead (VVT Lead) oversees product quality across the entire program. Feature-based tracking provides everyone with a common language for progress. The TCC role holds the team across a boundary. Integrated, central roles are indispensable. Without these, virtual integration collapses back into coordination overhead.

The CORE SPICE values—shared accountability, transparency on status, ownership of outcomes rather than deliverables—are what make the zone possible.

This is also why the model cannot be adopted and executed by an OEM and a supplier on their own. It needs a third actor, organizationally neutral to both sides, to run the operating system and hold the team-coaching role across companies. The CORE SPICE model helps remove friction and continues insisting on eliminating redundant requirements and ensuring a consistent sense of urgency.

What comes next

CORE SPICE Vertical Integration is a program/project consistent approach. It is not a product or a consultant framework. It is a strategy to achieve the much-envied “China speed.”

Several hard questions need to be worked out before any program can run on this model.

• Which categories of work belong inside the DMZ, and which stay behind the supplier’s IP firewall?
• What commercial frame replaces fixed-price MtO contracting, which is structurally incompatible with this model?
• How do embedded experts protect their careers inside their home organizations during eighteen-to-twenty-four-month assignments outside the normal reporting line?
• How does the zone handle export control and OEM-internal classification rules when access is granted at the artifact level rather than the company level?

I will address each of these in Part 2, including the commercial-model question.

The point is simple: legacy automotive OEMs cannot outwork Chinese vertical integration. They can, however, construct a synthetic version of it. The “Vertical Integration” program’s scope is to “reduce to the max” to the point where speed matters most, while preserving the safety and security of OEM platforms, the supplier ecosystem that took decades to build, and closing the speed gap exactly where it hurts most: at the commercial boundary, inside the program, between the companies.

That is what CORE SPICE Vertical Integration is.

Part 2 will go into how to make it work.

References:

• Car IT Reloaded, The “fusion” principle
• https://www.youtube.com/watch?v=CHGPejLA1bI: The proxy-presentation on Embedded World

W. Edwards Deming once stated: “In God we trust. All others must bring data.” In most distressed projects I have worked with, the problem is not that the team lacks data. The problem is that the data they do have cannot be relied upon. Tickets exist, reports are produced, charts are displayed—but the underlying system is often inconsistent, and the numbers, at best, describe a rough mood rather than a reality. However, without trustworthy insights, risk minimization (CORE SPICE Principle #7 and arguably the single most important principle when a project is under stress) will fail.

The underlying data, once it is tied together across the data sources, can deliver quality on the project progress and risks. Unique identifiers, clean taxonomy, clear ownership, consistent closure—those aspects are boring accounting work. But when they are missing, the dashboards above them report numbers that nobody can actually trust.

The good news is that the fix is not particularly sophisticated. It is mostly discipline, applied early and kept consistent. This article walks through what that discipline looks like.

Familiar Symptoms

Most projects under pressure I have encountered share a small catalog of symptoms.

• The same (or at least semantically equivalent) defect is logged several times by four engineers, each with a slightly different label, and nobody notices until the reopen rate starts climbing.
• A feature is declared done, but nobody can point to the specification it was built against.
• A change request gets processed through the defect workflow because that was easier at the time, and three weeks later, the scope has grown without anyone deciding so.
• A system “release” means one thing to engineering, another to testing, and a third to the customer’s purchasing team.
• A supplier tracks its contribution in its own spreadsheet, and the integrator’s project tool has no idea what state the supplier’s deliverables are in.
• The testing team tests based on personal experience because there are no documented specifications traced back to the design or requirements. The “completeness” presumption is a mere intention, not a quantifiable, measurable assessment.

These are some of the symptoms of project distress. More daily syncs, more risk registers, or more “write-only” documents cannot compensate for them. A project can have all of those and still be unable to answer, at any given moment, what exactly a feature is in this project, what counts as a defect, what is in the upcoming release, and who is accountable for each open issue right now.

Four Issue Types

Every trackable thing in an MtO project is an “issue” (or use an equivalent term that encompasses all of the below object types). It is practical to limit the taxonomy to four issue types:

Features are customer-visible functionality or essential quality aspects. They originate from specifications (requirements, design). Each feature has exactly one owner: the Feature Owner (see also the CORE SPICE Accelerator #3: end-to-end responsibility, see here). A Feature Owner is accountable for the definition and delivery of a feature from inception through verification.

Defects (or bugs): Deviations from an approved specification. This is not a philosophical definition; it is a practical one. Without a specification, there is no objective basis for calling something a defect. That is a frequent contractual and organizational problem.

Change Requests: agreed deviations from the approved (“baselined”) scope or specification. They are neither features nor defects, and treating them as either creates predictable trouble. When change requests are handled as defects, the scope expands silently while the quality metrics appear to worsen. When they are treated as features, the burndown inflates, making the project look slower than it really is. Change Request, as a distinct, separate type, avoids both distortions.

Work Items: General tasks. They are everything the team needs to do in order to implement one of the three above. They must always be linked to a feature, a defect, or a change request. An orphan work item with no parent is almost always a sign of either duplication or something that no longer needs to be done.

Often, those “tickets” have different prefixes, so that the nature of a unique object is immediately recognizable. Everything trackable fits into one of them.

The same system needs to serve all contributors, including suppliers. A supplier that maintains its defects in a separate tool with its own classification scheme creates a parallel universe. In such cases, the defect curve often spans only half the project. I prefer to be explicit about this in the Supplier Agreement: suppliers use the project’s issue management tool, with the project’s taxonomy and ID scheme.

Unique Identifiers

Every issue carries a unique identifier with a meaningful prefix, such as FEAT-0142 for features, DEF-1203 for defects, CR-0087 for change requests, or WRK-4561 for work items. The prefix makes the type obvious at a glance, and the number is unique across the project’s full lifecycle. This is one of those basic hygiene items that is easy to underestimate until it is missing, at which point cross-referencing becomes guesswork, and any automated traceability reporting becomes unreliable.

The same principle extends to specifications, test cases, and other artifacts. When a defect references REQ-0033 and TEST-INT-0891, the related trace is unambiguous.

The Small V: A Definition of Done for Every Issue

Every issue—feature, defect, change request, or work item—needs an explicit “Definition of Done.” One pattern that works well across all four types is what I think of as a small V, embedded in the issue itself.

On the left side of the V, the issue is defined: What must be delivered, fixed, changed, or done. On the right side, each item on the left has a corresponding verification.

_{(Remark: this is a simplified model that does not distinguish between system and software levels. However, I recommend NOT expanding it into system levels (e.g., system requirements, system design, etc.) for practical reasons.)}

For a feature, the small V traces from the linked specification down through implementation and back up through integration, system test, and customer acceptance. For a defect, it runs from the specification the defect violates, through the fix, to the verification that the fix holds in the target release. Change Requests follow the same pattern as the features. Work items are negotiable, but the expectation and its verification should be explicitly defined.

That is how the team operationalizes No Task Left Behind (CORE SPICE Accelerator #1). The detailed mechanics—lifecycles, states, review rules—belong in either the Project Approach or the Configuration Management Approach, whichever the team prefers as the home for issue governance.

Release Scope

Every release has a clearly defined scope: which features are included, which defects are resolved, and which change requests are incorporated. In the configuration management literature, this is called a baseline, which is accurate but sometimes sounds a bit ceremonial to engineers. In practice, I find “release scope” a good day-to-day term, while “baseline” remains appropriate in the Configuration Management Approach itself.

Whatever it is called, its absence is costly. Without it, “defect DEF-1203 is fixed” does not actually mean anything unless one can specify which release it is fixed in. The same applies to features. Release scope is what the customer is comparing against at delivery.

The discipline is not complicated: each release has a named, frozen scope. Every known defect carries an estimate and a target release, or it is unplanned work dressed up as planned work. Changes to the scope after freeze are themselves change requests and flow through the normal change request workflow. The Project Lead, supported by the Configuration Manager and the TCC, maintains scope consistency.

Effort Estimation

Effort estimation has a reputation for being annoying. It is, but it is also one of the most useful disciplines a project team can adopt—not because the numbers are precise, but because the act of estimating forces the team to think thoroughly about each new/modified issue before it enters a release scope. In a way, “the plan is nothing—the planning is everything.” The real value of the planning activity is gaining a thorough understanding of the complexity and risks of each new issue.

A simple three-bucket scale works well for most MtO projects I have seen:

• S: about 4 hours (a working morning)
• M: about 2 days
• L: larger than M

“S” issue is something that one engineer can complete in a focused half-day.

“M” is a two-day commitment, often with a small handoff.

“L” is everything beyond that.

More detailed estimates are usually not meaningful because of the uncertainty inherent in each set of issues.

Also, “L” comes with a specific rule. Whenever an “L” issue appears, the team’s first response should be to break it down into smaller “S” or “M” issues, each with its own Definition of Done, owner, and traceability. Most “L” issues, on closer inspection, decompose naturally. But not all of them do. Some tasks—a complex system integration, a regulatory submission, a particular safety-critical algorithm—are genuinely atomic. Forcing artificial decomposition produces a fake structure that hides the real risk rather than reveals it.

When an “L” issue cannot be meaningfully broken down, the team should treat its size as the actual problem to manage. Such treatment achieves two things: a) it helps prioritize at or near the top of the release backlog, and b) it is assigned to one of the most highly skilled available owners. Usually, junior engineers cannot effectively handle that level of uncertainty inside a fixed-budget MtO contract; senior engineers can. This is Risk Minimization (CORE SPICE Principle #7) made operational at the issue level.

A Note on Units

Estimates in CORE SPICE projects are expressed in real, calendar-aligned units—hours and days, not “story points” or other abstractions. Story points have their defenders, and there is a legitimate argument that they decouple estimation from individual capacity, so a junior and a senior engineer can agree on a relative size without arguing about who is faster. That argument is acceptable in open-ended R&D projects, but it does not survive contact with MtO reality. The customer’s contract is usually in working days or weeks. The Project Lead needs to know whether the release will land on time, in days, not in abstract points. In reality, story points must almost always be translated back to days anyway, which makes them an extra layer of abstraction with no added value to the team’s effectiveness.

Estimation applies to every issue type, not just features. Defects, change requests, and work items all carry estimates and target releases—or they are unplanned work masquerading as planned.

Traceability: The Minimum That Matters

Traceability is one of those topics that tends to get overblown in strongly regulated projects, where the tendency is to trace everything to everything and discover six months later that nobody is actually reading the traceability matrix. A smaller, deliberate set of traces is more useful and much easier to maintain:

• From specification (requirement, design) to feature.
• From specification (requirement, design) to test case.
• From test case to one or more test runs.
• From each test run to its result data.
• From any defect back to the test run, the test case, and the specification it violates (and, consequently, the associated feature).

These traces are sufficient to make the small V auditable for every issue, and to make the defect curve meaningful at release boundaries. The details of what is traced, how, and by whom belong in the Traceability Approach.

Living Documents and Baselined Documents (a.k.a. “Artifacts”)

Not every project artifact is “frozen.” Specifications—requirements, design, interface definitions—are baselined. They are fixed at a version, associated with a specific release, and changed only through a deliberate revision. In contrast, the CORE SPICE Approach documents—the Issue Management Approach, the Configuration Management Approach, the Project Approach, and others—are, by design, living documents. They evolve as the team learns what works and what does not. All artifacts must have clearly named owners and visible status, but the mechanics differ: a living document is versioned without being frozen; a baselined document is frozen by design.

Artifacts in distressed projects usually have at least one of the following flaws: Either the Approaches are frozen into bureaucratic immutability and become useless (“write-only”), or the specifications are never frozen at all, leaving them unreferenceable. Both failures are avoidable once the distinction is explicit and articulated in one of the corresponding Approaches.

Two Views, One System

A recurring question from customers is whether to display features and defects on a single combined burndown chart or on two separate ones. This is essentially a presentation choice, and I recommend treating it as such.

Keeping features and defects on separate charts makes sense. Feature closure is a steady, human-paced activity; defect closure arrives in waves, peaking around integration and release. Mixing them on a single chart obscures the dynamics of both. Externally, if the customer’s key stakeholder prefers a combined view, it is straightforward to derive one from the same underlying data. The two views are not in conflict. One serves operational needs, the other communication, and both are automated from the same issue management system.

A Simple KPI Set

Once the foundation is in place, a small set of KPIs is enough to give the Project Lead and the key stakeholders a clear read on progress, risk, and where to intervene:

• Feature closure rate and projected release completion can be visualized in the feature burndown.
• Critical defect backlog and its trend can be visualized as a defect curve.
• Open change requests and their scope impact can be visualized similarly to the features.
• Reopen rate. This metric is typically used for defects.
• Release scope readiness shows the next release has a frozen, deliverable scope. That can be integrated into the overall release plan (from inception to SOP).

Those metrics should be automatically generated daily. This is what the Project Lead reads to see progress and risk. It is also what the customer sees, and what builds or erodes trust over time. Further KPIs are optional. When a project starts tracking dozens of KPIs, it is usually because the underlying data cannot quite be trusted. So be careful when adding KPIs.

Radical Transparency

A unified issue system, properly used, produces something that distressed projects almost never have: an honest, shared view of reality. Every issue is visible. Every status is current. Every estimate is in real units. Every release scope is named. Every defect can be traced back to its specification. The Project Lead, the team, the suppliers, and the customer are looking at the same data, in the same system, at the same time. There is no parallel universe. There is no “internal” version of the truth and an “external” version for the steering committee. There must be a single source of truth for everyone.

This may appear uncomfortable at first, especially for teams accustomed to managing the customer’s perception by curating what they see. But it is also liberating. The team stops spending energy on impression management and starts spending it on the actual work. The customer stops asking suspicious questions because nothing is being hidden from them. The relationship shifts from adversarial to collaborative—not because everyone became more reasonable, but because the data made obfuscation impossible.

Radical transparency is also, in my experience, the single strongest predictor of whether a distressed project will recover. Teams that hide their problems cannot fix them.

Automation and the Project Tool Engineer

KPIs should not be maintained by hand. It should be automated, and the role responsible for that automation is the Project Tool Engineer. This project role should be introduced early (in line with CORE SPICE Accelerator #5 “Automate Everything” and Principle #12 (Automated Traceability)). This role designs and maintains the automations that generate the burndown, defect curve, KPI set, traceability reports, and release scope view.

When the role is missing or underresourced, engineers end up spending valuable time on manual reporting—or even worse, not at all. In such cases, teams work in expensive, wasteful silos, which is an anti-pattern that is expensive, error-prone, and demoralizing. In 2026, there is, in most cases, no good reason for manual reporting. The Project Tool Engineer role enables the rest of the foundation to pay for itself.

Discipline, Not Bureaucracy

A well-structured project management system may appear bureaucratic: more prefixes, more closure criteria, more fields to fill in, more structure around what engineers would prefer to simply get stuff done. Senior engineers have seen enough process-heavy initiatives fail to recognize the pattern, and their skepticism is a healthy reaction to their past experience.

The difference is that the strategy described in this article is both uncompromising and super simple. The “plumbing” described above is not compliance theater; it is the mechanism that replaces compliance theater. With honest data in place, the team stops being judged by numbers nobody trusts and starts showing—to management, to the customer, to each other—what is actually true. That is the opposite of bureaucracy. It is Merit Over Bureaucracy (CORE SPICE Principle #11) made operational.

Skepticism can, in my view, only be resolved by demonstrating the practical value of such an integrated project management system. In my experience, adoption rarely comes from the initial explanation. You cannot “convince” professionals by merely postulating a quality framework. It comes from the first honest burndown or defect curve that the team recognizes as the truth they already knew anecdotally. Once that moment arrives, the system becomes a Formula 1 car rather than a mule carriage.

Conclusion

Deming’s observation applies universally: no data, no insights; no insights, no real risk minimization.

The three articles of this series describe a complete recovery dashboard:

• The feature burndown tells the team whether delivery is on track.
• The defect curve indicates whether quality is on track.
• The unified issue system ensures that the data feeding both charts is honest.

With the simple taxonomy—four issue types, unique identifiers, one system including suppliers, a Definition of Done for every issue, a clearly defined release scope, living and baselined documents properly separated, and a handful of KPIs automated—the project team can see what is actually happening in their project.

That is the precondition for minimizing risk, for the radical Transparency that distinguishes recovering projects from sinking ones, for a trusting customer relationship, and ultimately for a successful SOP.

Where to Start

For a team starting a new project, the first Approach to draft is the Issue Management Approach. Note that the Project Approach is also created at the same time. Still, the Project Approach remains a working, living document for a long time—actually, until all other Approaches have been fully established. Nevertheless, the Issue Management Approach is the foundation on which everything else depends, and the one that repays the investment the fastest—often within a single release cycle. The Configuration Management Approach and the Traceability Approach follow naturally once the taxonomy and identifiers are agreed upon.

For a team already “in flight,” the honest answer is less tidy, but the same three Approaches remain the right starting point. Retrofitting costs more than a greenfield setup, but continuing without a foundation costs even more.

References

• Feature-Based Project Tracking — projectcrunch.com/feature-based-project-tracking-how-to-regain-control-in-distressed-mto-projects/
• The Defect Curve — projectcrunch.com/the-defect-curve-a-key-factor-in-turning-around-distressed-mto-projects/
• CORE SPICE Coaching Concept — projectcrunch.com/core-spice-coaching-concept/

An important visual metric to assess the trend in the MtO project is the defect curve—the quality counterpart to the feature burndown. Together, they form a complete picture of project health: one tracks what gets delivered, the other tracks how well it was built.

No Specification, No Defect

As a crucial precondition for managing defects effectively, identifying the failed requirement is essential. A defect can only be defined against a specification. This is not a technicality—it is the legal and technical foundation of defect management that sometimes gets overlooked in the hectic pace of an MtO delivery.

A defect is a deviation from specified, agreed, or contractually mandated behavior—a “requirements baseline.” Without a specification—a document that stipulates what the system is supposed to do—there is no objective basis for calling anything a defect. An engineer who believes something is broken and an engineer who believes it is working as intended will frequently argue indefinitely, because neither has a reference point.

Some projects don’t actually see the value in understanding this crucial distinction. That’s why proper coaching is so decisive in project management. This is why specification quality is a prerequisite for meaningful defect tracking. In MtO projects, the specification spans the entire V-model: from system-level behavioral specs, through architecture and design decisions, down to software-level interface and module specifications. The granularity and formality of traceability between V-stages vary by project complexity and customer requirements, but at every level, the specification serves as the baseline—no specification—no defect.

The practical implication is that, in a turnaround project, one of the first diagnostic questions is whether specifications actually exist at the level of granularity needed to drive defect assessment. If they do not, defect tracking is noise—and the first fix is not in the defect tracker; it is in the specification.

Minimum Viable Traceability

Traceability is one of the most over-engineered topics in MtO project management. Teams frequently spend months building elaborate trace matrices across hundreds of artifacts (sometimes driven by assessors or redundant quality representatives)—only to produce something nobody reads or maintains. That is not traceability. That is compliance theater.

The goal of traceability, in practice, is not completeness for its own sake. It is the ability to answer one question when a defect surfaces: what was specified, how was it tested, and what did the test reveal? Everything beyond that is fundamentally optional.

For defect management specifically, the minimum viable traceability chain has four links:

1. Specification → Test Case. Every test case must trace back to the specification element it is verifying. This is the foundational link. Without it, there is no way to determine whether a failing test reflects a real deviation from a requirement or an error in the test itself. It also answers the question that arises in every Quality Triage: “Is this a defect against the spec, or did the test case misinterpret the spec?” The trace makes the distinction possible.
2. Test Case → Test Run(s). A test case, as an isolated document, says little about the product quality. A test run is an instance of that test case executed at a specific point in time, against a specific build, with a specific result. One test case typically produces multiple test runs across builds, releases, and configurations. The trace from test case to test run enables the team to distinguish between a defect that appeared in build 1.3.2 and was resolved in 1.4.0 versus one that has been consistently failing for six builds.
3. Test Run → Test Run Data. Each test run must record its inputs, configuration, build identifier, execution environment, and result (pass, fail, or blocked). That helps ensure that the issue is not a random—perhaps test-environment-induced—aberration. Without a cleanly recorded test trace, finding the root cause can prove impossible. The data must be captured at the moment of execution, automatically where possible.
4. Defect → Test Case → Specification. When a defect is logged, it must trace back to the test case that revealed it, and through that test case, back to the specification element that defines the expected behavior. This chain makes the Quality Triage efficient.

This four-link chain is not optional in a non-trivial MtO project.

The Distinction between Feature, Defect, and Change Request

Once specifications exist, the team must agree on what a defect actually is—and what it is not. Often, the issue categories are confused, and the confusion is expensive.

A feature is a defined unit of customer-relevant scope. It exists because the customer or an applicable standard demands it. It is planned, owned, sized, and sequenced into a release. A feature is a delivery commitment.

A defect is a deviation from the specification, which, in turn, defines the project scope. The expected behavior or a product quality aspect, such as timing or data transfer rate, does not match the implementation. A defect is not a missing feature. It is a broken promise on something that was already agreed upon.

A change request is a request to modify the specification—to add, modify, or remove a scope-relevant product attribute. It comes from the customer, from a regulatory update, or from a technical decision that invalidates a prior agreement (requirements baseline). A change request is not a defect. It is a new or modified scope that must be assessed, negotiated, and planned like any other feature.

Misclassifying a change request as a defect inflates the defect backlog and obscures real scope changes.

The rule is simple: defects go in the defect tracker. Change requests go through the scope change process. These are different workflows, different owners, different planning implications. It can still all be tracked using one tool, as long as the issue types are clearly defined; it only implies different workflows and responsibilities.

Frequent Symptoms in Troubled Projects

Most distressed projects log bugs in Jira, a spreadsheet, or a makeshift team-specific board. The data is not systematically used to improve product quality.

The symptoms are familiar:

Defect inflation. A single issue spawns multiple duplicates logged by different engineers across disciplines. The backlog balloons, but nobody can tell how many real problems exist.

Defect hiding. Critical issues are quietly downgraded before milestone reviews or quickly fixed without logging them at all.

No closure discipline. Defects are opened enthusiastically and closed reluctantly—or not at all. Nobody feels responsible for driving issues to resolution, because nobody owns them.

No trend analysis. Management asks: “How many open bugs do we have?” The answer is a number. That number, in isolation, is meaningless. What matters is the trend—and that requires a tool capable of generating it.

A Word on Tooling: Spreadsheets Are Not an Option

In a non-trivial MtO project—anything with more than a handful of engineers, multiple suppliers, and a formal release cycle—managing defects in a spreadsheet or a makeshift Kanban board is a path to disaster. It is not a question of preference; it is a structural problem.

Spreadsheets do not enforce ownership. They do not generate trends automatically. They cannot link defects to features, to specifications, or to release plans. They break under concurrent edits. They have no audit trail. And they require manual effort to produce any report, which means reports are produced infrequently, and always too late.

The defect curve requires daily data. Daily data requires a proper issue management system. The tool must support automated status tracking, configurable severity schemas, traceability to features and specifications, and report generation without human intervention.

The investment is not large. The cost of not having it—in lost data, opaque status, and undetected trends—is enormous.

What Is the Defect Curve?

The defect curve is not a single data point; rather, it is a set of three tracked metrics, plotted over time—typically daily or weekly (“time unit”), aligned to release cycles:

1. New defects discovered (inflow) — how many new issues are found per time unit?
2. Defects closed (outflow) — how many are resolved and verified per time unit?
3. Open defect backlog (net) — how many valid, unresolved defects exist right now?

These three metrics tell a story that no status meeting can replicate. In a healthy release cycle, the curve follows a predictable shape: discovery peaks early in integration, closure accelerates behind it, and the open backlog rises briefly, then falls as the release stabilizes. In a distressed project, the story is different: discovery keeps rising, closure is flat, and the backlog compounds week over week. The wave never breaks. Sometimes, no defects are discovered at all, and then—often just at the time of customer delivery—the product falls apart, and everyone acts surprised.

That discrepancy is the earliest warning signal of a quality crisis. If you are watching the curve, you see it in time to act. If you are not, you discover it at system integration, when it is too late.

Interactive defect curve — click Healthy, Plateau warning, or Widening gap crisis buttons to switch between release quality patterns across a 12-week cycle

Figure 1: Insert defect curve chart here — three-line chart showing New defects/week (coral), Closed/week (teal dashed), and Open backlog (blue) across a 12-week release cycle with phase bands for Construction, Integration, Stabilization, and Release/SOP. Red dashed line = SOP acceptance threshold.

Why Trends Matter

The defect count at any given moment is a snapshot that says nothing about the health of the product release. Trends, on the other hand, provide a context for assessing the direction the project release is taking. Trends matter for three reasons:

Visibility. The customer often expects to see the defect curve—not as a courtesy, but as a control mechanism. In the final phase before SOP (Start of Production), most customers will insist on it. A team that can produce a credible, data-backed defect trend curve earns trust.

Risk management. A widening gap between discovery and closure is a risk indicator. It tells you, weeks in advance, that the release timeline is at risk. That is early enough to act: add resources, cut scope, adjust the release date. Detected at the milestone review, the same information arrives too late for anything other than damage control.

Resource demand. A rising defect backlog indicates insufficient team velocity. The closure rate is not keeping pace with the discovery rate. This is a concrete, measurable signal that either more people are needed, or the scope of “done” needs to be restructured.

Severity Classification

The defect curve only works if defects are classified honestly and consistently. A minimum severity model for MtO projects has four levels:

• Critical (Blocker): Safety, security, or compliance-relevant function fails. Release is blocked until resolved or explicitly accepted with documented rationale and customer agreement.
• Major: Significant functional degradation. Customer-visible and reproducible. Must be resolved or formally accepted before release.
• Minor: Limited impact. Accepted with rationale and logged in the release notes. Planned for a future release.
• Cosmetic / Observation: No functional impact. Tracked but not included in the release curve.

Severity is assigned by the VVT engineer (Verification, Validation, and Test) who discovers the defect during testing. That initial rating is then reviewed—and, if necessary, overruled—in the Quality Triage. Developer self-classification is a conflict of interest. The person who wrote the code is not the right person to assess its severity.

Every non-trivial defect must go through a structured assessment before it is acted upon. This process is sometimes called a Change Control Board (CCB) in process-heavy organizations. The name is unfortunate—it implies slow bureaucracy, committees, and multi-day cycles. In a turnaround environment, slow is not an option.

I suggest using a more constructive term, such as Quality Triage, instead. The name reflects what it actually is: a fast, focused daily or near-daily review, attended by relevant feature owners and the Project Lead when needed.

The Quality Triage answers three questions for each defect:

1. Severity confirmed? Does the initial VVT engineer rating hold under technical scrutiny?
2. Impact assessed? Which feature and specification are affected? Which release? Which customer-visible behavior?
3. Owner assigned and release planned? Who owns the fix, and in which release does it land?

That third question is where the Triage connects directly to release planning. A defect that cannot be fixed in the current release gets planned into the next one. It becomes a work item in the future release scope, with an owner and a target date.

Defects without a planned release are a wasteful dead end — deferred until no one remembers the original context of the defect.

Preventing Duplicate Defects

Duplicate defects are one of the most persistent sources of waste in any large defect backlog. Two engineers encounter the same failure in different test contexts, log it separately, and the triage team spends time debating two entries that describe the same root cause. In a project with hundreds of open defects and multiple suppliers logging independently, duplicate rates of 20–30% are not unusual.

This is a problem LLMs are well-suited to solve—and in 2026, there is no good reason not to use them for it.

Before it reaches the Quality Triage, a new defect is automatically screened against the existing open backlog using an LLM-assisted deduplication step. The model compares the new defect’s description, affected component, failure mode, and reproduction steps against the open issues and returns a ranked list of likely duplicates, with a confidence score. The VVT engineer reviews the candidates in seconds. If a true duplicate is found, the new entry is linked and closed immediately.

Beyond deduplication, LLMs can also assist the triage process itself: pre-assessing likely severity based on the failure description and specification context, suggesting a probable owner based on component and historical patterns, and flagging whether the defect description is sufficient. This does not replace the Quality Triage, but it significantly compresses preparation time.

Every Defect Has an Owner

Ownerless defects are backlog theater — they exist in the tracker, surface in meetings, and never get resolved.

Ownership is assigned in the Quality Triage, no later than 24 hours after the defect is logged. The owner is responsible for the defect from that point until closure. The owner drives the resolution (not necessarily personally).

The daily Sync applies the same ownership logic to defects as to features: “This critical defect has not moved in three days. What is the actual blocker?”

Releasing Features with Defects

A feature can be declared done while carrying open defects. This is not a contradiction—it is a deliberate and documented quality decision.

The rule is: a feature is done when all open defects against it are rated Minor or Cosmetic, and those defects are formally logged, owned, and planned for a future release. A feature with open Critical or Major defects is not “done.”

The end state of a well-managed MtO release is not “zero defects.” It is a known quality state: all Critical defects are resolved or explicitly accepted, with a documented rationale and customer sign-off.

The VVT Lead, together with the Project Lead, makes the release recommendation on this basis, not on a zero count. The test report and release notes are the formal record: every unresolved defect that ships with the release is listed, classified, and owned.

Escalations

Serious customer complaints, by definition, are escalations. Escalations must be treated with urgency and transparency. Routing a customer escalation through standard backlog processes is a trust-destroying mistake. The customer who escalates is already frustrated. Making them wait for the next triage cycle makes it worse.

The practical response is structural: plan a buffer of resources for escalations. In every release cycle, reserve a fixed percentage of available engineering bandwidth—held back from planned feature work—for escalation response.

The Anatomy of a Release Quality Cycle

Every MtO release has a natural quality lifecycle. Understanding it prevents the most common misreadings of the defect curve.

Phase 1 — Construction: Features are being implemented. Unit tests run. Defect discovery is low, not because quality is high, but because systematic integration testing has not yet begun. A suspiciously flat discovery curve in this phase is not reassuring; it signals that testing is not aggressive enough.

Phase 2 — Integration: Subsystems connect. Integration tests run. Discovery accelerates sharply. This is expected. A rising defect count during integration is the system doing its job. The critical question is whether the closure rate is keeping pace.

Phase 3 — Stabilization: New discovery slows. Closure dominates. The open backlog falls. The Quality Triage shifts from assessment-heavy to closure-heavy. Remaining defects are classified and owned, and either resolved in this release or explicitly planned for the next.

Phase 4 — Release: Open Critical defects: resolved or formally accepted. Open Major defects: resolved or planned. All defects documented in the test report and release notes. The product ships with a known quality state — not a hoped-for one.

The defect curve makes each phase visible and the transitions legible. If Phase 3 never starts — if discovery keeps rising with no closure acceleration — that is data. It tells you the product is not ready, regardless of the schedule.

Predicting the Defect Curve

One of the most important things to understand about the defect curve is that it looks very different depending on where you are in the product’s release lifecycle — and that the shape is predictable.

Early releases tend to be quiet. The scope is limited. Test coverage is growing but not yet comprehensive. Defect counts are low. This is normal. A low count in early releases is a function of coverage, not quality.

Middle releases are where defect volumes ramp up. Features are delivered in larger batches. Integration testing reveals cross-feature interactions that unit tests missed. The discovery curve steepens.

The final release before SOP is where the curve peaks. Every feature that has been deferred, every integration edge case that was “noted for later,” every customer complaint from field testing, etc., all converge. This is the defect “storm,” and it must be planned for. It is not a surprise. It is a structural feature of the MtO project lifecycles, and teams that are unprepared for it get destroyed by it.

There are several approaches to planning the “storm” phase. I will mention two of the most frequently used in my practice.

Tiger teams. A dedicated group of the project’s most experienced engineers. They are absolute insiders who know the product in depth. This team is assembled to attack the Critical and Major backlog head-on. This approach works best for systemic or deeply rooted defect clusters that require expert knowledge to resolve quickly.

Feature owner-driven resolution. For feature-specific, well-understood defects, the feature owner drives resolution directly with their development team. This is the default path. The feature owner who delivered the feature is responsible for its defect closure, with the same urgency and ownership logic as the original delivery.

Both approaches require deliberate capacity planning — without it, the customer may pressure the team into relying on weakly qualified “best-cost” resources.

The Customer Is Watching

In the late project phase, most customers will not ask for a defect count. They will ask for the defect curve. They will often impose, as part of the contract, a limit on the number of open defects. The product cannot proceed to SOP unless the open defect count for each severity class is below a defined threshold.

That may be perceived as annoying, but it is a healthy expectation. A customer who tracks the defect curve is engaged in quality. Limiting the number of high-severity defects helps assess the project risk early.

This is also why the defect curve must be established early in the project. The customer needs history. A curve that only covers the last month of a two-year project proves nothing.

The CORE SPICE Connection

The five project turnaround measures are also reflected in the article’s measures (Feature-Based Project Tracking: How to Regain Control in Distressed MtO Projects).

No task left behind. Every defect is an owned task. Unowned defects do not exist. Every open issue has a name and a planned release.

Maintain the sense of urgency. The Critical backlog is reviewed daily. A Critical defect that has not moved in 48 hours is a Sync conversation, not a footnote.

End-to-end responsibility. Feature owners own their feature’s defect state, even after implementation is complete. Defects against their feature are their problem until they are closed.

Radical transparency. The defect curve, the Quality Triage outcomes, and the release notes are visible to everyone. That includes the core team, suppliers, and customers. This is especially important in the SOP phase, when the customer is actively tracking the curve.

Automate everything. The defect curve must be generated automatically from the issue management system. That must happen daily, without manual effort. In a non-trivial project, any other approach is not just inefficient—it is a data integrity risk.

Putting It All Together

The feature burndown and the defect curve are the two instruments of a distressed project’s recovery dashboard.

• Feature burndown converging: delivery is on track.
• The defect curve converging indicates that quality is on track.
• Defect backlog planned into future releases ensures that nothing is lost and everything is actively managed.
• The escalation buffer in place ensures that the customer relationship is protected.
• The defect curve is shared with the customer. That helps build trust and team confidence.

The lifecycle of defect volume is predictable: quiet in early releases, rising through integration, peaking before SOP. Plan for that peak. Staff the tiger team. Protect the feature owner’s bandwidth. Set the customer’s expectations with data, not assurances.

In a distressed project, provided the sponsor actively supports the aforementioned measures, a turnaround is always possible.

If the Critical backlog is not falling—or not falling fast enough to meet the customer’s SOP threshold—there is no quality. But if it is falling with a known, documented, owned residual state, the product is under control. And everyone can see it.

References

• Feature-Based Project Tracking — The companion burndown article: projectcrunch.com/feature-based-project-tracking-how-to-regain-control-in-distressed-mto-projects/
• CORE SPICE Coaching Concept — The 12 CORE SPICE principles: projectcrunch.com/core-spice-coaching-concept/
• Car IT Reloaded — Disruption in the Car Industry. Springer-Verlag, 2025. ISBN 3658476907.

This expectation applies to automotive, but equally to aviation, medical devices, railway systems, and any domain where complex, safety-relevant systems are built to customer specification.

When MtO projects get into trouble, the symptoms are remarkably consistent:

• Work-item explosion. A single customer requirement spawns dozens of sub-tasks across disciplines—system requirements, architecture, software requirements, software design, implementation, integration, and verification. Responsibilities are often scattered across different engineers and tools. A project that started with 50 customer requirements now has 1,200 work items, and nobody can tell which customer feature is actually “done.”
• Silo thinking. System engineers don’t talk to software engineers. Software managers don’t talk to project leads. Line managers are randomly involved in the project work. The test team discovers what was built only when integration starts. Suppliers deliver their subsystems in isolation and claim everything is “on track.” The customer is kept at arm’s length. Each group optimizes for its own deliverables, not for the product as a whole. “I am not responsible for that” is often a popular attitude.
• Lack of sense of urgency. Once established, time buffers are consumed by other activities. The planning fallacy—well documented by Kahneman and Tversky—leads to optimistic schedules that drift, leaving deadlines impossible to meet.
• The “trust me” illusion. Management asks: “Are we on track?” The team answers: “Yes, we’ve got this.” That is a pointless ritual. No team or supplier will ever volunteer “No, we are failing.” Status must be measured, not asked for. Verbal assurances are not data. If control cannot be demonstrated with hard data, it does not exist.

The consequence: project status becomes opaque, customer escalations multiply, and team morale collapses. The project is “in trouble,” and nobody noticed until it was too late.

The Feature-Based Approach: What Is a Feature?

The definition of project scope can be structured in numerous ways (see WBS structures defined by the Project Management Institute, PMI). In recent years, many customers in the automotive industry have adopted the concept of a “feature” to define project scope.

While there are countless ways to define what a “feature” is, for our purposes, a feature is a well-defined chunk of customer-relevant scope. It is a deliverable slice of value that the customer or a standard demands, and whose completion can be objectively verified.

Features can be functional or non-functional:

• Functional: for example, “Active Steering Safety Manager,” “Bootloader Update Mechanism,” “CAN Communication Stack.”
• Non-functional: for example: “Startup Time < 200ms,” “ASIL-D Coverage,” “OBD Compliance,” “Cybersecurity Compliance Certification.”

The key criterion: a feature represents a meaningful unit of delivery. It aggregates all related work across the V-model—requirements, architecture, implementation, integration, and verification—regardless of whether the underlying work is system-level, software-level, or cross-disciplinary.

One Feature, One Owner

Feature ownership is a proven way to structure a project around technical expectations. Each feature has exactly one feature owner — a person responsible from inception to final verification. The feature owner is not “just software” or “just systems.” Feature owners own the outcome across disciplines—from left to right in the V. That directly implements the CORE SPICE principle of end-to-end responsibility: one person, one feature, from start to finish. It does not mean the feature owner must do all the work. Rather, the feature approach creates a matrix of responsibilities, and the feature owner must work with other feature owners to prevent redundancies. The advantage is that this approach is strictly merit-based: the feature management team follows the ideal path to delivery rather than requiring a more generalist mindset, since a feature owner usually does not know all the details across the V. Nevertheless, this approach offers a clear end-to-end view and closes the responsibility gap.

This is fundamentally different from tracking at the work-item level, where a requirement passes through five or six different hands, each responsible for only their discipline’s slice. In the feature-based model, the handover points—where things typically get stuck or lost—are eliminated.

Advantages of the Feature-Driven Approach

The feature-driven approach helps structure MtO projects systematically.

• It makes status measurable. Stakeholders see “Feature X: done” or “Feature X: blocked on integration test.” Not “247 work items, 63% closed.” The burndown speaks for itself — no more “trust me.”
• It forces prioritization. Features can be ranked, sequenced into releases, and traded off against deadlines. You cannot meaningfully prioritize 1,200 low-level work items, but you can prioritize 80 features.

The practical setup: The feature list is derived from customer requirements and applicable standards. In a typical complex MtO project, this results in 50-250 features. Each feature is mapped to a release. Status is tracked daily at the feature level—not at the sub-task level.

Radical Transparency: No Silos

Feature-based tracking only works if the entire operation is 100% transparent to everyone on the project team. This is not optional—It is a precondition.

“Everyone” means that:

• The core team: system engineers, software engineers, test engineers, integration leads — everyone sees every feature, every status, every blocker.
• Suppliers: If a supplier delivers custom-built systems or software components, they are part of the team. They participate in the daily Sync. They see the burndown. They report on the same features, in the same tool, with the same status definitions, and a clear “definition of done.” A supplier that delivers features in isolation and shows up at integration with “surprises” is a risk.
• The customer: The customer should see the feature status and the burndown. Hiding problems from the customer does not make them disappear—it makes the escalation worse when they inevitably surface.

No Information Asymmetry

In distressed projects, information asymmetry is a root cause of failure. When the supplier knows something the project lead does not, when the test team sees a problem that the customer has not been told about, when a feature owner is stuck but does not want to admit it—these are the moments where projects silently slide into crisis.

The feature chart, the burndown chart, and the daily Sync must be the single source of truth. If it is not easy to see for everybody, it effectively does not exist. If a supplier’s feature is red, everyone knows it is red—the supplier, the project lead, and the customer.

Risk Minimization Through Tight Tracking

Traditional risk management tends to be bureaucratic and reactive: risk registers, probability/impact matrices, and quarterly reviews are often boring activities that are increasingly pointless and wasteful. The risks sit in a spreadsheet. Nobody reads it until the steering committee.

Risk minimization, on the other hand, is the opposite: the goal is to make risks irrelevant by delivering early, testing often, and closing gaps daily. It is proactive and embedded in the daily workflow. This essential aspect is articulated as CORE SPICE Principle #7.

The Burndown Baseline

Using a burndown (or, alternatively, burn-up) chart is a well-proven risk-reduction, stakeholder-reporting, and project-tracking strategy. When properly set up, it offers near-real-time visibility into release progress, detects delays, and builds trust in the project delivery timeline.

At the start of a release (or a turnaround), the team establishes a baseline: the total number of items that must be completed for the release to ship. This includes features and critical bugs. During the release planning session, critical defects are prioritized alongside features — because a release is not “done” when all features are implemented. It is done when all features are verified, and all critical defects are resolved.

The baseline is not a straight line. Real projects follow an S-curve: slow at the start (ramp-up, architecture, design), steep in the middle (implementation at peak velocity), and tapering at the end (integration, verification, final fixes). A straight-line baseline is a textbook fiction that misleads the team into thinking they are behind when they are still ramping up. The S-curve reflects how value is actually delivered.

From that point, the team tracks daily how many items remain versus how many should remain based on the baseline. The burndown chart makes the answer to “are we on track?” visible to everyone, every day, without anyone having to ask.

Figure 1: Feature + critical bug burndown. The baseline (dashed S-curve) shows the plan; the actual line (solid) shows reality. Both start at the same point. The actual line falls behind the planned S-curve through W1–W5. After corrective measures at W5, velocity increases, and the team converges back to the planned end state.

The chart illustrates a typical pattern: the first weeks show sluggish progress (the team is still reorganizing, silos are being broken down), followed by acceleration once the feature-based approach takes hold. The gap between baseline and actual at any point is the conversation starter: not “are we on track?” but “what do we need to close this gap by next week?”

Advantages of Feature Burndown Charts

Burndown charts offer many advantages:

• They offer daily visibility, which means a daily opportunity to intervene—detect, assess, and plan specific corrective actions.
• They help detect small deviations before they compound.
• They prevent “surprises” at milestone reviews.
• They help maintain the “sense of urgency.” If the line is flat, the team sees it. If the line is steep, the team sees that too.

The Daily Sync: The Heartbeat of the Turnaround

Purpose

A “sync” (also known as “standup”) is a 15-minute daily check-in. Syncs are not status meetings, no reporting ceremonies, etc. They are coordination sessions focused on feature flow and blockers.

Format

• Which features have moved since yesterday?
• Which features are blocked?
• What is needed to unblock the stuck features or bugs

What matters is whether the feature or bug is closer to “done.” Attended by feature owners, the project lead, leading architects, verification leads, and the Team Capability Coach (TCC). Suppliers participate on equal terms.

What Makes This Different from a Scrum Sync

The unfortunate experience with “real life Scrum” is that Scrum tends to be—ironically enough—a heavyweight, cadence-driven, inflexible instrument facilitated by a “scrum master” who often has insufficient power to ensure flawless execution of feature implementation.

As opposed to Scrum, the CORE SPICE approach proposes a release-based, incremental strategy:

No sprints. MtO projects plan releases, not sprints. This is Kanban-style, release-based cadence.

No theater. No “what I did yesterday / what I’ll do today” rituals. The burndown chart is the visual anchor: everyone sees the same picture, every day.

Suppliers in the room. A supplier that delivers features for this release participates in the Sync like any other team member. No separate “supplier sync” behind closed doors.

The TCC role can be summarized as follows:

Challenge the delay: “This feature hasn’t moved in three days. What is the real blocker?”

Facilitate organizational positive attitude: Help the team resolve cross-functional dependencies on the spot.

Sense of urgency: Maintain urgency without creating panic. The TCC ensures the team stays focused without burning out.

Anti-Patterns

The “daily sync” must be crisp, data-driven, and purposeful. The following fallacies should be prevented:

• Turning the Sync into a 45-minute problem-solving session. Whenever needed, dedicated ad hoc working groups must be spun off after the meeting. A good practice is to set aside a “blocked” time for this action right after the meeting, when current open questions can be worked out during the Sync in a small expert group.
• Reporting up instead of coordinating. All features and bugs should already be updated by the feature owners before the Sync.
• Skipping days because “nothing changed”—the cadence is the discipline.

The Psychology of “Closing Features:” the Dopamine Effect

Feature-based tracking is not just a mechanism for visibility and progress control. It is a motivation mechanism.

Every closed feature is a visible, undeniable achievement. The feature owner and the entire team can see it on the burndown chart: one more item moved to “Done.” It triggers a psychological reward—a dopamine response that reinforces the behavior that elicited it.

Feature and bug closure is fundamentally different from closing low-level sub-tasks. Nobody celebrates completing one of twelve software design reviews. But when “OBD Compliance” moves to “Done,” the team knows that a real, customer-visible chunk of work is finished. The effect compounds: each closed feature raises confidence and energy for the next one.

Figure 2: The positive feedback loop. Delivering a feature leads to recognition, triggering a psychological reward that fuels motivation, which drives the next delivery.

Recognition Without Ceremony

Feature closures should be acknowledged in the daily Sync—briefly, factually, but visibly. It is paying respect to the feature owner, who often had to invest a lot of “blood, sweat, and tears” to deliver the feature on time. The team that delivers should be recognized. Not with extensive celebrations, but with a simple acknowledgment—something along the lines of “Feature X is done. Well done, [name].”

That creates a culture where finishing things is valued—not just starting them. Over time, the burndown chart itself becomes a source of team pride: a visual record of what has been accomplished.

Why Celebrating Feature Closure Matters

Distressed teams are often frustrated or even demoralized. They have been in “crisis mode” for a long time, sometimes for months, working long hours with no visible sense of progress. The open-item count goes up. The backlog grows. Nobody feels like they are winning.

Feature-based tracking breaks the monolith into achievable milestones. Each closed feature is proof that progress is real. The positive psychological feedback loop—deliver, recognition, dopamine, motivation, deliver more—is the antidote to the vicious cycle of despair that distressed projects often fall into.

CORE SPICE Measures

The feature-based tracking approach does not work in isolation. It requires a foundation of five CORE SPICE measures already in place. For detailed descriptions, see “CORE SPICE Coaching Concept”.

• No task left behind. Every identified risk or gap becomes an owned task. If you create an issue, you will eventually deal with its outcome—this negative feedback loop prevents backlog mushrooming.
• Maintain the sense of urgency. Every MtO turnaround project is a task force. The TCC ensures high urgency is upheld as long as substantial risks remain unmitigated.
• End-to-end responsibility. The feature owner concept directly implements this: one person responsible from inception to final verification, cross-functional, not discipline-bound.
• Constantly assess the team. Project Lead and TCC monitor whether everyone contributes. Ineffective team members must be swiftly replaced—keeping them demotivates the rest.
• Automate everything. Feature tracking itself should be automated: status pulled from the issue management system, burndown charts generated without manual effort. With LLMs gaining traction, it should be a no-brainer.

Putting It All Together

The elements described in this article are not independent techniques to be adopted piecemeal. They form a system. When all are in place, it creates a self-reinforcing cycle:

• Feature-based tracking provides visibility.
• Radical transparency provides trust.
• The burndown baseline (features + critical bugs) provides accountability.
• The daily Sync provides cadence.
• Feature closures provide motivation.
• CORE SPICE measures provide the cultural foundation.

The cycle: Visibility → Urgency → Action → Progress → Recognition → Motivation → More progress

Feature-based tracking is not a methodology. It is a pragmatic tool that makes existing methodologies work in distressed MtO environments. The key insight is that tracking what the customer or the standard demands—features, both functional and non-functional—not what the process generates. Include critical bugs to reflect reality, not just the plan. Make everything transparent to everyone—the core team, the suppliers, and the customer.

The “trust me, I have this under control” era is over. The burndown is the answer. If the line is flat, there is no control. If the line is steep, the team is winning—and everyone can see it.

References

• Unlock Efficiency with CORE SPICE — The 12 CORE SPICE principles: projectcrunch.com/unlock-efficiency-with-core-spice/

• The Right Genes for Your Project — MtO vs. R&D project typology: projectcrunch.com/the-right-genes-for-your-project/