From Vehicle Domain Model to Work Breakdown Structure

At some point, the automobile has to stop being only a model.

Engineers have to design it.

Software developers have to implement it.

Suppliers have to manufacture components.

Factories have to assemble it.

Test teams have to verify it.

And somebody has to coordinate all of this work.

This creates a fundamental transition in ZenOps:

How do we transform the model of the vehicle into the work required to create the vehicle?

The answer is the Work Breakdown Structure — WBS.

But rather than inventing the WBS independently as a project-management exercise, ZenOps can derive much of it from the vehicle domain model itself.

The result is a powerful chain:

Human Need → NDD → Requirements → Domain Model → WBS → Work → Evidence → Finished Vehicle

The technical definition of the product becomes the foundation for the definition of the project.

Product Structure and Project Structure

Consider a simplified vehicle domain:

Vehicle
│
├── Energy System
├── Propulsion System
├── Braking System
├── Steering System
├── Thermal System
├── Body Structure
├── Interior
├── Electronics
└── Software

This describes parts of the product.

Now compare it with a project structure:

Vehicle Development Program
│
├── Develop Energy System
├── Develop Propulsion System
├── Develop Braking System
├── Develop Steering System
├── Develop Thermal System
├── Develop Body Structure
├── Develop Interior
├── Develop Electronics
└── Develop Software

The relationship is immediately visible.

The first structure describes:

What must exist?

The second describes:

What work must be performed to make it exist?

This gives ZenOps a natural bridge between systems engineering and project management.

Do Not Start With Activities

Traditional project planning can easily begin with activity lists:

• Hold requirements meeting
• Design battery
• Develop software
• Contact suppliers
• Build prototype
• Perform testing
• Prepare factory
• Start production

These activities may all be necessary.

But there is a danger.

If the project begins with activities rather than the product model, important work can disappear simply because nobody thought to put it on the list.

ZenOps reverses the reasoning.

First ask:

What must become true?

Then:

What must exist?

Then:

What evidence must exist?

Only then:

What work must we perform?

The WBS becomes a consequence of the model.

Start With the NDD

Suppose the NDD contains:

Provide Safe Transportation
│
├── Maintain Vehicle Control
├── Protect Occupants
├── Maintain Driver Visibility
└── Support Emergency Response

These needs produce requirements.

Requirements produce systems and architectural responsibilities.

For example:

Maintain Vehicle Control
        ↓
Vehicle-Control Requirements
        ↓
Braking System
Steering System
Tires
Sensors
Control Software

Now the WBS can begin emerging:

Develop Vehicle Control
│
├── Develop Braking System
├── Develop Steering System
├── Develop Tire Solution
├── Develop Sensors
├── Develop Control Software
└── Verify Vehicle Control

The project structure is traceable back to the need.

Every Domain Object Can Generate Work

Suppose the domain model contains:

Battery Pack

The project does not merely need a node called:

Battery Pack

It needs work associated with bringing that object into existence.

For example:

Battery Pack
        ↓
Define Requirements
        ↓
Design Architecture
        ↓
Design Components
        ↓
Select Materials
        ↓
Develop Software
        ↓
Select Suppliers
        ↓
Build Prototype
        ↓
Verify
        ↓
Prepare Manufacturing
        ↓
Produce

The domain object becomes a source of work.

This pattern can repeat recursively.

Relations Generate Work Too

This is where the object-network model becomes particularly valuable.

Objects alone do not define the complete project.

Relations must also be engineered.

Suppose:

Battery
   supplies
Inverter

That relation may require work involving:

• Electrical interface definition
• Voltage compatibility
• Current limits
• Protection behavior
• Connector design
• Cabling
• Communication
• Fault handling
• Integration testing

Likewise:

Thermal System
   cools
Battery

may generate work involving:

• Thermal requirements
• Cooling capacity
• Fluid interfaces
• Pumps
• valves
• Control software
• Packaging
• Failure handling
• Thermal testing

The relationship itself produces work.

This is important because many project failures occur at interfaces rather than inside individual components.

Interfaces Must Appear in the WBS

Suppose two teams independently develop:

Energy Module

and:

Propulsion Module

