Projects, phases, tasks and milestones

A project is the level that carries a status. Everything below it exists to make that status defensible — so a reader can ask “why amber?” and find an answer without a meeting.

The pieces

Phase

A stage the project moves through. Created automatically from the space's phase template, so every project in a space starts the same shape.

Task

The work itself, with an owner, a start and due date, and a status. Tasks live inside a phase.

Subtask

A checklist inside a task, for when one task needs breaking down but does not deserve to be several.

Milestone

A dated commitment that is not itself work — a go-live, a board review, a contract date. Milestones sit alongside phases rather than inside them.

Dates roll upward

Once a phase contains tasks, its dates come from the earliest task start and the latest task due date, shown as “(auto)”. You only set phase dates by hand while a phase is empty.

This is deliberate. A phase that claims to end before the work inside it finishes is the most common way a plan lies, and deriving the dates makes that impossible.

Target dates and slippage

A project has a target date and remembers the original one. When the target moves, the project header shows the slippage against where it started — so moving a date is allowed, but never silent.

Two views

• •Plan — the list view. Expand a phase to see its tasks, expand a task for notes, dates, dependencies and its progress log.
• •Gantt — the same data on a timeline. Better for spotting phases that overlap when they should not.

How much detail is worth it

Enough that the status is explainable, and no more. If you are copying tickets across from your delivery tool, you have gone too far — that work has a home already, and a second copy of it will be out of date within a week.

A useful rule: if a steering group would not discuss it by name, it probably does not need to be a task here.