Define the finish line first
Write one sentence that describes what will be true when the project is complete. Avoid activity language such as “work on application.” Prefer a verifiable outcome such as “application submitted and receipt saved.”
This finish line becomes the test for every milestone and task. If an item does not move the project toward that state, it may not belong in the project.
Create milestones around meaningful states
Milestones should represent a change in project state: requirements confirmed, draft approved, materials complete, submission finished, result received. They are more useful than arbitrary percentage checkpoints.
Do not make every task a milestone. A milestone is a coordination point that helps you understand where the project currently stands.
Find dependencies before dates
Some work cannot start until something else is complete. Identify those links before placing everything on the calendar. Otherwise the plan looks busy but is not executable.
Once dependencies are visible, schedule the constrained work first and place flexible tasks around it.
- External deadlines
- Approval or review dependencies
- Inputs from other people
- Documents that must exist before submission
Write the next physical action
Every active project should have at least one next action that can be started without more planning. “Prepare interview” is vague. “Write answers for the three required questions” is executable.
When the next action is completed, calculate or choose the next unblocked action instead of scanning the entire project again.
Use the calendar for commitments, not the whole WBS
A work breakdown structure can contain many tasks, but the calendar should show fixed events, deadlines, and intentionally reserved work sessions. Keeping every tiny task off the calendar preserves its role as a time map.
Review project progress from completed work and milestones rather than manually guessing a percentage.
Keep fixed dates on the calendar, executable actions as tasks, and multi-step outcomes inside projects. Preserve source evidence whenever a date came from a document.
Use a two-level execution view
A useful project can be understood at two levels at the same time. The upper level shows the outcome, milestones, external deadlines, and dependencies. The lower level shows the next physical actions that can be started now. Keeping both levels prevents the project plan from becoming either too vague to execute or too detailed to understand.
During review, ask which milestone currently limits the project and which unblocked action moves that milestone forward. Schedule only the work that truly needs reserved time. Leave the remaining actionable work in the project task list so the calendar continues to represent time rather than the entire work breakdown structure.