Reference Example of a Work Breakdown Structure (WBS) for Auto Suppliers

The Work Breakdown Structure (WBS) can be a confusing document. As a result, most examples found in the literature or on the internet are oversimplified. This article offers a more comprehensive WBS example that can be used in real-world automotive development projects.

Even Automotive SPICE assessors often only give a vague response to the standard question about the existence and proper use of the work breakdown structure (WBS). This is surprising since WBS is a simple concept. A WBS defines the project/product work scope. It is used for project effort estimation, project accounting, and essential input for the subsequent project scheduling. The PMI has a deeper discussion of the WBS concept here

A WBS can take different shapes, depending on the purpose of the product. For example, a WBS can resemble a department organization structure in a strong matrix. It could look like this:

Management would review each of the above planning elements and put an estimated cost for a new product, and their sum would constitute a product development budget. In this hypothetical example, the product features—that is, the added value for each product aspect—would not be particularly emphasized.

Another example could be a functional WBS, which is beneficial for incremental development, with its architecture of secondary importance.

For instance, in the mobile communication business, for a “Key Product” like the 4G data feature, dozens (even hundreds) of functions are developed to reach a broad (or deep) market penetration.

For more examples of various WBS, reference the standard PMI book “Practice Standard for Work Breakdown Structures.”

WBS for Automotive Suppliers

In the realm of automotive suppliers, especially in customer projects, a mixture of V-model-based aspects and product features has proven useful. The following WBS reference example illustrates the concept:

The following table contains the full content of this reference example WBS:

The idea is to have a systems-oriented tree with additional planning elements such as FEMA and manufacturing as “branches” of the WBS. It roughly resembles the V-model: System/Software/Mechanical/Hardware Engineering constitutes the left-hand side of the V, while Test Management represents the right-hand side of the V. V-model “neutral” planning elements include the Project Management, FMEA, Product Samples, etc.

