Get Even More Visitors To Your Blog, Upgrade To A Business Listing >>

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


This post first appeared on Project Crunch, please read the originial post: here

Share the post

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

×

Subscribe to Project Crunch

Get updates delivered right to your inbox!

Thank you for your subscription

×