A project status report is a regular, one-page summary of where a project stands against its plan, what is at risk and which decisions are needed from whom. A good one answers five questions: overall status, what finished, what slipped, what comes next and what needs deciding. Write the status criteria down in advance and the report becomes quicker both to prepare and to read.
Key takeaways
- A status report is a decision tool, not an activity log; the overall status and the decision required belong at the very top.
- Red, amber and green only mean something if the criteria are written down in advance, and the critical path sits at the heart of those criteria.
- Every date and figure in the report should come from the plan and actual data, not from memory.
- Panorama Consulting's 2026 ERP Report found that almost a quarter of the organisations surveyed went over schedule; the real job of a status report is to surface slippage while it is still small.
- When tasks, dates and time entries live in one place, the report is read from the system rather than assembled by hand.
What does a project lose without a status report?
Without a regular report, project information scatters across meetings, email threads and people's heads. Usage data in Microsoft's 2025 Work Trend Index special report shows that employees using Microsoft 365 are interrupted on average every 2 minutes by a meeting, email or notification. Unplanned "where are we on this?" messages only add to that load.
The bigger cost is slippage spotted too late. Panorama Consulting's 2026 ERP Report found that more than a quarter of the organisations surveyed went over budget and almost a quarter went over schedule. The same report names organisational issues as the most common reason for overrunning the schedule. We look at why these projects go off the rails in why ERP projects fail.
A regular status report tackles both problems at once: information flows from one source in one format, and deviations reach the table while they are still manageable. If the task list lives in scattered spreadsheets, the report has to be rebuilt every week and the margin for error grows. We cover this in detail in outgrowing spreadsheets.
Which sections should a project status report include?
The shorter the report, the more likely it is to be read; for senior stakeholders one page is usually enough. The seven sections below make a solid skeleton for both team and management reports.
| Section | What goes in it | Common mistake |
|---|---|---|
| Overall status | One colour (green, amber, red) and a one-line reason | A colour with no reason |
| Schedule | Planned and forecast dates for each milestone | Writing "in progress" and nothing else |
| Scope and effort | Approved changes, effort spent and remaining | Quietly absorbing unapproved work |
| Completed | Deliverables finished this period | Listing activities such as "held a meeting" |
| Next period | Work due next, each item with an owner | Leaving items without an owner |
| Risks and issues | Impact, likelihood, owner and target date | Logging every worry as a risk |
| Decisions needed | From whom, by when, which decision | Burying the ask mid-paragraph |
The easiest way to fill the schedule section is to read it off a Gantt chart: if a milestone bar has moved, the report should say so. On the effort side you need actual hours, and we explain how to capture them in our project time tracking guide.
It also pays to keep risks and issues apart. A risk is something that has not happened yet but would hurt the plan if it did; an issue is happening now and needs resolving. Putting both on the same list makes it harder for the reader to see what is urgent.
Red, amber, green: how do you decide the status colour?
This convention is known as RAG status. Left to personal judgement, most project managers report green until the last minute, and the project becomes a "watermelon": green on the outside, red on the inside. The fix is to write the criteria at kick-off and apply the same ones in every report. A simple version:
- Green: No slippage on critical milestones; scope and effort within approved limits.
- Amber: A task has slipped, but the end date is not yet affected or the team can recover on its own.
- Red: The end date, budget or scope is affected and a management decision is needed.
The key concept here is the critical path. A task with float can slip a few days without moving the end date; a single day lost on the critical path moves delivery directly. Tying the colour to criteria follows the same logic as defining a KPI: measurable, written down in advance and known to everyone. For more on that, see how to set KPIs.
How do you write a project status report, step by step?
The sequence below turns the report from one person's habit into a repeatable process.
- Decide the audience and frequency. A team report is often weekly, a management report fortnightly or monthly, and a client report is kept separate.
- Fix a cut-off point. For example, data is frozen on Friday afternoon; anything that changes afterwards goes into the next report.
- Pull the data from the plan. Task status, overdue work, milestones and time spent come from a single source.
- Show the variance. For each milestone, give the planned date, the forecast date and the gap in working days.
- Assign the colour against the criteria. Add a one-line reason; if you cannot write the reason, the colour is probably wrong.
- Put decisions first. A reader who only gets through the opening paragraph should still know what is being asked of them.
- Send and archive. Keeping every report in one place shows the trend week by week and makes it easy to look back.
If an external software house is running the project, it is worth making this report a contractual deliverable. We explain how to tie acceptance and payments to reported milestones in supervising software contractors.
Example: a one-page weekly status report
The example below is fictional and shows a weekly report for a website project.
- Project and period: Corporate website rebuild, week of 21–25 October
- Overall status: Amber. Content sign-off is three working days late; the design work had float, so the launch date has not moved, but that float is now used up.
- Completed: Home page design approved; product page template built.
- Next week: Content entry (owner: content team); test environment set up (owner: development team).
- Risk: If product images do not arrive by the end of the week, launch slips by at least a week; owner: marketing.
- Decision needed: Managing director's approval to launch with placeholder images if they are late, by 30 October.
At a glance the reader sees two things: the project is amber and a decision is pending. A reader who wants detail moves on to the schedule and task list; one who does not can stop after the first two lines.
How can the report come from the system instead of being compiled by hand?
If the report is copied and pasted together every week, the problem is the data source, not the format. Once tasks, dates, dependencies and time entries live in the same system, the status report becomes a view of the plan. We set out the wider idea in real-time reporting.
AI can help here too: it can read overdue work, upcoming deadlines and recent comments and produce a draft summary. But a draft is all it is; the project manager still owns the colour, the reasoning and the decision being asked for. We look at AI in management reporting in AI for management reporting, and at spotting risk early in AI project risk early warning.
Producing the status report from the plan with SmartPM
SmartPM is the Smart family's web-based project management software, showing the same plan as a list, a kanban board and a Gantt chart. Its Reports section shows project progress and the number of overdue tasks, a list of overdue work with how many days each is late, workload per person, and a time summary by project or by person. Each section downloads as CSV, so the figures in your weekly report are not counted by hand.
The "is the end date affected?" question behind your RAG criteria can be answered on screen as well. The SmartPM Gantt chart shows the critical path in red and, next to other tasks, how many working days each can slip without moving the finish. When a task slips, the tasks that depend on it move forward with their durations intact, and you are told how many tasks moved.
For the first draft, SmartPM offers an AI-assisted status summary. It draws on overdue tasks, the critical path, upcoming deadlines and recent comments to set out the overall status, the risks and suggestions for the week; it relies only on data in the project and is rebuilt from current data each time it is opened. Usage counts against your organisation's monthly Smart360 AI allowance.
There is a concrete scenario for client reporting too. A client is added to the project with the Client role and sees only tasks marked as visible to the client; time entries and the team list stay hidden. When the team requests approval on a task, the client either approves it or asks for changes, and the answer is kept on the task with its note, so the decision your report asks for does not vanish into an email thread. You sign in to SmartPM with your Smart360 account, and tasks are written to your organisation's Smart360 calendar.
Next step
This week, build a one-page template from the seven sections above, write down your colour criteria and produce a first report from the data you already have. When you write the second report, note which piece of information took longest to gather; that is the first data to move into the plan.
To buy SmartPM, fill in the SmartPM sales form and the team will get back to you the same working day. If you would like help setting up project management and reporting around the way your organisation works, reach us through our contact page or by phone on 0850 346 41 09 (+90 850 346 41 09 from outside Türkiye). For more guides like this one, browse the software development topic page.