WBS Name Remarks Resources
1 Project “My Project” Entire project scope  
1.1    Project Management Project management artifacts  
1.1.1       Core Project Management Top-level project management activities  
1.1.1.1          Team setup report Includes selecting team members and maintaining the interface to the HR Project Manager
1.1.1.2          Project Team Chart Create, review, approve and maintain it. Project Manager
1.1.1.3          Project Management Plan (PMP) Create, review, approve and maintain it. Project Manager
1.1.1.4          WBS Work Breakdown Structure. Create, review, approve and maintain it. Project Manager
1.1.1.5          Effort Estimation WBS-based estimate effort, maintain it, and review it against the original schedule. Project Manager
1.1.1.6          Project Schedule Overall project schedule (until SOP). Create, review, approve and maintain it. Project Manager
1.1.1.7          Risk Register Create, review, approve and maintain it. Project Manager
1.1.1.8          Risk reports Periodically review & update Project Manager
1.1.1.9          Project reports Create, review, and deliver periodically, including status and feature progress Project Manager
1.1.1.10          Project closure confirmation Project closure – wind down the project, plan for post-project maintenance, clean data & close all tasks. Project Manager
1.1.1.11          General project management activities Misc PM tasks Project Manager
1.1.2       Change Request Management Managing the scope of the requirements, including all aspects (such as budget)  
1.1.2.1          CR Repository Impact analysis on all levels and aspects, including technical, budgetary, risks Project Manager
1.1.2.2          CR impact analysis Impact analysis on all levels and aspects, including technical, budgetary, risks, etc. Project Manager
1.1.2.3          CR Reports Status and progress of the CRs. The actual CR implementation is included in other schedules. Project Manager
1.1.2.4          General CR tasks Misc CR tasks Project Manager
1.1.3       Issue Management System Activity records, including defects, change requests, tasks, etc.  
1.1.3.1          Issue Management System (IMS) Create, review, and approve, including rules, workflows, etc. Issue Manager
1.1.3.2          IMS status reports and charts Cleanup, review, backup of defects, (overdue) tasks Issue Manager
1.1.3.3          General issue management activities Misc issue management tasks Issue Manager
1.1.4       Configuration Management Change management on all levels (systems, software, mechanical, etc.)  
1.1.4.1          Configuration Management Plan (CMP) Creation, peer-review, approval, and maintenance it. Configuration Manager
1.1.4.2          Branching Plan On all levels, including systems and software Configuration Manager
1.1.4.3          Baselines Create baselines and support their peer review. Include all disciplines (systems, software, etc.) Configuration Manager
1.1.4.4          Traceability Plan Automate this task and report to stakeholders frequently as defined in the CMP Configuration Manager
1.1.4.5          General configuration management activities Misc CM tasks Configuration Manager
1.1.5       Release Management Product releases as planned in the Project Schedule  
1.1.5.1          Key Release 1 A release as planned in the Project Schedule  
1.1.5.1.1             Effort estimation team workshop Perform an effort estimation team workshop. Analyze features and resolve/document interdependencies Release Manager
1.1.5.1.2             Release Approval Approved, as a minimum, by the QA Release Manager
1.1.5.1.3             Release Delivery to the Customer Physical delivery Release Manager
1.1.5.2          Key Release 2 A release as planned in the Project Schedule  
1.1.5.2.1             Effort estimation team workshop Analyze features and resolve/document interdependencies Release Manager
1.1.5.2.2             Release Approval Approved, as a minimum, by the QA Release Manager
1.1.5.2.3             Release delivery Physical delivery Release Manager
1.1.5.3          Key Release 3 A release as planned in the Project Schedule  
1.1.5.3.1             Effort estimation team workshop Analyze features and resolve/document interdependencies. Integrate into the overall Effort Estimation. Release Manager
1.1.5.3.2             Release Approval Approved, as a minimum, by the QA Release Manager
1.1.5.3.3             Release delivery Physical delivery Release Manager
1.1.5.4          (further key releases)    
1.1.5.5          General release management activities Misc release management tasks Release Manager
1.1.6       Prototype Management “Sample” and “prototype” are two synonyms  
1.1.6.1          Prototype management plan Specify and approve prototype construction, including tools and assembly procedures Sample Manager
1.1.6.2          Systems Integration Plan Describe how a prototype (including numbering scheme, versions of all components, etc.) Sample Manager
1.1.6.3          Integration Schedule Included in the overall Project Schedule Sample Manager
1.1.6.4          BOM Bill of Material, as defined by the system architecture team Sample Manager
1.1.6.5          Prototype components Order components as specified in the system architecture from sub-suppliers (or order internally) Sample Manager
1.1.6.6          System Prototypes Deliver physical samples according to System Integration Plan Sample Manager
1.1.6.7          General prototype management tasks Misc prototype tasks Sample Manager
1.1.7       Purchasing Project-specific purchasing  
1.1.7.1          Supplier contracts Review and sign parts Pos Project Manager
1.1.7.2          Parts and raw materials plan Based on the project contracts for the part defined by the system architecture team/BOM Project Manager
1.1.7.3          Sub-Supplier Management Plan Order, track and monitor the ordered parts Project Manager
1.1.7.4          Supplier reports Report the status of part orders and manage the delivery risks Project Manager
1.2    Product Samples A, B, and C-Samples  
1.2.1       A-Sample delivery A-Sample management  
1.2.1.1          A-Sample Plan, validate, and deliver the A-Sample Technical Manager
1.2.2       B-Sample delivery B-Sample management  
1.2.2.1          B-Sample Plan, validate, and deliver the B-Sample Technical Manager
1.2.3       C-Sample delivery C-Sample management  
1.2.3.1          C-Sample Plan, validate, and deliver the C-Sample Technical Manager
1.3    System Engineering System-level specification and other system-level aspects  
1.3.1       Feasibility Study Perform and document a technical feasibility study Technical Manager
1.3.2       Customer Requirements Specification (CRS) Customer and other key stakeholder input to the product requirements  
1.3.2.1          CRS Repository Define and set up the systems requirements database (e.g., Doors, etc.) Technical Manager
1.3.2.2          CRS requirements analysis CRS content. Analyze the Customer Requirements (CRS) Technical Manager
1.3.2.3          CRS peer-review reports CRS peer review reports and updates, documented in the CRS repository Technical Manager
1.3.2.4          Maintain Customer Requirements (CRS) That includes new/updated requirements from the Customer Technical Manager
1.3.2.5          General CRS tasks Misc CRS tasks Technical Manager
1.3.3       System Requirements (SysRS) System requirements, derived from CRS and other internal requirements  
1.3.3.1          SysRS Analyze the input from the Customer and internal requirements Technical Manager
1.3.3.2          SysRS Approvals Review and approve the System Requirements (SysRS) Technical Manager
1.3.3.3          SysRS Baselines Baselines as planned in the CMP Technical Manager
1.3.4       System Architecture Creation, peer-review, and approval  
1.3.4.1          System Architecture Create initial System Architecture System Architect
1.3.4.2          System Architecture approvals Review and approve the SysRS System Architect
1.3.5       Hardware-Software-Interface HIS: Hardware-Software Interface  
1.3.5.1          HIS specification Specify the HIS specification System Architect
1.3.5.2          HIS reviews Permanent review records. System Architect
1.3.6       System Feature Development Features are based on the SysRS and agreed with the Customer  
1.3.6.1          Feature Plan Create an SYS.2/SWE.3 – based feature plan. Project Manager
1.3.6.2          Feature Plan reviews and reports Reviews with key stakeholders (including the Customer) Project Manager
1.3.7       Safety Management General safety (functional safety is not further detailed in this WBS)  
1.3.7.1          Perform road approval That includes all levels (1 to 4) Technical Manager
1.3.7.2          Safety Features Specific safety features included in the Feature Plan Technical Manager
1.3.7.3          (further safety work products) ISO 26262 artifacts not included, such as FuSa technical concept, FTA, etc.  
1.3.8       Diagnostics Team System-level diagnostics.  
1.3.8.1          Team schedule Detailed planning for/with the developers. Included in the Project Schedule Diagnostics System Lead
1.3.8.2          Diagnostics Specification Define the systems diagnostics, including DTC and diagnostic jobs, include it in SysRS/SRS and features Diagnostics System Lead
1.3.8.3          System Features Specific diagnostics features included in the Feature Plan Diagnostics System Lead
1.3.9       (further system-level teams)    
1.3.10       General systems development tasks Misc systems development tasks Technical Manager
1.3.11       Root Cause Analysis Root cause management  
1.3.11.1          Root-Cause Analysis Reports That includes Fishbone reports, 8D reports, etc. Technical Manager
1.3.11.2          Root Cause Analysis reports Results and resolution status of severe defects. Technical Manager
1.3.12       Technical Documentation Internal, customer, and retail customer documentation.  
1.3.12.1          Documentation schedule Included in the Project Schedule Technical Manager
1.3.12.2          Technical Documentation Develop and deliver technical documentation for the customer Technical Manager
1.4    Software Engineering Software aspects of the system/product development  
1.4.1       Software Project Schedule Included in the Project Schedule Software Project Manager
1.4.2       Software Requirements (SRS) Software-specific product requirements  
1.4.2.1          SRS Analyze software requirements (SRS) Software Project Manager
1.4.2.2          SRS reviews and updates Maintain the Software Requirements (SRS) Software Project Manager
1.4.2.3          SRS Baselines Create, review, and release SRS baselines Software Project Manager
1.4.3       Software Architecture Software architectural design  
1.4.3.1          Initial Software Architecture Create initial Software Architecture Software Architect
1.4.3.2          Software Architecture reviews and updates Review and approve the Software Architecture Software Architect
1.4.3.3          Software Architecture baselines Create, review, and release software architecture baselines Software Architect
1.4.4       Software FMEA Results are included in the system-level DFMEA  
1.4.4.1          Software FMEA Initialize and plan a Software-FMEA Software Architect
1.4.4.2          Software FMEA report Preform Software-DFMA sessions Software Architect
1.4.4.3          Software FMEA status Track and report the Software-FMEA the detection/prevention Software Architect
1.4.5       Continuous Software Integration (CI) Integrate software and report status  
1.4.5.1          CI specification and tools Setup the continuous integration system CI Lead
1.4.5.2          CI reports Create CI reports and dashboards, report CI Lead
1.4.5.3          Source Code Baselines Using the versioning tool (e.g., GIT) CI Lead
1.4.6       Bootloader Team An example software development team  
1.4.6.1          Team schedule Detailed planning for/with the developers. Included in the Project Schedule Software Bootloader Lead
1.4.6.2          Component Design Develop component design Software Architect
1.4.6.3          Software Feature Development Software features as aligned with the systems engineers  
1.4.6.3.1             Software code Develop a component-specific design Software Developer
1.4.6.3.2             Unit Test Specification Write unit tests for the code Software Developer
1.4.6.3.3             Software code peer reviews Perform and document code peer reviews Software Developer
1.4.6.3.4             Feature peer-review approvals Develop unit test specification Software Developer
1.4.6.4          Static Analysis Report Setup, run and report the static analysis Software Developer
1.4.6.5          Components approval Peer-review the components to ensure software requirements compliance Bootloader Lead
1.4.6.6          Defect and defect resolution reports Report and resolve defects Software Developer
1.4.7       (further software-level teams) Misc software development tasks  
1.4.8       General software development activities Team standups, status meetings, etc. Software Project Manager
1.5    Mechanical Engineering Mechanical aspects of the system/product development  
1.5.1       Mechanical Engineering Schedule Included in the Project Schedule Mechanical Manager
1.5.2       Mechanical Design Develop mechanical design. Note: mechanical requirements are included in the SysRS. Mechanical Manager
1.5.3       Mechanical validation prototypes Create mechanical engineering prototypes Mechanical Manager
1.5.4       CAD blueprints Develop and approve the CAD blueprints Mechanical Manager
1.5.5       Mechanical parts Schedule mechanical parts delivery Mechanical Manager
1.5.6       General mechanical engineering activities Misc mechanical development tasks Mechanical Manager
1.6    Electronics Engineering “Hardware” and “Electronics” are two synonyms. Included in the overall system/product  
1.6.1       Hardware Engineering Schedule Included in the Project Schedule Hardware Manager
1.6.2       Hardware Design Develop hardware design. Note: hardware requirements are included in the SysRS. Hardware Manager
1.6.3       Hardware validation prototypes Create hardware engineering prototypes Hardware Manager
1.6.4       CAD blueprints Develop and approve the CAD blueprints Hardware Manager
1.6.5       Hardware parts Schedule hardware parts delivery Hardware Manager
1.6.6       General hardware engineering activities Misc hardware development tasks Hardware Manager
1.7    Test Management Manage testing activities on all test levels  
1.7.1       Test Management Plan Create and maintain the overall Test Management Plan, including updates to the plan Test & Validation Manager
1.7.2       Test Schedule Included in the overall Project Schedule Test & Validation Manager
1.7.3       Test Benches Test benches usually include customized prototypes/samples.  
1.7.3.1          Test Benches That includes all kinds of benches for systems, integration, software Test & Validation Manager
1.7.3.2          Test Benches scripts Script/program test benches for manual/automated testing Test & Validation Manager
1.7.4       Vehicle Field Tests Validation activity in a real car, driving on track or street (depending on the street approval level)  
1.7.4.1          Vehicle validation and test reports Order test vehicles and customize them as needed Test & Validation Manager
1.7.4.2          Field test results Report and document the vehicle-based test drives Test & Validation Manager
1.7.5       System Testing System qualification verification  
1.7.5.1          System Test Schedule Included in the Test Schedule System Qualification Test Lead
1.7.5.2          System Test Specification Develop system test specifications based on the SysRS System Qualification Test Lead
1.7.5.3          Automated system test scripts Programm automated System Test Cases System Qualification Test Lead
1.7.5.4          System Test Reports Analyze and deliver the test reports System Qualification Test Lead
1.7.5.5          Defect reports Analyze and deliver the test reports System Qualification Test Lead
1.7.5.6          General system testing activities Misc system test tasks System Qualification Test Lead
1.7.6       System Integration Test System integration verification  
1.7.6.1          Integration Test Schedule Included in the Test Schedule System Integration Test Lead
1.7.6.2          System Integration Test Specification Develop the System Integration Test Specification based on the System Architecture System Integration Test Lead
1.7.6.3          Automated system integration test scripts Program automated Integration Test Cases System Integration Test Lead
1.7.6.4          Integration Test Reports Perform automated/manual integration testing System Integration Test Lead
1.7.6.5          Defect reports Analyze failed tests and issue defects System Integration Test Lead
1.7.6.6          General system integration test activities Misc system integration test tasks System Integration Test Lead
1.7.7       Software Testing Qualification test verification. The system integration is delivered by the prototype team (see there)  
1.7.7.1          Software Test Schedule Included in the Test Schedule Software Qualification Test Lead
1.7.7.2          Software Test Specification Develop a Software Test Specification Software Qualification Test Lead
1.7.7.3          Automated software test scripts Program/code the automated software test scripts Software Qualification Test Lead
1.7.7.4          Software Test reports Preform the automated/manual software test Software Qualification Test Lead
1.7.7.5          Defect reports Analyze failed tests and issue defects Software Qualification Test Lead
1.7.7.6          General software test activities Misc software test tasks Software Qualification Test Lead
1.7.8       Software Integration Testing Software integration test verification. Software integration is delivered by the CI team  
1.7.8.1          Software Integration Schedule Included in the Test Schedule Software Integration Test Lead
1.7.8.2          Software Integration Test Specification Develop the Software Integration Test Specification Software Integration Test Lead
1.7.8.3          Automated software integration test scripts Automated software integration test scripts Software Integration Test Lead
1.7.8.4          Defect reports Analyze failed tests and issue defects Software Integration Test Lead
1.7.8.5          General software integration test activities Misc software integration test tasks Software Integration Test Lead
1.8    FMEA System-level FMEA  
1.8.1       D-FMEA management Design FMEA on all levels  
1.8.1.1          D-FMA Define and plan the Design-FMEA and prepare according to design documentation Technical Manager
1.8.1.2          D-FMEA report Perform and report the D-FMEA results Technical Manager
1.8.1.3          D-FMEA status Track and report the D-FMEA the detection/prevention Technical Manager
1.8.2       P-FMEA management P-FMEA tasks  
1.8.2.1          P-FMEA Prepare the P-FMEA Technical Manager
1.8.2.2          P-FMEA report Perform and report the P-FMEA Technical Manager
1.8.2.3          P-FMEA Status Record failure modes and report their resolution. Technical Manager
1.8.2.4          DV DV: Design Verification  
1.8.2.4.1             DV Schedule Included in the Project Schedule Technical Manager
1.8.2.4.2             DV review report and approval Design Review documentation, review, approve with QA and other key stakeholders Technical Manager
1.8.2.5          PV PV: Product Validation  
1.8.2.5.1             PV Schedule Included in the Project Schedule Project Manager
1.8.2.5.2             PV review report and approval Production Validation documentation, review, approval with QA and other key stakeholders Project Manager
1.8.2.6          Internal SOP Internal Start of Production  
1.8.2.6.1             Release Candidate Confirm the SOP Project Manager
1.8.2.6.2             Internal SOP approval Deliver internal SOP approval Project Manager
1.8.2.7          Customer SOP Customer Start of Production  
1.8.2.7.1             Customer’s SOP Prepare Customer’s SOP, including documentation Project Manager
1.8.2.7.2             Customer SOP approval Confirm the SOP, ensure payment Project Manager
1.9    Process Quality Process quality-centric. Product quality is handled by the test management team.  
1.9.1       QA Plan Creation, peer-review, and approval QA Manager
1.9.2       QA schedule Included in the Project Schedule QA Manager
1.9.3       QA Checklists Prepare and approve QA checklists for all processes QA Manager
1.9.4       Audits and assessments That includes internal and external (Customer) audits/assessments. QA Manager
1.9.5       QA Report QA status reports QA Manager
1.9.6       Process deviation list and report Use the IMS to maintain deviations, such as ASPICE issues. Send report to stakeholders QA Manager
1.9.7       General QA tasks Misc QA tasks QA Manager
1.10    Manufacturing Plan Product manufacturing.  
1.10.1       Parts plan The final BOM content and production parts orders and schedule Project Manager
1.10.2       Standard manufacturing documentation Documentation as required by standards like ISO TS16949 Project Manager
1.10.3       EOL Specification Define the EOL (end-of-line) test specification Project Manager
1.10.4       Production line readiness reports Review the production line, validate the production line Project Manager
1.10.5       Product Maintenance Plan After customer SOP Project Manager

