To write a project update, lead with the overall state, then report the meaningful change since the last update, the next milestone, risks or blockers, and any decision you need from readers. A project update is a decision aid: it helps people understand whether the plan still holds and where attention is needed. It is different from a handover note, which equips a new owner to continue specific work.
Lead with a status readers can interpret
Open with a plain status such as “On track,” “At risk,” or “Blocked,” but explain what the label means. “At risk: the prototype review is two days later than planned, leaving less time for revisions before the demonstration” is more useful than a color or label alone. State the period covered and the next milestone so readers know the frame of reference.
Then summarize what changed since the previous update. Focus on new information: a completed deliverable, a changed date, a decision, or an issue. Avoid repeating the entire plan each time. Plain language guidance recommends shaping content for its intended audience, which means selecting the detail those readers need to understand their obligations or choices [1].
Show progress against a visible plan
Tie progress to milestones or deliverables rather than vague effort. “The team worked on testing” describes activity; “The team completed tests for the sign-in and reset flows; payment testing remains” shows what is done and what remains. If the plan changed, state the old expectation, the new expectation, and why the change occurred when known.
Use parallel labels to make updates easy to compare: “Done,” “Next,” “At risk,” and “Decision needed.” Keep each item short enough to scan, but add a sentence of explanation when a reader would otherwise have to infer the consequence. Purdue’s sentence clarity guidance recommends keeping familiar information before new information, so readers can connect the update to what they already know [3].
Work through an example update
Consider an invented example: a small team is preparing a bilingual event registration page. The previous plan was to publish Friday after a language review. A useful update might say: “Status: at risk. The English page is ready; review of the translated page is still open, so Friday publication is uncertain. Next: Ana sends the final text to the reviewer by noon Wednesday. Decision needed: approve a one-day publication shift if review is not complete by Thursday morning.”
The example names the impact and the decision window. It does not claim the translation is wrong or blame a person. Add evidence that supports the status, such as the unfinished review or a confirmed date, but distinguish facts from estimates. If the date is only a forecast, label it as a forecast. A useful update allows a reader to see both the project state and the reasoning behind the requested decision.
Describe risks as cause, effect, response
A risk is not just a problem word. Explain what may happen, what it would affect, and what the team is doing. For example: “The reviewer may not return comments by Thursday. If that happens, publication moves to Monday. Ana has asked whether a short review window is possible.” If the issue has already happened, call it a blocker or issue and report its current effect.
Make ownership explicit when you assign follow-up. “The vendor will confirm the delivery date by 10 June” gives a person or group and a deadline. Passive wording can be appropriate when the doer is unknown or irrelevant, but active phrasing often makes responsibility easier to identify [4]. Keep the request specific: name the choice, the person who can make it, and when the answer is needed.
Choose detail and format for the reader
A sponsor may need milestones, cost implications, and decisions; a delivery team may need task dependencies and owners. Adapt the level of detail without changing the underlying facts. Put the most relevant information first and use headings that describe their contents. W3C guidance notes that informative headings help readers scan and navigate documents, including people using assistive technology [2].
Before sending, compare the update with the previous one. Are changes obvious? Are dates consistent? Does every “next” item have an owner or a clear reason it does not? Replace unexplained abbreviations, long noun strings, and ambiguous pronouns. If readers need to act, end with the exact decision or response you need and its deadline.
