Best Practices for Project Reporting: Standardization (Part 5/6)

The fifth segment of our series covers the importance of standardization in project reporting. This can be a pretty daunting task, especially if everyone reports on projects in different ways, but it’s important to undertake.

Before we get into the details of standardizing project reporting, let’s depart for a moment to think about how standardization plays into the mundane world of business travel. Imagine you’re waiting for your flight at the airport when you find out that the flight crew has called in sick. There’s a perfectly healthy flight crew sitting the next gate over, but they’re an Airbus crew, and your flight is scheduled on a Boeing.

Airbus A340 at Denver International Airport

Go ahead and grab a drink at the airport lounge, because you’re going to be there a while. While you’re waiting, envision what happens when you finally do get to your destination and you pick up your rental car. Does it matter whether you rent a Toyota or a Dodge? Brand preferences aside, you’re capable of driving either car, so a last-minute switch won’t impact your plans like it did with the airplanes.

The difference in these two situations is standardization, and the same concept applies to project reporting. When you present multiple projects to executives or clients, you don’t want to spend time retraining the audience on how to interpret each report separately. You want a simple, standard report that you can explain once, and then apply across the board.

Why standards matter

Standard project reporting is important for two key reasons:

  1. Improved communication
  2. Time savings

Improved communication is fairly obvious: when you present consistently across different projects, it’s easier for your audience to understand what is going on, and to draw conclusions across projects. The time savings are important because a standard project view means that individual project managers aren’t spending several hours dreaming up their own custom formats for reporting. Instead, the format is already defined, and all they have to do is plug and play.

Take a look at this portfolio of projects with no standards whatsoever:

Project portfolio with no standards

Not only is it hard to compare one project to another, but each of these reports took the PM a few hours to create because they didn’t have a basis for what the report should look like.

Now, take a look at a standard set of project reports. These are the same four projects that are shown above, but have a set of standards applied:

Project portfolio with standards applied

These are much easier to understand because they follow a standard convention. Once you understand one report, you an understand them all. Furthermore, the PMs aren’t wasting time coming up with their own custom views—they’re following a set of guidelines that allow them to create a report and then get back to work.

Which report elements to standardize

Standardization is easier said than done, especially when you are trying to create a consistent reporting structure across scores of projects. Before you get too hung up on standardizing everything under the sun, remember that no two projects are alike. This means that no matter how strict your reporting standards are, the projects themselves are different, and the reports will be as well. This is ok.

No one expects you to grab the exact same 35 tasks across 17 different projects, or to show the same date range in all your reports if the start dates for each project are staggered across three years.  There are, however, lots of report elements that should be standardized, because they can be carried across projects without a lot of work. Here are some examples:

  • Swimlanes: If you go back to our earlier swimlane article, you know that it’s important to group and sort your project plan consistently. This holds true across your entire portfolio as well.
  • Colors: Our eyes easily pick up colorful cues in a project presentation. If you use a red color for risky items in one report, you should use red the same way in all reports.
  • Units of time: If you show fiscal years in one report, show fiscal years in all reports. This makes it easier to understand what is happening when.
  • Decorations: As soon as you show a baseline for one project, your executives will want to see it for all schedules. The same is true for percent complete, and critical path. Think about which decorations your reports really need and then be consistent from one project to the next.

Standardization doesn’t mean disruption

One of the concerns we often hear from PMs who are trying to standardize project reporting is the disruption that it may cause. Some people use Microsoft Project, others use Primavera P6, and still others still in Excel. Even within those three tools, no two project plans look the same.

If you standardize in an intelligent way, you won’t have to change your underlying tools or force people into using restrictive templates just for the sake of standardization.  This can be accomplished by standardizing your reports, not your data.  A good reporting tool will be able to import data from multiple sources, and in multiple formats, and then standardize the look and feel for you. This is done through intelligent templates and column mapping wizards that do the heavy lifting of standardization for you.

If you’re modifying your underlying data so that you can shoehorn it into a report, you’ve got the wrong reporting tool, and you’re wasting time.

The next post will be the final in this series, and will focus on versioning and historical tracking of project reports. After that, we’ll move onto a new topic entirely, so stay tuned!