A weekly project status report should let a client, manager or team decide what to do next. It is a short account of what changed, whether the next milestone is still credible, and who needs to act. Below, you will learn how to judge the status before writing it, copy a one-page template and see a filled example. The cooking school and dates are fictional.
Start with a question, not a color
Imagine a neighborhood cooking school whose clients currently reserve group classes by phone. Each class has 12 places. The project is to launch, by 30 October, a mobile-friendly page where clients choose a class, reserve a place, pay by card and receive confirmation by email. Maya coordinates the launch, Leo builds the page, and the cooking school owner decides any change to the offer. On 16 October, the class list and booking form have been reviewed, but the payment provider has not approved the account. The team therefore cannot test a paid booking. The important question is not “What percentage is complete?” It is: Can we still launch the agreed service on 30 October, and what must happen first?
A page that looks 90% finished can still miss its launch if the remaining 10% blocks payment. Report the effect on the next milestone, not an unverified completion percentage.
Check four things before writing the report
- The agreed plan: What is the next deliverable, on which date, with which scope? Here it is a working class-booking flow with card payment and email confirmation on 30 October. Keep the original date visible even if you later propose a change.
- What is confirmed: Ask the person doing the work for evidence, such as an approved page, a completed test or a written reply from the provider. “We expect approval soon” is a forecast, not a fact.
- What changed: Compare this week with last week. Name the new dependency, missed date or completed result that changes your confidence in the milestone.
- The response: For each significant problem, state an action, owner and deadline. If the team cannot decide alone, name the choice and the person who can make it.
Write “not confirmed” when information is missing. A report that admits uncertainty is more useful than a confident status based on a guess.
How to choose green, amber or red
Agree on the rules with your readers before using colors. A practical starting point is: green when the next agreed milestone remains credible with no unresolved critical dependency; amber when it is threatened but a dated recovery action could still protect it; red when the agreed date or scope is no longer credible without a decision to change it. Always add the evidence and the next action. These are working definitions for this template, not universal thresholds.
The project is amber on 16 October: payment approval is pending, but approval by 21 October would leave time for the planned test on 23 October. If approval has not arrived by 21 October, the original paid-booking launch needs a new decision. Do not leave the report amber automatically. Reassess the evidence and escalate.
Risk, issue and decision: three different lines
A risk is something that may happen: “Approval may arrive after 21 October.” An issue is a problem already present: “The provider has rejected the account” or “The 21 October deadline passed without approval.” A decision is a choice someone must make: “Open online booking with payment at reception, or move the launch date?” Treating all three as “blockers” hides what the reader should do. Keep the detailed trigger and response in a project risk register.
Copy this one-page weekly project status report template
Project / reporting date: [name] / [date]
Overall status and why: Green / Amber / Red — [one sentence tied to the next milestone].
Since the last report: [up to three verified outcomes or changes].
Next milestone: [agreed deliverable and date] — [still credible? Why?].
Main risk or issue: [what may happen or has happened] — [effect on date, scope or cost] — [owner].
Decision needed: [precise options] — [decision maker] — [latest useful decision date]. Write “None” if no decision is needed.
Next actions: [verb + deliverable — owner — due date].
Evidence: [link to plan, test or risk register; mark anything unconfirmed].
Keep it to one page by linking to the plan rather than pasting every task. The report is the decision summary; the plan and registers hold the detail.
Filled example: the cooking school’s update on 16 October
Project / date: Online class booking with card payment for the 12-seat cooking classes / 16 October.
Status: Amber. A paid-booking launch on 30 October is still possible, but the payment account is awaiting approval. We need approval by 21 October to run the planned end-to-end test on 23 October.
Since the last report: The owner reviewed the mobile class list and booking form; privacy copy was approved. Payment approval is still unconfirmed.
Next milestone: Complete a test class booking with card payment and email confirmation by 23 October. This date depends on the provider’s approval by 21 October.
Risk: Approval after 21 October would shorten or prevent payment testing. Maya owns the provider follow-up. This is a risk until the deadline passes or the provider rejects the account.
Decision needed: By 21 October, the cooking school owner chooses between opening online booking with payment at reception or moving the launch if approval is still missing. Neither option is silently treated as the original scope.
Actions: Maya requests a dated answer from the provider by 19 October. Leo prepares the test booking by 20 October. The owner confirms the fallback on 21 October if needed.
Evidence: Link to the approved page, provider correspondence and test checklist; no approval date has been confirmed.
This example separates the fact (approval pending) from the forecast (testing could slip). It also names the point at which the team must stop waiting and choose a different path.
What to do after sending it
- Send the report to people who can act on it and make the requested decision visible, including its deadline.
- Record the decision and update the project plan if the date or scope changes. Do not quietly overwrite the original target.
- At the next update, check whether the promised actions happened. If nothing changed, say so and explain why the milestone is still credible.
Between weekly reports, agree on where urgent changes are posted and how quickly someone must respond. Our asynchronous project management guide
How Altirya helps you prepare the next report
In this example, Maya could create a project for the cooking school’s class-booking launch and put the 23 October paid-booking test and 30 October launch on its schedule. She could assign herself the provider follow-up and Leo the test, each with a due date. In Altirya’s risk register, she could record the possible late approval, its owner, the 21 October warning threshold, a mitigation action and the next review date. This gives the team a shared place to check what was planned, what has happened and who is acting before they write the weekly update.
On eligible Professional plans, Altirya can generate a draft project report using the project information that has actually been entered, including tasks, milestones, risks and, when available, costs and discussions. You can choose whether it is aimed at a client, team, project manager or executive. For the cooking school, a useful draft would highlight the pending payment approval, the test date at risk and the decision needed from the owner. The tool cannot obtain the provider’s answer or make that launch decision for you: check the evidence, correct any missing context and approve the report before sharing it.
Want to try the method? Create the project, enter the next milestone, assign the two actions and record the approval risk. You can use the one-page template above immediately; report generation is available on eligible Professional plans.
Method note: the distinction between a possible risk and a present issue is also explained in the Northern Ireland Department of Finance guidance on project issues. The template, rules and cooking-school example here are original and illustrative.
Frequently asked questions
What should a weekly project status report include?
Include the reporting date, status with evidence, what changed, the next agreed milestone, the main risk or issue, any decision needed, and actions with owners and due dates. Link to supporting evidence instead of copying the full task list.
How do I decide whether project status is green, amber or red?
Agree on definitions with your team. One useful rule is green when the next milestone is credible, amber when it is threatened but a dated recovery action may protect it, and red when the agreed date or scope needs a change decision. Explain the facts behind the color.
What is the difference between a project risk and an issue?
A risk is a possible future event, such as a supplier approval arriving late. An issue is a problem that has already happened, such as the agreed approval deadline passing. Both need an owner and response.
How long should a weekly project report be?
For a small project, aim for one page. Keep the decision summary in the report and link to the plan, tests or risk register for details.
