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

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.

This entry was posted in Best Practices, Project Reporting and tagged , , by Safford. Bookmark the permalink.

About Safford

Safford is a versatile technology professional with a solid history of empowering emerging growth companies in a broad array of industries. His employment history includes energy industry consulting at Quorum Software, Senior Manager of Client Services and Technical Sales at telecom service aggregator GetConnected, and Vice President of Strategic Partner Management at electronic payment processor IP Commerce. Prior to his tenure as OnePager's COO, Safford was the company's Vice President of Marketing and Alliances. Safford holds a BA in Psychology and management from Rice University.

Leave a Reply

Your email address will not be published. Required fields are marked *