This WBS example is typical for automotive suppliers, though it could include more elements. For instance, projects with an ASIL level above QM, like ASIL-B or even ASIL-D, will consist of several additional artifacts, such as hazard analysis and risk assessment, FTA, technical safety concept, safety plan, and also other kinds of reviews such as walkthroughs and inspections, and so forth. Further additions could include computers, various cloud-based licenses for your team, supplier-specific work products, training materials, external training meetings, AUTOSAR stack, security certifications, coffee, catering, train and flight tickets, etc.

As a bonus in our example, the responsibility for each planning element (WBS “leaf”) is defined based on project roles. The roles are typically defined in the project team chart and referenced in the project management plan. See the article Standard Reference Project Team Chart for Customer Automotive Development Projects.

The WBS Tool: Simple Solutions Work Best

I used Microsoft Project (MSP) to develop this reference WBS example. It offers automatic WBS numbering and a practical indentation of the WBS. It also can be expanded to include effort and budget tracking. Here is an excerpt from a full MSP document that provides a project budget for each planning element:

Admittedly, using MSP in such a way is unconventional and far from perfect. It is a desktop application that cannot be used for shared access by several persons simultaneously and is challenging to master. Minor user mistakes can cause many annoying problems that take much effort to fix. Also, an MSP license is relatively expensive and increasingly unpopular among software developers. In a way, MSP is like MS Excel: it can be used for many things, but most of those applications are not scalable.

