Status definitions work by turning vague labels into explicit operational states.
Without definitions, two people can look at the same work and assign different status labels while both believing they are being accurate.
The problem is not colour.
The problem is semantics.
Done, in progress, blocked, waiting, at risk and on track need shared meaning if they are going to support coordination.
This article is the first pillar of How Status Updates Fail.
The Core Idea: A Status Label Is a Contract
A status label should tell the reader what is currently true and what may happen next.
The label is useful only when it maps to observable criteria.
‘Done’ should mean more than ‘someone worked on it’.
‘Blocked’ should mean more than ‘this feels difficult’.
‘At risk’ should mean more than ‘I am worried’.
Define the Object First
Status applies to something specific.
A task, milestone, article, learner skill, project, approval, source, risk or dependency can each have a different state.
Do not attach one ambiguous label to a whole programme when the reader actually needs several component states.
Define the Dimension
The same object can have several status dimensions.
- Schedule.
- Scope.
- Quality.
- Cost.
- Risk.
- Technical performance.
- Approval.
- Learning independence.
- Publication readiness.
NASA technical-assessment guidance separates technical, cost, schedule and risk information for exactly this reason: health is multi-dimensional.
A project can be green on one dimension and amber on another.
Define Done
Done should mean the required work has reached its intended acceptance state.
That often requires more than production.
A draft is not done if review is required.
A student exercise is not done if the target is independent transfer.
A technical component is not done if verification is still open.
Define the acceptance condition.
Done Versus Complete
Complete can mean the producer has finished their part.
Done can mean the system has accepted the output.
Separating these states prevents premature closure.
For example: writing complete, factual review pending; implementation complete, test pending; practice set complete, transfer test pending.
Define In Progress
In progress should mean active work is currently advancing the item toward its next state.
It should not become the default label for anything unfinished.
If no progress can occur because an external condition is missing, the item may be blocked or waiting instead.
Define Blocked
Blocked means meaningful progress cannot continue on the critical path because a required condition is unavailable.
The blocker should be named.
- Waiting for approval.
- Missing source.
- No access.
- Unresolved dependency.
- Required person unavailable.
- Prerequisite skill not ready.
- System failure.
Blocked is a causal state, not an emotional one.
Define Waiting
Waiting is useful when the next action depends on an external event that is expected to occur.
Unlike blocked, waiting may be normal.
For example: application received and waiting for scheduled review.
A waiting state should identify what event will move the item again.
Define At Risk
At risk means the current trend, dependency or uncertainty threatens a required outcome, even though failure has not occurred.
The definition should include a trigger.
Examples: critical supplier date unconfirmed; error rate rising across three consecutive checks; available buffer below a stated level.
At risk is an early-warning state.
Define On Track
On track should mean current evidence supports meeting the relevant requirement or milestone under current assumptions.
It should not mean ‘nothing bad has happened yet’.
The relevant target must be named or obvious.
Define Off Track
Off track means current evidence shows the existing plan will not meet the required outcome without change.
The next question is then not whether the label is red enough.
It is what corrective action, replan, escalation or scope decision is required.
Define Unknown
Unknown is a legitimate state.
A system that forbids unknown will encourage invented confidence.
Use unknown when the evidence is insufficient or stale.
Then attach the action required to establish state.
Define Not Applicable
Not applicable prevents empty fields or false zeros from being misread as poor performance.
It should be used only when the dimension genuinely does not apply.
Define Deferred
Deferred is different from blocked.
The work could proceed but has been intentionally postponed by decision.
Record who made the decision and what trigger or date will reactivate the item.
Define Cancelled or Stopped
A stopped item should not remain indefinitely ‘on hold’.
Cancellation is a state.
It preserves the fact that the work will not continue under the current plan.
Use Mutual Exclusivity Where Possible
Status categories should not overlap so much that every item could fit several labels.
If an item can be both blocked and at risk, decide whether one is the primary workflow state and the other is a risk dimension.
Separating dimensions often solves apparent overlap.
Use Observable Criteria
The strongest definitions can be checked.
For example: blocked = no executable next action exists because one named dependency is unavailable.
Done = acceptance criteria met and required review closed.
At risk = forecast misses target unless one identified assumption improves.
Observable definitions reduce argument.
Avoid Percent Complete as the Only State
A percentage can coexist with status.
It should not replace the state.
A task can be 95% complete and blocked on one irreversible approval.
A learning programme can be 80% through the syllabus and off track for exam readiness.
Use Entry and Exit Criteria
A state becomes clearer when both entry and exit conditions are defined.
Blocked entry
A required dependency is unavailable and no critical-path work can proceed.
Blocked exit
The dependency becomes available or an authorised substitute route is approved.
This reduces status drift.
Use State Transitions
Status becomes more useful when the allowed transitions are understood.
Draft → in progress → review → done.
In progress → blocked → in progress.
Waiting → approved → implementation.
At risk → replan → on track.
The exact workflow varies, but explicit transitions make hidden jumps visible.
Do Not Skip States Silently
If an item jumps from in progress to done, that may be fine.
If review or approval is normally required, the system should explain why it was bypassed or whether it was actually completed.
Status history protects process integrity.
Status Definitions in Learning
Learning status needs careful semantics.
‘Taught’ is not ‘learned’.
‘Can do with prompt’ is not ‘independent’.
‘Independent in familiar practice’ is not ‘transferred to unfamiliar questions’.
eduKate’s learning architecture benefits from state definitions because progression depends on capability, not lesson count.
Status Definitions in Mathematics
A Mathematics skill can move through states such as introduced, guided, stable in direct questions, stable in mixed questions and transferable under timed conditions.
Those states are more informative than ‘covered’.
Status Definitions in English
A writing skill can be present in untimed drafting and absent under examination load.
Status labels should preserve the performance condition when it changes the interpretation.
Status Definitions in Publishing
Useful states may include draft, editorial review, factual review, collision hold, approved, scheduled, published and verified.
‘Published’ should not be confused with ‘fully verified’ if post-publication checks are still open.
The Definition Table
- Status name.
- Plain-language meaning.
- Entry criterion.
- Exit criterion.
- Evidence required.
- Allowed next states.
- Owner.
- Escalation trigger if the state persists.
The table can be lightweight.
Its purpose is shared meaning.
The Label Test
- Can two competent people classify the same case similarly?
- Does the label refer to one object and one dimension?
- Is the state observable?
- Does the label imply the next workflow step?
- Can the item remain in the state indefinitely? If not, what escalates it?
- Is unknown allowed when evidence is weak?
- Is done tied to acceptance rather than effort?
The Deeper Principle: Shared Language Creates Shared State
Status definitions are small pieces of infrastructure.
They reduce translation cost between people, meetings, reports and systems.
When the labels are stable, the organisation spends less time arguing about what ‘green’ means and more time deciding what to do.
Across the eduKate Ecosystem
eduKateSG’s How Dashboards Fail uses status labels as visual signals. How Approvals Fail distinguishes review, approval and authorised state. How Dependencies Fail gives precise meaning to blocked and waiting. How Reviews Fail helps define accepted versus merely produced work.
Sources and Further Reading
NASA Systems Engineering Handbook — Technical Assessment
NASA NPR 7120.8A — Periodic Project Reviews
Continue the Series
How Status Updates Fail | Why ‘On Track’ Can Be Stale, Vague or Unverifiable
How Status Freshness Works | Every Update Needs an As-Of Time, Source and Owner