Giant Guide to Project Reporting [How to do it well]

The regular rhythm of your project is ticked out by your project reporting cycle. Quarterly, monthly, fortnightly, or weekly… you’re there again. It’s time to produce your regular project report.

Project reporting is as much a part of project life as weekends and annual holidays form part of the fabric of our wider lives. They tick off passing time and are a core part of what we do. And, for some project managers, they are nothing but a chore.

But I don’t see project reporting as a chore. I have always seen it as a valuable opportunity to understand my project, communicate with my stakeholders, and access decision-makers.

So, in this giant guide, let’s see how to do project reporting well. I’ll show you how to design and build effective project reports.

Why do We Need Project Reports?
What’s the Point of them?

That’s a good question, and I’ll tell you why. If you are a good project manager, and you’re doing your job well, then you know everything that’s going on in your project. And, more than that, you’ll also be communicating regularly with all your stakeholders, so they’ll know it too.

So, checking off progress one more time, and then communicating status, could be a nugatory activity. But it isn’t. Good project reporting serves many purposes, and reviewing status and communication are only two of them.

• Reviewing status
  Can’t ignore it – your project report must certainly do this
• Communication
  Your report is a channel to get information to people who need it
• Governance: Oversight
  Now we’re into new territory. One of the prime functions of governance is oversight. And your report feeds the governance processes with the information they need, to oversee what you and your team are doing, and how you are doing it. This may be about everything from time-keeping to value-for-money, or from ethics to compliance.
• Governance: Record-keeping and audit trail
  If you are spending someone else’s money and hazarding their reputation, they will need a record of what you have done. Again, compliance demands an audit trail, but the wider governance imperative also needs some form of traceability and transparency of decisions and actions. Your reports can provide these.
• Governance: Decision-making
  For me, one of the biggest issues for governance and reporting is the need for sound decision-making. And one of the necessary conditions for a good decision is good information. And that’s what your project reports must provide.
• Fresh Eyes
  It’s easy to kid yourself that you know everything that is going on, and that you have a clear, unbiased perspective on your project. But a periodic reporting cycle compels you to look at your project with fresh eyes. It allows you to validate what you think you know or, more important, correct it. Project reporting needs to be driven by a cold analysis of hard data.

What are these Project Reports called?

You’ll find all sorts of names for project reports. The most common are:

• status report
• highlight report
• update report
• periodic report
• turnaround report

But they all share the same basic nature. They all:

1. Deliver a broad update on project status
2. Address the needs of a specific audience
3. Appear at a set time – usually on a regular cycle

Design your Project Report

Your project reporting process needs to serve one or more specific purposes. So, it pays to invest some time and effort into designing it to meet those needs. Start by asking some key questions.

Five Questions to Ask

1. Why are you producing it, and what does your report need to achieve?
2. Who is it for?
3. What information does it need to contain?
4. How can we best present that information?
5. When and how often do we need to produce the report?

With the answers to these questions, you can start to design both you project report format, and your project reporting process. So, let’s look at these in some more detail.

What does your Project Report need to Achieve?

Right at the top of this article, I suggested six reasons why you need a project report. It is helpful if you can avoid your report from serving too many different purposes. So think about priorities. What are the primary reasons for creating a report on your project, and which ones are secondary?

Who are your Potential Audiences?

There are three primary audiences you may want to address. Of these, the first is usually the one that will dominate your thinking when you design your report and reporting process.

1. Governance Tiers
   Your Sponsor, Project Board, and the organization’s top leadership.
2. Wider Stakeholders
   The people with an interest in what your project is doing, and where it is going.
3. Project Team Members
   The people who are doing the work, and need to understand the wider context of your project, beyond their own narrow focus.

What Information to Include

There will be two views on this:

1. What your audience wants
2. What you need them to know

Ultimately, the balance of information you present, and the depth of detail you choose, is your call; the Project Manager’s. Because, with all the reasons for crafting a project report, you bear the responsibility.

But, of course, you’d be barmy if you did not heed the views of the people who are, ultimately, your customers. Each of your three potential audiences has a reason to expect you to do so…

1. Governance Tiers
   Because they mark your homework.
2. Wider Stakeholders
   Because they will determine the success, or not, of your project.
3. Project Team Members
   Because if they don’t have the information they need, they can’t deliver their part of your project.

So, my tip is:

Here’s a list of what you should consider for inclusion in your regular project reports.

• Overall assessment
• Detailed analysis
• Resource utilization (people and others)
• Financial monitoring
• Progress against schedule
• Product delivery
• Quality data
• Changes
• Risks
• Issues and actions
• Upcoming milestones
• Anticipate questions… and answer them

