How do I set a clear checkpoint for a project milestone?
Quick answer
Describe the result the milestone is meant to produce, then state what evidence will show it is ready and what conditions count as acceptable. Name who reviews it, when the check happens, and what happens if something is incomplete. A checkpoint should test the milestone’s intended result—not simply whether people have been busy or tasks have started.
The question, the details, the next step.
Our project plan says, “Milestone: draft ready,” but the team has different ideas about what ready means. How do I make that checkpoint clear?
Write the checkpoint around the result someone can inspect, rather than a feeling of progress. Specify the item being produced, its intended audience or use, and the minimum conditions it must meet. Then state what evidence the reviewer will look at and who makes the acceptance decision.
For example, assume the project is preparing a staff onboarding guide. Instead of “draft ready,” try: “A complete first draft of the onboarding guide is available for review, covers the agreed sections, identifies unresolved questions, and is shared with [reviewer] by [date].” This says what exists and what makes it reviewable; it does not imply the guide is approved or final.
How do I choose evidence and acceptance criteria without making the checkpoint a long list of every task?
Start with the purpose of the milestone: what should someone be able to see, decide, or do once it is reached? Choose a small number of observable checks that demonstrate that result. Evidence might be a file, a demonstration, a decision record, or a review comment; select what fits the actual deliverable.
Keep acceptance criteria distinct from activity. “Three people attended a meeting” records an event; it does not by itself show that a decision was made. For the guide example, useful criteria could be: the agreed sections are present, each section has an identified owner or a marked open question, and the reviewer can leave comments on the shared draft. Avoid adding requirements that belong to a later milestone, such as final approval, unless approval is truly part of this checkpoint.
What if a criterion is partly met, or the reviewer finds a gap? I want the checkpoint to help us decide what to do next.
Include a simple outcome rule before the review. For instance, the checkpoint can be marked “met,” “not met,” or “met with follow-up,” with each outcome linked to a next step. Define which gaps block acceptance and which can be recorded for later, based on the milestone’s purpose. Name the person who records the outcome and where it will be noted.
If the guide is missing an agreed section, your rule might say that the checkpoint is not met and [owner] adds the section by [date] before review. If a nonessential wording question remains, the reviewer might accept the draft with that question logged for the next revision. These are example rules, not universal standards: agree them with the people responsible for the work and review.
Can you give me a copyable checkpoint that I can adapt for a different kind of project?
Use this template, replacing the brackets with details your team agrees on:
“By [date], [owner] will provide [specific result or deliverable] for [audience or intended use]. We will review [evidence] against these acceptance criteria: [observable criterion 1], [observable criterion 2], and [observable criterion 3]. [Reviewer or decision-maker] will record the outcome as [agreed outcome choices]. If the checkpoint is not met, [person] will [next action] by [date]; if it is met with follow-up, the open items will be recorded in [location] with an owner and due date.”
Before sharing it, check that each criterion can be answered using the stated evidence. If a word such as “complete,” “good,” or “ready” remains, define what it means here or replace it with an observable condition.
A practical checklist
State the milestone’s specific result and intended use.
Name the evidence the reviewer will inspect.
Set a few observable acceptance criteria tied to that result.
Identify the reviewer, review date, and outcome-record location.
Agree what happens when a criterion is unmet or an item remains open.
A few more useful answers
Should every checkpoint have a numerical target?
No. Use a number only when quantity genuinely defines the result. A reviewable document, recorded decision, or demonstrated capability may be better described with clear evidence and observable criteria.
What if the milestone depends on another person’s approval?
Separate what your team can deliver from the approval decision. State what will be submitted, who is expected to review it, and how pending approval will be recorded so submission is not mistaken for approval.
How often should we revisit a checkpoint’s criteria?
Revisit them when the deliverable, intended use, or project assumptions change enough that the original evidence or acceptance conditions no longer fit. Record the agreed revision so everyone is working to the same checkpoint.