Both teams complete their internal work.

Yet the vehicle still fails because the interface between them was insufficiently defined.

A domain-derived WBS makes interface work explicit:

Energy–Propulsion Interface
│
├── Define Electrical Interface
├── Define Communication Interface
├── Define Mechanical Interface
├── Define Thermal Constraints
├── Define Failure Behavior
└── Verify Integration

The interface is no longer invisible coordination work.

It becomes a first-class work package.

Requirements Generate Verification Work

Every significant requirement should eventually ask:

How will we know this is true?

Suppose:

REQ-0217
Maintain required braking performance
under defined low-friction conditions.

This creates engineering work.

But it also creates verification work:

REQ-0217
│
├── Analyze
├── Simulate
├── Implement
├── Test
└── Produce Evidence

The WBS therefore should not contain only build work.

It should contain evidence work.

This is central to ZenOps.

Tests Can Become WBS Elements

A useful transformation is:

Requirement
     ↓
Test Definition
     ↓
Work Package

For example:

Winter Operation Verification
│
├── Prepare Test Vehicle
├── Prepare Environmental Conditions
├── Execute Cold Start Test
├── Execute Traction Test
├── Execute Visibility Test
├── Execute Thermal Comfort Test
├── Record Results
└── Evaluate Evidence

Testing is not something added after engineering.

It is part of the project structure from the beginning.

The Definition of Done Becomes Evidence

Traditional project management can define completion as:

Task completed.

ZenOps asks a stronger question:

What evidence demonstrates completion?

For example:

Weak definition of done:

Battery thermal system designed.

Stronger definition:

Battery thermal architecture implemented and demonstrated to satisfy the defined operating requirements under specified conditions.

The difference is substantial.

The first measures activity.

The second measures demonstrated outcome.

Quality Thresholds Become Project Gates

This connects the WBS directly to the ZenOps Quality Threshold — QT.

A work package should not advance merely because its planned duration has expired.

It should advance when sufficient evidence exists.

For example:

Battery Module QT
│
├── Needs Traceable
├── Requirements Defined
├── Architecture Defined
├── Interfaces Defined
├── Failure Modes Evaluated
├── Prototype Verified
├── Manufacturing Feasibility Demonstrated
└── Evidence Accepted

Only then does the work cross the threshold.

The project becomes evidence-driven rather than calendar-driven.

Patterns Can Generate WBS Templates

The automotive Pattern Library provides another major advantage.

Suppose we repeatedly use the pattern:

Sense
  ↓
Evaluate
  ↓
Decide
  ↓
Act
  ↓
Verify

That pattern can carry a reusable WBS template:

Implement Control Pattern
│
├── Define Sensing Requirements
├── Select / Design Sensor
├── Define Signal Interface
├── Implement Evaluation Logic
├── Implement Decision Logic
├── Implement Actuation
├── Implement Diagnostics
├── Integrate
└── Verify

Now reusable engineering knowledge produces reusable project knowledge.

A pattern tells us not only:

How this type of system is structured

but potentially:

What work is normally required to implement and verify it.

Modules Can Become Major Work Packages

The modular vehicle architecture provides another natural WBS level.

For example:

Vehicle Program
│
├── Energy Module
├── Propulsion Module
├── Chassis Module
├── Compute Module
├── Thermal Module
├── Cabin Module
└── Vehicle Integration

Each module can then decompose:

Energy Module
│
├── Requirements
├── Architecture
├── Battery
├── Charging
├── Thermal Integration
├── Control Software
├── Diagnostics
├── Supplier Integration
├── Module Testing
└── Manufacturing Readiness

The WBS follows the product architecture while adding the work needed to realize it.

Do Not Forget Integration

If every module generates its own work package, there is a danger:

Everyone finishes their module.

Nobody finishes the vehicle.

Therefore the WBS must explicitly represent integration.

Vehicle Integration
│
├── Mechanical Integration
├── Electrical Integration
├── Software Integration
├── Communication Integration
├── Thermal Integration
├── Safety Integration
├── Human-Machine Integration
└── Vehicle Verification

Integration is not leftover work.

It is a major engineering deliverable.

