Monthly Archives: September 2012

Best Practices for Project Reporting: Snapshots (Part 6/6)

Posted on by
Reply

Our sixth and final installment in this series will cover the importance of creating snapshots, or versioning, of your project reports. In short, as your project progresses, you need to make sure that your project reports remain up-to-date without losing sight of where the project has been in the past.

At the risk of sounding trite, managing a project is a lot like building a skyscraper. Every day, something new is going on: new floors are being poured, wiring is being installed, and many other jobs are starting and finishing.

If your project reports are out of sync with the actual status of your project, it’s analogous to taking a still photo of a three story building when it’s already 35 floors up. The picture doesn’t say anything about the 32 new floors you’ve poured, and it doesn’t mention that you had to lay a foundation and connect a bunch of pipes before putting in the first three floors in the photo. Projects aren’t static, so your reporting shouldn’t be either: project reports need to be able to look both forward and backward.

The time-lapse photos in this video show a new condo tower as it’s being built in downtown Denver. Each frame tells a story, and when put together, you can really get a feel for how the project is progressing.

Of course, you can’t make a time-lapse video of a server migration or a defense program—at least in the traditional sense. However, your project reports can adopt elements of the time-lapse video to help people understand the progression and status of your projects. These date-specific versions of your project plans are called snapshots.

Using snapshots in project reporting

The following two snapshots were created from the same Microsoft Project plan at two different points in time. In the first snapshot (February), notice that the Engineering Team 2 task is about 40% complete, and is on track relative to the baseline:

First project snapshot

Now, let’s move forward two months to see the project status in April instead of February. The task has made some progress, but the finish date is now several months past the baseline, indicating tha that it is behind schedule:

Second project snapshot

This is a simple example of how you can take two snapshots of the same project to give a view for how the project is changing, and where risks might need to be addressed.

Creating project snapshots successfully

Snapshots work best when you can maintain consistency from one version to the next. This makes it easier for your audience to see which elements of your project are changing, and to make comparisons from one snapshot to another. When creating snapshots of your project, keep the following tips in mind:

  • Filter forward: In order for snapshots to be successful, you need to look at the same set of tasks and milestones from one period to the next. When you create the first snapshot of your project, you should be thinking not only of what is important now, but what may be important down the line. Include all of this information in your initial project snapshot so that you can easily compare it as you create future snapshots.
  • Format consistently: Comparing the same set of data doesn’t do you any good if it’s presented inconsistently. When you create your first snapshot, think about how you want your report to look, and then maintain that format as you create future snapshots. Things like swimlanes, colors, and decorations are important to establish up front and then maintain throughout your series of snapshots.
  • Maintain frequency: Decide on a good frequency between snapshots. Weekly and monthly snapshots are the most common, but each project will vary as to the frequency that is most appropriate. Once you’ve determined the update frequency, be disciplined and stick with it, as users will come to expect updates, and may be thrown off by revisions that come too early or too late.

All three of these tips boil down to being consistent across snapshots. If you can maintain this consistency, you’ll have an easier time of communicating your project or program status to stakeholders, because you won’t have to take time re-training them to look at different views.

Snapshots create value

Snapshots are one of the most important aspects of good project presentations because they provide a lot of value to the project team.

Snapshots are a great way to facilitate project post-mortems. Instead of thumbing through piles of old schedules to understand when a project went off track, you can simply browse through a series of sequential snapshots to identify the elements of the project that need attention.

Scenario planning is also easier with snapshots. If you get to a point in your project where you need to make a decision, snapshots give you an easy way to visualize the outcome of each scenario. Once you have created the scenario in Microsoft Project, Excel, Primavera P6, or your PPM tool of choice, you can create snapshots side-by-side that show the projected outcomes. Difficult decisions can be easier to make when you can visualize the result.

Most importantly, snapshots are a time-saver. If you’re making updates to a PowerPoint-based project plan each week as your schedule changes, you are wasting a lot of time, and potentially introducing errors into your report. Snapshots are designed to quickly and accurately update the project report so that you don’t have to sanity check your schedule line-by-line or redraw your reports by hand each time the schedule changes. The time you’ll save by using snapshots adds up quickly—you’ll be surprised how much time you actually get back to do other things!

Wrapping Up

This post marks the end of our six-part series on best practices for project reporting. Hopefully, you’ll be able to incorporate a few of these suggestions into your team’s reports. All of the best practices mentioned in this series are supported by Chronicle Graphics’ OnePager Pro and OnePager Express reporting tools for Microsoft Project and Excel, respectively, though you are certainly not required to use OnePager to generate your project reports.

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

Posted on by
Reply

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!