Project status update: how to write one from a Gantt chart

A good project status update answers three questions in under a minute: are we on track, what changed since last time, and what do you need from me? Most updates fail because they answer none of them clearly. They list activity ("worked on the design") instead of telling the reader where the project stands.

If your plan lives in a Gantt chart, most of the answers are already on screen. This guide shows how to turn the chart into a short, honest project status update, with a template and a worked example.

What a project status update is for

A status update is not a diary and not a report of effort. It exists so that people who are not doing the work can make decisions: a client who wants to know if the launch date still holds, a manager deciding whether to add someone to the team, a teammate waiting on your task.

That means a good update is:

• Short. One screen. If it needs scrolling, nobody reads the second half.
• Comparative. It says what changed against the plan, not just what happened.
• Honest about risk. A date at risk is more useful on Tuesday than a date missed on Friday.
• Actionable. It ends with the decisions or help you need.

Step 1: Start from the plan, not from memory

Writing from memory produces optimistic updates. Open the chart first and read it the way a stranger would. If you need a refresher on the symbols, how to read a Gantt chart covers bars, groups, dependencies and progress.

Look at four things:

1. Where today falls on the timeline. Everything to the left of today should be finished or explained.
2. Progress on active tasks. Is the percentage what you would say out loud, or what you hoped last week?
3. The next milestone. Is it still on its date? Milestones are the best anchor for a status update because everybody understands "the beta is on 12 November".
4. Anything blocked. Follow the dependency arrows from late tasks to see what they hold up.

If the progress numbers are stale, update them first. A routine like the one in how to keep a project plan up to date makes this a ten-minute job instead of a scramble before every meeting.

Step 2: Give one overall status

Start the update with a single status word the reader can scan. Three levels are enough:

• On track: the next milestone is safe and no decision is needed.
• At risk: the date can still be met, but only if something happens (a delivery arrives, a decision is made, a person is freed up).
• Off track: the date will be missed unless the plan, scope or team changes.

Choose the level from the chart, not from your mood. If the late task is on the path that leads to the milestone, the status is at risk at best. If it has slack before anything depends on it, it may not matter at all. The article on the critical path explains how to tell the difference.

Step 3: Say what changed

The reader already knows the plan. Tell them only what is different from the last update. Three short lists cover it:

• Done since last update: tasks finished, milestones reached.
• Slipped or changed: tasks that moved, with the old and new date and the reason in one phrase.
• Added or removed: new work that appeared, work that was cut.

If a slip moved a milestone, say so first. That is the line the reader is looking for. For what to do about it, see how to handle project delays.

Step 4: Name risks and asks

Close with the part that makes the update useful. List the top one to three risks, each with an owner and what you are doing about it, and then list your asks as concrete requests:

• "Need the client's logo files by Friday to keep the build start on 2 November."
• "Need a decision between option A and B by Wednesday."

Avoid vague asks like "support would be appreciated". If you cannot name a person and a date, it is not an ask yet.

A template you can reuse

Copy this into an email, a chat message or a document:

Project: Website relaunch
Date: 23 October
Status: At risk

Next milestone: Beta ready, 12 November (was 10 November)

Done since last update
- Homepage and product page designs approved
- Content inventory complete

Changed
- Navigation build moved from 26 to 29 October (waiting for final copy)
- Added: cookie banner (2 days)

Risks
- Final copy still missing. Owner: Ana. If it arrives by 27 October, beta holds.

Asks
- Client: approve the final copy by 27 October.

Keep the same layout every time. Readers learn where to look, and you stop spending effort on formatting.

Worked example: a two-week check-in

Imagine a website relaunch with four phases: discovery, design, build and launch. It is the end of week four, and the build phase is the one in progress.

Reading the chart, you see that design is complete, the navigation build is at 40% when it should be at 60%, and the beta milestone is two weeks away. The navigation task is linked to the content migration task, which in turn leads to the beta milestone, so the slip travels along the whole chain. Pushing the late task by three days shows the beta moving by two days, because one later task had a little slack.

The status is therefore At risk, not Off track: the date moves slightly and one input from the client would recover most of it. The update writes itself from the chart: one milestone change, one cause, one ask.

Keeping the update and the plan in sync

The most common problem with status updates is that they say one thing and the plan says another. Two habits prevent that.

First, update the plan before you write the update, never after. The message should be a summary of the chart, not a separate source of truth.

Second, let readers see the plan itself when they want detail. In ProGantt Flow you can share a project with a client or teammate with view-only access, so they can open the live schedule instead of asking you for a new export. Our guide on sharing a Gantt chart with a client explains how to choose what to show, and editor vs viewer access helps you decide who can change what.

Getting a first draft from an AI assistant

If you connect an AI assistant to your plan through MCP, you can ask it questions that read straight from the chart, such as which tasks are still blocking a given milestone, or who is overloaded over the next two weeks. That gives you the raw material for the "changed" and "risks" sections in seconds.

Treat the output as a draft. The assistant can read the dates and the dependencies, but it does not know that the client is on holiday next week or that a delivery was promised verbally. The judgment about status, risk and asks stays with you.

Common mistakes

• Reporting effort instead of progress. "Spent 20 hours on the build" tells nobody if the milestone is safe.
• Hiding bad news until it is certain. Early warnings give people time to help. Late warnings only give them time to be upset.
• Sending too often or too long. Weekly is enough for most projects; daily updates turn into noise.
• Different numbers in different places. One plan, one source of truth.

Summary

A strong project status update is short, built from the plan and structured the same way every time: an overall status, what changed, the main risks, and clear asks. Keep the chart current, read it as a stranger would, and let the schedule do the talking.

You can build and share a plan to report from at app.progantt.com.