Exploring the Dos and Don’ts of Status Reports

Dos and don’ts for status reports

There are many types of communication that exist, but the most common and influential is the project status report. This may be in a written form, in a meeting, or via a slide deck, but the purpose and content should largely be the same across these formats. We’ll be using the written format because it is common and the easiest to work within a course, but the concepts are translatable to whichever format you or your company use.

First up, here’s a quick inventory of what items should be included in a status report:

• Executive summary: This is a high-level summary of the project's progress that is easy to digest and clearly states the trajectory of the project. The traffic-light status is included here, as well as the items contributing to the current traffic-light color the project is on.

• Project milestones: There are two schools of thought on milestones. They are either a list of predefined phases or steps that every project goes through, such as implementation, testing, deployment, launch, and post-launch, or are used as shorthand for the deliverables of the project. Using milestones as the former provides good metrics that can be used across all projects (such as how often a project’s deployment takes longer than expected) and distinguishes milestones from the feature deliverables.

• Feature deliverables: This is a list of deliverables, usually synonymous with the top-level tasks (also called epic tasks) in a task list. This lets the stakeholders know when to expect a specific feature or group of features and varies with every project.

• Open and recently resolved issues: This is a list of issues that are currently being tracked. These are separate from the known tasks and the known risks but will include realized risks as they are being dealt with. Having a separate table where resolved items are moved once a status report has shown them as resolved can help reduce the size of individual tables.

• Risk log: This is a log of the risks, as discussed earlier. If the number of risks is large, we could include just the high-risk items in the status report with a link to the full risk log.

• Contact information: In case of issues or concerns, a reader of the status needs to know who to contact.

• Project description: Not everyone that is a stakeholder may remember what the project is about, especially in large organizations and email distribution lists, so including a blurb on the project helps set the stage.

• A glossary of terms: This won’t make or break a status report, but if it is included, you'll receive praise. Tech companies are large, and the number of three-letter acronyms (TLAs) that are in use can quickly become daunting. Just as not everyone will know the project, not everyone knows all of the terms being used. Be kind and don’t assume.

Now that we know the basic elements that should go into a status report, here’s a list of things to consider that turn an okay status report into a great one:

• Every action must have an owner and date

• Define the traffic light and stick to it

• A non-green status must have a path to green

• Keep important details above the fold

• Format and grammar matter

Let’s go through each of these in detail.

Every action must have an owner and date

The number one rule for any status report is that for every action, an owner and date must be identified. This helps ensure the right people are accountable for actions and that the stakeholders know when to expect a resolution. This conveys that you, as the TPM, are in control of the situation and are proactively engaged in all issues.

In some cases, an action item may not have a date at the time of a status report; in these cases, a date should still be supplied as a date for a date (DFD), or a date that indicates when another date will be decided. This lets people know when to expect a concrete plan of action.

Define the traffic light and stick to it

A traffic light, in this case, is the convention of using red, yellow, and green to denote different conditions of a project. It’s easy to understand because the meaning of an actual traffic light closely matches how it is used in project management. That being said, every company is different, and even within a company, the thoughts behind how each should be used can be different. With different cultures as well as people originally from different companies involved, preconceived notions can cause confusion. For this reason, its best to define our usage of the traffic light status to make it clear why a project is a particular status. Let’s look at the definition of each color we'll use.

Green