Milestone vs Deadline

A calendar date can arrive while the work is still not in the state required to move forward.

Deadlines measure time. Milestones measure change.

“Complete five screens” is an activity.

“Prototype ready for onboarding tests with real users” is a milestone because the project entered a new state.

Outcome — what change is the project pursuing?

Milestone — what intermediate state must be reached?

Evidence — what proves that state exists?

Dependency — what must be ready before or after it?

Deadline — what timing protects the sequence?

A label like “Design done” can mean different things to different people.

Definition of Done makes the milestone inspectable.

“90% complete” is difficult to evaluate.

A prototype, approved copy, deployed build, signed decision, or validated dataset is more concrete.

A milestone can be completed on time and still be useless if the next dependency is not ready.

Deadlines should protect coordination, resource windows, launches, or dependency chains rather than simply add pressure.

If teams only watch the final deadline, problems are often discovered too late.

Milestones create earlier checkpoints.

Forwork can include a Milestone Block: Outcome, Target State, Definition of Done, Evidence, Dependencies, Owner, Target Date, Status.

Work Tracking then shows the state the project has actually reached, not only dates.

Do not only ask, “What is the deadline?”

Ask: “By that date, what must become true, and what evidence will prove it?”

Outcome → Milestone → Evidence → Dependency → Deadline.