Made-to-Order (MtO) projects are fundamentally different from R&D. A customer defines the requirements. The scope is contractually fixed. The lifecycle follows a V-model (at least in regulatory-relevant projects) with formal verification at every level of V. In MtO projects, the team must deliver a specific product—not a prototype or a proof of concept. It is usually a production-ready system that meets safety, security, and compliance standards.

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. “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 to 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, No Exceptions

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 exactly 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 does not exist. If a supplier’s feature is red, everyone knows it is red—the supplier, the project lead, and the customer. That is not confrontation. That is professionalism.

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 “sanc” (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 organisational 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 visibility and progress control mechanism. 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

---

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

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