How to Write a Weekly Project Update from Daily Voice Notes

Daily voice notes can capture the small changes that disappear by Friday: a task finished, a date moved, a dependency surfaced, or a question still waiting for an owner. The problem is that five recordings are not yet a weekly project update. A stakeholder should not have to replay the week to understand the current state.

A useful weekly update compresses those notes into a short, checkable record. It separates completed work from work in progress, identifies what changed, keeps blockers visible, and names the next action. Each important statement links back to a dated source marker so another authorized reviewer can confirm it.

This workflow is for ordinary voice notes that you are permitted to record, retain, and share with the intended audience. The website-refresh example below is entirely fictional and contains no customer material, private recordings, or Recolx internal data.

Define the audience and reporting window

Before listening, write two boundaries:

Audience: Project team and sponsor
Reporting window: Monday 09:00 through Friday 15:00

The audience determines the level of detail. A delivery team may need task-level dependencies; a sponsor may need only the milestone, risk, decision, and next step. The reporting window prevents a Friday-evening note from being mixed into a report that was already sent.

Atlassian’s weekly project update guidance recommends communicating current status, roadblocks, next steps, and any specific help needed. Asana’s status-report guidance likewise emphasizes concise progress, challenges, and next steps. The exact headings can vary, but the reader should leave knowing what changed and whether they must act.

Create a dated source index first

Do not begin by drafting a smooth narrative. First make a source index with the date, marker, topic, and evidence state. This keeps later summaries traceable.

The evidence-state column prevents a confident sentence from hiding uncertainty. “Review completed” does not mean every requested change has been applied. “Mobile review planned” is not the same as “mobile review passed.”

Normalize verbs before grouping the notes

Use a small set of status verbs:

• Completed: the defined output exists and the completion evidence is available;
• In progress: work has started but the expected output is not complete;
• Planned: a future action has been proposed or scheduled;
• Blocked: progress depends on an unresolved condition;
• Changed: scope, owner, timing, or approach differs from the previous plan;
• Unverified: the note states a result, but the supporting artifact has not been checked.

These labels make contradictions easier to see. If Tuesday says the image delivery moved to Thursday and Wednesday still says “waiting for Wednesday delivery,” retain the later schedule change and flag the older expectation rather than blending both into a vague delay.

Separate four questions

A compact weekly update can answer four questions in order:

1. What moved forward?
2. What changed from the previous plan?
3. What is blocked, at risk, or undecided?
4. What happens next, and who owns it?

Do not put a future action under progress. “The team will test mobile on Friday” belongs in next steps until the test result exists. Do not put an unresolved dependency under “minor notes” if it can move the milestone.

Write one honest status sentence

The first sentence should summarize the current state without hiding the important condition:

Weak: The website refresh is going well.

Better: The website refresh remains on track for desktop review, while mobile approval depends on completing Friday’s image and layout checks.

The better version states both movement and dependency. If the evidence does not support an “on track” label, use plain language instead of guessing a health color.

A finished weekly update from the fictional notes

Status

Desktop review is complete. Mobile approval remains open and depends on the final image accessibility check and Friday afternoon layout review. [Sources: Thu 14:18; Fri 10:25]

Progress this week

• Homepage copy review was completed on Monday; two wording changes were requested. Application of those changes has not yet been verified. [Mon 09:12]
• The final image set arrived Thursday. [Thu 14:18]
• Desktop review passed Friday morning. [Fri 10:25]

Changes from plan

• Image delivery moved from Wednesday to Thursday. [Tue 16:05]
• Mobile layout testing moved behind image receipt because the final asset dimensions were required. [Wed 11:40; Thu 14:18]

Blockers and decisions needed

• One delivered image is missing alternative text. The content owner needs to provide or approve it before mobile approval. [Thu 14:18]
• No decision is currently recorded for whether an incomplete mobile check changes the launch date. The project owner should confirm that rule. [No answer in reviewed notes]

Next steps

• Content owner: approve the missing alternative text by Friday 13:00.
• Design reviewer: complete the mobile layout check Friday afternoon.
• Project owner: record the launch decision after the mobile result.

The second blocker is deliberately unresolved. A polished update should not invent a launch rule simply because the source notes are silent.

Resolve contradictions with a change log

When two notes disagree, do not quietly select the version that fits the narrative. Create a small change row:

Field: Image delivery date
Previous statement: Wednesday (Mon 09:12)
New statement: Thursday (Tue 16:05)
Reason recorded: Not stated
Current value: Thursday
Verification needed: Confirm delivery with asset folder timestamp

This preserves history without forcing readers to replay every note. If the reason is missing, label it missing.

Keep decisions separate from activity

Daily notes often mix “we discussed,” “we decided,” and “we will.” Only the second is a decision, and even then it needs scope and an owner. A discussion about moving launch does not mean launch moved.

If the week ends with a handoff, use a dedicated project handover from meeting notes rather than expanding the weekly update into a replacement for ownership transfer. The weekly update explains current state; the handover confirms who carries the work next.

Trim detail with a relevance test

Keep a note only when it changes at least one of these:

• the current status;
• a milestone or date;
• scope or approach;
• a blocker, dependency, or risk;
• a decision or decision request;
• the next action, owner, or deadline.

A useful observation that does not affect this week’s project state can remain in the source index. Compression is not deletion: the update points back to the notes when more context is needed.

Copy this weekly update template

Project:
Reporting window:
Audience:
Prepared at:

Status sentence:

Progress this week:
- Outcome — source marker — verification state

Changes from plan:
- Previous value → current value — source marker — reason if known

Blockers, risks, or decisions needed:
- Issue — impact — owner or decision maker — source marker

Next steps:
- Action — owner — date — dependency

Missing or conflicting evidence:
- Question — notes checked — follow-up owner

Run a final source check

Before sharing, reopen every marker used in the update. Confirm that completed work is truly complete, planned work is not written in the past tense, changes retain the previous and current values, and every next step has an owner or an explicit owner gap. Remove private detail that the intended audience does not need.

If a long voice memo covers several unrelated subjects, first create a source-linked outline from the voice memo. Use that structure to find the project-relevant sections, then build the weekly update from dated evidence rather than from memory.

Take five daily notes you are allowed to review. Build a dated source index, write one honest status sentence, and add only the progress, changes, blockers, decisions, and next steps that the notes support.

Sources

• Atlassian Team Playbook: Weekly Project Updates
• Asana: How Project Status Reports Work