The Need for Balance

Ultimately, your decision-makers, stakeholders, and team need good information, and enough information to do their job or play their role well. But they don’t want or need too much information.

In a world of information overload, a vital part of your job as a Project Manager is to select the information your readers will need. I like to bear in mind a question that medical consultants ask trainee doctors when they suggest tests for a patient…

If you get that information, how will it affect the decisions you make, or the actions you take?

I call this the ‘doctors’ rule’. If the information won’t affect either of these, how valuable is it? In particular, does its value exceed the cost of gathering and assimilating it? So, always ask: ‘What will you do with the knowledge?’

Stakeholder consultation on format and content

You may choose to impose your influence on what you tell your audience, but only they know best how they like to assimilate and understand your information. So consult your reporting stakeholders (governance, team, and wider stakeholders) on the style of the report they want, and how you will distribute it.

The main questions to ask are about the balance between

• Texty reporting – large amounts of text
• Data-heavy/light – how much raw data
• Picture / Graphics – large amounts of data visualization and images
• Use of online tools and dashboards

Primarily, your report needs to address the consumption style your users prefer. But be aware that you may get a range of views to accommodate. So, a good starting point is always to fit with culture of the organization, and then seek feedback on how to improve a prototype report.

Choose your Frequency

The last decision to make on the report itself – rather than your reporting process – is when to publish it. You are likely to go for a regular cycle, but do keep in mind that you can always vary the frequency as your project goes through its different stages. At some times, you’ll want a more frequent cycle, and at others, you will only need to report less often

You may wonder: ‘what is the alternative to a regular cycle?’

The answer is that some projects attach reports to key milestone dates. It’s a far less common approach, but it does have merit. And these milestones may be your gateway reviews. Certainly, your gateway process will need some form of formal reporting.

How to Produce a Regular Report

We’ve talked about your project report, so the next concern is to craft a project reporting process. Your objective will again be balance. In this case, you’ll want to balance:

• rigor and thoroughness
• efficiency and value for money

Can you Use Templates?

The use of templates is a great way to speed production – and also data collection. Don’t just think of a template for the output report, but also for your:

• data gathering request messages
• data input tables
• analysis process
• tabulating and graphing

Note that you can readily change your templates at different points during a longer project, to meet your varying needs.

You may also want to construct your own PowerPoint template. There are plenty of excellent resources on the web, and one I particularly like is Slideegg.

The Key to Good Analysis: A Bottom-up process

You know your project. So it is very tempting to start writing your project report with what you know are the key points, and then illustrate them with relevant data.

But that would be WRONG.

It’s a clear route to ‘confirmation bias’ and, believe me… that’s bad.

Confirmation bias is the tendency to most readily notice information that confirms your beliefs and conforms to your expectations. Conversely, we tend not to notice the odd fact or event that goes against our expectations. And, if we do, we tend not to pay it much attention, or give it a great deal of weight in our thinking. Yet it’s often that one rogue fact; that inconvenient oddity, that signals an important insight.

So always work from the bottom up:

1. get the raw data
2. compile it
3. analyze it
4. draw inferences
5. test them
6. if they stand up, write them up
7. summarise the data, and
8. highlight what’s most important

… and do it in that order.

Checking: Mark Anthony’s Law

In Shakespeare’s Julius Ceasar, Mark Anthony says:

The evil that men do lives on, the good is oft’ interred with their bones

Put more simply, and in a less poetic way:

Or, in terms of reporting, one silly numerical error can mean your readers fail to take an otherwise good and important report seriously. Oops. Think about:

• Re-reading after a day
• Getting someone else to proofread – who do you know who is especially persnickety?
• Re-checking every table and graph

End with your Executive Summary

The last part of your project report you prepare – never your first – should be your executive summary. discuss the key messages with your team, let them bubble away in your brain for an hour or more, then write down the one thing you audience absolutely must know, which the report is telling you.

Respect your Deadlines

If you deliver your report late, you not only undermine its value; you also say something about your project’s attitude and capability with regard to schedule. It may seem like an administrative extra, but your project reporting cycle is a bell weather for all your project process management.

Table your Report at a Meeting and Record the Responses

Good governance means you don’t only need to record your project status. You also need to record that the people who matter are fully aware of it. You need to be able to offer evidence that you have informed them. So, deliver your report and make it an agenda item at the relevant meeting. Then document in your meeting record that the report was tabled and discussed. Also, record key comments and decisions that resulted from the discussion.

Follow-up

