An assessment can’t give you credit for what it can’t see.
Picture a fairly ordinary moment in an Automotive SPICE assessment. An assessor is looking at a software requirement and asks a question that does not sound particularly dangerous.
“Can you show me where this requirement came from?”
Nobody in the room is particularly worried. The systems engineer knows where it came from. The software lead remembers the discussion that changed it. Someone else remembers the customer document, and the test engineer is pretty sure she knows which test verifies it. The answer exists. Everyone knows it exists.
Then the screens start opening.
First the requirements system. Then Jira. Someone goes looking for the customer PDF while another person searches for the meeting notes where the change was discussed. The test engineer opens a different system and starts searching by an identifier that everyone hopes survived the trip from one repository to another. A few minutes later, the team is still working on an answer that everyone in the room already knew.
From inside the engineering organization, this feels mostly like a search problem. The information is there; it just takes a little effort to assemble it. From the assessment side of the table, however, the same few minutes reveal something more interesting. Automotive SPICE cannot assess what the organization collectively remembers. It can assess the engineering process the organization can demonstrate.
That difference explains a surprising amount about why capable engineering teams can enter an assessment confident in the work they have done and leave wondering why proving it was so difficult.
Automotive SPICE cannot assess what the organization collectively remembers. It can assess the engineering process the organization can demonstrate.
The project people remember is not always the project the system can show
Engineering organizations develop a kind of shared memory. People know which requirement changed late and why the original architecture was abandoned. They remember the supplier issue that forced a workaround, which decision was made in a meeting rather than recorded in the normal system, and which version of the spreadsheet quietly became the real one even though nobody officially announced its coronation.
That memory is enormously useful, and it is one reason fragmented engineering environments can survive for years without appearing nearly as fragmented as they actually are. Experienced people compensate for missing connections almost without noticing. An engineer sees a requirement and knows which design element it affects. A test lead sees a failed test and remembers which software change probably caused it. A project manager knows that the status in one system is technically correct, but that everyone should really look at the spreadsheet Maria sends every Thursday.
Work continues because people supply the context the systems do not. Most of the time, we call that expertise, and much of it genuinely is. The problem appears when someone who does not share that organizational memory asks the engineering environment to tell the story on its own.
That person may be an assessor, but it could just as easily be a customer, a new engineering lead, a quality manager, someone investigating a defect six months later, or the unfortunate person assigned to the program after three key engineers have moved elsewhere. In each case, the question is essentially the same: how much of what the organization knows can the engineering record actually show?
Automotive SPICE is looking for evidence, not confidence
The Automotive SPICE Process Assessment Model makes an important distinction here. It provides indicators that help an assessor determine whether process outcomes and process-attribute achievements are present or absent. These indicators provide the evidence needed to judge process capability. Practices show what activities were carried out, while information items show what those activities produced. They guide the assessment; they are not intended to become a mandatory checklist.
That sounds like assessment language, but there is a useful engineering idea underneath it. Automotive SPICE is not simply asking whether a team did systems engineering, reviewed its requirements or tested its software. The assessor has to determine whether there is sufficient evidence to support a judgment that the expected process outcomes are actually being achieved.
A team may discuss an interface thoroughly and make a sound technical decision. Everyone may understand why it was made. But if the requirements, architecture, analysis or other engineering records do not show what happened, there is a gap between the process the team remembers and the process an outsider can verify.
Traceability creates the same problem. A developer may know which software requirement led to a particular implementation. A tester may know why a test exists, while a systems engineer may be able to explain every important relationship among customer needs, system requirements and software requirements. All of that knowledge is valuable, but a mature engineering environment should not require an assessor — or another engineer — to reconstruct those relationships by interviewing the people who happen to remember them.
The relationships should be part of the engineering record.
This is where good teams get frustrated
The frustration is understandable because the engineering work often did happen. Requirements were reviewed, architecture was discussed, changes were approved and tests were run. The problem is that the evidence is scattered across tools, documents, conversations and people, making proof a separate activity from the work itself.
There is rarely a single bad decision responsible for this. The customer sent requirements in the format it preferred. Systems engineering used the environment that worked for its discipline. Software development adopted the tools that fit its workflow, while test had its own needs and its own repository. Project management needed a convenient way to consolidate status, which is how a spreadsheet entered the picture and, like many temporary engineering solutions, began a remarkably successful long-term career.
Each choice made sense locally. However, the connections among those choices became another system that somebody had to maintain, often without anyone recognizing it as a system at all. The requirement existed in one place, the implementation in another and the test somewhere else. The explanation of how they were related lived partly in links, partly in documents and partly in the memories of experienced engineers.
This is why telling teams to “be more disciplined” misses the interesting part of the problem. The people may already be disciplined. What they lack is an environment in which engineering work automatically leaves behind a connected record. Without that, every handoff creates another small reconstruction problem: where something came from, what changed, who approved it, what it affected and how it was eventually verified.
None of those questions is particularly difficult. In fact, they are almost embarrassingly ordinary, which is why answering them should not require archaeology.
The assessment exposes the cost of reconstruction
Automotive SPICE often gets blamed for the scramble that happens before an assessment. Teams clean repositories, reconcile spreadsheets, repair links and compare requirements against test cases. They discover that two groups have been using slightly different versions of the same information. Meetings begin appearing on calendars with titles such as “ASPICE Evidence Review,” which is usually a polite way of saying that everyone is about to spend an afternoon figuring out what happened six months ago.
It is tempting to dismiss all of this as assessment overhead, and some of it certainly is. Much of it, though, is deferred engineering administration coming due. The assessment did not create the missing relationship between a requirement and its test; it discovered that the relationship had been living in somebody’s head. It did not create disagreement about which specification was current; it exposed the fact that the organization had been resolving that ambiguity socially rather than systematically.
Seen that way, the assessment is less the cause of the scramble than the event that makes its cost visible. The organization has probably been paying that cost all along, only in smaller installments: an engineer spends ten minutes finding the right document, a test lead asks someone which requirement applies, a new team member needs a meeting to understand why a decision was made. Because those interruptions are scattered across months and across dozens of people, they rarely appear as a single problem.
An assessment concentrates them into a room.
That is one reason Automotive SPICE can feel harder for an organization than its day-to-day engineering work. Daily engineering has access to the people who remember how the pieces fit together. An assessment asks the organization to demonstrate the process those people leave behind.
Traceability is really about preserving the engineering story
The word traceability is used so often in engineering that it can start to sound like plumbing: Requirement A links to Requirement B, which links to a design element, which eventually connects to implementation and verification. All of that is necessary, but it understates why those relationships matter.
Traceability preserves the story of an engineering decision. It helps explain why a requirement exists, what it influenced, what changed because of it and how the team determined that the resulting system behaved as intended. When the requirement changes, those same relationships help reveal what may need to be reconsidered.
Those connections matter to Automotive SPICE because they contribute to the evidence available during an assessment. They matter to the engineering organization for an even more practical reason: they reduce the amount of the project that people have to remember.
A connected engineering environment does not replace expertise. It keeps experienced engineers focused on difficult technical judgment instead of reconstructing connections the engineering record should already preserve.
A connected engineering environment does not replace expertise. It keeps experienced engineers focused on difficult technical judgment instead of reconstructing connections the engineering record should already preserve.
Nor does this mean every artifact must live in one tool. Modern engineering organizations rarely work that way, and forcing every discipline into a single application can create a different variety of unhappiness. Requirements may live in one environment, models in another, implementation somewhere else and tests in yet another. What matters is whether the relationships among that work survive the boundaries among the tools.
Without those relationships, the organization has a collection of engineering artifacts. When the relationships are deliberate, maintained and retrievable, those artifacts begin to tell a clear engineering story.
The real test happens long before the assessor arrives
Imagine a senior engineer leaves tomorrow and another engineer must understand an important requirement. Could they determine why it exists, what architecture it affects, where it was implemented, how it was verified and what changed over time — without three meetings and relying on memory?
If they can, the organization is probably creating much of the evidence an assessment will eventually need simply by doing its normal engineering work. If they cannot, the problem is larger than assessment readiness. The project has become dependent on undocumented organizational memory.
That dependency is easy to underestimate because it works until key people leave, unexpected questions arise, defects require tracing past decisions, or assessors request evidence spanning multiple disciplines.
Automotive SPICE gives that weakness a day on the calendar, but it did not put the weakness there.
This is where lifecycle tooling starts to matter
Engineering lifecycle tools earn their place here. The Process Assessment Model defines evidence and process-achievement indicators, but not specific tools.
A lifecycle environment such as IBM Engineering Lifecycle Management is useful because it keeps engineering information connected. Requirements can link to other requirements, architecture, development work and verification. Teams can understand changes in context, connect reviews and approvals to the work they concern, and link test evidence to what it verifies.
For organizations using multiple engineering environments, integration matters because engineering relationships should remain visible across tool boundaries.
When those connections are created during the work, assessment preparation becomes simpler. Teams can retrieve the project story they have already recorded instead of assembling a special version for the assessor.
The difference becomes clear when capable engineers spend half an hour proving something everyone already knew.
Then it becomes difficult to miss.
What the assessor really saw
Return to that requirement from the beginning.
In one project, answering the assessor requires searching emails, spreadsheets and systems before engineers can reconstruct a convincing explanation. The engineering decision may be sound, but the record depends heavily on human memory and effort.
In another, the engineer follows the requirement through its history, related work and verification evidence. Experienced engineers still provide judgment and context, but they are no longer the project’s search engine.
The engineering work may be similar. The difference is what remains afterward: one organization recreates connections when asked; the other preserves them as the work happens.
That is what Automotive SPICE sees — not the late nights or knowledge in people’s heads, but the evidence showing how the engineering work was produced.
Which is why some of the best Automotive SPICE preparation happens long before anyone schedules an assessment.
It happens in the ordinary work of the project, when a decision leaves behind enough of its story that, months later, nobody has to reconstruct it from memory.
