This week our PM intern asked me about the best way to write the project status reports. I like when interns ask me questions. I can spend one more working hour speaking about the question topic, work, clients, projects and the hard life of the project managers. If I am lucky I can get up to 7-8 questions per day, so I can be pretty busy with that hard work.
Ok, back to the topic. “Report” – that is one of the most important things in the life of project manager *serious face*. Developers even think that this is the only thing managers do. So, I explained to the intern, you should be thorough and never forget to send you weekly project report to the client. I also shared with him my template of the status report, that I developed over the years and that works for me best. Then I realized that it would be better to write a post about the status reports, so next time intern asks me this question I can just share this link with him and spend the rest of the hour talking about the hard life of the project manager.
Why do we need status reports?
The answer is obvious – to keep the customer/your boss/colleagues informed about the progress, issues and how they can help (no, reports are not for blaming or checking you!).
Usually you send tons of emails during the development process. No one reads all them. No one remembers all of them. So status report is a great place to accumulate all news/questions and also show progress. Status report keep you client calm and shows how great thing are going (or explains why they are not going well but how you are fighting the obstacles like a real hero).
*Tip for the introverts: Good status report can prevent people from calling you and asking stupid questions about the project.
What to do first
Before you can start making a report make sure:
- you read all emails in your inbox (you don’t want to look stupid if client already informed you about some changes and you do not mention that in report);
- Jira boards and diagrams are up to date
- backlog file is updated
- you asked the team if they feel that the end of world is coming
The report template
Now you are ready to create the report email. I am usually using formatted emails, not an attached files, but you can do both.
Do not forget to put a nice name to the email. Something like “Project name | Week [Iteration] number | Status report “ instead of “Report!!!”.
1 sentence summary of the project status. For the very busy clients.
Example: “Finalized app designs, payment integration demo build 2.17 published”
% done/ % budget spent
When you send the report you usually include several people in To and CC. Some of these people on the customer’s side are too busy to read your long report. So this section with the most important information should come first – how much you spent and how much done for that budget. One glance at the beginning of the report, you see green % numbers – project is OK. For me it appeared to be the best way to show the progress to the clients in 2 numbers.
% done – that is the % of the work done from the estimated backlog that you have today. Backlog can change, features can be added any time, so today you can have 50% done, tomorrow – 30%. But the budget increases too.
% budget spent – % of the budget you already used since the beginning of the development. It can change too, as the budget changes as we change the scope (God bless out t&m contracts!).
Simple project dashboard (yes, I have chosen a tiny, but successful one 🙂
Here you should provide very short overview of the next milestones and if you feel they can be reached on time.
Second demo build – Oct 1 – Done
Beta build – Nov 15 [green]
User testing start – Nov 22 [green]
What was planned vs done
Just copy the “Planned” section from the previous week here. And mark what was done. And what was not done. Almost nothing was done? That’s ok. It is the thing which usually happens. Here is the trick – add also “Was not planned, but done”. These are the usually the reasons why the planned list was not completed.
Next week plan
Mention what is planned for the next week. If there are any dependencies – point them out and add to the “Blockers/Issues” section.
If the tasks are assigned to someone on the client’s side it is great to add the (Name) for such tasks, so client see what should be done from their side to succeed with they plan.
That is the hourly report table, just the timesheet from Jira. It’s useful also to mention the total hours spent for the development since the project beginning and which hours were paid for (balance).
Do not forget to mention the blockers and issues. Especially if i it something you are waiting from the client’s side.
Mention the project risks and for each specify how probable it is and how harmful. Plus write what you are doing to prevent the risk. Mark it green if it is handled, red – it you can’t handle it now.
Rule 1: Report should fit 1 page in your file. If you want to add more information – write that in “Appendix”. People are not able to read long reports – you just increase the probability of receiving the call “Yes, I received your report… So how the things are going?”.
*If you are reading this you can come to my desk and I will give you a cookie.