Day 5: Generate the Development Structure

Day 1 defined x.

Day 2 constructed the NDD.

Day 3 built the ORIGIN model.

Day 4 identified reusable automotive Patterns.

Day 5 asks:

What work must now be done to turn this model into a vehicle that can earn evidence?

This is where the development structure begins.

The key ZenOps principle is:

Do not invent the Work Breakdown Structure independently of the engineering model. Generate it from what remains unresolved.

The Day 5 transformation is:

Need + OR Model + Pattern Status + UNKNOWNs → Questions → Work Packages → WBS → FLEXI Execution Structure

The project plan should become a consequence of the model.

Not the other way around.

Start With What Is Already Known

Suppose the AURORA vehicle architecture now contains:

Braking Pattern:
REUSE
Drive Unit Pattern:
REUSE
Battery Structural Pattern:
REUSE
Thermal Pattern:
MODIFY
Winter Preconditioning:
NEW
Charging Interface:
MODIFY

This already tells us something important.

Not every subsystem needs the same engineering effort.

The mature areas need confirmation.

The modified areas need impact analysis and revalidation.

The new areas need full development.

Stop Treating the Whole Car as Equally Unknown

A traditional WBS may decompose:

Vehicle Development
├── Battery
├── Brakes
├── Steering
├── Software
├── Body
└── Charging

and then assign large task structures under all of them.

But this hides the most important information:

Which parts are already well understood?

A ZenOps development structure should preserve the knowledge state.

Classify the Work by Pattern Status

A useful first rule is:

REUSE
→ confirm applicability
MODIFY
→ analyze impact + adapt + revalidate
REPLACE
→ remove old Pattern + introduce replacement + prove transition
NEW
→ full learning cycle

This immediately changes the WBS.

Example: Reused Brake Pattern

Suppose:

Brake Pattern v5
Status:
FIELD VALIDATED
Decision:
REUSE

The work might be:

Confirm AURORA mass within Pattern range
Confirm wheel/tire compatibility
Confirm software interface compatibility
Run required regression evidence

That is very different from:

Develop brake system from scratch.

Example: Modified Thermal Pattern

Suppose:

Thermal Pattern v4
Decision:
MODIFY

because AURORA requires more aggressive cold-weather charging.

The work may become:

Identify changed thermal requirements
Model additional heat demand
Modify control logic
Evaluate pump capacity
Prototype revised thermal strategy
Validate winter charging

The work follows the delta.

Example: New Preconditioning Pattern

Suppose:

Winter Preconditioning:
NEW

Then the team may need:

Understand customer preconditioning use case
Define thermal strategy
Define control architecture
Simulate energy consumption
Prototype software
Test in climate chamber
Validate in vehicle

This is full development because organizational knowledge is weak.

The WBS Should Be Knowledge-Weighted

Conceptually:

Mature Knowledge
↓
Small Confirmation Work
Changed Knowledge
↓
Moderate Revalidation Work
New Knowledge
↓
Large Learning Work

This concentrates resources where uncertainty is highest.

Start Day 5 by Listing Every Important UNKNOWN

From the previous days, AURORA may contain:

UNKNOWN:
Preconditioning energy budget
UNKNOWN:
Thermal response at -30°C
UNKNOWN:
Charging connector sealing durability
UNKNOWN:
Supplier separator resilience

These are the true seeds of development work.

UNKNOWN Should Produce a Question

For example:

UNKNOWN:
Thermal response at -30°C

becomes:

Question:
Can the selected thermal architecture bring the battery
into its required charging range within the target time
at -30°C?

This is much better than:

Task:
Thermal development

The question tells us what must be learned.

Questions Generate Work

The question may generate:

Create thermal simulation model
Define cold-soak boundary conditions
Run simulation
Analyze result
Prototype revised control strategy

Now the work has a clear reason.

Work Should Resolve Something

A useful Day 5 rule is:

Every significant work item should resolve a need, requirement, architectural uncertainty, Pattern gap, risk, or evidence gap.

If a task cannot answer:

Why does this exist?

challenge it.

A WBS Item Should Point Back Upstream

For example:

WORK-THERM-041
Validate -30°C battery warm-up performance

should link to:

NDD:
Winter Operation

Requirement:
REQ-WINTER-011

OR Objects:
Battery + Thermal System

Pattern:
Thermal Pattern v4 — MODIFY

The work becomes fully contextualized.

This Is Different From a Detached Project Schedule

