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 SystemSteering SystemTiresSensorsControl 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 suppliesInverter
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 coolsBattery
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-0217Maintain required braking performanceunder 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 installsBattery 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 providesBrake 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 executesBrake 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 DepartmentElectrical DepartmentSoftware DepartmentProcurementTestingManufacturing
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-00418Verify Battery Thermal PerformanceOwner:Thermal EngineeringContributors:Battery EngineeringSoftware EngineeringTest EngineeringInputs:REQ-221Battery PrototypeThermal SoftwareOutputs:Test ResultsEvidence PackageQT 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 onObject B
then development or integration work may contain a corresponding dependency.
If:
Module A requires interface fromModule B
then:
WP-A depends onWP-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 onWP-BWP-C verifiesREQ-102WP-D producesCOMP-419WP-E integratesMODULE-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.
