Project Milestones
Plan and review major project checkpoints from the project detail page.
Project milestones mark important checkpoints in a project. Use them for phases, delivery dates, approvals, launches, or major review points.
Use milestones to show project progress at a higher level than individual tasks.
Milestones should make the project easier to review. If a checkpoint does not change planning, delivery, approval, or communication, it may be better as a task.
Open Milestones
Open Productivity > Projects, select a project, then open the Milestones tab. The tab shows the milestones connected to that project.
Add a Milestone
Create a milestone when the project needs a visible checkpoint. Add a clear name, description when helpful, due date, status, color, and position.
Good milestone names describe the outcome, such as Design approved, Content ready, QA complete, or Launch handoff.
Choose due dates that represent real commitments. If a milestone is only a loose idea, keep it out of the plan until the team can act on it.
Before adding a milestone, confirm who owns the checkpoint and which tasks or deliverables prove it is complete.
If a milestone depends on customer approval, name the approval explicitly. A
generic milestone such as Phase 1 done is less useful than Client approves Phase 1 designs.
Milestone Planning Checklist
Before saving a milestone, define:
- the outcome
- owner or reviewer
- due date
- tasks that must finish first
- files or deliverables required
- customer or internal approval needed
This keeps milestones tied to real progress instead of becoming decorative labels.
Update Milestones
Update milestone status and due dates as the project changes. Reorder milestones when the sequence changes so the project reads in the order your team expects to deliver it.
Delete a milestone only when the checkpoint no longer matters. If the checkpoint was missed or moved, update the status or due date instead so the project history stays understandable.
When a milestone slips, update the due date and add context in project notes or comments so the reason is visible later.
Milestones vs Tasks
Use a milestone for a checkpoint. Use tasks for the actual work that moves the project toward that checkpoint.
During project review, check whether each active milestone has tasks that can actually complete it.
If a milestone has no tasks, files, or owner, it is only a label. Add the work needed to reach it or remove it from the project plan.
Review Routine
Review milestones during weekly project check-ins. Update due dates, status, and notes before reporting project health to customers or leadership.
After a milestone is completed, check whether follow-up tasks, invoices, files, or customer updates should be created before the next milestone begins.
Use milestone status in reporting only after tasks and deliverables are current. A completed milestone with unfinished tasks creates misleading project health.
Troubleshooting
If milestones slip repeatedly, check whether tasks are missing, dependencies are blocked, or the milestone is too broad.
If completed milestones do not match project reality, reopen the milestone or add follow-up tasks before reporting the project as healthy.
Milestone Reporting Checklist
Before sharing project status:
- confirm each active milestone has an owner
- confirm due dates match current commitments
- check dependent tasks and files
- record customer or internal approval state
- update slipped milestones with context