This month, I’ve had cause to think rather a lot about reporting. And the one thing I keep coming back to is what an under-utilised resource it is. For something that has the potential to be so powerful, it is amazing to me how frequently it comes to be seen as an irritating admin overhead. It’s like owning a beautiful sportscar and seeing it as nothing more than something you need to get MOT’d. None of the beauty, none of the power. Just a tax disc with wheels.
So, consider the following a track day for your reports. Something to remind you why they’re so much fun to drive as you throw them into the next bend. I may have stretched this analogy too far. The point is, project reports are a genuinely powerful tool that we need to fall in love with again. So let’s do a few laps to remind ourselves how to get the most out of these gorgeous machines.
Lap one: It’s your report. Own it.
Stop seeing reports as something that is asked of you, and start viewing them as something you produce deliberately and with intent. The project report is your megaphone to the world outside your project (and, often, those inside the project who need to pay more attention!) Use your reports to highlight the things you want to highlight and as a vehicle for raising awareness and gathering support from your stakeholders. And then get it out there and make sure everyone is aware of the challenges and lining up to help you fix them.
Lap two: Be clear about who the report is for.
A lot of organisations require you to produce a regular report on your project, typically feeding it into the PMO. But what if that report just isn’t working for, say, your sponsor updates.
A report created by the PMO for the PMO may contain information that isn’t quite as relevant to the average project sponsor (e.g. information that feeds into a portfolio report: project lifecycle stage, project type, portfolio dependencies, etc.) This is all well and good, but might reduce the report’s impact when speaking to the project sponsor. Is there a way to make it more relevant to them? Could some of the fields be hidden to better highlight the information the sponsor wants to know about? Or, for a little extra effort, could you create a summary report to brief sponsor and stakeholders without going into minute detail each time?
It is also worth thinking about how different recipients like to receive their information. Perhaps what is required isn’t a “report” in the normal sense at all. An email each week with five key bullet points is still a report of sorts, but might be far more useful to the sponsor than getting copied in on the detailed report you send to the PMO.
It might even be that your weekly report is a phone call. Think about who is receiving the information and structure the information you present to them accordingly.
Some project managers seem practically allergic to giving anything a red or amber status.
Lap three: If you want someone to read it, make it readable.
Dense blocks of text? Diagrams that require a degree in geometry to decipher? Get rid of them.
Consider the difference between these two updates:
Progress this week:
This week we identified a new bug in the software and deployed our testing and development team to conduct a thorough analysis. The output of this analysis is expected next week at which point the anticipated impact will be advised. Initial drafts of the company-wide email communications have also been prepared and circulated for approval. Comms team awaiting response. Other than that the project is progressing well.
Compared with…
Progress this week:
- New bug identified. Analysis in progress. Impact TBC by end of next week.
- Response required: Draft comms circulated for approval. Please approve.
In terms of content, there is no difference between these two updates, but I know which one I’ll read (and respond to) each week.
Lap four: If you’re using RAG statuses, make them objective and be clear what they mean.
Used well, RAG (Red-Amber-Green) statuses are a fantastic shorthand that make zeroing in on the project issues quick and easy. But there must be agreement about what each status means. For the avoidance of doubt, I would be inclined to include it somewhere on the report, so anyone picking it up and reading it is clear what is indicated by a red, amber or green status.
Importantly, the RAG status you assign to an activity, risk, issue or other metric must not be subjective! The minute you start getting into conversations about whether an issue ‘feels’ like it’s a red, you are into dangerous territory. One person’s red is another one’s amber – what you judge to be an important risk might mean something completely different to me. What’s more, some project managers (for understandable, but still incorrect reasons) seem practically allergic to giving anything a red or amber status. They think that unless everything is green, they are somehow failing to manage the project properly. Nothing could be further from the truth. Good project management means highlighting issues early so that appropriate measures can be taken before it is too late. Flagging items as red or amber is not only the honest thing to do, but, frankly the only responsible thing to do.
One way to help with this, is to make the criteria for RAG reporting as objective as possible. I would suggest something along the lines of the following:
Green: This item is progressing as planned and within the agreed tolerances for delivery.
Amber: There is an issue/potential issue with this item. As a result we are forecasting that this item may exceed the agreed tolerances for delivery, and stakeholders should be aware. However, the project team is working to address the issue and bring the project back on track. No formal escalation at this stage.
Red: The is an issue with this item. Our assessment is that the issue is now beyond the capacity, authority or mandate of the project team to resolve without external assistance. This is a formal escalation and a request for help resolving the issue.
A report is at its most effective when it is being used to properly highlight the important stuff.
Lap five: If you don’t have anything to report, say so.
It is (to my mind) a cardinal sin on reports to have a big empty box and then ask the PM to fill it in. Projects are like life. Some weeks you’re really busy, other weeks it’s all a bit quiet. Having a big box that says ‘Progress’ is stressful to the PM each week as they grasp at thin air to find things to fill it. It also results in genuinely important information getting lost. A report is at its most effective when it is being used to properly highlight the important stuff. If there is no important stuff this week, don’t be afraid to say “All good this period, nothing to escalate”. That’s still reporting, folks.
What are your reporting cardinal sins and top tips? Let me know in the comments.
To receive these blogs, project management tips and video tutorials straight to your inbox click here to sign up to our newsletter.