Project management best practice: The report

Posted by Heather Villa, CMA, MBA, MSM on September 10, 2009 in: Project Management, Tools & Resources

When you’re putting together a project there will come a time when you need to file a report. But how do you do it… and how do you do it well?

I’m reminded of a story once where I worked on a project (as an employee who participated, not as the project manager). The project manager had to create a weekly report that estimated the time we spent on the project. They had each employee estimate the number of hours we worked on the project. Then they took those numbers and (fully admitted to us) padded the numbers to bring them in line with expectations (I guess we were too efficient or the project manager needed to justify their budget). It made me look at project management reporting with disdain so I’ve revised how I manage projects ever since.

It seems like in some of the projects I’ve worked, the reporting can take just as long as the project itself: You write a report then you print it and give it to everyone… and then you have to go into a room and read it for everyone because they didn’t read it. Then you field questions. (And somewhere in there, the project has to get done).

Project management reporting best practices

First, create a quick, one-page report that is visually appealing. A report that requires a small forest to be cut down so that everyone can stay up-to-date isn’t going to be read anyway. This might be necessary for an end-of-the-project report but an interim report doesn’t have to be very long. It’s funny, people might resist the idea of shorter reports in the interim but they will at least read them!

This one page report should be set up in the following way: At the top, using a nice visually appealing diagram like an overall fishbone diagram or Gantt chart or whatever you’re using as a primary tracker. Keep it small and neat and just an overview. Indicate where in the project you are and where you had hoped to be.

Below the diagram, list current milestones you’re working on and (if it’s not clear from the diagram) previous successful milestones (although this can get to be lengthy if you’re not careful).

Next, highlight a couple of successes that you’ve had and a couple of challenges that you’re working on. Don’t put in really redundant challenges. Instead, put in challenges that you could use some help and/or guidance on from the group to whom you’re reporting. (So, if you’re reporting to a bunch of Executive Vice Presidents, don’t write in that a challenge you’re facing is motivating your troops. That won’t look good on you. Instead, write in a challenge like some of the budget clawback has threatened the timeline).

If you want to really avoid any questions, maintain a blog or project management site (which will probably require a login and password) and invite people to read that if they want to stay informed. I’ve found that people won’t read it but will ask fewer questions because they don’t want to admit that they haven’t read it.

I don’t want to give the idea that this report is something you do to avoid doing the work of reporting. But I do want to make reporting a practical step in the project management process… and often it’s not.

Heather Recommends:

I love working with coaches, freelancers, and entrepreneurs to help them become more successful. If you'd like to improve your business, find out how I can help.

Product Spotlight


Business Lunch Club