Project Status Report Checklist: Milestones, Decisions, Risks and Next Period
A project status report checklist for consulting teams covering milestone progress, decisions needed, risks, blockers and next reporting period commitments.

A project status report should help a sponsor decide where attention is needed. It should not be a diary of activity or a color-coded mystery. The best reports explain progress against the plan, name decisions that are blocking movement, show risks and commit to the next period.
This checklist uses a consulting project: a strategy review moving from discovery into options analysis. The engagement lead sends a weekly status report to the client sponsor. The same gates work for many client-delivery projects, but the evidence and cadence should match the approved project brief.
Check The Reporting Header
Before writing narrative, make sure the report can stand alone:
- Project name.
- Reporting period.
- Report date.
- Prepared by.
- Sponsor or recipient.
- Overall status.
- Baseline document or project brief version.
Use a short status summary:
Overall status: Needs attention. Discovery interviews are complete, but customer data is incomplete. Options analysis can start for qualitative themes, while quantitative validation depends on the data file due [date].
That is more useful than a yellow icon by itself. If you use red, amber and green, explain why the status changed and what would return it to green.
The State of Michigan Project Management Methodology describes status reporting as a way for the project team, contractors and executive management to stay informed about progress, key activities, issues and risks that must be resolved (Michigan PMM Manual). That is public-sector guidance, but it captures the purpose of a report: it exists to support management action.
Check Progress Against Milestones
Report progress against agreed milestones, not against effort spent.
Checklist:
- What milestone was planned for this period?
- Was it completed, partially completed or delayed?
- What evidence proves completion?
- What variance exists against baseline date?
- What recovery action is underway?
Sample language:
Milestone: Complete stakeholder interviews.
Baseline date: [date].
Current status: Complete. Eight of eight planned interviews held. Interview notes stored in the project folder.
Variance: None.
Next milestone: Draft options analysis by [date].
For a delayed item:
Milestone: Receive customer onboarding data.
Baseline date: [date].
Current status: Delayed. File received on [date] is missing first-use timestamp for [period].
Impact: Quantitative comparison cannot be completed until corrected file is received.
Owner: Client data lead. Due: [date].
The California Project Management Framework says a monitoring goal is to use current metrics and progress or status reports against plans to identify potential issues or risks early (CA-PMF Monitoring and Controlling). That is exactly why milestone status should include variance and impact.
Check Decisions Needed
A status report should not hide requests in the final paragraph. Put decisions in a visible section.
Use this structure:
| Decision needed | Owner | Needed by | Impact if delayed |
|---|---|---|---|
| Confirm whether billing handoff remains in scope | Sponsor | [date] | Options analysis may exclude a root cause |
| Approve two additional operations interviews | Sponsor | [date] | Evidence base remains limited |
Draft language:
Decision required by [date]: Approve or reject two additional operations interviews. Without this decision, the final report will state that implementation-team evidence was not gathered and recommendations may be limited.
This gives the sponsor a real choice and explains the consequence without drama.
Check Risks And Blockers
Risks are possible future events. Issues or blockers are happening now. Keep them separate when you can.
Risk: Sponsor review meeting may move because two executives are unavailable.
Trigger: No confirmed calendar hold by [date].
Response: Engagement lead to propose two backup review slots.
Blocker: Data file missing first-use timestamp.
Owner: Client data lead.
Action: Send corrected file by [date].
The Federal Acquisition Institute's Project Manager's Guidebook describes a risk statement as defining the risk as an event and including causes, trigger events, missed milestones and estimated time frames (FAI Project Manager's Guidebook). You do not need a heavy risk methodology for every consulting report, but a risk should be specific enough to manage.
Check Next Reporting Period Commitments
Close the report by saying what will happen next. Do not write "continue analysis" if you can be more specific.
Next period commitments
- Complete options analysis for qualitative findings by [date].
- Receive corrected customer data by [date] or mark quantitative validation as limited.
- Hold sponsor decision meeting on [date].
- Issue draft recommendations report outline by [date].
Each commitment should have an owner in the report or action log. If a commitment depends on a client action, say so.
Add a short "watch list" when a commitment is not yet a risk but deserves attention:
Watch list: Sponsor workshop attendance is not confirmed for [date]. If fewer than [number] decision-makers can attend, the team may need to convert the workshop into a review of written options.
The watch list should stay short. If an item has a defined probability, impact and response, promote it to a risk. If it is already stopping work, call it a blocker. The watch list is only for issues that need attention before they become either.
Check The Evidence Behind The Report
Before sending a status report, ask whether every important statement can be traced to a record. That does not mean loading the report with attachments. It means the team knows where the proof lives.
For example:
| Status statement | Supporting record |
|---|---|
| Interviews complete | Interview tracker dated [date] |
| Data incomplete | Data receipt note and issue log item I-03 |
| Sponsor decision pending | Meeting minutes dated [date] |
| Draft report due next week | Delivery plan version [x] |
This evidence check keeps the report from becoming opinion. It also protects the engagement lead when a sponsor asks why the status moved from green to amber. The answer should be in the records, not in someone's memory.
Use careful language when evidence is incomplete:
Current evidence suggests [finding], based on [source]. The team has not yet validated this against [missing source], which is listed as dependency D-02.
That is stronger than overstating confidence. It tells the sponsor both what is known and what is still missing.
Final Review Gate
Before sending, check:
- Does the report state the period?
- Does overall status explain the reason?
- Are milestones compared with baseline dates?
- Are decisions visible with owners and due dates?
- Are risks separate from current blockers?
- Does each blocker have an owner?
- Are next-period commitments specific?
- Are confidential details minimized or referenced by document version?
Once sent, use the report as the baseline for the next reporting conversation. Carry forward open decisions, risks and blockers until they are closed, superseded or moved into a change request. A status report loses value when unresolved items vanish between weeks.
Start From An Editable Structure
The consulting project status report template is an editable Word file with sections for period and overall assessment, milestone progress, decisions, risks, blockers, next-period commitments and approval. It is a reporting structure, not a substitute for active sponsor follow-up.
Last updated: September 26, 2026
Frequently Asked Questions
Related Articles
Change Request Best Practices for Client Delivery
Change request best practices for documenting the reason, scope impact, schedule and cost implications, and authorization before changed work starts.
Change Request Checklist for Reviewing Scope, Schedule and Cost
A change request checklist for consulting projects covering reason for change, scope impact, schedule and cost implications, and authorization.
Change Request Examples: Scope, Schedule, Cost and Authorization
Practical change request examples for consulting projects, with annotated language for the reason, scope impact, schedule, cost, decision and authorization.
Handover Document Best Practices for Client Delivery
Handover document best practices for completed work, outstanding actions, access, operating instructions, acceptance, and ownership.
Handover Document Checklist: Completed Work, Open Actions and Ownership
A practical handover document checklist for consulting work, with review gates for completed work, outstanding actions, access, operating notes and acceptance.
Handover Document Examples for Consulting Work
Handover document examples for consulting teams, covering completed work, outstanding actions, access and operating instructions, and acceptance and ownership.