Do you feel like no one reads your weekly status reports?
Does it take you the whole day to create it?
Stakeholders ignore valuable information and wonder why you did not ping them.
But you did. In the weekly status report.
But you can change that.
There are even several ways.
You can silently change and tweak the report to improve it. However, it may not alter the fact that no one reads the report.
I would suggest another approach.
Talk to stakeholders directly. Though there may also be impediments.
Here’s a real story by one of my colleagues.
“I do not know. We always do it this way”
The project was a long lasting one.
I took it over in the middle of the action from another manager.
They had a long history of developing processes and documents here.
But I had a strange feeling that most of the artifacts they use are too robust for a small team like this.
For example, they had this weekly status report.
It was huge. A detailed description of the daily progress of the whole team. After that, there were risks, blockers, open questions, a long list of defects from the JIRA.
It took me the whole day to compile this report. Of course, I had to ask the team to help.
With a scarce amount of time our customer has, I doubt he has time even quickly to review this report.
Do we need this kind of report?
The answer was:
I do not know. We always do it this way. It is valuable for me, so keep on doing it.
That was a signal to test it.
In the next three reports somewhere in the middle I wrote: “No one reads this report anyway. I do not like this section, so I do not want to fill it out.”
This sentences did not stand out from the whole lot of other text. But if you even scan it, you will notice that for sure.
In three weeks I checked again, how the status reports looked.
They are very informative, thank you very much!
Then, I pointed out those texts.
That is the way we agreed to simplify the report the next week.
Do not do it alone
I can write it in every article. As a project manager, you should do as l little as possible yourself.
Why?
Your job is to make decisions. To do that you need to have spare time to think and analyze.
Moreover, I can bet that there is always more on your plate than you can handle.
There is a set of project management tasks that you can not delegate. But collecting data for the weekly status report is not one of them.
Delegate it evenly between team members. Use templates to ensure that you can copy and paste their parts into the report.
Your primary responsibility is to analyze the data and inform stakeholders about required actions.
So, how does it look?
Contents of Project Weekly Status Report
An efficient weekly report consists of two parts:
- The report itself.
- The message of the email where you send the report.
What’s the catch?
State the main Call to Action in accompany note.
How does your email with status report look like?
That is a waste.
Your stakeholders do not have any incentive to open that attachment.
How about something like this:
Alternatively, this one for example:
My point is simple. Do not broadcast your report. Don’t assume that your stakeholders are waiting in anticipation for it to read.
If there is something important in that report state that upfront.
OK. What should go inside?
Task Management Report Template
The idea of this template is simple:
You report on tasks that were done this week and that are planned for the next week. You will find the details below.
Download Weekly Project Status Report Template
I suggest using this report template directly in the email.
Executive Summary
It is the most important part.
Here you need to summarize all the important information that you have in the rest of the report.
Treat it as if it is the only paragraph that people will read.
The truth is, it is the only paragraph they do read.
Do I need visuals here?
I like a visual representation of the project health. But I think they are more useful for daily gauging. If you use a collaboration tool that everyone uses it is better to have visual status there.
Do I need charts in this section?
No. Keep it as short as possible. You need to put the processed information here.
Where should defects go?
I suggest stating only the outstanding defects that stakeholders may see in the interim deliverables. Just to control their expectations. Do it in the executive summary.
The weekly status report is not the place for defects report. So, either have a separate report for that or describe all the known defects in a release note related to the deliverable.
What was done
It seems like an easy task. You can copy entries from task tracker and just put them here. Add percent done if needed.
That is not something that can help stakeholders. They do not really want to control your progress as well.
Most of all they are interested to find out that the team works on the right tasks and towards the required goals.
How can you do that?
The best way is to use Work Breakdown Structure Elements. You do have a WBS on your project, don’t you?
Depending on the required level of details you can put it this way:
Deliverable 1
– Work Package 1
– Task
– Task
– Task
Or roll it up to work package level:
Deliverable 1
– Work Package 1 (70% done)
Or
Deliverable 4
– Work Package 4 (3 days left)
– Work Package 5 (2 days left)
The main point here?
You need to use the same pieces of work in the reports as you used during planning. Naming should be consistent.
How should I state progress?
- In percents. 25% done.
- In the remaining calendar days or man-days.
- Complex progress report:
Estimated: 10, Used: 7, Remaining; 5
It reads in the following way. The initial estimate was 10 man-days, we have used 7 man-days, and we need 5 man-days more.
It may mean that the estimate was inaccurate or additional tasks were added. That is why you need to clarify the reasons.
There is a problem:
This information alone does not answer the main question.
Can we finish the project on-time and within budget?
Milestone chart
When you create a weekly status report, you need to check whether you can keep up to your commitments.
If you plan your project well, a small variation of scope, costs or time should not impact your deadlines. Therefore, a milestone chart will stay the same for the duration of a project.
Usually, it is enough for stakeholders to see the same dates in the report. By this, you reconfirm your commitment.
Milestone chart can be as simple as a list of dates:
Alpha build – June 23
PayPal Enabled – July 6
Membership Area – July 24
Ready for Launch – August 3
Likewise, it can be a visual chart like this one:
What you plan to do
The same goes for the plans for the next week.
You need to state what you are going to do following the initial plan. If you cannot keep to the plan – it is the place to report that.
Again it is best to keep to the WBS elements.
It makes weekly status report consistent when you see that planned entries go to the Done section in the next report.
Also, it saves lots of time as you can copy most of the entries from one section to another.
Risks
This section should include imminent risks. The ones that stakeholders should be aware of and can take action right now.
I do not recommend to put all the related information on the risks here. It is better to keep the report shorter and give links and references to the Risk Register.
Blockers
This section is dedicated to the imminent impediments that will block the project team’s work.
Why is it separate from the risks?
Because these are facts. Events that will happen with 100% certainty.
It might not be useful for all projects so you can consider combining it with the risk section. However, it is a must-have for small projects. You cannot change the schedule to workaround risks too often.
Conclusion
Weekly status reports are your primary tool to manage stakeholders’ expectations.
Your first priority is to make it useful. This report should enable decision making not analysis or discussions. Therefore, develop a report template that will work.
Keep it simple and delegate its creation to the others.
Leave a Reply