A conventional schedule may say:

Task 511:
Thermal test
Owner:
Alice
Duration:
5 days

OPUS Delivery should additionally know:

Why:
Resolve Thermal Pattern applicability
Evidence Expected:
Cold-soak performance result
QT Dependency:
Battery Prototype QT

Now task completion has meaning.

Build the WBS From the Model

A top-level AURORA development structure might become:

AURORA DEVELOPMENT
│
├── 001 Need Resolution
├── 002 Architecture Confirmation
├── 003 New Pattern Development
├── 004 Modified Pattern Revalidation
├── 005 Supplier Development
├── 006 Prototype Development
├── 007 Verification
├── 008 Manufacturing Development
└── 009 Release Evidence

This is one possible structure.

The exact hierarchy is less important than its traceability.

Work Can Also Be Organized by Domain Object

For example:

Vehicle
├── Battery
│   ├── Confirm structural Pattern
│   ├── Modify thermal Pattern
│   └── Validate charging
│
├── Braking
│   └── Confirm mature Pattern applicability
│
└── Charging
    ├── Modify connector Pattern
    └── Develop preconditioning logic

Both views can be useful.

One Underlying Work Item, Multiple Views

This is important.

Do not create duplicate tasks simply because project managers and engineers want different views.

One work item can appear under:

Object View
Pattern View
WBS View
QT View

The underlying identity remains the same.

Work Package vs Work Item

Large unresolved questions may become:

Work Package

For example:

WP-THERM-001
AURORA Winter Thermal Capability

containing:

Simulation
Control Design
Prototype
Testing

Individual executable actions become Work Items.

Work Packages Should Have Clear Outcomes

For example:

WP-THERM-001
Outcome:
Enough evidence to determine whether the modified thermal Pattern
satisfies AURORA winter charging needs.

This is stronger than:

Complete thermal engineering.

Avoid Activity-Based Work Packages

Weak:

Battery Meetings

Stronger:

Resolve battery thermal architecture decision

The second describes a needed result.

Project Work Should Follow Decisions

Some work exists because an engineering decision has not yet been made.

For example:

Decision Needed:
Select cooling architecture

Then the work may include:

Compare Pattern A and Pattern B
Generate evidence
Record decision

The WBS should support decision resolution.

Candidate Architecture Work Can Be Explicit

Suppose:

Candidate A:
Liquid cooling
Candidate B:
Refrigerant direct cooling

The development structure may include:

Evaluate performance
Evaluate manufacturing
Evaluate serviceability
Evaluate supplier risk
Compare evidence
Select architecture

The decision object closes the work package.

Use FLEXI for Small Learning Cycles

Day 5 should not immediately convert every work item into multi-month tasks.

Large questions should be decomposed.

For example:

Can AURORA meet winter charging performance?

is still too large.

Break it into FLEXI questions:

What thermal energy is required after -20°C soak?
Can current heater capacity deliver it?
What is the energy penalty?
Does preconditioning timing solve the problem?

Each can produce evidence quickly.

The FLEXI Cycle

The structure remains:

Question
↓
Small Work Cycle
↓
Evidence
↓
Decision

The development structure becomes a series of learning loops.

This Reduces Large Hidden Tasks

A task such as:

Develop charging system — 120 days

can hide enormous uncertainty.

A series of explicit questions exposes it.

That makes progress more meaningful.

Work State and Knowledge State Are Different

A work item can be:

COMPLETE

while the result is:

FAIL

For example:

Task:
Run cold-charge test
Work Status:
COMPLETE
Evidence:
FAIL

The project should not interpret completed activity as successful engineering.

Day 5 Should Preserve This Separation

Useful dimensions include:

Work Status:
NOT STARTED
ACTIVE
COMPLETE

and separately:

Evidence State:
PASS
PARTIAL
FAIL
UNKNOWN

This is central to ZenOps project management.

Failed Work Can Create More Work

Suppose:

Cold-charge test:
FAIL

Then:

Root-cause investigation
Modify control strategy
Repeat test

may be generated.

The WBS evolves with evidence.

This Means the WBS Is Living

The complete development plan cannot always be known on Day 5.

That is acceptable.

The initial structure should represent current knowledge.

As evidence arrives:

New Work

may emerge.

ZenOps favors adaptive evidence-driven planning over pretending all future work is knowable.

Still Create a Program Backbone

A living WBS does not mean no structure.

A useful backbone might include:

