Best of OnePager Blog – Formulas in Microsoft Project

We’ve recently had a significant uptick in readership and for that reason we’d like to begin sprinkling in some of, what might be considered, our best posts in organized groups.

This week we’re going to share previous posts that will help you automate population of Flag columns in Project through the use of formulas.  Your Flag columns are Custom Fields in Project, which means that you can write formulas to avoid manually combing through your data and putting a “yes” value where you need them.FormulasImage Continue reading

Best Practices for Project Reporting: Filtering (Part 1/6)

Here at Chronicle Graphics, we see thousands of project reports, presentations and timelines in a year’s time. Some look great and some leave a lot to be desired. From time to time, our customers ask us for best practices when it comes to reporting on projects and programs. This six-part series will walk you through what we have seen that works and doesn’t work when it comes to summarizing and presenting your project information.

The first segment in the series will focus on filtering. If you read Guy Kawasaki’s blog, you may be familiar with his 10/20/30 rule for PowerPoint. We take a similar approach to the appropriate level of detail with the following mantra:

Show enough detail so that your audience can connect the dots, but not so much that they lose focus.

So, what does this mean? First off, here are some things that it doesn’t mean:

  • Show every single line item of detail
  • Roll things up into a single, top-level project summary

Showing every single line item of detail is probably the biggest offense in project reporting, and it happens a lot because it’s very tempting. As project managers, we’re aware of how each detail contributes to overall delivery. Don’t get us wrong–details are important–but does your audience need to review every detail line by line? Hopefully not. After all, as a PM, that’s your job. Here is an example of a very busy project report that shows too much detail, and is hard to read:

Project report with too much information

The project above only has 70 line items, so you can imagine how cluttered and hard to read it would be if you did this for a 1,000-line project plan.

Overcorrecting to only a high-level summary isn’t particularly useful either, though for different reasons. In the example below, we’ve rolled the project plan up into just a phase-by-phase summary. It’s easy enough to understand the overall timeline, but as soon as someone asks why a particular date is where it is, your graphic isn’t going to be able to provide the supporting detail:

Project report without any detail
Achieving a good balance between hard-to-read and “information-lite” is more of an art than a science. It’s going to vary based on the nature of your project, and more importantly, what your audience wants to see. This may mean creating different views for different audiences, and that’s ok, as long as the underlying data is the same, and each audience gets what they need to see out of your report.


As a rule of thumb, we always recommend bringing in the summary tasks for your project. These give a high-level understanding of the project overall. From there, you’ll need to bring in a subset of the supporting tasks. The following four suggestions will help you decide which tasks should make the cut:

  1. Tasks that are on the critical path
  2. Tasks that will start soon, or have recently finished
  3. Tasks that are at risk of going over budget or being delayed
  4. Tasks that have changed since the last discussion

With this in mind, you should be able to start creating project reports that offer the appropriate level of detail to your audience without creating information overload, or information deficiency:

Project plan with appropriate level of detail

In our next post, we’ll discuss best practices for using color in your project reporting.