Monthly Archives: August 2012

Best Practices for Project Reporting: Decorating and Annotating (Part 4/6)

Posted on by
5

Our next installment in the best practices series focuses on how to decorate and annotate your project report. These types of decorations are probably not quite as fun or flashy as the ones you might put on a cake, but I can guarantee you that decorating project reports is healthier.

Unlike a cake, the decorations you include in a project report are intended to be more informative than they are decorative. There are many different graphical decorations and textual annotations that you might choose to include in your project report:

  • Progress (percent complete)
  • Baselines
  • Critical path
  • Relationships or dependencies
  • Deadlines or milestones
  • Key dates
  • Important comments

Depending on the nature of your project plan, you may find yourself making use of some decorations or annotations more than others, especially if you find that certain decorations resonate better or are requested more often by your audience.

As a result, this post will focus less on which decorations are appropriate, and more on how to optimize your annotation skills regardless of what your audience wants to see.

Use Graphics Instead of Text

Should you annotate your project report with text, or should you decorate it graphically? While you’ll probably do a little of both, we strongly recommend using more graphics than text whenever possible. This is because text will clutter your report, while graphics will not. Clutter is the enemy of simplicity, so if you want your audience to grasp the highlights of your project quickly, graphics are the way to go.

Not convinced? Take a look at the sample project report below. The presenter wants to track the start and finish date of each task, plus track each task’s progress. This can be done using text, but it borders on illegible:

Project report with text annotations

The text-based dates clutter up the page, and the percent complete information down the left-hand side doesn’t really add much. In fact, there is so much information being squeezed onto a single page that some of it is bleeding off the left and right edges.

Let’s replace the text-based annotations with graphical decorations instead. We’ll do the following:

  • Convert percent complete from text to progress bars
  • Remove the date text and insert a time grid instead

Project plan with graphical decorations

The result is much cleaner. By using graphical decorations, we’re presenting the same information without all the clutter. Granted, graphics make it more difficult to tell whether something is 49% or 51% complete, or whether a task starts on August 28th or 29th, but generally, this isn’t the level of detail you’re aiming to provide in a project report anyway, and the payoff in terms of readability is worth the slight loss of detail.

Call Attention with Comments and Curtains

Don’t let the disparagement of text-based annotations in the previous section turn you off text completely. The fact is that there are some elements of your project report where text—used sparingly—is the best answer.

Two annotations, comment boxes and curtains, are very powerful ways to draw your audience’s attention to tasks or periods of time that are critical to delivery.

Comment boxes give you the ability to call out a specific task or milestone with additional text that may not be stored in your project plan. It is a good way to indicate risk, call attention to an important item, or highlight a delay or acceleration in the schedule. Comment boxes are anchored to the task so that no matter where the box itself appears, it’s clear which task is being identified for discussion.

Curtains serve a similar purpose in that they draw your audience’s eye to a particular part of the schedule. Instead of focusing on a specific task or milestone, the curtain focuses on a period of time, such as a code freeze, quiet period, or budget cycle. Curtains should appear somewhat transparent on the page so as not to obscure the detail of the project plan itself.

The following chart shows two comment boxes and one curtain, which have been added to focus the discussion:

Comments and Curtains

These annotations call attention to the items that need discussion during a client or executive review. As with all annotations, use them sparingly. A project report with 23 comments isn’t going to lead to a very focused discussion.

The same holds true for curtains. We once had a customer who inserted a curtain across every weekend for six months saying “Not Working” because she wanted to make it clear that she wasn’t working on the weekends. I can’t blame her for trying, but it probably wasn’t the best message, because now she’s not working at all!

Use Links, but Fewer is Better

Links are the easiest way to show relationships or dependencies between different tasks, or even across different projects. Our eyes have a natural tendency to follow the path of an arrow from one place to another, so these types of graphics are a simple way to help the audience understand causality and other relationships that may otherwise be difficult to explain.

In this example, we’ve selected a few key dependencies from the project plan and have highlighted them in the project report. It’s very easy to see which items are dependent on others:

Project plan showing dependencies and relationships with links

It’s important to resist the temptation to show every predecessor or dependency. Just like you need to filter your project plan overall for the relevant tasks and milestones, you need to decide which dependencies are truly relevant to your audience.

The reason for this is that links can cause a lot of distraction as your audience’s eyes travel from one end of a link to another. Think back to how we showed percent complete as a column of text in the original chart. Associating the percent complete text column to the Gantt chart itself was disruptive because the eye had to move back and forth to connect the text to the graphics. The same basic principle holds true for links.

If you don’t want people’s eyes zooming all over the page while you’re trying to hold a meeting, keep the distractions to a minimum. This means figuring out which links to show, and which ones to leave out. Otherwise, you may end up with a mess like this:

