Project Status Reports Everyone Can Understand

Creating basic highlight reports which clients and management can comprehend.

Letting people know how a project is coming along is obviously a key responsibility of any project manager. With so many methodologies to choose from these days, it becomes hard to determine which key pieces of information will be useful to those involved in the project. These methodologies often come with a tangled mass of cryptic terminology, often only recognizable to practitioners of the system (e.g. burn down chart, sprint backlog, concession, story points, etc).

Let’s say for instance your client is in the food transport business and is getting your company to build them an ERP application. Chances are they wont understand concepts from Agile or PRINCE2, and why should they, they are in a totally different industry.

The issue then becomes; what information do you present when creating a status report that will be useful to the broadest audience (e.g. client, senior management, non-technical user advocates, etc). The project information maintained internally for planning and day-to-day management is one thing, but what gets shown to non-technical stake-holders is something entirely different. Of course, the details going into progress reports will most likely be derived from the project tracking documentation (e.g. number of bugs held in the issue log, tasks remaining as shown by the project schedule, etc).

So what kind of information will a non-technical audience understand? The simple answer is percentages and bullet points in plain English (with no methodology specific jargon).

Here is an example of a Project Status Report (or Highlight Report as its known in PRINCE2). I send these to clients and senior management via email on a weekly basis (generally on Friday afternoon):

Hi Tom,

I wanted to provide you with a brief summary on how your project is progressing:

• Your project is currently 65% complete.
• 100% of all tasks in the design phase have been completed.
• 70% of the tasks in the coding phase are finished.
• The project management phase is 45% complete.
• The quality control phase is 10% complete so far.
• 35% of auxiliary tasks have been completed

Our bug log is currently tracking 3 unresolved bugs (1 of which is marked as high priority). The bug log also holds 3 feature additions pending approval.

We have just uploaded the latest work to our staging server for you to review (this can be viewed by following this link: http://www...).

The next thing we are planning to work on is the photo gallery component, we are aiming to have this completed by late next week (12/Dec).

We are still waiting to receive media release articles from your PR person. Without these, your site will launch and this section will be blank (or have to be hidden initially).

Let me know if you have any questions, I will be happy to answer them as best I can.

- LM

The email subject would be something like ‘RE: Blue Widgets, Project Status Report’.

The structure of the report is as follows:

Bullet points - the first bullet point is always a percentage saying how much of the overall project has been completed. The remaining bullet points give a percentage completion on the various phases of the project (you may have different naming conventions, but that’s OK). Will the client really analyze these figures closely and go “yeah, yeah, auxiliary tasks, 35% complete, awesome”? Probably not. So what’s the point of listing all these stats then? It’s more about the effect it will have, it will give people the feeling that you have your finger on the pulse of the project, that you know exactly where it’s at. This translates into confidence that the project is being managed in a predictable fashion.

Bug summary - a very brief run-down of where you are at with logged issues. You may want to include some information on how many bugs were closed this week, or how many feature additions are waiting approval. This demonstrates that you are dealing with the inevitable issues that will arise on the project in a systematic fashion. I should make a point regarding the discussion of bugs with clients; there are different levels of disclosure senior managers find acceptable. Personally, I like to be very open with this information, but I suggest you ask management about how much ‘bad stuff’ you are allowed to reveal to the clients.

What we’ve just done - a description of any major movement made on the project since the last update. This could be the addition of a new module, completion of a documented milestone, anything which says “we are really getting places now”.

What we are planning on doing next - this is pretty straight-forward, but is helpful because it gives the client (and management) a heads-up on what you are about to start working on. The client may suddenly say “we thought you were doing the billing module next?” or “we need to change that around, we prefer you work on... next”.

Any problems that occurred or may occur in the immediate future - this doesn’t necessarily have to be a gripe or panic zone, who knows, maybe your project is running 100% smoothly (unlikely, but you may be the first). This area can be used to give the client a polite nudge (e.g. “we need ... from you, or else this will happen”). Again, caution should be exercised about what ‘bad stuff’ senior management allows you to disclose to the client.

Also notice that the statements in the report are very brief, to the point, no longer then two sentences. This just comes down to being respectful of peoples time. Everyone in corporate life is very busy, no one wants to read long emails.



The format of the status report I have presented here is very basic. I wouldn’t suggest that Gnatt or Burn-down charts aren’t useful, just that the information contained within these or any other management tool needs to be converted to plain English before being given to clients.