Status report — A practical model and example

Status report is a very powerful tool used for many different subjects and intentions. This practical example brings a real scenario created by me few weeks ago and shows an approach to pass the message to people that matter.

The model is presented below, and all the sections are also described after it, showing what is the intention and why it makes sense to this scenario. It’s AVAILABLE HERE (english and portuguese) and is free to be used in your projects.

The model

Identification, project manager, objective and date

These four sections are very important to ensure everybody who opens your file know exactly about what project you are talking about.

• Client X — What is the company paying and interested in your project? It’s important to you and any other people inside your company to understand;
• Project Y — What’s the project name? It’s the identification to whoever may receive this file to understand its purpose;
• Project Manager — Who is responsible for this project? On all sides that matter to you. In this case just my company and client’s were important. You may add other suppliers as an instance;
• Objective — Your main goal. It’s important to keep focused. Since it’s a file accessible to everybody on the project, everybody must understand to what they are contributing and feel part of that;
• Date — it shows the period the file regards. Keep track of your status reports! This will allow you to know your progress and things you have already tried to do, and how they are going;

Status, logos and deadlines

• The overall status is an executive information and to where everyone will take a look. It’s a simple message showing how your project is going on. It’s not what you think is happening. You have to have numbers to set it. In this document we used 3 KPIs (explored below) and the rules are: if all of them are green, the overall is green. If at least one is yellow, the project is yellow. If anyone is red, the project is red;
• The logos (yours and your client’s) have an important message about the partnership responsible to conduct this project. It passes a subjective message showing to the whole team how the two companies are engaged to reach the same objective;
• The original deadline is the first planned date to finish the project according to the schedule;
• The replanned deadline is filled only if you had to replan your deadline for some reason. The reasons must be shown on the updates (explored below) when a replanning happens;

Risks, changes and dependencies

Whatever happen to risks and changes must be checked by you, as the project manager in charge, to understand if it will require any kind of replanning. It can affect your schedule, your costs, people involved, external resources, suppliers, etc;

• Risks is where you list everything that may affect your project and make something planned to change. It’s common to be something out of your control, so have a plan to each of them to deal with problems when something go wrong;
• Changes must be filled when something relevant arranged was changed for some reason. A decision was rethought? Make it loud;
• Dependencies section is used when you have tasks depending on someone else’s effort. It’s very important because if they are delayed, you will have to deal with the impact;

The example has a dependency with a strikethrough deadline. It’s meant to show that a planned deliver was not finished and was replanned.

There is also a dependency with a deadline painted red. It regards a task that must be performed by someone outside the original project’s team. It must have a person responsible and also the date when the deliverable will be available. If that task is delayed, the whole project can be delayed.

Updates

This section is the one which will have a high rate of information change from week to week. All of its content can be changed from one week to another. Here is where you list everything that happened, new people added, results of tests, deliveries from another suppliers, and etc. I also like to keep two sub sections: what was finished during the last week, and what will be done in the next.

Schedule

The schedule makes sense when you are dealing with a project with fixed scope, and also when not. You can use it to make things visible about the next important deliver, when talking about agile. You can show macro deliveries or show 100% of your whole planning process (as the example shows).

It lists macro tasks, and gives them colors:

• When green, it’s ready to be developed;
• If its orange, it depends on something external and can’t be started now;
• For red, it means it’s delayed for any reason;

It also shows the tasks planned to be delivered during the current week (orange painted on the first line of the table). It’s represented by the X on the respective cell. And at last has the percentage of each one of the tasks;

KPIs

The things you decide to measure during the project. For this one, people, scope and dates were the main things. The table shows the metric and the status for each of them. Whenever you have something different than green, you have to write a reason telling why it’s not going well. Do not forget to add the costs to this KPI section;