Project plan with too many links

Do us all a favor: try to make your project presentations easier to follow than the Tokyo subway map!

Every project report is different, of course, but these pointers are broadly applicable, no matter what type of project or program you are managing. Remember to make use of graphics when you can and to keep it simple! Next up: standardization.

Best Practices for Project Reporting: Swimlanes (Part 3/6)

Posted on by
Reply

In this installment of our best practices series, we’ll visit the concept of a swimlane (or swim lane), and its importance in the realm of project reporting.

Swimlanes are not a new concept, but have been underutilized in project management. The swimlanes of yesteryear evolved out of business process modeling, where consultants would map out complex business processes and divide them into sections that were easier to comprehend.  Tools like Visio and CorelDRAW were a good way to create swimlane charts.

Today, Microsoft Project is the tool of choice for PMs, and PowerPoint is eclipsing Visio for all but the most detail-oriented types of business visualization. Neither supports swimlanes natively, though we certainly hear of people splicing swimlanes together by hand, if they’re not using a fit-for-purpose solution like our OnePager Pro tool, or a myriad of other options.

If you don’t use swimlanes in your project reporting today, try a quick exercise. Look at a map of the continental US (or your country of choosing) without any lines on it. Are you able to find your hometown accurately? Florida and Hawaii have it easy, but for those of us located in Denver, it’s much easier to find home when I can see the boundaries of Colorado.

How lines help you see where you are

Not a bad guess, I suppose, but Vernal, UT is some 300 miles and one full state from where I thought I was. The same holds true for swimlanes. It’s much easier for your audience to understand where to look on your chart when you’ve given them some sense of direction as to what is where. Consider how the first chart below without swimlanes compares to the second chart with swimlanes:

Without Swimlanes:

Project report without swimlanes

With Swimlanes:

Project report with swimlanes

Thanks to swimlanes, the second chart is much easier to read, because the audience is able to focus on one portion of the project plan at a time, instead of having to consume all of the details at once.

No matter how you choose to create your swimlanes, there are a few guiding principles that will make your reports and presentations easier to understand.

The Ideal Number of Swimlanes

If you read last week’s article on the use of color, you’ll recall that our brains are good at remembering 7 +/- 2 items. This is a good rule of thumb for the number of swimlanes you should have in your chart as well. The example chart above has six swimlanes, with a handful of tasks per swimlane, and it’s pretty easy to comprehend.

If you were to increase the number of swimlanes to 20, for example, each swimlane gets smaller, contains less information, and is harder to distinguish from everything else on the page. At this point, the swimlanes really aren’t doing you much good.

Having just a couple of swimlanes doesn’t really serve you well either, because you end up with too many items in a single swimlane. If you took the chart above and divided it into two swimlanes, each swimlane would contain quite a bit more information—potentially too much information for your audience to comprehend quickly.

Maintaining Consistency

Consistency is important when setting up your swimlanes as well. If you make recurring presentations, you want to ensure that you use the same swimlane layout from one week to the next. This helps your audience understand what they’re seeing without having to figure out a new layout each time.

The easiest way to maintain consistency is to always group your project into swimlanes by the same piece of data. For example, building your swimlanes by phase, client or sub-project are natural divisions of a report and are easy to comprehend. If you build swimlanes based on the same construct week after week, your reports will maintain the consistency that your audience demands.

However, not all swimlane groupings are created equal, even when they are used consistently. If you build swimlanes by something that is likely to change from one meeting to the next (e.g. status or resources), you may find tasks jumping all over the page from one swimlane to another. 

The example below shows the same project, grouped into swimlanes by status. You’ll notice that the “Build Billing” task (marked in red) moves from the top swimlane to the bottom as a result of a status change.

Consequences of inconsistent swimlane data

When tasks jump from one swimlane to the next, it can be a jolt to your audience, especially if they’re used to seeing things in a certain order. Because of this, we recommend against setting up your swimlanes based on dimensions of your project that are subject to change.

Data-driven Swimlanes are Best

When you create swimlanes for a project report, you may have the ability to do so dynamically based on your project plan (e.g. Microsoft Project), or you may choose to build swimlanes by hand. Ideally, your swimlanes should be based on data.

Data-driven swimlanes don’t take as much work to set up initially, and they are much easier to maintain going forward. If you get into the habit of building swimlanes manually, you’ll have to carve out time to adjust your swimlanes every time your project changes, which is not very efficient. Data-driven swimlanes are also more accurate, since they are based on the project data itself. Whenever you build swimlanes by hand, you run the risk of placing a task in the wrong place and embarrassing yourself when you make the presentation!

