Picture the last project review you sat through. Somebody opened a deck with a title slide, then a slide called “Background,” then a Gantt chart so dense that people started checking their phones by slide four. The work behind it was probably good. The presentation buried it.
I’ve been on both sides of that table, and most of the damage happens before anyone opens PowerPoint. The tips below come from watching project updates land well and land badly, and from fixing a fair number of my own.
Start with the one decision you need
Every project presentation exists to move something forward. You want sign-off on a budget, agreement on a revised deadline, a yes to the next phase, or simply confidence from a stakeholder who has been nervous.
Write that ask down in one sentence before you build anything. For example: “I need the steering group to approve moving the launch from March to May so we can finish vendor testing.” Everything in the deck should either support that sentence or get cut.
When you know the ask, the order of your slides almost writes itself. Context, the problem, what you’ve done, what you recommend, what you need from them. Five beats.
Build the outline before the slides
Open a plain document, not a slide tool. Type one line per slide. If the lines don’t read as a story when you scan them top to bottom, no amount of design will rescue it.
A typical project update outline looks like this:
- Where we are (one sentence status, green, amber or red)
- What we set out to do
- What’s done since the last review
- The one risk that needs attention
- Options for handling it
- My recommendation
- What I need from you today
Seven slides. You can add an appendix for anyone who wants the detail, but the main flow stays short.
Once the outline is solid, turning it into slides is the fast part. I usually paste the outline into a presentation maker to get a first designed version, then spend my time on the wording and the numbers instead of fighting with alignment and fonts. It’s a good way to avoid the trap of spending two hours on a colour scheme for a deck nobody will remember for its colours.
A worked example: from notes to a seven-slide update
Say you’re running a website migration for a mid-sized retailer, and the monthly steering meeting is on Thursday. Your notes from the week are a mess: vendor emails, a spreadsheet of open bugs, a half-written risk log.
Here’s the prompt I’d give an AI slide tool once the outline is done:
“Create a 7-slide project status update for a steering committee. Project: e-commerce website migration. Status: amber. Done since last review: product catalogue migrated, checkout rebuilt, staging site live. Main risk: payment provider integration delayed by the vendor, which threatens the planned go-live date. Options: (a) delay launch four weeks, (b) launch with the old payment flow and switch later, (c) pay the vendor for extra support. Recommendation: option b. Ask: approval for option b today.”
The draft that comes back will usually have the right shape and the wrong emphasis. What I typically change:
- Headlines. Generated titles tend to be labels (“Project Status”). I rewrite each as a sentence, for example “We can still launch on time if we keep the old payment flow for six weeks.”
- The options slide. AI tools like to give every option equal weight. I add a column for cost and one for risk, then visually mark the recommended option so it can’t be missed.
- Numbers. Any figure I didn’t provide gets deleted. The real dates and bug counts come from my spreadsheet.
- Length. If the draft adds a “Team” or “Thank you” slide, I cut it. A steering group knows who the team is.
That editing pass usually takes twenty minutes. Building the same deck from a blank file would take a lot longer, most of it spent on layout rather than on the argument.
Put the headline on the slide, not in your head
Slide titles like “Budget” or “Timeline” tell the audience what the slide is about. They don’t tell them what to think. Replace them with full-sentence headlines.
Compare these:
- “Timeline” versus “We’re three weeks behind, all of it on vendor onboarding”
- “Budget” versus “Spend is on track; the contingency is untouched”
With sentence headlines, someone who only reads the titles still gets the whole argument. Senior stakeholders often do exactly that. They skim.
One idea per slide
If a slide has two charts, it probably has two ideas, and one of them will get ignored. Split it. More slides with less on each is almost always easier to follow than fewer, crowded ones.
Data slides suffer most. A project team tends to show everything it measured because measuring it took effort, while the audience mainly wants the number that changes their decision. Show that number big. Put the rest in the appendix.
Pick charts that answer one question
Every chart on a project slide should answer a single question the audience actually has. A few pairings that work well:
|
Question the audience has |
Chart that answers it |
|
Are we on schedule? |
A simple milestone timeline with today marked |
|
Are we on budget? |
Planned versus actual spend, as two bars or two lines |
|
Is quality improving? |
Open defects over time, one line |
|
Where is the effort going? |
A single stacked bar by workstream |
Burn-down charts, detailed Gantt views and resource heatmaps are useful to the team running the project. They rarely help a steering group make a decision. Keep them in the appendix and bring them up only if asked.
Make the status impossible to misread
Nothing frustrates a sponsor more than realising halfway through a meeting that the project is in trouble. Say the status on slide one, plainly.
If things are behind, say so and say why. People tend to forgive delays they were told about early far more readily than delays they discovered late, and a presenter who opens with “We’re behind, here’s why, here’s the fix” usually earns more trust than one who saves bad news for slide nine and hopes the clock runs out.
Tell the story of one problem
A project has dozens of moving parts. A presentation should focus on the one or two that matter most right now.
Pick the risk or blocker with the biggest consequence and give it proper space: what happened, what it affects, what the options are. A short, specific example beats a general summary every time. “The payments API failed load testing at 400 concurrent users; we need 1,000 for launch” is clearer than “We’re experiencing some performance challenges.”
Give the options side by side on one slide, with the cost and the consequence of each. Three options is a comfortable number. Label your preferred one clearly so nobody has to guess, and be ready to explain why you rejected the other two. Stakeholders relax when they can see you considered alternatives instead of arriving with a single answer and daring them to disagree.
Adjust the deck for who’s in the room
The same project needs a different presentation for different audiences, and reusing one deck for everyone is a common source of bored or confused faces.
Executives and sponsors want status, risk, decision. Keep it to five to seven slides and put the ask on the first or second slide, not the last. They may leave early or get pulled into another call.
The project team wants detail: who owns what, what’s blocked, which dependencies moved. Here a longer deck with task-level slides is appropriate, and a live walk through the tracker can replace slides altogether.
Clients want reassurance and clarity about what they need to do. Avoid internal jargon, remove internal debates, and make every action item on their side explicit with a date.
Cross-functional partners (legal, finance, operations) care about how the project affects their work. Lead with the impact on them, then give the project context.
When I have to present to more than one of these groups in the same week, I build the longest version first and cut it down for the others, rather than stretching a short deck.
Rehearse out loud, with a timer
Say the whole thing out loud, standing up if you can, with a timer running.
You’ll find three things. The deck is longer than you thought. At least one slide makes no sense when spoken. And there’s a transition where you have no idea what to say. Fix all three.
If you have a 15-minute slot, aim to finish in 10. Questions will eat the rest, and questions are where decisions actually get made.
Prepare for the obvious questions
Before the meeting, list the five questions you’d least like to be asked. Then answer each one in a sentence or two, and put any supporting data in a backup slide.
Common ones for project reviews:
- What happens if we don’t approve this?
- What would it cost to hit the original date anyway?
- Who else is affected by the delay?
Having a backup slide ready for a hard question signals that you’ve thought it through. Scrambling signals the opposite.
Keep the design quiet
Plain backgrounds, one font, one accent colour, and charts with clear labels will serve you better than animated transitions.
Use your organisation’s template if it has one. If not, a clean generated layout is fine. When I’m short on time, I’ll run my outline through a presentation maker just to get consistent spacing and layouts, then strip out any decoration that doesn’t help the point. The goal is that nobody notices the design at all.
Mistakes that sink project presentations
A handful of problems show up again and again in project reviews.
Opening with history. Three slides of background before the status means the audience spends the first five minutes waiting for the point. Lead with where things stand.
Hiding the ask. If the decision you need only appears on the final slide, there’s a real chance the meeting runs out of time before you reach it.
Showing the tracker instead of the story. A screenshot of a project tool with forty rows tells people you’re busy. It doesn’t tell them what matters.
Using acronyms from the team channel. Internal codenames and ticket numbers mean nothing to a finance director. Spell things out.
Defending instead of explaining. When someone challenges a delay, explaining what happened and what you’re doing about it goes over far better than arguing that it wasn’t your team’s fault, even when it wasn’t.
Handle the room, not just the slides
Look at the people, not the screen. Pause after your key slide and let it sit for a moment. If someone looks confused, ask them directly whether it makes sense.
When a question takes you off track, answer it briefly and offer to go deeper afterwards. Don’t let one person’s detail question consume the time the group needs for the decision.
And if the meeting reaches a decision early, stop presenting. Thank them, confirm what was agreed, and give everyone their time back.
Send a follow-up the same day
Within a few hours, send a short note with the decision, the owners, and the next dates. Attach the deck. This turns a good presentation into an actual outcome, and it protects you if someone remembers the meeting differently next month. Keep the note short enough to read on a phone: the decision in the first line, then a small list of actions with a name and a date next to each one, then a line on when the next review will happen.
Quick answers
How many slides should a project update have? For a 15 to 30 minute review, five to ten main slides is usually enough, with an appendix for detail.
Should I send the deck in advance? For decision meetings, yes, a day ahead if possible. People who have read it come with better questions, and the meeting can focus on the decision.
What if I don’t know the answer to a question? Say so, say when you’ll have it, and put it in the follow-up note. Guessing in front of a sponsor causes more trouble later than a short delay.
A quick pre-meeting checklist
Run through this before you walk in:
- Can I say my ask in one sentence?
- Does every slide title read as a sentence?
- Is the status on the first slide?
- Did I rehearse out loud and finish early?
- Do I have backup slides for the three hardest questions?
If you can tick all five, the presentation will probably go fine. The rest is just being clear, calm, and honest about where the project stands.