Standard Reference Project Team Chart for Customer Automotive Development Projects

Project team charts are a powerful tool to define responsibilities in projects. While it is impossible to create a project team chart for all kinds of businesses, there is a good practice template that can be reused in automotive customer projects.

Organizational team charts (also known as “org charts”) differ from project team charts, as the former is typically used in functional management, while the latter is used in projects.

While org charts are used in all kinds of organizational contexts, the project team charts are particularly useful to define the individual responsibilities in customer projects.

Automotive suppliers are my favorite genre. In particular, in customer development projects, I have observed a lot of confusion regarding the team structure and individual team member responsibilities. As assessment models such as Automotive SPICE or CMMI don’t define any particular roles, project teams create their team structure that ranges from helpful to impossible to follow.

The team structure depends on the nature of a project. From my observations in dozens of auto supplier projects in the past, the following project types occur frequently:

  1. R&D (research & development) projects
  2. Platform projects
  3. MtO (made-to-order) projects (or customer projects)

R&D (research and development) projects are often agile and less restrictive, having a project structure that is impossible to standardize strictly.

Platform projects do not really fit the project definition from PMI as platform development goals emphasize continuous delivery of reusable components (such as generic features and software libraries).

Customer projects (MtO) projects are particularly interesting as they can be, at least, roughly standardized since auto supplier contracts resemble requirements based on systems, software, validation, and process quality customer expectations.

Standard Team Chart for Auto Supplier-Customer Projects

As discussed in the article Adaptive-Agile Team Structure, it is crucial to have an efficient team setup. Self-organization, especially in safety-relevant customer projects, is not a viable option. Thus, a well-defined, central set of hierarchical roles are needed. In that context, a project team chart can be used to communicate team-wide responsibilities. From experience in dozens of past automotive customer projects and based on basic Automotive SPICE/CMMI process quality requirements, a generic reference project team structure can be derived using the following assumptions:

  • The team is project-driven (as opposed to strong matrix organizations)
  • The project manager is the leading role
  • The project is a systems development project. Software, but also electronics (hardware) and mechanical engineers are involved
  • The project is based on a V-model principle (as opposed to Scrum or other project management approaches)
  • The roles are based on individuals (as opposed to committees or general “teams”)

The below chart is a general team structure that works well for automotive, safety-relevant, customer projects:

Project Team Chart

Corporate functions such as the Department Manager are only included in the overall chart to establish a project context. Such functions include:

  • Department Manager, who is often also a “project sponsor,” as defined in the PMBoK Guide
  • QA Manager, who is independent of any project
  • FuSa (acronym for “Functional Safety”) Manager, related to the ISO 26262 functional safety standard
Project ManagerWholly responsible for the project’s successful delivery. That includes top-level planning, risk management, project-level, customer escalations, etc.The Project Manager should be able to control the teams’ resources.
Configuration ManagerResponsible for configuration management on system/software levels, as described in SUP.8 Configuration Management as defined in Automotive SPICE.Separating the configuration management responsibility in “system” and “software” specific configuration tasks should be avoided to prevent establishing system vs. software silos.
FuSa EngineerAssures the proper implementation of the ISO 26262 aspects. FuSa Lead reports to the FuSa Manager line management function.FuSa Engineer works closely with the Process Quality Engineer.
Sample ManagerEnsures the availability of the prototypes (such as A-sample, B-sample, C-sample) for the entire project team.This role is sometimes overlooked but substantial as it is crucial for both development and validation (as the so-called “test beds” for validation purposes).
QA EngineerEnsures the process quality, typically Automotive SPICE – related, but also IATF 16949, ISO 9001, etc.)Works closely with the FuSa Engineer.
Supplier ManagerSupport the Project Manager to ensure that the project suppliers deliver as stipulated in the sub-supplier contract.This role is not needed if there are no outsourced system/software components to be managed separately.
Project Tools EngineerDevelopment of reporting and automation services for the entire project team.Repetitive activities must be automated to avoid waste and increase the process quality.
Technical ManagerWorks for the Project Manager to deliver the left-side of the V-Model (development) content, such as architecture, design, and implementation.The Technical Manager (also often called “Chief Engineer,” “Lead Engineer,” etc.) ensures the technical planning and deals with technical risk management.
The left side of the V-model
System ArchitectDelivers system-level architecture for the Technical Manager 
Mechanical ManagerInterface role to the rest of the mechanical design and testing.Mechanical design and tests are usually performed in a different sub-organization.
Hardware ManagerInterface role to the rest of the hardware (electronics) design and testing.Hardware (electronics) design and tests are usually performed in a different sub-organization.
System Integration LeadIntegrates the entire system from all components, including software, mechanical, and hardware (electronics).The System Integration Lead and the Sample Manager could be unified in one role. However, it is impossible to have one person in large, complex FuSa settings.
Software Project ManagerSoftware Project Manager delivers complete software for the Technical Manager and the Test & Validation ManagerThis role is increasingly strategically crucial in the automotive systems development business.
Software ArchitectDelivers software architecture for the Software LeadSW Architect and System Architect work closely together as a team.
(Further software-related teams)Software leads deliver chunks of the product as defined by the Software Architect and the Project Manager.  Depending on the overall architecture, for example, “Network Lead,” “Security Lead,” etc.
The right-side o of the V-model
Test & Validation ManagerWorks for the Project Manager to ensure product quality, including validation and requirements-based verification on all test levels (system and software).“Product quality” and “process quality” should always be two different roles.
System Qualification Test LeadVerifies the requirements on the system level (black box).Corresponds to SYS.2-level of Automotive SPICE.
System Integration Test LeadVerifies the system architecture (white box).Corresponds to the SYS.3 level of Automotive SPICE.
Software Qualification Test LeadVerifies the entire software (black-box)Corresponds to the SWE.6 level of Automotive SPICE
Software Integration Test LeadVerifies the software architecture (white-box)Corresponds to the SWE.5 level of Automotive SPICE