Need Validation
Architecture
Pattern Qualification
Prototype
Supplier Readiness
Manufacturing Readiness
Verification
Release

The details evolve underneath.

Use QTs as Higher-Level Milestone Definitions

Instead of:

Milestone:
Prototype Complete
Date:
June 1

define:

Prototype QT

with evidence criteria.

The date remains a planning target.

The QT defines actual readiness.

WBS Items Should Feed QTs

For example:

Battery Prototype QT

depends on:

Thermal Evidence
Charging Evidence
Safety Evidence
Software Evidence

Work packages exist to produce those evidence objects.

The flow becomes:

Work
↓
Evidence
↓
QT

This Creates a Better Project Structure

The program can answer:

Which work items are blocking Prototype QT?

This is much more useful than:

Which tasks are late?

Both matter.

But blocking evidence is the deeper delivery question.

Example AURORA Prototype Structure

AURORA PROTOTYPE DEVELOPMENT
│
├── Battery
│   ├── Structural Pattern applicability
│   ├── Thermal modification
│   └── Safety verification
│
├── Charging
│   ├── Fast-charge definition
│   ├── Connector durability
│   └── Preconditioning development
│
├── Drive
│   └── Reuse confirmation
│
├── Software
│   ├── Thermal control
│   ├── Charging coordination
│   └── Diagnostic logic
│
└── Prototype Integration
    ├── Build Prototype P1
    ├── Integrate systems
    └── Execute Prototype QT evidence

The structure mirrors the engineering model.

Work Can Cross Multiple Objects

Not every work package belongs neatly under one subsystem.

For example:

Fast-Charging Winter Performance

may involve:

Battery
Thermal System
Charge Port
Navigation Software
Vehicle Controller

The work package should be cross-functional where the need is cross-functional.

Avoid Organizational WBS Silos

A weak WBS may be:

Mechanical Team
Electrical Team
Software Team

That mirrors the organization.

But the product problem may cut across all three.

A better work package is:

Resolve winter charging capability

with contributors from multiple teams.

Ownership Is Still Useful

Each work item should have a responsible owner.

But ownership should not define the engineering meaning.

For example:

Work:
Resolve charging connector environmental durability
Owner:
Connector Engineering

The problem remains a product problem.

Define Expected Evidence Before Starting Work

This is one of the strongest Day 5 practices.

For each major work item, ask:

What evidence should this produce?

Example:

Work:
Validate thermal warm-up strategy
Expected Evidence:
Measured or simulated warm-up time under defined cold-soak conditions

This keeps work outcome-focused.

A Work Item Without Expected Evidence Is Suspicious

If the output is only:

document produced

ask whether the document itself matters or whether it should support a claim.

Documents can be useful.

But evidence and decisions are the real goal.

Engineering Documents Can Be Outputs, Not Ends

For example:

Simulation Report

is useful because it supports:

Claim:
Thermal architecture satisfies warm-up need.

Keep the relationship explicit.

Generate Work From Pattern Gaps

Suppose Day 4 found:

Pattern:
Preconditioning
Status:
NEW

Then Day 5 should create a development package.

The Pattern gap itself is the source.

Generate Work From Pattern Modifications

Suppose:

Liquid Cooling Pattern v4:
MODIFY

Create:

Identify changed interfaces
Review inherited evidence
Define new evidence needs
Modify architecture
Revalidate

The work is delta-based.

Generate Work From Anti-Patterns

Suppose the old architecture triggered:

ANTI-PATTERN:
Critical connector without positive seating verification

The new development structure should explicitly contain:

Define positive connector verification
Validate manufacturing detection
Generate regression StoryQ

Negative knowledge creates preventive work.

Generate Work From FMEA Later

As failure analysis develops, high-priority failure modes may generate:

Mitigation design
Test
Evidence

The WBS can absorb these.

It remains connected to risk.

Generate Work From Supplier UNKNOWNs

Suppose:

Secondary cell source:
UNKNOWN

Then:

Identify candidate supplier
Assess interface compatibility
Assess capacity
Assess evidence
Qualify

Procurement work becomes part of the same development structure.

Generate Work From Manufacturing UNKNOWNs

Suppose the product requires:

Battery Installation Relation

but no production method has yet been proven.

Then:

Develop installation process
Select tooling
Create verification method
Run process trial

The factory WBS derives from the product model.

Day 5 Is Where Product and Factory Work Begin to Meet

The vehicle architecture creates manufacturing needs.

