Does Your Project System Deliver Status or Evidence?

A status tells you what happened.

Evidence helps you decide what should happen next.

The difference is easy to lose because both arrive through the same machinery. Dashboards, standups, reviews, reports, and steering meetings can carry either one.

The format does not decide which one you are receiving.

Its effect on a decision does.

Status is not useless

A project needs orientation. People need to know what moved, what is blocked, what changed, and where attention is required.

The problem begins when the system treats the description of activity as proof of progress.

Ten completed tasks may matter. A green dashboard may matter. A burn chart may matter. None of them, by themselves, shows that the project has reduced an important uncertainty, produced a usable outcome, or made the next choice clearer.

Activity can be accurate and still be insufficient.

Evidence has a decision attached

Useful project evidence answers at least one consequential question:

• Did the work produce the outcome we expected?
• What became possible that was not possible before?
• Which assumption survived contact with reality?
• Which constraint is now governing the project?
• What should we continue, change, stop, or escalate?

If no answer can change a commitment, a priority, a design, a budget, or a boundary, the information may be status. It is not yet decision evidence.

This is why a working increment matters in Scrum. The Scrum Guide describes inspection as a basis for adaptation. The Daily Scrum exists to adjust the plan toward the Sprint Goal. The Sprint Review exists to inspect the outcome and determine future adaptations.

The events do not create evidence automatically. They create opportunities to confront it.

A dashboard can hide the project

Most reporting systems favor what is easy to count.

Tasks completed. Hours spent. Milestones reached. Defects closed. Money consumed.

These measures may reveal capacity, flow, cost, or delivery health. They become dangerous only when the organization lets them stand in for value or learning.

A project can be efficient at producing something nobody needs. It can meet a milestone while preserving the assumption that threatens the whole investment. It can close defects while the product remains unusable in the situation that matters.

The dashboard stays green because the project asked it to report movement, not truth.

Build the report backward from the decision

Before asking for another metric, name the decision the metric is meant to improve.

Then ask:

1. What claim are we testing?
2. What observation would support or weaken it?
3. What threshold would change our course?
4. Who has the authority to make that change?
5. When will the evidence arrive?

This makes reporting smaller and more demanding.

It also exposes a common failure. Sometimes the organization has enough information but nobody owns the decision. The missing element is not a better dashboard. It is an explicit decision right.

Keep the operating distinction

Status supports coordination.

Evidence supports judgment.

A healthy project system needs both. It should not confuse them, and it should not reward one for impersonating the other.

The final test is simple:

What could we decide differently because we know this?

If the answer is nothing, keep the information if it helps coordination. Just stop calling it evidence of progress.