The BOM Can Generate Manufacturing Work

Once the Bill of Materials becomes sufficiently mature, it creates another branch of the WBS.

Suppose the BOM contains:

Vehicle
│
├── Battery Assembly
├── Drive Unit
├── Front Suspension
├── Rear Suspension
├── Interior
└── Electronics

Manufacturing must determine how these objects become a physical vehicle.

The manufacturing WBS might become:

Prepare Vehicle Manufacturing
│
├── Define Assembly Sequence
├── Design Workstations
├── Specify Tools
├── Specify Robots
├── Develop Fixtures
├── Define Material Flow
├── Develop Quality Inspection
├── Develop Calibration
├── Develop End-of-Line Testing
└── Validate Production Process

The product model begins generating the production model.

Manufacturing Relations Generate Operations

Recall the ORIGIN principle:

Objects + Relations

Manufacturing relations can become operations.

For example:

Robot
   installs
Battery Pack

becomes:

Battery Installation Operation
│
├── Position Vehicle
├── Position Battery
├── Align Interfaces
├── Fasten Battery
├── Connect Electrical Interface
├── Connect Thermal Interface
├── Verify Installation
└── Record Evidence

A relation in the manufacturing domain becomes executable work.

Suppliers Generate External Work Packages

The automotive domain also contains suppliers.

Suppose:

Supplier A
   provides
Brake Controller

That relationship creates project work:

Brake Controller Supplier Integration
│
├── Define Specification
├── Select Supplier
├── Agree Interfaces
├── Review Design
├── Verify Prototype
├── Validate Manufacturing
├── Approve Production Part
└── Monitor Quality Evidence

Supplier management is therefore connected directly to the object being supplied.

Software Must Be Inside the Same WBS

A modern vehicle cannot have one project structure for hardware and an unrelated project structure for software.

Suppose:

Brake Controller
   executes
Brake Software

The WBS should preserve the relationship:

Braking System
│
├── Mechanical Brakes
├── Brake Actuation
├── Sensors
├── Brake Controller
├── Brake Software
├── Communication
├── Diagnostics
└── System Verification

Hardware and software converge at the system level.

This reflects the actual vehicle rather than the organization chart.

The WBS Should Not Mirror the Organization

This distinction is critical.

A project organization might contain:

Mechanical Department
Electrical Department
Software Department
Procurement
Testing
Manufacturing

Those groups may be necessary.

But the vehicle does not behave according to those boundaries.

If the WBS simply mirrors departments, responsibility for complete system outcomes can become fragmented.

ZenOps instead derives the WBS from:

needs + requirements + domain objects + relations + evidence.

People and departments are then assigned to the resulting work.

The work structure follows the problem.

The organization serves the work structure.

From WBS to Responsibility

Once work packages exist, they can be assigned.

For example:

WP-00418
Verify Battery Thermal Performance
Owner:
Thermal Engineering
Contributors:
Battery Engineering
Software Engineering
Test Engineering
Inputs:
REQ-221
Battery Prototype
Thermal Software
Outputs:
Test Results
Evidence Package
QT Decision

Now the work package has context.

It is not merely a task title.

It knows why it exists, what it depends upon, what it must produce, and how completion is judged.

Dependencies Can Come From Domain Relations

This produces another powerful connection.

Project dependencies do not need to be invented manually from scratch.

Many can be derived from the technical model.

If:

Object A
   depends on
Object B

then development or integration work may contain a corresponding dependency.

If:

Module A
   requires interface from
Module B

then:

WP-A
   depends on
WP-B Interface Definition

The technical dependency becomes a project dependency.

This helps align the schedule with engineering reality.

FLEXI Turns the WBS Into Execution

The WBS defines what work exists.

ZenOps FLEXI provides a way of executing bounded pieces of that work in small cycles.

A simplified cycle might be:

Select Work Package
        ↓
Understand Need + Requirement
        ↓
Implement
        ↓
Test
        ↓
Produce Evidence
        ↓
Evaluate QT
        ↓
Integrate

Instead of enormous tasks remaining open for months, work can be decomposed until useful evidence can be produced in short cycles.

The WBS becomes executable.

