Two kinds of milestone
Free
A milestone is a point in time, not an activity with a duration. Tidigar has two kinds: a milestone that follows work, and a fixed milestone that anchors work to a date.
A milestone that follows activities
Prototype ready waits for Build prototype. Watch the build finish a week later: the milestone moves with it. This is useful for a handover or review whose date depends on the preceding work.
A fixed milestone
Conference opens has a fixed date. It does not follow the build. Activities can wait for this kind of milestone: Prepare conference demo cannot start before the conference opens. The second part of the animation moves the conference date and shows that waiting activity follow.
These are different directions of dependency. An ordinary milestone waits for activities; an activity can wait for a fixed milestone. A fixed milestone does not acquire predecessors. It is also not a deadline constraint that automatically schedules other activities backwards to finish before it.
Choose the right kind
- Add a milestone and give it a name and date.
- For a following milestone, leave Fixed: an event on a set date off and choose the activities it waits for.
- For an anchor, turn Fixed: an event on a set date on and choose the activities that wait for it.
- Show milestone labels in your custom timeline view so readers can distinguish the named points.
A following milestone may retain a gap after its predecessors; it is not necessarily forced onto the very next day. The fixed milestone holds its date until you edit it yourself.
Try moving Build prototype in the embed, then replay the story. For another use of dependencies, see Moving activities and dependencies.
How milestone dates work in detail
Following work leaves room for a handover
A following milestone must be at least the day after the latest end among its selected activities. Choosing a date before that limit moves it back to the allowed bound. Choosing a later date keeps room for a review or handover. With no predecessors, it has no activity-based lower bound and keeps the date you choose.
When a predecessor's end moves, a following milestone moves along with it while retaining its gap, unless you explicitly change the milestone date in the same edit. With several moved predecessors, the furthest resulting date is used and the latest predecessor still sets the earliest allowed date. This does not change the activities themselves.
The ordinary lower bound is the next calendar day, including a weekend or vacation. In work-day planning, propagation counts work days, but a milestone is still a dated point rather than a duration. Compact the plan in roadmap Properties removes gaps after predecessors and places following milestones on the next work day. In calendar-day planning it uses the next calendar day.
A fixed date is an anchor, not a deadline
A fixed milestone may have activities waiting for it, but cannot itself wait for activities. A waiting activity may start on the milestone's date, rather than the day after. In work-day planning, it moves to the next work day if that date is a weekend or vacation. Editing the fixed date carries the waiting chain with it, subject to any other dependencies.
“Fixed” does not lock the record against editing. It holds the date against changes in other activities; you can still edit the milestone itself. It can represent a conference opening or an externally agreed start. It does not require other work to finish before it, schedule backwards, or move automatically when the project runs late. Check a deadline against the actual finish dates yourself.
Keep the direction clear when changing kind
In the milestone's properties, Depends on selects activities for a following milestone. Waited for by selects activities for a fixed milestone. Review those relationships when changing kind: a fixed milestone cannot retain incoming dependencies, and an activity cannot wait for a following milestone. Do not change kind merely to alter the symbol on the timeline.
The milestone's date, kind and relationships belong to the plan. Labels and visibility belong to the view. Hiding a milestone or filtering out work does not release its dependencies. For activities that start partway through other work, use an activity overlap relationship as described in Moving dependency chains.