Other corporate functions, such as HR, manufacturing, customer, suppliers, etc., are omitted in our reference team chart while crucial for the automotive supplier business.

A brief description of each role is shown in the following table:

Further role definitions can be (and often are) useful, such as

  • Change Request Manager (as opposed to “Change Manager,” which should not be used as it is ambiguous), to help the Project Manager to deal with customer change requests
  • Issue Manager (or Problem Manager), to help deal with tickets, issues, and work packages
  • System/Software Requirements Manager, to deal with a high number of requirements that must be sorted, analyzed, tracked, and frequently reported
  • Resident Engineer, who joins the customer team to ensure better communication between the project and the technical customer teams
  • Cyber Security Engineer (analog to the FuSa Engineer)

Roles are not functions, and they should be persons and not groups of people

“Roles” are, fundamentally speaking, work packages, not functions. It is an important distinction. Functional managers can be defined in many ways in the corporate world, whereas the project roles are usually individual persons (and not committees or similar groups) and must be protected from responsibility dilution. Roles come with both responsibility, accountability, and rights to perform the tasks as defined in the team chart.

In customer (MtO) projects, the role association within a project must be stronger than the association between a role and a project-external functions. In other words, the Project Manager must have a stronger influence and control over the project members than the functional line managers have over the same persons in the organizational matrix. While it may sound like a call for a corporate palace revolution, such stipulation is a bitter necessity. Since MtO projects (customer projects) managers usually walk the thin line between regular systems development and late deliveries and customer escalations, it is imperative that the responsibilities are not distributed across the matrix organization. MtO project structure must be hierarchical. Otherwise, a “not-my-problem” syndrome” quickly becomes notorious. Lack of commitment by the team members often follows.  

As described in this article, the project team chart only works well if the team follows the projectized organization scheme (the term “projectized” is explained here). The project team chart works best when the vertical project integration (top-down between system and software teams) and the horizontal integration (left-to-right side of the V-model) are strongly controlled by the Project Manager and the Technical Manager. That prevents the often dreaded “silo thinking” within an MtO team.

Don’t forget the test management

Testing (validation) deserves extra attention. Firstly, the test & validation team does not have to be independent. In Automotive SPICE, testing does not have to be an independent team, while the process quality must be independent. This confusion stems from the ambiguity of the term “quality.” Process quality, as opposed to product quality, are two very different tasks, while they are about “quality” in general. The former is about the Automotive SPICE compliance, while the latter is about the validation and testing. Furthermore, there are typically no additional “leads” for “standard test definition” and “unit test execution” (corresponding to the Automotive SPICE reference processes “SWE.3 Detailed Design and Unit Construction” and “SWE.4 Software Unit Verification”) as software developers themselves conduct those tasks.

The Bottom Line

There is no literal one-fits-all approach to the customer project team charts. The reference chart described in this article shows a project team chart, not the project team chart. Not only the structure but also the wording can be different. For instance, instead of a “Lead” word in a role name, “manager,” “leader,” etc., can be used. For instance, I saw the role of “Product Owner” instead of “Project Manager” or “Project Lead” in some organizations, regardless of the fact that “Product Owner” is differently defined in the generic Scrum scheme).

The important aspect is not the specific wording scheme but the way roles are used in customer projects.

Each of the roles should also be thoroughly defined in the project management plan, including:

  • Unique role name
  • Responsibilities
  • Required skills (with skill levels from low (proficient) to high  (expert)

In Automotive SPICE, no explicit roles are mentioned nor demanded. However, a good team chart description as part of the Project Management Plan helps achieve a higher organizational capability level as defined in the standard. Also, when used in projectized organizations, especially in customer projects (MtO), the reference team chart is an excellent project leadership tool to ensure that the number of customer escalations is kept low and the team members are retained long-term.

There is no need to re-invent the organizational wheel. A good project team chart is good for the organization, the project, and the entire project. Both your customer and your Automotive SPICE assessor will be thankful for the clarity of a well-defined project chart. The herein-defined reference team chart is an excellent measure for achieving higher project maturity and a crucial strategy to lower project risks.

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

United Mentors GmbH | Website | + posts

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.