For example:

Vehicle
contains
Battery

means:

Factory must create
Vehicle-Battery relation

That generates manufacturing development work.

Do Not Wait Until Design Freeze to Think About Production

If an architecture is impossible or expensive to manufacture, early factory input should reveal that.

The development structure should include manufacturing evidence early.

Serviceability Work Can Be Generated Too

Suppose NDD requires:

Replace failed charging controller

but the architecture is new.

Create:

Define service access
Define replacement method
Define configuration recovery
Define repair verification

Service readiness becomes part of development.

Lifecycle Work Belongs in the WBS

For example:

Define OTA update method
Define persistent vehicle identity
Define service-history structure

if these are part of the product needs.

The development structure should cover the complete lifecycle, not just SOP.

Use Work Dependencies Carefully

Some tasks genuinely depend on others.

For example:

Select Thermal Architecture
↓
Build Prototype
↓
Physical Test

That dependency should be explicit.

Avoid Artificial Dependencies

Do not require:

All Battery Work Complete
before
All Software Work Begins

if software can develop against simulations or interface definitions.

FLEXI favors parallel learning where possible.

Work Can Be Parallelized by Questions

For example:

Thermal Simulation
Supplier Capability
Connector Durability

may run in parallel.

The program should exploit independence.

Dependency Comes From the Domain, Not the Gantt Chart

If object A depends on object B, work may inherit that dependency.

The OR model can help derive project dependencies.

This is another advantage of connecting engineering and project management.

The WBS Can Be Seen as an Action Projection of the Domain

The OR model says:

What exists?

The Pattern Network says:

What do we already know?

The WBS says:

What must we now do?

All three are views of one transformation.

Define a Work Item Model

A useful OPUS Delivery Work Item may contain:

Id
Title
Question
Owner
Upstream Need
Related Objects
Related Pattern
Expected Evidence
Status
QT Dependency

This is far richer than a simple task row.

Example

WORK-CHG-041
Title:
Validate cold fast-charging performance
Question:
Can AURORA meet the defined fast-charge need
after -20°C cold soak?
Related Need:
NDD-WIN-004
Related Objects:
Battery Pack
Thermal System
Charge Port
Pattern:
Thermal Pattern v4 — MODIFY
Expected Evidence:
Cold-charge test evidence
QT:
Battery Prototype QT

Now the entire reason for the work is visible.

Work History Matters

If the item fails and is repeated, preserve the history.

For example:

Run 1:
FAIL
Run 2:
PARTIAL
Run 3:
PASS

The learning path may be useful later.

WBS Should Not Hide Iteration

Traditional schedules may want one:

Validation Task

ZenOps can represent repeated learning cycles explicitly.

This creates better organizational memory.

Work Can Create New Questions

Suppose a test reveals:

Unexpected voltage drop

Then:

New Question:
Why?

The new question generates another work item.

This is legitimate.

The Development Structure Becomes Self-Extending

Conceptually:

Question
↓
Work
↓
Evidence
↓
New Question

until sufficient knowledge exists.

Stop When QT Has Enough Evidence

The objective is not infinite investigation.

Once the relevant QT criteria are satisfied:

PASS

the current development cycle can close.

This gives a stopping rule.

Cost and Schedule Still Matter

ZenOps does not remove:

Budget
Dates
Resources

They remain project constraints.

But they should be attached to meaningful work.

The engineering reality should not be reduced to those numbers.

Estimate Work Based on Knowledge State

A mature reused Pattern may have predictable effort.

A new Pattern may carry much wider uncertainty.

This should influence estimates.

The WBS Itself Can Learn Over Time

If every new thermal Pattern historically requires:

Simulation
Prototype
Climate Test

future projects can inherit that work Pattern.

Project execution becomes reusable knowledge too.

Work Patterns Can Exist

Examples:

New Pattern Development Work Pattern

Modified Pattern Revalidation Work Pattern

Supplier Qualification Work Pattern

The WBS can reuse proven project structures.

This Is Pattern Thinking Applied to Project Management

A project task sequence that repeatedly works can itself become a Pattern.

The organization learns how to engineer, not only what to engineer.

Day 5 Should Produce a Development Baseline

By the end of the day, AURORA should have:

Major Work Packages
Critical Questions
Pattern-Based Work Classification
Owners
Dependencies
Expected Evidence
QT Links

This becomes the initial execution structure.

Example Day 5 Development Baseline

