The Project Status Report: What to Include, How to Color It Honestly and a Builder You Can Copy

Every project has a report that says "Status: Green." Every project also has, somewhere in the building, a person who knows it is not green. It is green the way a watermelon is green: perfectly fine on the outside, and when someone finally cuts it open on the day of the steering meeting, it is red all the way through, and the seeds have already been spat in every direction.

Project managers call this the watermelon report, and I have never met anyone who enjoyed receiving one. Nobody writes it out of malice. The author is usually optimistic, busy, afraid of being the bearer of bad news or simply unsure what "green" is supposed to mean. The fix is not a bigger template. It is a smaller one, with rules.

This guide shows what a status report is for, the seven parts that belong on its single page, how to give colors a definition nobody can bend, what to write and what to cut, and how to produce the report in twenty minutes a week. In the middle there is a builder: fill in a sample project, change the sample text to your own, and copy the result. Nothing you type leaves your browser.

What a status report is actually for

Strip away the logos and the corporate headers and a status report does three jobs.

1. It tells people where the project is. Not how hard everybody is working, which is a different and much longer document. Where it is, compared with the plan everyone agreed to.
2. It tells people what is coming. The next few weeks, in plain terms, so that nobody is surprised by a delivery, an outage or a bill.
3. It asks for help. This is the job people forget. A report is the cheapest, politest way to say "I need a decision from you by Thursday, and here is what happens if I do not get it."

Notice what is missing from the list: proving that you are busy. A report that exists to protect its author is easy to recognize. It is long, it is vague and it lists every meeting held, every email sent and every "ongoing activity," like a diary kept by a very nervous bureaucrat. The sponsor reads the first paragraph, does not find the answer and either asks for a call or, worse, stops reading.

If your project has a clear charter, the report has an easy job: it compares reality with the charter. If the charter is vague, the report will be vague too, because there is nothing to compare against. Garbage in, green out.

Who reads it, and what each reader needs

The same project usually needs two or three versions of the report, each for a different reader. This is where many reports fail: one document tries to satisfy everybody and ends up pleasing nobody.

• The sponsor wants the answer fast: are we on track for the date and the budget, what is the biggest risk and what do you need from me. One page, with the headline in the first three lines. This is the report most people mean when they say "status report."
• The team wants to know what is happening this week, who owns what and what is blocked. This one is better as a short weekly meeting or a board than as a document. A kanban board is a status report that updates itself.
• The client or the wider stakeholders want confidence and no surprises. A short monthly update, written in their language, with dates they can plan around. Your communication plan should say who gets which version and how often.

Start with the sponsor's version. It is the hardest to write well and the most useful to have. If you can explain the project to the person who owns the money in two minutes, you understand your project.

The seven parts of a one-page report

After years of writing and reading these, I have settled on seven parts. Together they fit on a single page, even a short one.

1. The headline. One sentence that gives the overall status and the date it applies to. "Amber: the opening date holds if the permit arrives by November 20." It is the only sentence some readers will read, so write it for them.
2. Status by dimension. Schedule, budget, scope and risk, each with a color and a one-line reason. Four lines in total. This is where the watermelon gets cut open on purpose.
3. What was done. The milestones reached since the last report, in plain sentences with dates. Results, not activity: "Permit application submitted and accepted" beats "worked on permits."
4. What is next. The two or three things that will happen before the next report, each with an owner and a date.
5. The top risks and issues. Three, not thirty. A risk is something that might happen, an issue is something that already has. Each has an owner and a next step. The full list lives in your risk register, and the report shows only what the reader needs to see.
6. Decisions and help needed. The most valuable box on the page. Each item says what you need, from whom, by when and what happens if it does not come.
7. Numbers that matter. A few, no more: percent complete against plan, money spent and committed against the budget, and the forecast to finish. If you track earned value, the schedule and cost indexes go here. If you do not, plain actual-versus-plan is fine.

Give the colors a definition

The red-amber-green scheme is the most popular tool in project reporting and also the most abused. The colors are not the problem. The problem is that every author uses a private definition, and the reader cannot tell whether amber means "a small wobble" or "I am scared."

The cure is to define the colors in numbers, write the definition once at the top of the report template and apply it mechanically. A definition for a small project might read like this.

• Green. The forecast finish and the forecast cost are inside the plan, and no risk needs help from outside the project.
• Amber. The forecast is slipping, by up to ten percent on time or cost, but the project manager has a plan to recover it, and no decision is needed yet. Or a risk needs a decision within the next two weeks.
• Red. The forecast misses the date or the budget by more than ten percent, or a decision is needed now that the project manager cannot make. The report must say what is needed.

