Copy the template below and paste it into your sponsor email or meeting notes; every field uses [bracketed placeholders] you must replace before sending. It includes decision, health, blockers with impact, owners, options, and a recommended next step so the sponsor can decide without reconstructing the project.
Subject: Status: [Project name], [Health], Decision: [Approval needed] | Due [Date]
Body: Decision requested: [Decision and due date]; Health: [Status and reason].
Executive summary, ready to copy:
Subject: [Project name] | Decision: [Approval or review needed] by [Date]
Body: Decision requested: [Decision and due date]. Health: [Status]. Recommendation: [Recommended action and consequence of waiting].
Sponsor needs
- Decision requested and due date.
- Health and a brief reason.
- What the sponsor must approve or do.
- Consequence of waiting.
- Where to see evidence, using an accessible record reference or filename.
Quick send checklist
- Replace every [placeholder].
- Confirm evidence references and who verified them.
- Confirm sponsor authority for the decision.
- Confirm owners checked changed dates and blockers.
- Send the subject and executive summary, with the full report location when needed.
How do I compress the report into a paragraph?
Use a compressed sponsor report when the sponsor needs the decision and its context in the email itself. Keep the requested response, project health, progress, blocker, and recommendation together. Include the owner and consequence of waiting, then check whether approval requires supporting detail from the fuller report.
Copy this paragraph and replace the placeholders:
Subject: Status: [Project name] | Decision: [Decision] by [Date]
Body: Decision requested: [Decision]. Health: [Status and brief reason]. Progress: [Meaningful change]. Blocker: [Blocker description], owner: [Name], consequence of waiting: [Impact]. Recommendation: [Action and owner].
Check that the recommendation says what the sponsor should approve or review. If the sponsor needs to compare options, include the relevant blocker entry from the full report rather than compressing away the trade-offs.
What should a status report include?
Include a summary, progress, schedule, budget where relevant, blockers, and next steps in your status report. (Atlassian) Put the sponsor’s decision near the top, with the impact of waiting and your recommendation. Give each action an owner, and distinguish accepted deliverables from work still awaiting review.
- Do: Keep the information that explains progress or changes a decision. Remove unused fields rather than filling them with vague updates.
- Say: “Approval needed: [Decision]. My recommendation is [Action] because [Reason].”
- Check: Can the sponsor see what needs approval, when a response is needed, and what follows?
What do I do before I send this to the sponsor?
Before sending a status report, confirm that the decision, health statement, and supporting details agree. Ask the relevant owners to check changed dates, blockers, and recommendations. Keep the sponsor’s summary short, but include enough context to assess the options and access the evidence needed for approval.
Use the quick send checklist above, then read the report as the sponsor would. If the opening says the project is on track while a blocker threatens sign-off, revise the health statement or explain the condition.
Say: “Please review [Recommendation] by [Date]. Approval allows [Next step]; waiting affects [Deliverable or commitment].”
Route specialist review to the appropriate reviewer before asking for final approval.
Can I get a complete copy-paste status report template?
Copy the status report template below into your existing email, document, or meeting notes. Replace the bracketed placeholders and remove fields that do not apply. Keep blockers, impacts, owners, options, and recommendations together so the sponsor can review the decision without reconstructing the project from separate updates.
PROJECT STATUS REPORT
Project: [Project name]
Report date: [Date]
Reporting period: [Start date] to [End date]
Author: [Author name]
Sponsor: [Sponsor name]
EXECUTIVE SUMMARY
Decision requested: [Approval, review, or help needed]
Response needed by: [Date]
Health: [Status and reason]
Progress since the previous report: [Accepted deliverable or meaningful change]
Impact of waiting: [Effect on delivery or commitment]
Recommended next step: [Action and reason]
KEY METRICS
Progress measure: [Measure and value]
Definition: [What qualifies and what is included]
Calculation: [Formula using named inputs]
Scope changes affecting comparison: [Change or none]
Schedule: [Status, planned date, and current forecast]
Cost to date, if relevant: [Amount and currency]
Forecast at completion, if relevant: [Amount, method, and assumptions]
Evidence reference for each reported measure:
Provenance: Tool: [Tool name]; Source record or export: [Record identifier or filename]; Captured: [Date and time with timezone]; Included records: [Record identifiers or selection criteria]; Verifier: [Name] checked [Records and calculation] on [Date].
MILESTONES
| Milestone | Planned date | Status | Change from plan | Owner | Evidence reference |
|---|---|---|---|---|---|
| [Sign-off gate] | [Date] | [Status] | [Schedule change] | [Owner name] | [Review record] |
COMPLETED THIS PERIOD
- Deliverable: [Deliverable name]
Acceptance: [Accepted by name or role, date, and evidence reference]
Outcome: [What is now available or agreed]
PLANNED NEXT PERIOD
- Deliverable: [Deliverable name]
Owner: [Name]
Target: [Date]
Dependency: [Approval, input, or prerequisite]
Acceptance condition: [What the reviewer needs to confirm]
BLOCKERS
| Blocker | Impact | Owner | Options | Recommended next step |
|---|---|---|---|---|
| [Pending approval] | [Affected deliverable and consequence] | [Owner name] | [Available option]; [Alternative and trade-off] | [Action], owner: [Name], due: [Date] |
DECISIONS NEEDED
- Decision: [Decision required]
Decision owner: [Name]
Due: [Date]
Recommendation: [Preferred option and reason]
Consequence of waiting: [Effect on the plan]
RISKS
- Risk: [Possible future event]
Impact: [Consequence if the event occurs]
Owner: [Name]
Mitigation: [Action]
Escalation trigger: [Condition requiring sponsor attention]
SUPPORTING EVIDENCE
- [Plan record or document reference]
- [Acceptance or review record]
- [Metric source record or export reference]
NEXT STEPS
- [Action], owner: [Name], due: [Date], dependent on: [Condition]
AFTER THE SPONSOR RESPONDS
Decision recorded: [Response and date]
Plan changed: [Affected work, owner, and commitment]
Follow-up: [Next review or action]
Use the provenance line as a reusable pattern, not a requirement to export every record. Where a source table helps explain a measure, use a filename and row pattern like the following. Replace the placeholders with checked records, and keep sensitive details in the appropriate project records.
Source filename pattern: [Project identifier]-[Measure]-[Report date].csv
Header: "deliverable_id","acceptance_status","accepted_on","scope_status"
Sample raw row: "[Deliverable ID]","[Acceptance status]","[Acceptance date]","[Scope status]"
Calculation inputs: [Included deliverable IDs and acceptance records]
Verification: [Verifier name] checked [Records and calculation] on [Date].
How do I calculate key metrics and where do I pull the numbers from?
Calculate status report metrics from checked project records, and state the metric name, calculation formula, and source file or tool beside the result. Agree what the measure includes with the people reviewing the report, then use the provenance pattern to record the inputs and verification.
Copy this calculation pattern when deliverables are comparable:
Metric: Accepted-deliverable share
Calculation: [Accepted in-scope deliverable count] / [Total in-scope deliverable count]
Result: [Calculated value]
Source file: [Project identifier]-deliverables-[Report date].csv
Source tool: [Tool name]
Checked by: [Verifier name] on [Date]
For the fuller explanation, state what each measure includes, how the calculation works, and when the source was checked. Keep effort spent separate from deliverable acceptance when explaining progress.
- Progress: If deliverables are comparable, use accepted in-scope deliverables divided by all in-scope deliverables, and label the result as an accepted-deliverable share. Otherwise, report acceptance by deliverable rather than combining unlike work.
- Schedule: Compare the current forecast date with the agreed planned date. Record an approved change separately from an unexplained delay.
- Cost: Use the agreed finance records. State the assumptions behind any forecast and distinguish confirmed costs from estimates.
Say: “Progress measure: [Definition]; calculation: [Inputs and formula]; result: [Value]; checked against [Source record].” Check whether scope or acceptance rules changed before comparing reports.
How do I prove the numbers behind each KPI?
Support each status report KPI with a clear definition, identifiable source records, and a recorded calculation check. Use the provenance pattern in the template to connect the reported value to its evidence. Keep detailed records available for review without copying sensitive or irrelevant information into the sponsor’s email.
- Do: Record the source, capture time, included records, and person who checked the calculation. Retain an export when the underlying records may change and project policy allows it.
- Say: “The reported value uses [Included records] and excludes [Excluded records] because [Reason].”
- Check: Can a reviewer follow the calculation from the retained evidence? A sample row illustrates the format; keep the relevant input records available as well.
How do I report blockers with impacts, owners, options, and recommended next steps?
Report each blocker as a current obstacle with an affected deliverable, a responsible owner, available options, and a recommended action. Explain what the sponsor can approve or help resolve. State the consequence of waiting, and use a quantified impact only when the project evidence supports the estimate.
Copy the blocker row in the main template, or use this wording:
Blocker: [Current obstacle]
Impact: [Affected deliverable and consequence]
Owner: [Name or role coordinating resolution]
Options: [Available option and trade-off]; [Alternative and trade-off]
Recommendation: [Preferred action and reason]
Sponsor response needed: [Approval, review, or help]
Next step: [Action], owner: [Name], due: [Date]
Check that the owner coordinating the work is distinguished from the person authorizing the decision. If the impact is still being assessed, name who will confirm it and when.
Who should get which view and how do I name the email?
Send the sponsor a concise summary with the decision, health, recommendation, and enough context to respond. Give delivery leads the details needed to act, including dependencies and evidence references. Share the fuller report with the sponsor when the decision requires deeper review, rather than limiting access to a short summary.
Use the subject pattern at the top of the guide. Include people whose approval, review, or action is needed, following your project’s sharing rules.
Say: “The decision summary is above; supporting detail is in [Report location]. Please confirm [Requested response] by [Date].” Check that recipients can access the evidence they need and that the report does not expose restricted information.
Which milestones matter and who owns them?
Include milestones that affect sponsor decisions, sign-off, delivery handovers, or important dependencies. Show the agreed planned date, current status, change from plan, and accountable owner. Add an evidence reference where review or acceptance determines whether the milestone is complete, and explain any action needed to protect the commitment.
Use the sign-off row in the main template as the formatting pattern. Keep routine activities in the team’s existing task records unless they affect a milestone.
Say: “[Sign-off gate] is [Status] because [Reason]. [Owner name] needs [Review or approval] by [Date].” Check that the owner has agreed to the next action and that the forecast reflects known dependencies.
What did we finish this period?
List accepted deliverables in the completed section of the status report, with the acceptance record or review evidence beside each entry. Describe what became available or agreed, rather than listing activity alone. Keep work awaiting feedback visible under review so the sponsor can distinguish delivery from pending sign-off.
- Do: Use the completed-deliverable pattern in the template.
- Say: “[Deliverable] was accepted by [Reviewer name or role] on [Date]; evidence: [Record reference].”
- Check: Confirm that the acceptance covers the reported scope. If approval is conditional, record the outstanding condition instead of presenting the deliverable as fully complete.
What will we deliver next period?
List the next planned deliverables with owners, target dates, and the dependencies that affect completion. State the review or acceptance condition so the sponsor understands what delivery means. Where work depends on approval, connect the planned deliverable to the decision requested and explain what can proceed while feedback is pending.
- Do: List the deliverable, owner, and prerequisite in the planned section.
- Say: “[Owner name] plans to deliver [Deliverable] by [Date], subject to [Dependency]. Review will confirm [Acceptance condition].”
- Check: Copy unresolved sponsor approvals into Decisions Needed. Keep conditional work clearly marked so a proposed date does not read as an unconditional commitment.
How do I use the template?
Use the status report template in the tools and meetings your team already uses. Gather changes from delivery owners, check the evidence, and prepare the sponsor’s decision summary. After the sponsor responds, record the decision and update the affected work so owners know the next step.
Before the next sponsor meeting, ask owners to confirm progress, changed commitments, and unresolved blockers. Use the quick send checklist at the top rather than maintaining a separate reporting process.
In the meeting, say: “The decision needed is [Decision]. I recommend [Action] because [Reason]. Can you confirm [Approval or next review]?” Afterward, check that the decision record and delivery plan agree.
For broader reporting guidance and alternative layouts, consult ProjectManager, Smartsheet, and Atlassian. Keep the version that helps your sponsor understand progress and respond to the next decision.