Lesson 5 of 16 · Automotive SPICE, the vital 20 %
Level 2, part 1: managing performance (PA 2.1)
Level 1 asks "did the outcomes happen?" Level 2 asks "did you make them happen on purpose, against a target, and would you have noticed if they didn't?"
A requirement is linked to its test, but the test checks an outdated threshold. Traceability or consistency?
Which of these is in the base of the recommended VDA Scope?
Generic practices apply to every process
Base practices are specific to one process. From level 2 up, the indicators are generic practices (GPs), and the same GPs are applied to each process in scope[PAM §3.3.1, p. 23]. So "SUP.10 at level 2" means the GPs of PA 2.1 and PA 2.2 applied to change request management.
The PA 2.1 loop
| GP | Name | The question it asks |
|---|---|---|
| 2.1.1 | Identify objectives, define a strategy | What target does this process have, and how will you approach it? |
| 2.1.2 | Plan the performance | Which activities and work packages, estimated, scheduled? |
| 2.1.3 | Determine resource needs | How many people, which skills, what tools, and who is responsible for what? |
| 2.1.4 | Identify and make resources available | Are those people and tools actually assigned, and qualified? |
| 2.1.5 | Monitor and adjust | Do you notice deviations from the plan and act on them? |
| 2.1.6 | Manage the interfaces | Who is involved, who is responsible, how do they communicate? |
Source: PAM §5.3.1, pp. 101–103. The Guidelines draw them as a chain: objectives and strategy, then a plan, then resources according to the plan, then monitoring against the plan[Guidelines §4.1.3.1, p. 244].
The keystone: process performance objectives
Everything in PA 2.1 hangs off GP 2.1.1, and it is the GP most often misunderstood. A process performance objective is not a project goal and not a restated outcome[PAM GP 2.1.1 note 1, p. 101]. It says how the process's outcomes are to be organised. The PAM's own examples:
- SUP.10: "all incoming CRs are analyzed within z days"
- SUP.8: a maximum share of configuration items "in work" at given milestones before the next delivery
- SWE.6: "Test coverage of Functional Safety Requirements at baseline y is 100%"
They may be quantitative or qualitative, ideally SMART, and they do not require the formal measurement of MAN.6 or level 4[Guidelines §4.1.2.1, p. 235]. The strategy doesn't have to be a document either: tools that enforce a workflow, automated pipelines and continuous integration all count[Guidelines §4.1.2.2, p. 236]. Explicit process descriptions are not required at level 2, "providing the PA achievements are met"[Guidelines §4.1.1, p. 234].
MAN.3 vs PA 2.1. MAN.3 manages the whole project. PA 2.1 manages one process. They are linked: the ratings of MAN.3.BP4–BP8 "should be in line with" GP 2.1.2–2.1.6 of the other processes, and a gap of more than one NPLF step between them "might be indicative of an inconsistent rating"[Guidelines §4.1.3.2, p. 245].
Seat-Heat's SUP.9, two ways
Both versions may reach PA 1.1 = F for SUP.9: problems are recorded, analysed and closed. Only version B has anything for PA 2.1 to rate.
Practice
A. Is it a process performance objective?
"Release 3.0 ships on 1 March."
"No more than 10 open change requests six weeks before each release."
"Change requests are approved before implementation."
"Every safety-relevant software requirement has a passing hardware-in-the-loop (HIL) test at the release-candidate baseline."
B. Which generic practice does version B's evidence show?
"Every new bug triaged within 2 working days."
The named triage rota and the reserved 20 % sprint capacity.
The dashboard of overdue bugs, and re-planning when the target is breached.
OEM bugs arrive via their portal, and the triage owner answers there within one day.
C. From memory
What is a process performance objective, and what two things is it not?
A target for how one process is performed, such as "all CRs analysed within 5 days". It is not a project goal (a release date, a budget), and it is not a restatement of the process's level 1 outcomes.
List the PA 2.1 loop in order, in your own words.
Objectives and strategy → plan → resource needs → resources assigned → monitor and adjust against the plan. Managing the interfaces between the parties runs alongside all of it.
Your win: you can tell a performed process from a managed one, and point to the missing link in the loop when it isn't managed. Next: the other half of level 2, managing the work products themselves.
To keep it: import this lesson's Anki deck (how).
Read next
VDA Guidelines chapter 4 introduction and §4.1, pp. 233–245. It is the clearest account of level 2 anywhere, with many examples of objectives and strategies.
Try writing one process performance objective for a process in your own work, and ask your teacher to critique it.