Copy the short project update template
Project: [project name]
Checkpoint: [milestone, review, or event]
Prepared by: [name], [date]
Current state
[State what is ready and what has not been accepted.]
Change since the previous checkpoint
[Name the result or change that affects the project.]
Decision and owner
[State the required choice, who makes it, and when it is needed.]
Next checkpoint
[Name the next review and the condition needed to reach it.]
Use the short project update template when the project has a clear next decision. Include enough context for someone who did not attend the review. If you need to explain scope, cost, or several dependencies, use the detailed version instead of squeezing them into one paragraph.
Copy the detailed checkpoint report
Project: [project name]
Checkpoint: [milestone, review, or event]
Prepared by: [name], [date]
Previous checkpoint: [reference]
Goal and current state
[Restate the agreed goal and where the project stands.]
Evidence and acceptance
[Link to completed work and state who has accepted it.]
[Identify work awaiting review or approval.]
Changes to the agreed plan
[State any change to scope, timing, or cost.]
[Separate proposed changes from approved changes.]
Risks and dependencies
[Name the unresolved condition, its effect, and its owner.]
Decision required
[State the choice, decision owner, and required input.]
[Explain what cannot proceed without the decision.]
Next checkpoint
[Name the next review, its owner, and its starting condition.]
[Use a confirmed date or state that timing is not confirmed.]
Project record
[Link to the approved plan, review files, and decision record.]
Keep the report about the named project. A list of tasks across a team belongs in a team report. A checkpoint update needs the agreed goal, the state of the deliverable, and the decisions required to move forward.
Guide to the sections
Identify the checkpoint
Name the event that prompted the update. A design review, supplier change, or milestone acceptance gives the reader a reason for the report. Include the author and preparation date so readers can check which information was known at the time.
Do not tie every checkpoint to a weekly schedule. Send the report when the event occurs. Keep a routine client note separate if you also send one between milestones.
Describe the state and evidence
Compare the current work with the agreed goal. State what is ready for review and what has been accepted. Review and acceptance are different states. A submitted file is not an approved deliverable.
Link to the work that supports your statement. Name the person responsible for acceptance. If approval is missing, state that clearly rather than presenting the milestone as closed.
Separate changes from proposals
State any approved change to scope, cost, or timing. Include the decision reference so readers can find the agreement. Put an unapproved request in a separate sentence and identify who must decide it.
Do not silently replace the original plan with a new estimate. Explain the reason for a change and the effect on remaining work. If timing is not confirmed, state what information is missing and who is obtaining it.
Assign risks and decisions
Describe a risk as an unresolved condition with an effect on the project. Name the person who will check it or act on it. Avoid a list of concerns that nobody owns.
For a decision, state the available choice and the required input. Explain which work depends on the answer. A reader should know whether you need approval, information, or an investigation.
Define the next checkpoint
Name the next review and the condition required before it begins. Assign an owner to arrange it. Use an agreed date only when it exists, and avoid creating a promise from an unconfirmed estimate.
Keep the project record separate from the email conversation. Record the final decision in the shared location after the responsible person answers. Someone joining later needs the accepted plan, not only the request that preceded it.
Filled example at a milestone review
The following example is illustrative. The project, work, and roles are invented to show how to distinguish review from acceptance.
Project: Service website redesign
Checkpoint: Design review
Prepared by: Project lead
Previous checkpoint: Approved page outline
Goal and current state
The goal is an approved set of page designs for development. The designs are ready for review and have not been accepted.
Evidence and acceptance
The review folder contains the page designs. The project sponsor is responsible for accepting them.
Changes to the agreed plan
The page outline remains approved. A request for an additional service page is awaiting a scope decision.
Risks and dependencies
Development cannot begin until the sponsor accepts the designs. The project lead is collecting review comments.
Decision required
The sponsor needs to accept the current designs or request revisions. The sponsor also needs to decide whether to add the service page before the development plan is confirmed.
Next checkpoint
The development review follows design acceptance and the scope decision. Its timing is not confirmed. The project lead will arrange the review after both decisions are recorded.
Project record
Use the approved outline, design review folder, and scope decision record.
The example keeps the completed design work separate from acceptance. It also separates a requested page from approved scope. The reader can see why the next stage has no confirmed timing.
Send a checkpoint update by email
Use the project name and checkpoint in the subject. Paste the chosen version into the body and put the decision request near the top when approval is urgent. Check that recipients can open the linked files.
Subject: [project name], [checkpoint] review
Hello [name],
Please review the decision request below before [dependent work] begins.
[Paste the completed checkpoint update here.]
Please reply with your decision. I will record the agreed next step in [project record].
[Your name]
Choose detail for the audience. The client information guide explains what clients need to understand. For routine client contact, use the short client update format rather than sending the entire internal checkpoint record.
Common questions
What should a project status update include?
Include the project, checkpoint, current state, evidence, decision owner, and next review. Add scope, cost, timing, and dependencies when they affect the decision. Keep approval status explicit.
When is the detailed version useful?
Use it when a change affects several parts of the plan or when reviewers need supporting records. Use the short version when a clear state and decision request are enough. Delete sections that do not apply without hiding unresolved work.
Does a checkpoint replace a regular client email?
No. A checkpoint records a project event. A regular note keeps a client informed between events. The weekly client update guide covers that separate habit. Send a checkpoint update when a decision or milestone needs attention, even if the routine note is not due.