A project status update presentation should cover the current position, recent changes, next work, risks, and decisions. Six to eight slides are enough for most recurring reviews.
Start with a short written update. It forces the project owner to settle the message and evidence before choosing layouts. The presentation then assigns each part of the update a visual role.
Lead with the change
The first slide should state the current position in one sentence. “Onboarding refresh: August update” names the topic. “SSO access delays the pilot by one week while the September 2 rollout stays fixed” tells the audience what changed.
The remaining slides cover:
- Current status and reporting period
- Progress against the plan
- Changes since the previous update
- Work planned before the next checkpoint
- Risks, blockers, and responses
- Decisions or help needed
An appendix can hold definitions, detailed metrics, or a full task list. If the audience has no decision to make, the final slide can record the next checkpoint and its owner.
The UK government’s guidance for managing projects says regular highlight reports should cover progress against the plan, resource and budget status, problems, the impact of issues and changes, upcoming deliverables, and revised cost or schedule forecasts. This sequence keeps the details needed for decisions.
Write the source memo before opening a presentation editor
The template fits a weekly or monthly update. Replace the bracketed fields.
Project: [project name]
Reporting period: [start date–end date]
Owner: [name or role]
Audience: [review group]
Overall status: [On track / At risk / Off track] — [one-sentence reason]
Executive summary
[Two or three sentences: what changed, why it matters, and whether the main target changed.]
Progress against plan
- [Deliverable or milestone]: [actual result] vs [planned result]
- [Deliverable or milestone]: [actual result] vs [planned result]
- [Metric]: [current value] vs [target or previous value]
Next reporting period
- [Outcome due] — [owner] — [date]
- [Outcome due] — [owner] — [date]
Risks and blockers
- [Risk or blocker] — Impact: [effect on scope, date, cost, or quality]
Response: [action, owner, and review date]
Decisions or support needed
- By [date], [decision-maker] to decide [specific choice].
If delayed: [consequence].
Sources
- [Link to plan, dashboard, risk log, or supporting document]
Compare every result with a plan, target, or previous value. Give each risk an effect and response. Name the decision-maker and deadline for every request. Without these details, the deck becomes an activity list.
Copy-ready example: customer onboarding refresh
This example is hypothetical. Its dates and figures demonstrate the format and do not describe a real project.
Project: Customer onboarding refresh
Reporting period: July 15–August 2
Owner: Product Operations
Audience: Launch steering group
Overall status: At risk — the pilot moves from August 12 to August 19 because
the team does not yet have access to the SSO test environment. The September 2
rollout date remains unchanged.
Executive summary
Eight of ten critical onboarding journeys have passed QA. The SSO and password-
reset journeys remain blocked by test-environment access. Content, analytics
events, and the support handoff are ready for the pilot. The group needs to
choose whether to wait for full SSO coverage or run a smaller pilot on August 12.
Progress against plan
- Critical journeys passed QA: 8 of 10 vs 10 of 10 planned by August 2
- Help articles approved: 24 of 24 vs 24 planned
- Analytics events verified: 18 of 18 vs 18 planned
- Pilot participants confirmed: 32 vs target of 30
Next reporting period
- Complete SSO and password-reset QA — Engineering and QA — August 9
- Rehearse support escalation path — Support Operations — August 13
- Confirm pilot cohort and send instructions — Product Operations — August 14
Risks and blockers
- SSO test-environment access — Impact: full pilot starts up to one week late.
Response: Infrastructure owner reviews access daily; escalation on August 6.
- Compressed pilot window — Impact: five fewer days to fix issues before rollout.
Response: Reserve August 20–23 for pilot fixes; review rollout date on August 23.
Decisions or support needed
- By August 6, the launch steering group to choose one option:
A. Move the full pilot to August 19.
B. Start a 12-person pilot without SSO on August 12, then add SSO users later.
If delayed: participant communications miss the August 7 send date.
Sources
- Delivery plan: [link]
- QA results: [link]
- Risk log: [link]
The memo becomes a seven-slide project update presentation
The slide titles should tell the story on their own.
| Slide | Copy-ready title | Content | Why it earns a slide |
|---|---|---|---|
| 1 | SSO access delays the pilot by one week while September 2 rollout stays fixed | Project, reporting period, owner, overall status | States the change and its consequence. |
| 2 | Eight of ten critical journeys have passed QA | Four actual-versus-plan measures | Supports the “At risk” label without reproducing the task log. |
| 3 | SSO access blocks the final two journeys | Blocker, affected journeys, escalation date | Names the cause of the schedule change. |
| 4 | Three outcomes prepare the pilot by August 14 | Next outcomes with owners and dates | Defines the work before the next review. |
| 5 | A shorter pilot window leaves five fewer days for fixes | Two risks, impacts, responses, review dates | Connects each risk to a consequence and response. |
| 6 | Choose the full or limited pilot by August 6 | Options A and B; consequence of delay | Gives the steering group a bounded decision. |
| 7 | Definitions and source links | Delivery plan, QA results, risk log, metric definitions | Keeps supporting detail outside the main story. |
A short internal check-in can combine slides 2 and 3 and omit the appendix. A governance review can split progress into schedule and budget slides. Either change preserves the sequence.
Annotate status update slides with evidence and consequences
An “At risk” label needs a reason and reassessment date. Here, two unfinished journeys and a missing test environment explain the label; August 6 is the escalation date.
Progress needs a baseline too. “QA is nearly complete” makes the audience guess. “8 of 10 critical journeys passed; target was 10 by August 2” shows the result and gap. Compare a metric without a target with the previous reporting period, or remove it.
From a risk register, keep the event, impact, response, and review date. Link to the other fields from the appendix.
Use one message per slide and preserve accessible structure
Each slide should make one claim, supported by text, a number, or a timeline. A unique, descriptive title helps the audience navigate the deck and follows Microsoft’s official PowerPoint accessibility guidance. Microsoft also recommends checking reading order, using sufficient contrast, and avoiding color as the only carrier of meaning.
Pair every red, amber, or green status with a text label such as “On track,” “At risk,” or “Off track,” followed by the reason. The status should remain clear in grayscale and in an exported document.
Move supporting detail out of the main deck
Keep a detail in the main deck only if it changes the audience’s view of progress, risk, or the requested decision. Notes or an appendix can hold:
- completed tasks that do not affect a milestone;
- a full risk register when only two risks need attention;
- dashboard screenshots with unreadable labels;
- meeting history and process narration;
- metrics without a target, comparison, or stated consequence.
Source links let reviewers inspect the supporting detail.
Turn the written update into editable slides
Plainline can split the memo into slides, identify each block’s role, and select layouts while keeping typography, spacing, and placement consistent. The author can edit the content, structure, semantic blocks, layout variants, and media before previewing, sharing, or exporting the deck.
Fill the bracketed fields, remove empty sections, and keep the memo’s order: current state, evidence, then action.