If you take any communication seriously, you will always test how your audience has received it. I always like to speak with the people who are most important every few cycles, but now, finding out how your project report is landing with a wider cross-section of your audience has never been easier: Google Forms, SurveyMonkey, Typeform… User surveys are really easy.

Do you want to see the Project Reporting Process I used on a Successful 2½-year Multi-million Dollar Project?

This process is not ‘the right’ process. But it is a good process, from which you can learn a lot.

In this process, the day of report publication is Day 0.

Pre-Publication

• Day -8:
  The project Manager and reporting team discuss changes to standard report content and format, based on events since the last report, and forthcoming milestones.
• Day -7:
  Reporting team sends out request emails for reports from each workstream. These contain reminders of data proformas that we had already agreed with team leads, and also any specific requests for additional information.
• Days -6 to -4:
  Conversations with workstream leaders where the project report is likely to place special attention, or if they have a poor record in timely or accurate reporting
• Day -4 morning:
  Last reminder: 24 hours to the workstream reporting deadline
• Day -3 10:00 am:
  Deadline for receipt of information from workstreams
• Day -3 10:30 am:
  Phone calls to workstream leads whose reports are overdue, or clearly incomplete
• Days -3 & -2:
  The project team collates and starts the analysis of the data coming in. Project manager may task additional project team members to support, if the reporting lead requests them
• Day -1:
  Reporting team finalizes data analyses to prepare a draft report for review by the Project Manager.
• Day -1:
  The project Manager reviews the draft report and marks it up for corrections.
• Day -1:
  The project Manager and reporting team discuss key messages and insights that the report raises.
• Day -1:
  The project Manager retreats to quiet space to contemplate and draft a hard-hitting Executive Summary of no more than 200 Words.

Publication Day

• Day 0 morning:
  The project Manager takes Project Sponsor through the report. They discuss key findings, and Project Sponsor reviews the draft Executive Summary. After discussion, the Sponsor may make changes.
• Day 0 morning:
  Reporting team update report with final Executive Summary and any changes the Sponsor and PM have agreed.
• Day 0 early afternoon:
  The project team publishes the Project Report.
• Day 0 mid-afternoon:
  Most key stakeholders have read the Executive Summary, and comments are starting to come in, if it has been controversial!

Post-Publication

• Day 3:
  The Project Board meeting formally discusses the report. Its agenda combines standing items and one-off items driven by the content of the report.
• Day 4:
  The project Manager writes up and published a formal record of the Project Board meeting.

RAG Status Reporting

One way of summarising the status of any particular element of your project – or, indeed, your whole project – is a RAG, or ‘traffic light’  status. Here is a short video explaining more about this.

RAG Report, or Traffic Light Report. It is widely used by project managers and it stands for Red Amber Green. But what is a RAG Report?

Exception Reports

An exception report does not appear at a pre-determined time. It appears when something unexpected and exceptional has happened. So it’s a way of alerting people to it, and of seeking guidance, resources, or permission to act.

But note: if something serious has happened, your first response should not be to sit down and write a report. It should be to deal with the issue and to speak with the people you need to involve. Often an exception report formalizes the decisions and actions that you and your sponsor have already made.

An Exception Report has a Four-part Format

A project exception report needs to be short, sharp, and to the point. It will have four components.

1. What happened
   A summary of the incident that has triggered the exception
2. What it means
   The results of the incident; both what has already happened and what the future implications are. Where there is uncertainty, use scenarios, with an assessment of the likelihood and impact of each
3. Options
   Describe the choices you have, along with the costs, risks, and benefits of each
4. Recommendations
   Set out which option you recommend, and why you think this.

Formally, your exception report should have signatures from you, the Project Manager, and from the sponsor or other executive who has received it. You will also need to record what you do as a result, and the ultimate outcome. This could be part of your exception report, but is more commonly documented on the next scheduled status report.

Level-up Your Project Reporting with Our Templates and Checklists

OnlinePMCourses has exclusive sets of Project Management Templates and Project Management Checklists.

[one_half_first]

Among the checklists are:

• Status Reporting
• Reporting Process
• plus over 60 more…

[/one_half_first][one_half_last]

Among the templates are:

• Progress Report
• Exception Report
• Milestone Status Report

[/one_half_last]

Learn more about our Project Templates Kit, our Project Management Checklists, or the super-value Project Management Productivity Bundle with both kits at a reduced price.

Or try before you buy…

What is Your Experience of Project Reporting?

…and what questions or observations do you have about this article?

Please use the box below to comment, and we’ll respond to any contribution you make.