In the automotive industry, we often mention the term "baseline management." In the latest ASPICE standard, the word "Baseline" appears as many as 32 times. Some project managers talk about baseline management in every conversation. So what exactly is baseline management? Why is it important? Can we choose not to do it? And if we must, how should we do it?

What Exactly Is a Baseline?

There are many definitions of baseline online. Let me share my understanding: a baseline is the starting point of a project task.

In most companies, projects are executed in phases by multiple people—especially in the automotive industry. From the perspective of the full vehicle R&D lifecycle, there might be market research, concept design, prototype design, product definition, functional design, architecture design, detailed design, implementation, testing and validation, production, manufacturing, after-sales service, and maintenance. Various tasks arise in each of these phases, often involving multiple companies collaborating.

A baseline is the starting point of each "process." At that starting point, it contains all the requirements, specifications, and standards needed for the entire project. It's important to note that the "process" here doesn't refer to a specific phase of the vehicle R&D lifecycle—it's entirely up to the project team to define. In software development, we typically create a baseline for a planned release version.

Why Do Baseline Management?

At the starting point of a project phase, many teams hold a kick-off meeting to tell everyone what the goals are and where the finish line is. But during execution, goals may adjust, execution methods may differ from initial plans, and even requirements themselves may change.

No matter how hard we try to think through requirements and break down tasks before a project starts, change is inevitable.

Even if the project content itself doesn't change, team members come and go. One person might participate in multiple projects, move to other teams midway, or new members might join. At this point, the baseline has changed, and knowing only the original starting point is no longer enough. What we care about more is, "What are our requirements right now?"

So the essence of baseline management isn't just recording the starting point—that's too simple, just a backup. The essence of baseline management is recording all requirements at every moment of the project, and all changes relative to the original starting point.

If mid-project changes aren't communicated to everyone, consequences follow: requirements change but developers don't know; architecture changes but testers don't know; test cases change but product managers don't know; project scope changes but the project manager doesn't know—leading to delayed delivery. The end result might be: you set out to build an SUV but end up with a tricycle, or a 3-month delivery turns into 3 years.

Since change is inevitable, what we can do is embrace it actively. Even if we make some deviations and changes along the way toward our goals, if we can record what basis changes were made, what changes happened, and where they ended up, then even if a change goes wrong, we can easily course-correct or analyze afterward where a change led to the final outcome.

Some might argue that internet development doesn't seem to have the concept of baseline and still works well. Because they need to respond to market changes in real time—whatever the market wants, internet teams build. Compared to knowing where the starting point is, they care more about where the market wants them to go. This isn't that they don't care—it's that internet iteration speed is fast enough. Days per version, and in a very short time, team changes are negligible, and any goal drift is quickly forgotten. Plus Agile development emphasizes rapid communication and information sync. Once the next version ships, the previous version's starting point becomes less relevant.

But this doesn't mean internet development has no baseline management—it's just that baseline management can be stored in everyone's head for a short time, achieved through quick word-of-mouth communication, and paper records are skipped.

Our conclusion: in a multi-person, medium-to-long-term project with long phase durations, we need baseline management to record requirements at any given moment and all changes relative to the original starting point.

Six Principles of Baseline Management

Principle 1: Store "every moment" of the project baseline in one place—the current latest requirements.

Baseline management isn't about simply storing the original requirements. The core problem it solves is: how to let everyone on the team always know what the latest requirements are.

Principle 2: Be able to easily look back at the original baseline when needed.

If any team member has doubts about the latest requirements, or feels they're unreasonable, they should be able to look up at any time: what did this requirement look like originally? What changes happened midway and when? Who initiated this change? Who approved it?

Principle 3: After storing a baseline, allow adding, deleting, or changing requirements—even by multiple users, at any time, from anywhere.

Since change is inevitable, or rather, baseline management exists not to record "no change" but to "handle change," we should boldly embrace it. Anyone should be able to raise change requests against a baseline at any time. Change requests should be parallel—multiple people can raise changes at any time without worrying about whether others are also making changes.

Principle 4: In principle, changes must go through review. Unreviewed changes don't need to be known by the rest of the team. Once a change is approved, everyone on the team gets "notified."

Any change request initiated by anyone generally needs to be reviewed by several key roles on the team. Only after all of them approve does the change become officially valid and can formally modify the original requirements.

Principle 5: If the team unanimously agrees that changes don't need review and can go through directly, this must also be supported—it's the team's own decision.

Some teams change very fast. If every change needs review, the waiting time is very long. Some internet teams fully empower people—they trust everyone's technical ability and want to respond quickly to any requirement changes.

Principle 6: Regardless of whether changes go through review or not, everything must be traceable afterward—from the baseline starting point, what additions, deletions, and changes occurred.

This process should be natural—engineers shouldn't need to rummage through various places to find original archives or track every intermediate change. Engineers should be able to find the latest requirement and easily see its complete change history right there.