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.

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 message me via LinkedIn if you want to receive this MSP WBS document. I am always happy to be of help.

---

Let’s start a conversation on LinkedIn or X.com (formerly Twitter).