AURORA DEVELOPMENT
│
├── WP-001 Customer / Need Resolution
│
├── WP-002 Reused Architecture Confirmation
│
├── WP-003 Winter Preconditioning — NEW
│
├── WP-004 Thermal System — MODIFY
│
├── WP-005 Charging Interface — MODIFY
│
├── WP-006 Supplier Qualification
│
├── WP-007 Prototype Integration
│
├── WP-008 Manufacturing Process Development
│
└── WP-009 Verification and QT

Each package contains explicit questions and evidence outputs.

Day 5 Development QT

A useful threshold could be:

DAY 5 DEVELOPMENT STRUCTURE QT
[ ] Major UNKNOWNs mapped to questions
[ ] REUSE work limited to applicability confirmation where appropriate
[ ] MODIFY / REPLACE / NEW areas generate explicit development work
[ ] Major work items linked to NDD and OR objects
[ ] Expected evidence defined for critical work
[ ] Important dependencies visible
[ ] Owners assigned
[ ] Relevant QT dependencies established
[ ] Major manufacturing / supplier / service work not omitted

If these conditions are satisfied:

DAY 5 DEVELOPMENT STRUCTURE QT:
PASS

The vehicle program now has an actionable execution model.

PASS Does Not Mean the WBS Is Frozen

The WBS will change.

New evidence will create new work.

Some planned work will become unnecessary.

Some reused evidence may prove sufficient.

That is normal.

The Development Structure Is a Living Projection

The stable foundation is:

Need
Objects
Relations
Patterns

The work structure changes as knowledge changes.

That is appropriate.

What Not to Do on Day 5

Do not:

• invent thousands of tasks merely to look complete
• treat every subsystem as equally uncertain
• copy an old WBS without checking the new context
• hide engineering questions inside vague activities
• confuse completed work with successful evidence
• freeze the project plan before learning begins

The purpose is not administrative detail.

The purpose is executable learning.

A Bad Day 5

A bad result might be:

Battery Development — 180 days
Software Development — 220 days
Testing — 90 days

with little explanation.

This describes calendar allocation.

It does not describe what must be learned.

A Good Day 5

A good result says:

Question:
Can modified Thermal Pattern v4 meet -30°C fast-charge requirements?
Work:
Simulation + prototype + climate test
Evidence:
Cold-charge performance
QT:
Battery Prototype QT

This is much stronger.

The Complete Day 5 Flow

The day can be summarized as:

DAY 4 PATTERN MODEL
↓
IDENTIFY REUSE / MODIFY / REPLACE / NEW
↓
COLLECT UNKNOWNs
↓
TURN UNKNOWNs INTO QUESTIONS
↓
TURN QUESTIONS INTO WORK PACKAGES
↓
DEFINE EXPECTED EVIDENCE
↓
ADD OWNERS + DEPENDENCIES
↓
CONNECT WORK TO QTs
↓
CREATE INITIAL WBS
↓
DAY 5 DEVELOPMENT STRUCTURE QT

The vehicle program is now ready to move from structured thinking into systematic execution.

Why Day 5 Matters

Before Day 5, the organization understands:

• why the vehicle should exist
• what needs it must satisfy
• what the main system objects are
• what knowledge can be reused

Day 5 converts that understanding into action.

But it does so without losing meaning.

The project plan is no longer an independent administrative artifact.

It is generated from the engineering domain.

From Domain Model to Delivery Model

The transition is:

NDD:
Why?
ORIGIN:
What?
Patterns:
What do we know?
WBS:
What must we do?

This is the practical bridge between ZenOps engineering and ZenOps project management.

Day 5: Generate the Development Structure

That is the fifth practical step in the ZenOps Car Factory.

Take the NDD, ORIGIN model, Pattern Network, and visible UNKNOWNs from the first four days; turn every important uncertainty into a clear question; generate work only where a need, dependency, Pattern gap, risk, or evidence gap demands it; classify work according to REUSE, MODIFY, REPLACE, and NEW; define the evidence each important work item must produce; connect the work to Quality Thresholds; and build the initial WBS as a living projection of the vehicle model rather than as an isolated schedule.

Day 1 defined why.

Day 2 structured the need.

Day 3 modeled the system.

Day 4 separated known Patterns from genuine novelty.

Day 5 turns the remaining uncertainty into work.

And from this point forward, the most important question is no longer:

How many tasks have we completed?

It is:

What have those tasks taught us, and what evidence do we now have?