Your thresholds may differ. The point is that they are written, agreed with the sponsor and the same every week. Then two things happen. Authors stop arguing with themselves about the color, because the rule decides. And readers learn to trust it, since an amber on Monday means the same as an amber in March.

Add a trend arrow if you like: better, same or worse than last report. A project that was amber for six weeks and just turned green deserves a different reaction from one that has been green for six weeks and just turned amber. Many sponsors say the trend tells them more than the color.

Why people lie in green, and how to make it safe not to

Let us be fair to the authors of watermelon reports. In many organizations the green report is rewarded and the red one is punished. Nobody says so, but everybody watches what happens to the person who reports the first red. So people wait. They hope. They tell themselves that next week will be better and that red will not be necessary. Then the project turns out to be more broken than anyone knew, and the delay in saying so is the thing the sponsor remembers.

If you are the sponsor, the fix is yours. Thank the first person who brings you bad news early, loudly and with a plan. Ask "what do you need from me?" before you ask "whose fault is it?" If you are the project manager, make early red part of the agreement from the start, ideally in the charter: "I will report red as soon as the rule says so, and I will bring a proposal with it." A culture that rewards early warnings is worth more than any template. I wrote about keeping the sponsor close in how to keep your executive sponsor engaged.

Write it so it can be skimmed, acted on and checked

The template matters less than the writing. A few habits separate reports people read from reports people file.

• Lead with the answer. Do not build up to it. The headline comes first, the story second.
• Use dates and numbers. "Soon" is not a date. "Good progress" is not a number. "Permit expected November 20, ten days after the submission" is both.
• Name owners. Every action, risk and decision has a person next to it. A line without a name is a wish.
• Say what changed. The reader who sees the same list every week stops reading. Mark what is new, what moved and what closed.
• Keep the same format every time. Readers learn where to look. When the shape changes, they have to read everything again.
• Compare with the plan. A number with no baseline is trivia. "Spent $82,000" means nothing; "spent $82,000 of $280,000, against a plan of $90,000 at this point" tells a story.

The hall of fame of status report phrases

Every project manager has a favorite phrase from the dark side. A few that turn up in reports everywhere, lightly exaggerated for your enjoyment:

• "On track." The most overworked words in the profession. On track to what? By what measure? Replace with a date and a number.
• "Ongoing." Used for tasks that have no end, no owner and no result. If it is ongoing, ask what "done" looks like.
• "We are monitoring the situation." Translation: we have seen the problem and we have not decided what to do. Replace with the decision and its deadline.
• "Challenges." A polite word for problems. Call them issues, give each one an owner and a next step.
• "Some delays." How many days? Which milestone? What is the new date?
• "TBD." To be determined by whom, and by when? A TBD without a date is a permanent resident.

If you find these in your own reports, do not feel bad. Everyone has written them, usually at 5:45 on a Friday. The trick is to catch them and replace each one with a fact.

A bad report and a good one

Here is the same fictional project written two ways. The project is an illustrative second location for a small bakery. The names and numbers are made up for teaching.

The weak version. "Status: Green. Good progress this week. The team is working on the build-out and the equipment order. Some challenges with the permit, but we are monitoring the situation. Budget is on track. Next week we will continue working on the items above."

It sounds calm. It also contains no date, no number, no owner and no request. A sponsor reading it cannot tell whether the bakery will open on time, and cannot help even if they wanted to.

The strong version. "Amber. The December 1 opening holds only if the health permit is issued by November 20. The inspection is booked for November 12, two weeks later than planned because of the inspector's backlog. Schedule: amber, recoverable by working weekends on fit-out, cost about $3,200. Budget: green, $82,000 spent of $120,000 against a plan of $85,000. Done this week: ovens installed, display cases delivered. Next: inspection November 12 (owner: Maya), final cleaning November 25 (owner: Luis). Decision needed: approve up to $3,200 for weekend fit-out by November 5, or the opening moves to December 15."

Same project, same week. In ninety seconds the sponsor knows the problem, the cost of solving it, the deadline and the consequence of waiting. That is a status report doing its job.

The builder: write this week's report

Use the builder below to draft a report for a project of your own. The sample is the bakery. Change the fields, pick a status and read the page that appears. The tool warns you when something a sponsor would ask about is missing, such as a decision for an amber report. Copy the result into your email or document.

Interactive tool

The status report builder

Loading the tool…

How to produce the report in twenty minutes

