What Automotive SPICE reveals when engineering evidence has to be rebuilt by hand.
The meeting had been scheduled as an engineering readiness review, but it began with a question that had very little to do with engineering.
“Which spreadsheet are we using?”
Several files appeared before the group found the one everyone trusted. One contained the latest supplier updates. Another had the current test results. The accepted version belonged to the person who had spent the morning reconciling requirements, defects, tests, architecture, and email.
Once the file was open, the review could begin.
This is the kind of moment that makes Automotive SPICE uncomfortable, although not because someone used Excel. The real problem is that the organization cannot explain the state of the product until one person manually reconstructs it.
Automotive SPICE is often treated as a demand for more documents. Teams prepare templates, add approvals, and create reports because they expect an assessor to ask whether the required artifacts exist.
But existence is only the beginning.
The more important question is whether the organization can demonstrate that its engineering work is controlled. Can it show what was required, what was designed, what changed, what was tested, who made the decision, and whether the evidence still applies to the current product baseline?
A polished status report cannot answer those questions by itself. Neither can a folder full of documents. The evidence has to connect.
That is where many organizations discover the difference between the process they have defined and the process they actually use.
On paper, requirements may be managed in one system, test cases in another, defects somewhere else, and changes through an approved workflow. In practice, the engineering conversation often depends on exports, local trackers, meeting notes, email, and the memory of people who know how the pieces fit together.
The formal process describes a connected lifecycle. The working process relies on people rebuilding those connections whenever a decision has to be made.
The spreadsheet simply makes the gap visible.
A team may have all the expected artifacts and still struggle to answer basic questions. Which version of the requirement was tested? What changed after the architecture review? Who approved the deviation? Which open defects affect the release decision? What evidence supports the claim that the feature is complete?
When those answers depend on one experienced person interpreting several disconnected sources, the process is not as repeatable as it appears.
This is why assessments often expose information-flow problems rather than missing documents. The organization has the information, but it does not have a dependable way to connect it.
The cost appears first in meetings. Time that should be spent evaluating engineering risk is spent reconciling status. People compare reports, explain exceptions, and decide which representation of the project is current. The meeting may still produce a decision, but the decision depends heavily on the people in the room. Meetings become exercises in asking “Where are we?” instead of deciding “Where should we go?”
That dependence becomes more serious when the program changes. A new engineer may see the requirement, test result, defect, and approval without understanding the conversation that connected them. A later assessment may find the artifacts but not the reasoning. A supplier change may invalidate evidence without making the impact obvious.
The process looked controlled while the same people remained available to explain it. The weakness appears when the explanation has to stand on its own.
This is not an argument to ban spreadsheets. Engineers will always create temporary views, perform local analysis, and organize information for a specific conversation. That is useful work.
The dividing line is whether the spreadsheet is a temporary lens or the place where the engineering process becomes whole.
A shadow process is different. It contains relationships, decisions, and interpretations that do not exist anywhere else. Lose the file or the person maintaining it, and part of the process disappears with them.
Automotive SPICE is trying to distinguish between those two conditions.
The answer is not simply better reporting. The deeper requirement is a lifecycle environment in which requirements, architecture, work, tests, defects, changes, and baselines retain their relationships as the program evolves. That may involve integration, disciplined configuration, shared identifiers, clearer ownership, or better use of the engineering lifecycle platform already in place. In many organizations, the needed capability is already present in tools such as IBM Engineering Lifecycle Management; the harder work is configuring the environment and the process so the connections remain visible and dependable.
The goal is not to eliminate every export. It is to stop asking exports to carry the authority of the engineering system.
An assessor who asks how a status was determined is not asking for a prettier spreadsheet. The assessor is asking whether the result can be reproduced and trusted. Can another competent person follow the same evidence and reach the same conclusion? Can the organization explain what changed and why? Can it connect the release decision to the artifacts that support it?
Those questions are not bureaucratic decorations. They are the same questions the project needs when the decision matters.
The spreadsheet at the beginning of the meeting is therefore useful evidence, just not in the way the team intended. It shows where the designed process ends and the improvised process begins.
If the project cannot begin its readiness review until someone opens the right personal tracker, the most important Automotive SPICE finding may already be on the screen.