That’s it for this week. Feel free to let us know of other tips and tricks that we may have missed, as they relate to swimlanes. Next week, we’ll move onto installment #4, which will cover decorations and annotations.

Best Practices for Project Reporting: Color (Part 2/6)

Posted on by
Reply

In this second installment of our blog series on best practices in project reporting, we’ll cover the importance of color, and how it can best be used in your project charts. Most of us are already using color in project reporting without much thought today, but it does make sense to step back and understand how color should be used and why.

Color, more so than any element of your project report, can be used in a number of powerful ways:

  • Engage the audience: Your audience will more likely to pay attention to a colorful chart, especially if that chart is competing with other distractions (smartphone, chatter, etc.)
  • Distinguish important elements: Our brains (by way of the eyes) are very good at detecting differences in color, which means that colors are a good way to call attention to different groups of data in your project report.
  • Communicate psychologically: Different colors evoke different emotions and reactions. We’ll get into the science of color selection in a future post, but for now, it’s probably safe to assume that something painted bright red may have different implications than something painted cool blue.

Before we get into how color should be used, let’s take a look at an example of a project report without any color:

Gantt chart with no color

All in all, pretty boring. It doesn’t engage the audience, and you can’t really tell which elements of the chart are important. This is comparable to what you get out of the box in Microsoft Project and other PPM solutions, and is part of the reason for the negative sentiment around Gantt charts in general.

A splash of color would certainly help things along, but there is a right way and a wrong way to do it. When deciding how to color-code your project reports, there are three key rules to keep in mind:

  1. Selecting which dimension of your project is best for color-coding
  2. Ensuring that colors are easily distinguishable
  3. Maintaining consistency

Selecting a Dimension

If you want the colors in your project reports to be meaningful, you need to assign them in a meaningful way. This means that you need to select a dimension of your project to drive the color-coding. Common dimensions include status, phase, and resources, among others.

When selecting a dimension, you want to make sure that you do so in a way that doesn’t create too many colors on the page. For example, choosing to assign a different color for each individual task is a bad idea because your chart will end up with too many colors, which makes it very hard to distinguish what the colors actually mean:

Gantt chart with too many colors

As a rule of thumb, try to select a dimension of your project that will result in 5-7 distinct colors. This is a good rule for two reasons. First, cognitive psychology tells us that our brains can remember about seven items at once (plus or minus two). If you go too far above that, it’s not going to stick in people’s heads. Second, it’s easy to think of seven distinct colors (red, yellow, blue, green, orange, purple, black). Once you get beyond that, you get into weird shades (sky blue, teal, etc.) that are more difficult to tell apart.

In the example, below, we’ve color-coded our chart based on status. It’s much easier to get information from three colors than the 21 different colors above:

Gantt chart with an ideal number of colors

Using Distinguishable Colors

The second item to consider is whether or not the colors on your chart are easily distinguishable. Have you ever wondered why traffic signals use bright, vivid colors instead of pastels? The same holds true when you’re building a report or giving a presentation: the colors need to be easy to quickly tell apart.

Here is an example of the same status chart using pastel colors instead of the vivid colors from before. It’s much harder to read, because the colors are more difficult to distinguish:

Gantt chart using washed out colors

When selecting colors from a palette, make sure that there is enough variance between the different colors you select so that your audience can easily spot one from another. You can do this by selecting colors that are more saturated, or simply by avoiding too many colors from the same family.

Whiteboard markers serve as a good example for how projects should be presented.Both of the rules we’ve discussed so far are actually pretty easy to remember if you think about the whiteboard markers that are in your office or your conference room:

Unlike crayons, whiteboard markers don’t come in 64 different colors, and each color is very easy to distinguish from the next. The dry erase guys figured this out a long time ago (despite sniffing all those fumes), and it’s an easy principle to apply to project reporting.

Maintaining Consistency

The third rule is to make sure that you are using colors consistently across your different project reports and presentations. This is a pretty easy rule to follow, provided you build a good foundation with #1 and #2.

Your audience doesn’t want to have to learn a new color scheme each time they look at a different project report. So, if you decide to color code based on project status, stick with it, and make sure that the colors you use in one report correspond to the next. After all, it’s confusing when high-risk items show up as red one week and green the next.

Of course, you’re not locked down to only using a single color convention. Sometimes you need to color code by status, and sometimes you need to color code by resources. Just make sure that if you do change conventions that you make it clear to your audience so they don’t spend a lot of time trying to figure out which way is up.

What other best practices have you come up with when it comes to using color in your project reporting? We’d love to hear them. In the meantime, we’ll move onto our next topic in the series: swimlanes.

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

Posted on by
Reply

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.

Recommendation

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.