What, when, where, why & how?

Ok, let’s get the basics out of the way first…

What is status?

Status refers to the state of something: in this case, our project.

Our project can be going awesomely well, it can be going absolutely disastrously, or might be anywhere on the spectrum in between.

Elements of the project will each have their own status as well, although these might be independent of each other.

For example, we could be doing great on time (ahead of schedule) and terribly on cost (over budget).

We can also break status down to the task level (for example, Task A is complete, and Task B is yet to start).

When do we report status?

Although we usually think of status as being reported formally, and might even have a status reporting template, it is also reported informally in almost every project conversation we have.

For that reason, every project team member should be intuitively across the status of their own tasks, as well as any interdependent tasks that may affect them.

Similarly, a project manager should have access to all this information on demand, enabling them to report relevant project-level status to interested and entitled stakeholders.

Where do we report status?

The most common forum for status reporting is the (usually monthly) sponsor or steering committee meeting.

This is where we submit our report, discuss status, risks, and issues, and seek approval for any necessary changes to the project plan.

We also report status at (weekly) team meetings or the daily stand-up (also known as the scrum, in agile project management).

External stakeholders might also be kept abreast of status through our informative communication media – newsletters, blogs, press releases, open days, etc.

The level of detail will obviously vary depending on the stakeholder we are reporting to – this is something else we will look at in this Unit.

Why do we report status?

Perhaps the better question is, what happens if we don’t report status?

In the absence of ‘official’ information, our stakeholders (especially our highly interested ones) will often draw their own conclusions about our project’s status.

Quite often, these conclusions are wrong.

Stakeholders who make erroneous assumptions about your project are either angry when you disappoint them, or – more often – angry until you set the record straight.

Angry stakeholders tend to consume a disproportionate amount of your time and effort, a situation you definitely want to avoid!

How do we report status?

In this Unit, we primarily look at the formal, written process for status reporting to internal stakeholders, such as your governance group.

That said, the lessons here are equally relevant to the informal and external reporting methods.

As with all things project management, you should scale your approach to fit your needs and stakeholder audience.

---

The default setting

Stakeholders will always need certain data from you to see the project’s overall health, performance against milestones, and the threat that project issues present.

At a high level, these data points might include:

• The project’s name
• The project’s overall health (or status)
• Earned value data (which we will cover shortly), including schedule and cost performance indices and forecasts to completion 
• Changes to the risk environment, and
• Issues or barriers to planned performance.

Your job is to report on the details of your project in concise, crisp bites that stakeholders can consume rapidly without spending much effort on. 

It might take you three hours to write your report, but always remember that your stakeholders do not have three hours to spend reading it!

Your reader realistically only has minutes to consume your status, as they may have 30, 40, 100, or more concerns for which they are responsible.

There is enormous value in a project manager who can report status without a detailed narrative. 

In addition to some of the report-writing tips we introduced back in the first Module, here are some suggestions:

• Write in bullets, not in prose – this is not the place for paragraphs.
• Reduce, reduce, and reduce some more. Do your best to shorten all expressions and sentences.
• Avoid ‘intensifiers’ (very, really, much) and adjectives (good, bad, ugly).

We advise developing and using a lean status reporting template… like the one provided here!