Projects & work tracking

A practical project-status update template for service teams

Keep project conversations focused on completed work, open tasks, blockers and the next decision with a repeatable update format.

A useful project-status update helps another person understand what changed and what needs attention. It does not need to repeat every task or describe activity without context. For service teams, a short, consistent structure can connect the current work to the next delivery conversation.

Start with a clear summary.

Name the project or client, the period covered and the person providing the update. State the most important change in a sentence. If work is blocked or a decision is needed, put that near the beginning instead of hiding it in a long activity list.

Use status words that your team has defined. If “in progress” means different things to different people, add the missing context: what is complete, what remains and what input is needed.

A worked status update: what the reader can act on.

A useful status report separates an activity from a result and a blocker from a request. “We worked on onboarding” does not tell the reader whether anything is ready for review. Naming the output and the missing input makes the next decision visible.

The following fictional example uses the same five prompts as the template. Its dates are relative to the team’s agreed review period; it is not a customer case study or a claim of a measured improvement.

Fictional client-onboarding status update
PromptExample content
SummaryThe draft handover notes are ready; the file pack is waiting for one source document.
CompletedDraft notes prepared and linked to the working task for review.
NextCompile the pack once the missing source document is received.
Blocker / decisionThe project owner needs to confirm the correct source-document version.
Reference / ownerLink the working task and name the person responsible for the next follow-up.

Use the same five prompts.

The following is a proposed editorial template. Adapt it to your delivery process and keep sensitive client information in your approved work system.

  • Summary: what changed since the last update?
  • Completed: which tasks or deliverables are ready for review?
  • Next: what work is currently open?
  • Blockers and decisions: what is needed, from whom, and when?
  • References: where are the relevant tasks, files and review notes?

Keep work time separate from completion.

Recorded time can support a discussion about effort, but it does not prove that a deliverable is complete or acceptable. Pair time information with the task status and the relevant working record. Avoid turning a project update into an unsupported assessment of individual performance.

Similarly, a task marked done can still need a separate review or acceptance step in your own process. Make that distinction clear to the person reading the update.

Choose a cadence people can maintain.

Pick a review rhythm that fits the work and the people who need the information. The most useful frequency is one your team can maintain with meaningful changes, not an arbitrary volume of updates.

At the end of a review, make sure each unresolved item has an owner and a next step. Keep the task or source record current so the next conversation begins with the same information.

For more context on effort and progress, read our task tracking vs time tracking guide. Atlassian’s work-management documentation explains work items and status as background to organizing the working records.

  • Keep one agreed location for the update.
  • Link to records rather than copying large amounts of content.
  • Use fictional or sanitized information in demos and training.
  • Review whether the format is helping people make decisions.

Check whether blockers have next actions.

Track open blockers with an owner and a next review date. Report the count missing either field. Record a baseline before changing the update format; do not claim time savings without comparable observations.

Keep the period, population and definitions consistent when comparing results. These are suggested measures, not industry benchmarks or observed FilWorx customer outcomes.

Sources & further reading.

Further reading from the original publishers. Product documentation describes that publisher’s product; it does not establish FilWorx capabilities.

← More on projects & work tracking