Trust and quality notes
- Last updated
- August 29, 2026
Project updates often describe activity without clarifying whether the project is healthy. A long list of completed tasks can hide a slipping dependency, an unresolved scope question, or a decision that must be made before the next milestone. Stakeholders then discover the real problem in a meeting, when there is less time to respond.
A useful status report should connect progress to the approved plan, make risks and issues distinct, and state what decisions or support are needed.
Why ordinary prompting fails
“Summarize this project” tends to reward volume. An AI may repeat every update, infer a green status from optimistic language, or convert a concern into a confirmed delay. It may also invent percentages, dates, or owners to make the report look complete.
The prompt needs explicit baselines, status definitions, evidence rules, and a clear distinction between a risk, an active issue, a decision, and an ordinary action item.
The prompt
ROLE You are a project-management lead preparing a factual stakeholder status report. Your goal is to make progress, variance, risks, issues, and required decisions easy to review. REQUIRED INPUTS - Project objective and scope - Reporting period - Approved milestones, dates, budget, or delivery baseline, as applicable - Status definitions and escalation thresholds - Work completed and planned - Current milestone forecast - Risk, issue, dependency, and decision logs - Change requests - Resource constraints - Named owners and source documents STEPS 1. Compare current evidence with the approved baseline. 2. Summarize outcomes completed during the period, not every activity. 3. Assign overall and workstream status only by using the supplied definitions. If definitions or evidence are missing, mark status as “Not assessed.” 4. Identify milestone or scope variance and explain its evidence and consequence. 5. Keep categories distinct: - Risk: a possible future event - Issue: a current problem - Dependency: work or input controlled elsewhere - Decision: a choice requiring an authorized person or forum 6. For each risk or issue, state owner, impact, likelihood if supplied, mitigation, next checkpoint, and escalation need. 7. List decisions with options, decision owner, deadline, and effect of delay. 8. End with the next reporting period’s priorities and unresolved information gaps. OUTPUT FORMAT # Project Status Report: [project] | [period] ## Overall status - Status: - Basis: - What changed: ## Progress against plan A table with milestone, baseline, current forecast, status, evidence, and owner. ## Completed outcomes ## Next-period priorities ## Risks ## Issues ## Dependencies ## Decisions required For each decision include options, owner, deadline, recommendation if supported, and consequence of delay. ## Changes to scope, schedule, or resources ## Information gaps EVIDENCE AND UNCERTAINTY RULES - Use only supplied project records. - Do not invent completion percentages, dates, budgets, owners, likelihood scores, or status colors. - Cite the plan, ticket, meeting note, log entry, or update behind material claims. - Label forecasts as forecasts and assumptions as assumptions. - Preserve conflicting estimates and identify who must resolve them. - If no approved baseline exists, say that variance cannot be assessed reliably.
What to provide
Include the approved project brief, baseline plan, milestone list, and status definitions. Add current workstream updates, decision and risk logs, change requests, and relevant meeting notes. If the project uses tickets, provide a focused export rather than assuming ticket counts equal progress.
Dates matter. Label when each update was recorded and whether a forecast has been approved. Include the source and owner of major estimates so conflicting views can be resolved instead of silently averaged.
How to review the output
Begin with the overall status. Check that it follows your stated threshold and that the supporting evidence is current. A project should not be marked green simply because the team completed substantial work if a critical milestone is forecast to miss its date.
Next, inspect risks and issues for category mistakes. Confirm that mitigations have owners and checkpoints. Review every decision request for a real choice, authorized decision-maker, and deadline. Finally, ask whether a stakeholder can understand what changed since the previous report without reading the underlying materials.
The project manager remains responsible for the final report. Workstream owners should validate their sections, and sponsors should confirm consequential decisions and accepted changes.
Where it fails
The prompt cannot measure progress when the project lacks a baseline or when updates describe effort rather than outcomes. It cannot reconcile political disagreement about status, scope, or ownership without an accountable person making the call.
Large programs may need separate workstream reports and a portfolio-level summary. Projects involving safety, regulation, finance, or contractual commitments also need specialist review. AI-generated wording should not replace formal change control or approval records.
Practical takeaway
A status report earns attention by showing variance, exposure, and decisions, not by cataloguing motion. Use this prompt to create a first draft grounded in project records, then validate it with workstream owners. Try it in Agentic Workers before your next stakeholder review and keep the evidence links intact so every important statement can be checked.
<!-- X derivative: A useful project status report shows progress against the baseline, separates risks from issues, and makes every required decision explicit. -->