The report should not be a project of its own. A rhythm that works for small teams, and scales up fairly well:

1. Friday, 10 minutes: collect. Ask each owner for three lines: what finished, what is next, what is blocked. Better still, pull it from the board or the task tool so nobody has to write anything twice.
2. Friday, 5 minutes: compare. Apply the color rules. If one dimension changes color, write the reason in one line. If you are surprised by the result, that is information.
3. Friday, 5 minutes: write. Start with the headline and the decision box. Then fill in the rest.
4. Before you send: read it as the sponsor. Do the first three lines answer the question? Is there anything on the page the sponsor cannot act on? Delete it.

For recurring numbers, automation helps. A spreadsheet that pulls the budget, a board that counts open tasks and an assistant that drafts the first version from your notes all save time, as long as a person reads the result before it goes out. I cover the AI side in AI assistants for project managers, and the weekly rhythm itself in the weekly review template in the toolkit.

Status report or dashboard?

They are cousins, not twins. A dashboard shows a few numbers continuously, so anyone can look at any time. A status report adds judgment: what the numbers mean, what the author is worried about and what is needed. A dashboard without a report makes people stare at charts. A report without any numbers is an opinion. The best setup is both, with the dashboard kept clean of vanity metrics and the report doing the explaining. Both rest on honest data, as I describe in data-driven project management.

Common mistakes

• Too long. Two pages are rarely read, six pages never. If a section does not change a decision, cut it or link to it.
• Too late. A report on Tuesday about last Wednesday describes history. Send it at the same time, every time.
• Activity instead of results. "Held 14 meetings" is a count of calendar entries.
• No baseline. Everything is "fine" until you compare it with something.
• Hiding the decision. The request is the point of the report. Put it where the eye lands.
• Changing the rules to change the color. If the thresholds move every time the number is bad, the colors are decoration.
• Reporting to a spreadsheet nobody opens. Check who actually reads it. Ask them once, kindly: "What do you do with this report?" The answer is often humbling and always useful.
• Never closing the loop. If the sponsor makes a decision from the report, say so in the next one: "Weekend fit-out approved, completed November 8." People send reports to people who respond.

What to do this week

Pick one project, whether it is a build-out, a software release or a family move. Write the three color rules in numbers and agree them with whoever reads your update. Draft one page with the seven parts, using the builder above. Send it at the same hour for four weeks in a row and ask the reader once what they would remove. You will probably find that the habit matters more than the format.

If you are in Utah and want a hand, see how I work in project management consulting in Salt Lake City. Pair it with a RACI chart so that every action in the report has a clear owner, and with a lessons-learned review at the end, where your old reports become a very honest diary of the project. If you want help setting up reporting for a project that is already running, or building a rhythm for a growing team, that is what I do with Project Focus, and you can describe your situation on the contact page. For the monthly roundup of new guides and templates, join the newsletter.

Which phrase in your reports would you most like to retire? Tell me in the comments.

More tools. The weekly review, the risk register and the decision log are free in the toolkit, and a dedicated status report template with weekly and monthly versions is scheduled in the publishing calendar.

Names, places and figures in the examples are invented for teaching. The thresholds are suggestions, so adapt them to your project and your contract.

Frequently asked questions

What should a project status report include?

A good one-page report has seven parts: a one-sentence headline with the overall status, status by dimension (schedule, budget, scope and risk), what was done, what is next with owners and dates, the top three risks and issues, the decisions or help needed, and a few numbers compared with the plan.

How often should I send a status report?

Weekly for the team and the sponsor on most small and medium projects, monthly for wider stakeholders and clients. What matters most is that the report goes out at the same time every time, so readers can rely on it.

What do red, amber and green mean in a status report?

Only what your team defines. A common rule is green when the forecast is inside the plan, amber when the forecast slips by up to about ten percent and there is a recovery plan, and red when the forecast misses by more or a decision is needed that the project manager cannot make. Write the rule in the report so the colors mean the same every week.

How long should a status report be?

One page. If a reader needs more detail, link to the risk register, the schedule or the dashboard. A report that takes longer to read than to write is serving its author, not its reader.

Join the conversation

Did this help? A quick reaction tells me what to write next.

Useful Made me smile Go deeper on this

Be the first to react.

Comments

Loading comments…

Leave a comment

NameEmail (required, never shown)

Which phrase in your reports would you most like to retire? Post comment

Your name and email create a small profile that shows you are a real person. The email is never shown. The first time, I send you a confirmation link, and every comment is reviewed before it appears. Please keep it respectful and leave links out.