How to Set Project Milestones: A Template and Acceptance Criteria

A project milestone makes an important decision or handover visible. A date alone is insufficient: specify who decides, which version is assessed, and what evidence supports passing the point. This guide uses a fictional web project to show copyable records, acceptance conditions, and a change log that preserves the original plan.

Separate Milestones from Preceding Work

Schedules commonly represent milestones as zero-duration points. Preparing documents, testing, reviewing, and obtaining the decision still take time. A requirements-approval milestone without those preceding activities can hide work that the schedule needs. Display conventions may also vary between tools.

The Microsoft milestone-field documentation provides a reference for how Project handles milestones. A product-specific field definition is not the only possible organizational convention. The practical distinction is between work leading to a decision and the point where that decision is recorded.

Completing a task and passing a milestone are different. Sending a document can complete submission while approval remains pending. Agree whether receipt, a pass, approval, or conditional approval is needed. Identify an authorized substitute for an unavailable decision-maker and how unresolved items will be handled.

Use Five Criteria to Place Milestones

Choose milestone candidates by the significance of the decision, rather than only by elapsed time. The following five criteria are a planning aid, not a universal required count or interval.

A small project may need only a few milestones, while a larger project may need many. Five to ten milestones or a two-week interval are not universal requirements. A recurring meeting can remain a routine review if no important decision or transfer occurs.

If the full list becomes hard to read, show major decisions in the overview and maintain departmental detail separately. Decide what to display according to the information downstream owners need. Names such as “Requirements v1 approved” communicate more than a generic “Review.”

Copy a Template for Dates, Acceptance, and Evidence

Keep original dates and current forecasts in separate fields. The preparation owner makes the decision ready; the decision-maker has authority to determine the outcome. One person may fill both roles, but the roles still need to be clear. Evidence should identify the assessed version and the decision record.

Detailed conditions can live in a linked checklist with its own version. They need not fit inside one cell or one line. Keep the milestone summary connected to the evidence used for the decision. Distinguish draft criteria from criteria accepted by the relevant parties.

Worked Example: Requirements and Acceptance Approval

This fictional web project places requirements approval on working day 2 and a release decision on working day 12. The criteria are an agreed example, not minimum requirements for every release. Real projects must establish their applicable contractual, quality, and safety conditions.

Executing all 120 planned tests gives an execution rate of 120 ÷ 120 = 100%. Passing 118 gives a pass rate of 118 ÷ 120 = approximately 98.3%. Those are different measures. Zero critical defects does not automatically authorize release when the two remaining results and other release conditions have not been resolved.

In this example, record the residual risk, repair dates, and owners for the two minor exceptions, then confirm evidence that an authorized decision-maker accepted them. M02 remains pending until that decision. If an exception is refused or a mandatory condition fails, repair and reassess or revise the release plan. Some conditions may not permit exceptions; define that boundary beforehand.

Preserve Planned Dates, Forecasts, and Change History

When dates change, preserve the original plan, current forecast, reason, and decision. Overwriting dates hides both slippage and the effect of corrective action. Even a formally revised baseline should remain traceable to the previous agreement. A provisional forecast must not look like an approved commitment.

This is a separate delay scenario from the approved result in the preceding example. It illustrates recording a late answer during planning, rather than rewriting an already completed approval. In real records, retain timestamps and versions, and distinguish the current status from a hypothetical scenario.

Assess Slack, Dependencies, and Decisions When Dates Slip

Whether a delayed milestone moves the final date depends on successor dependencies and slack. The Microsoft critical-path guidance is a reference for identifying the chain governing completion. An external handover delay does not necessarily shift every later date by the same amount.

Consider a safe partial handover, scope stages, qualified alternative reviewers, adjusted capacity, or an agreed date change. Do not bypass quality conditions or authority merely to mark a milestone complete. Update remaining slack when it is consumed, rather than continuing to assume the original allowance is available.

Finish by recording who must decide what and the next review point. Repeated changes for the same reason may require better inputs, response agreements, decision authority, or duration assumptions. The count of date changes alone does not establish failure. Check whether the decision evidence and downstream commitments are now explicit.

Before the decision, confirm that the approver can access the evidence, versions match, and remaining exceptions are listed. Approval for an earlier version is not automatically approval for later changes. Transfer residual conditions and follow-up dates when an owner changes. If new requirements arrive after approval, assess the changed scope and define any necessary reapproval under the agreed authority, rather than silently treating the old decision as covering the new work.

Related practical guides

• How to Build a WBS: A Deliverable-Based Example and Effort Totals Without Double Counting
• Build a Gantt Chart in Excel or Google Sheets: Worked Table and Formulas
• Project Scheduling: Six Steps for Dependencies, Capacity, and Dates

If you need to connect task progress with marketing plans and approved budgets, explore Xtrategy’s project features. Xtrategy keeps task progress within each marketing project, shows monthly plans alongside approved budgets, and links to related budget, CRM, and approval information.