Work Packages Can Be Recursive

Consider:

Develop Energy Module

This is too large for execution.

It decomposes:

Develop Energy Module
│
├── Develop Battery Pack
├── Develop Charging System
├── Develop HV Distribution
├── Develop Thermal Interfaces
├── Develop Energy Software
└── Verify Energy Module

Then:

Develop Battery Pack
│
├── Define Cell Requirements
├── Develop Module
├── Develop Housing
├── Develop BMS
├── Develop Thermal System
└── Verify Pack

Decomposition continues until the work becomes manageable.

The WBS therefore mirrors the recursive nature of the domain model.

The WBS Is More Than a Task Tree

Traditional representations often show the WBS as a hierarchy.

That remains useful.

But just like the vehicle itself, the project is actually a network.

Work packages have relations:

WP-A
   depends on
WP-B
WP-C
   verifies
REQ-102
WP-D
   produces
COMP-419
WP-E
   integrates
MODULE-12

Therefore the complete ZenOps project model is better understood as a work network with hierarchical views.

The WBS is one view of that network.

Every Work Package Should Know Why It Exists

This may be the most important principle.

Suppose an engineer receives:

WP-771 — Develop windshield heating controller.

The work package should be traceable upward:

WP-771
   ↑
Windshield Heating Controller
   ↑
Visibility Requirement
   ↑
Maintain Driver Visibility
   ↑
Operate Safely in Winter
   ↑
Provide Reliable Year-Round Transportation
   ↑
Human Need

The engineer does not merely know what to do.

The engineer can discover why the work matters.

Every Work Package Should Know What Evidence It Owes

Traceability should also work downward:

WP-771
   ↓
Software
   ↓
Integrated Controller
   ↓
Test
   ↓
Test Result
   ↓
Evidence
   ↓
QT

Now “done” has meaning.

The work package is complete when the expected result exists and the required evidence demonstrates acceptable quality.

From Project Plan to Evidence Network

This changes the nature of project management.

Instead of tracking only:

Task → Start Date → End Date → Percent Complete

we can track:

Need
↓
Requirement
↓
Work Package
↓
Deliverable
↓
Test
↓
Evidence
↓
Quality Threshold

Schedule still matters.

Cost still matters.

Resources still matter.

But they surround the central question:

Are we progressively creating evidence that the vehicle will satisfy the need?

The Complete Transformation

We can now connect the product model and project model:

REALITY
   ↓
x
   ↓
NDD
   ↓
REQUIREMENTS
   ↓
ORIGIN
   ↓
OBJECTS + RELATIONS
   ↓
PATTERNS
   ↓
MODULES
   ↓
VEHICLE ARCHITECTURE
   ↓
DOMAIN MODEL
   ↓
────────────────────────────
   ↓
WBS
   ↓
WORK PACKAGES
   ↓
FLEXI EXECUTION
   ↓
IMPLEMENTATION
   ↓
TESTING
   ↓
EVIDENCE
   ↓
QUALITY THRESHOLD
   ↓
INTEGRATION
   ↓
MANUFACTURING
   ↓
FINISHED VEHICLE

The line in the middle is not a break.

It is a transformation.

Above it:

we describe what must exist.

Below it:

we organize the work required to make it exist.

The Model Becomes the Plan

This leads to a powerful conclusion.

The project plan should not be a separate administrative interpretation of the engineering problem.

It should emerge from the engineering model.

Needs generate requirements.

Requirements generate systems.

Systems contain objects.

Objects participate in relations.

Patterns define reusable structures.

Modules create boundaries.

Interfaces create integration obligations.

Requirements create tests.

Tests create evidence obligations.

All of these create work.

Therefore:

The vehicle domain model already contains much of the information needed to discover the Work Breakdown Structure.

The WBS is the domain model viewed through a different question:

What must humans and machines do to make this model become reality?

And once the work has been executed, the answer returns to the domain model as evidence.

Model → Work → Reality → Evidence → Model

That closes another ZenOps loop.

We are no longer managing a project that happens to produce a car.

We are managing a controlled transformation in which a model of human need progressively becomes a physical vehicle—and every work package exists because it contributes evidence to that transformation.