As TPMs, we are often asked to provide regular status reports on ongoing projects and programs. While sharing personal weekly summaries may avoid the need for formal status reports, there are differences between the two that different situations may call for. That said, one should not assume that a recurring status report is necessary for every project! Rather, think through the overall communication strategy for a project and consider if status reports make sense within that – they often do!

This post defines a best practice around status reporting, starting with first evaluating if status reports are a good fit for your situation before then sharing how to source the content and format your report. If you have already read this post and just want the status report template, here you go. I advise you read the post at least once though, as this template is lightweight for reasons explained in the post.

Step 1: Identify Your Audience

Before you get into thinking about what your status report will look like, you must first identify your audience; they are who this activity will serve, after all! It can be helpful to write this down in a list format where you group as desired. You should be able to see fellow members directly working on the project separate from senior leaders and see if the audience is cross-functional or not. What you tend to see is a mixture across levels and functions, which might lead you to realize that you have a broad audience with different goals. If this is the case, don’t panic! This is common and solvable.

Like any good product, it is important to do a small number of things well vs a large number of things less well. Think of your audience groupings like this: does one communication mechanism need to serve all audience members equally? The answer to this question – no – frames this activity. For example, why would direct working members need a high-level summary of the project they are working on via email? You likely have recurring meetings and dedicated working Slack/Teams channels with such members already, as they need to be up-to-date on the project in real-time. Therefore, it is normal to prioritize the groups identified in a stack ranking. It is OK to have a larger audience, but remember who is most important to serve!

Status reporting is usually to keep stakeholders – not active working group members – informed. Such stakeholders usually include senior leadership and multiple functions such as Design, Product, Marketing, Operations, Legal, and Engineering leaders. This is not to say this must be the case; this is just the common case. Regardless of your answer, be sure to do this exercise to clearly identify your audience, as the rest of the process documented here will work backwards from your answer.

Step 2: Layout your Overall Communication Strategy

Once you have your audience identified, you must consider your overall communication strategy to your audience. For example, are you doing Monthly Business Reviews (MBRs) with your leadership already? Many organizations have their own processes; understanding this entire communication strategy and overlaying your audience is important.

Do your primary audience members need another communication mechanism? It is OK if not; you can always add to your communication strategy later. More communication is different from effective communication, and what you want as a program owner is effective communication. In doing this exercise, any gaps that a recurring status report will fill within your overall communication strategy will be made clear and be used to frame the problem(s) that your status report will solve.

Step 3: Determine Your Medium and Frequency

Assuming you need a status report after the above exercises, you should determine your communication medium (such as email vs Slack/Teams) and frequency (such as weekly, fortnightly, or monthly). Not all status reports have the same needs here, so there is no “standard.” For example, a status report to leadership is often less frequent and more formal (typically email based), whereas a status report for working group members is often more frequent and less formal (often Slack based). Due to these differences, it is reasonable to have different answers for different audience members if needed.

If you are using email as the medium, you should setup an email distribution list (DL) to allow for users to subscribe and unsubscribe as needed.

Step 4: Source the Information for your Status Report

We are now getting to the “meat” of your status reporting, and this is where TPMs can easily start to get a bad reputation:

First things first: don’t be the polar bear. When you’re the polar bear, everything breaks down. Your peers avoid you (as seen in the meme). Your status report has high-overhead cost, leading to lower quality. You likely are copy & pasting words you didn’t write and may not understand, leading to a report that is written by multiple authors that is hard to read.

Wait – what if I already am the polar bear? How do I stop? If you are the polar bear, it is likely that you are asking for far too much detail for your status report. Review your results from Step 1 where you identified your audience. Is your audience senior leadership? As if so, detail is not what is required!

Remember: it is your job to produce the status report. Yes, this requires input from others, but this should involve minimal additional effort outside of your working norms. For example, if you have a recurring sync with your working group already, this meeting should give you the information you need for your report. If it doesn’t, address the discrepancy. This doesn’t mean that you write every word live in a meeting, but you should at least be getting the high-level updates, and more importantly, the net-new risks and changes discovered. You can then dive deeper outside of the meeting context to better understand the risk(s) and choose mitigation plans.

It is common to use a tool or set of tools here to help you. Be it Jira, Cloud Docs/Spreadsheets (Quip, Google, Microsoft Office, etc), Trello, SmartSheet, internal tools, or my current favorite – Airtable – you have lots of options at your disposal. Note that you shouldn’t need all of these tools; ideally, you only need one for project tracking, although it’s fine to draft and write your report in a separate tool like Google Docs.

The reason Airtable is my current favorite is its flexibility. I love Trello, but Airtable can do everything Trello can and more. I also love just having spreadsheets and having multiple filtered views on those spreadsheets, but Airtable can do this as well. Being able to produce multiple status reports that look very different for different audiences but using the same underlying data is very powerful and scalable. And for this reason, it is what I am currently using to track a project that spans 10+ teams and 100+ people.

Step 5: Produce the Status Report (Formatting)

I made this section last for a reason. I see so many people assuming they need a status report when no one asked for one, jumping straight to this step. On top of skipping the first four steps, many people assume that status reports should cover every detail about a project. This often leads to a large table with red/yellow/green breakouts of every component.

However, you should always work backwards from your audience and produce a report to best serve them. If your audience is other working group members that are deep in the weeds of a project, perhaps such a detailed table makes sense. However, if your audience is senior leadership (the norm for status reports), then such a table is likely not the best format to serve them. This becomes even more true if your audience reads the report on their phone with less screen real estate than on desktop; tables often require horizontal scrolling 🤢.

Instead, distill the overall status down to one answer and explain it at the top of any email. Include a target release date if applicable and the summary of what will be accomplished by this date. If your status is anything other than green or “on track,” you must include your path to green and you should expect a high amount of engagement on the report. Often an ask is involved in such a status report, and you should be comfortable being transparent about such an ask when required. However, status reports do not replace direct conversation with individuals as needed. For example, if a dependent team is unable to prioritize work needed for a project, it is OK to surface this as a blocker and the need to align on priorities. When surfacing these challenges, however, remember to do so with a blameless postmortem mindset!

If you would like to follow a lightweight template for status reporting, here you go.

Conclusion: Rules of Thumb

1. Work backwards from your intended audience, and this will determine your content, medium, frequency, and format.
2. Don’t assume a status report is necessary for every project; understand your overall communication strategy and how this serves different audience members at different times before adding another communication mechanism!
3. Remember to keep your status reports mobile friendly! Wide tables that require horizontal scrolling are not mobile friendly.

---

FAQ

If I am already sharing sharing personal weekly summaries, why would I write a status report as well?

It is common to be able to avoid doing both. In my past 4 years of work (perhaps longer, but I can’t remember 🧠), I have only needed supplemental status reports for a project once, and this project lasted about 6 months. But I share my weekly summaries publicly and quickly and directly escalate issues as they arise outside of it as needed.

The reason I needed a separate status report for this one project was it had too many moving parts and started to take away from other areas of my weekly summary. I did not duplicate effort during this time, and instead just mentioned the separate status report in my weekly summary for updates on that project.

---

Appendix: Good External Resources

These are other relevant articles I found after writing this post. I will update this in the future as I find more, so you may notice this change:

1. A Guide to Writing Status Reports – This ScarletInk post (that came out after mine 😉) is a good read that generally agrees with my post here.