Status is what the tool says. State is what is true.

That distinction sounds pedantic until you watch a team spend half a meeting discovering that every green item is green for a different reason. One project is green because the team is genuinely on track. One is green because nobody updated it. One is green because the risk is politically inconvenient. One is green because the owner thinks "no known problem" means "healthy." One is green because the problem has not reached the executive dashboard yet.

The status did its job cosmetically. It failed operationally.

Status fields compress reality. That is useful when the compression preserves the right meaning. It is dangerous when the compression hides the next action. "In progress" can mean actively being worked, waiting between work sessions, blocked but not admitted, under review, half-owned, or forgotten. A system that uses one label for all of those states is not simple. It is blurry.

A good state model answers a better question: what condition is the work actually in, and what kind of action would move it forward?

Waiting for triage is different from ready to start. Active work is different from waiting on another team. Waiting on a customer is different from waiting on an internal decision. Under review is different from pending approval. Done pending verification is different from accepted and closed.

Those distinctions matter because each state has a different owner behavior.

If work is waiting for triage, the system needs intake capacity and routing rules. If it is ready to start, the bottleneck may be team capacity or priority. If it is waiting on a dependency, the owner needs a dependency owner and date. If it is blocked by a decision, the workflow needs a decision forum. If it is under review, the reviewer needs a service level. If it is done pending verification, the acceptor needs to test the output.

When all of those states collapse into "in progress," managers lose the ability to intervene cleanly. They either micromanage everything or wait until delay becomes visible enough to hurt.

This is where status theater begins. Teams learn which labels make the organization comfortable. Green means safe. Yellow means defensible. Red means blame is coming. The status label becomes a social signal instead of an operating signal.

The fix is not to add twenty statuses. That usually creates a different mess. The fix is to define the minimum states that change action.

A practical state model might start with:

  • New: entered the system, not yet accepted.
  • Triaged: accepted and routed.
  • Ready: can be worked when capacity exists.
  • Active: someone is working the next step.
  • Waiting: progress depends on an outside response.
  • Blocked: progress requires intervention or decision.
  • Review: output exists and needs acceptance.
  • Done: accepted and closed.
  • Reopened: closed state was wrong or conditions changed.

The exact labels matter less than the rule behind them: no state should exist unless it changes what someone does next.

If a field cannot answer "who should act now?" or "what kind of intervention is needed?" it is probably status decoration.

The practical test is simple. Pick ten items marked in progress. Ask the owner what is actually happening, what the next action is, and what would cause the item to move state. If the answers do not match the labels, the workflow has state drift.

Do not blame the team first. Blame the model. People often choose vague statuses because the system gives them no honest place to put reality.

This is part 3 of 10 in Workflow Ontology.