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.
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.
You’ll find all sorts of names for project reports. The most common are:
But they all share the same basic nature. They all:
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.
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.
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 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.
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.
There will be two views on this:
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…
So, my tip is:In your #Project Report, include what the primary recipients want plus anything else that you believe they need. Click To Tweet
Here’s a list of what you should consider for inclusion in your regular project reports.
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 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?’
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 report they want, and how you will distribute it.
The main questions to ask are around the balance between
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.
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
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.
We’ve talked about your project report, so the next concern is to craft a project reporting process. Your objective will again bebalance. In this case, you’ll want to balance:
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:
Note that you can readily change your templates at different points during a longer project, to meet your varying needs.
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:
… and do it in that order.
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:People remember your small mistakes, and forget all the good work that surrounds them Click To Tweet
Or, in terms of reporting, one silly numerical error can mean your readers fail to take an otherwise good and imprtant report seriously. Oops. Think about:
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.
If you deliver your report late, you not only undermine its value; you also say something about your project’s attitude and capability with regards to schedule. It may seem like an administrative extra, but your project reporting cycle is a bell-weather for all your project process management.
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.
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.
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.
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?
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.
A project exception report needs to be short, sharp, and to the point. It will have four components.
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.
Among the checklists are:
Among the templates are:
Or try before you buy…
…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.
Dr Mike Clayton is one of the most successful and in-demand project management trainers in the UK. He is author of 13 best-selling books, including four about project management. He is also a prolific blogger and contributor to ProjectManager.com and Project, the journal of the Association for Project Management. Between 1990 and 2002, Mike was a successful project manager, leading large project teams and delivering complex projects. In 2016, Mike launched OnlinePMCourses.
Please log in again. The login page will open in a new tab. After logging in you can close it and return to this page.