A few other software tools for building and maintaining a WBS could be used. For example, various add-ons and plug-ins for popular project management software like WBS Gant-Chart or Structure for JIRA could emulate the classic WBS. However, setting up such a sophisticated WBS structure is not a simple task and should be left to tool experts in your organization.

As a quick measure, I would recommend using our example MSP-based WBS as a template that could be used and calculating the effort estimation. Once you get more experience with that template, discussing a more sophisticated WBS using multi-user-enabled project management tools may make sense.

WBS and Automotive SPICE Compliance

Using our simple MSP-based example helps systematically structure the project. It is also handy during Automotive SPICE assessments. It, of course, only works if the WBS can be traced to the project schedule. In other words, the WBS must be a fundamental input to the project schedule, which should be demonstrable during the assessment.

The WBS should be included in the project management plan where it should be peer-reviewed and systematically maintained when the project structure changes, which is usually frequently the case.

I recommend embracing the WBS as a mental prop for the project structure. It is not only a helpful checklist for new projects but also resolves the confusion that often occurs when other project stakeholders, such as change request managers, are attempting to perform deep-dive impact analysis of new CRs.

Additionally, sophisticated project managers can use the WBS as a budgeting tool that can help lowering project risks. For that purpose, a comprehensive description of each work product (called “WBS dictionary”) to achieve a clear project scope definition.

When creating your own WBS, I recommend keeping it as simple as possible. In our example, we have created five WBS levels. It should not be more complex than that. Remember that a WBS is basically a project accounting tool. If there is no way to put a tangible price tag on a WBS element, it is probably redundant. Avoid the temptation to make the WBS perfect. Neither your team nor your assessor will appreciate it. It never will be. Like many things in project management, a good-enough approach is often the best.

The Bottom Line

Our WBS reference template is a real-life example of how a work breakdown structure can be shaped in automotive supplier projects. You can use it as a nucleus for your real-life project. As long as the WBS has a real-life added value for the project manager and the rest of the team, it can (and should) become a central tool to maintain the project scope.

When the customer or an assessor asks about WBS and project scope, you have little to fear now.

Please send me a message via LinkedIn if you want to receive this MSP WBS document. I am always happy to be of help.

Roman Mildner
About Roman Mildner 60 Articles
I am a project manager (Project Manager Professional, PMP), a Project Coach, a management consultant, and a book author. I have worked in the software industry since 1992 and as a manager consultant since 1998. Please visit my United Mentors home page for more details. Contact me on LinkedIn for direct feedback on my articles.