What should a project status presentation answer?
A project status presentation should do more than list completed work; it should help the audience understand how close the project is to its goal, what obstacles exist, and what decisions are needed. As you prepare the presentation, focus on three questions: What is the difference between what was planned and what actually happened? What caused that difference, and what might its impact be? Who needs to do what, and by when, to keep progress moving?
The structure below is a practical recommendation for this article; adapt it to the project’s scope and the audience’s decision-making role. Cornell’s “Project Status Update Process” and Michigan State University’s Capstone program documents on team status report presentations are relevant reference materials (Cornell document; Michigan State University document). The excerpts provided here do not include the readable text of these PDFs, so I do not attribute any particular template or rule to the documents.
What you need before the presentation
Specify the reporting period and presentation date; for example, “October 1–14.” Compare the original plan, the latest forecast, and the project records on which they are based. If a task’s completion criteria or current status is unclear, do not present its progress as certain.
Gather the following information in your preparation notes:
- The project’s purpose and the milestone targeted for this period.
- Completed work and the output or record that demonstrates completion.
- Work in progress, dependencies, and current completion forecasts.
- Significant risks or issues that have occurred; their potential impact, the action to take, and the person responsible.
- The decision requested, who will make it, and the date by which it is needed.
If information is missing, do not fill the gap with a guess. Note who will verify it and when that will be completed; in the presentation, clearly state that the data has not been confirmed.
Slide sequence: concise and decision-focused
You can organize an update into five parts: The first slide gives the project name, reporting period, and overall status; the second compares the target with actual progress; the third covers completed and upcoming work; the fourth presents significant risks and responses; and the final slide lists the decisions requested. This is not a required template, but one way to organize the information.
Put one main message on each slide. Instead of “Work is ongoing,” use a specific headline such as “User testing is complete; two critical bugs may affect readiness for launch,” but only if the project records support it. If you use colors or status labels, explain what they mean; alongside the label, also state the reason and the action needed.
Hypothetical example: website redesign
The names, dates, and numbers below are entirely hypothetical. In this example, the team is redesigning product pages, the target launch date is November 30, and the reporting period is October 1–14.
Slide 1 — Status summary: “Target date remains on track; content approval is a critical dependency.” Briefly explain which current forecast this assessment is based on. If the data has not been confirmed, do not present the date as final.
Slide 2 — Progress: Three of the five planned pages have passed design approval, while two are awaiting feedback. Identify the completed pages and show the approval record. Use “60% complete” only if you can explain how the figure was calculated and what it is based on; otherwise, list the milestones.
Slide 3 — Risk: If content approval is delayed, the copy may need to be changed during development. Example action: the content owner approves the remaining two pages by October 18; until then, the team validates the design using placeholder copy. This action and date are specific to the example; for a real presentation, confirm the owner and schedule with the project team.
Slide 4 — Decision request: “Can the product team complete copy approval for the two pages by October 18? If not, which page should we address first?” Specify who will make the decision and the response date. If no course of action has been determined in the event of no response, note this as an issue to clarify in the meeting rather than inventing a default decision.
Explain risks and decisions clearly
It is useful to distinguish a risk, a possible situation that has not yet occurred, from an issue, an obstacle that has already arisen. Describe each in the format “situation → impact → action → owner → date.” “The supplier may be delayed” does not, on its own, help people make a decision; add which delivery could be affected and who will take what action. If the impact or likelihood has not yet been confirmed, say so.
On the decision slide, do not present a request for information as if it were a decision request. List the options, the possible outcome of each if known, and the basis for your recommendation. If the authorized decision-maker is unclear, record that the decision owner must first be identified. Report that a decision has been made only if it has been confirmed.
Final checklist and presentation tool
Before sharing, check the following:
- Is there a basis or data date for every significant claim?
- Are planned and current dates being compared using the same period and criteria?
- Is completed work supported by verifiable outputs?
- Are risks and issues clearly described, including their impacts and next actions?
- Is the decision owner and required date specified for every decision request?
- Does the summary slide conflict with the details, and are abbreviations clear?
If you use Google Slides, you can create the presentation manually. Optionally, you can also consider the feature for generating slides with Gemini: Google’s current help guide explains that it requires an eligible Google Workspace or Google AI plan, and describes how to generate a new slide through “Ask Gemini” in Slides and add it to a presentation (Work with Gemini in Google Slides). Check that the feature is available on your account and that the menus appear in your current interface. Do not treat the generated draft as an approved status report; review dates, calculations, risks, and decision owners against project records. If you do not have access to the feature, manually build the same slide sequence in the presentation tool you use.
If your presentation is for a different purpose, you can also read project presentations for interviews and preparing a presentation for a website project.
Frequently Asked Questions
How many slides should a project status presentation have?
Rather than specifying a fixed number, use enough slides to make progress, significant risks, and required decisions clear. Shorten repeated details; do not remove evidence needed for a decision.
How should you explain that a project is delayed?
Show the planned date and the current forecast side by side. Explain the reason for the difference, which milestone it affects, and what action the responsible person will take. If the new date is not certain, state that it is an estimate and specify what information will be used to update it, and when.
← Back to blog
