The room was purple. Vincent Van Gogh’s “Bedroom in Arles” is one of the most famous paintings ever made. (Technically, it’s a series of three almost identical paintings. Van Gogh really liked that bedroom.) You’ve seen it. It’s been reproduced in countless prints, postcards, T-shirts and handbags. It’s been displayed in some of the world’s most iconic museums. For a while you could rent a Chicago bedroom decorated exactly like it for $10/ night on Airbnb…seriously.

One of the most memorable features of the painting — particularly the versions at the Van Gogh Museum in Amsterdam and the Art Institute of Chicago — are the sky blue walls. They’re blue on the prints, the postcards, the T-shirts, the handbags and Airbnb. And why not? They’re blue when you look at them in the museum. Your eyes see blue, your brain interprets and remembers blue. They’re blue.

But they weren’t. The room wasn’t blue. It was purple — “a pale violet,” as described by Van Gogh in an 1888 letter to his brother Theo. Van Gogh didn’t get it wrong. He painted a purple bedroom. But it’s not visually accurate now.

What does this have to do with data visualization and project management? Frankly, a lot. And it all comes down to this: You don’t want to make the same mistake that Vincent Van Gogh made.

Van Gogh really wanted to show a purple bedroom, but his medium failed him. As Art Institute conservation scientists recently discovered, the 19th-century pigments he used changed as they were exposed to light. A tiny flake of paint removed from the canvas appeared blue under a microscope on the outward-facing side, and the original purple on the inward-facing side. Turns out, he’d mixed blue and pink pigments to make purple; but the fragile pink, made from the bodies of insects, couldn’t stand the test of time. It faded, and the blue remained.

The tools Van Gogh used had no way to ensure the integrity of the data he wanted to present. He had the best intentions, but his paint couldn’t keep up. The truth became blurred — and blue.

For “Bedroom in Arles,” it’s no big deal. The tool failed, and the walls are now blue. An inaccuracy, sure, but a minor one. For a project manager or other professional trying to convey information visually, however, any difference between the source data and the final representation can have dire consequences. Read on to learn why — and how to choose a tool that can help you avoid the problem.

Why Data-Driven Matters

If you’re reading this, it’s all but certain that you understand how valuable data visualization can be in plan communications. Project managers and schedulers spend the majority of their time building and maintaining a document (or series of documents) in an application built for that purpose. This often becomes a mountain of data. Inevitably those same project managers will need to show a timeline to executives. Are they going to open up their project files and guide their leadership through each individual cell? Of course not! Management doesn’t look at the details in the project management app on a daily basis, and probably won’t be able to follow what you’re saying. Eyes will glaze over, and the message will be lost.

By contrast, a summary timeline or Gantt chart is universally understood, at least when it’s put together well. Anybody with any experience working on long-term projects can grasp the concept of a task lasting the length of a bar on a timeline, with overlapping bars happening concurrently. It’s left to right, just like we English speakers read, and the end point is obvious. So long as the chart isn’t overly complicated, it’s all pretty simple.

Can your CEO better understand this…

…or this?

Accuracy

But there’s an inherent issue when it comes to this kind of visualization. Traditionally, it doesn’t happen automatically. There’s something between your source data (usually in Project, Primavera P6, Planisware, Excel or another cell-based tool) and the final graphic. It’s Van Gogh’s pigment — if it allows the data to change in the finished product, the finished product is inaccurate.

That’s a big deal in the world of project management. If you’re showing anyone inaccurate information, you, your team and your business are all operating off of false data, which can and will wreak havoc. Interim targets where parallel work must be delivered simultaneously or the overall completion date of the entire initiative could be compromised. Budgets could be blown. And it is very likely that you, personally, will be held accountable — forever labeled as someone who can’t get the job done.

Credibility

This is also true when you’re first mapping out and building a plan vs. simply reporting what is already in flight. Early on, it’s often necessary to whiteboard your plan at a high level, and a manually created visual is generally the starting point. But without building in dependencies (at a minimum) in some systematic way, your plan isn’t credible. It’s just a cartoon — shapes on a page. Getting data across in an understandable way is great, but only if it’s the real data; a pretty chart that’s inaccurate has value only in being pretty.

This is an especially big problem when project managers, portfolio managers and scientists use rudimentary tools to create their Gantt charts. PowerPoint, in particular, is a major offender. A Gantt chart created in PowerPoint is little more than some boxes, lines, numbers and letters. There are no underlying rules, logic or integrations. One slip (unintentional or not) can dramatically change the time allotted to or taken by a particular task. A milestone can be moved with a bad copy/paste. An entire swimlane can be accidentally deleted or duplicated. There are no failsafes whatsoever; you’re just drawing. And as management and employees see the mistakes manifest themselves consistently, trust in your summary graphics is shot. After a while, nobody will pay attention.

Efficiency and Analysis

It is possible to create an accurate project timeline using drawing software. But only if you’re willing to spend hours upon hours creating the chart by hand, then checking, re-checking and triple-checking the data. Hope you don’t like weekends, because you’ll be spending them staring at your laptop.

The limitations of manual data visualization in planning can also limit the benefits to be gained by using visuals to look at the data. For example, a chart that orders your tasks in sequence top to bottom and left to right in terms of time has value — but what about grouping your tasks by team to ensure nobody is over-allocated? The latter has significant analytical value; but if you want to create that visual, you’ve just doubled the amount of time you’ll need to spend to create it.

As a result, many savvy project managers are turning to specialized software solutions designed specifically to turn project data into Gantt charts. Problem solved, right? Well, kind of. Many of these solutions have the same problem as PowerPoint — it’s possible to mistakenly or intentionally change the underlying data while you’re styling and customizing the finished product.

Fortunately, finding data-driven project visualization software is relatively simple, if you know the two hallmarks to look for.

Any software solution designed for project visualization runs on data. That’s a given. When it comes to being data-driven, however, there are two things that set the good ones apart from the glorified drawing tools: 1) How the application gets the source data; and 2) What it allows the user to do with the finished product.

When it comes to getting the data, everything comes down to how tight the integration is between the Gantt chart software and the source application. Ideally, it should be integrated directly with the core program. If that’s not possible, it should leverage only industry-standard tools like Excel as go-betweens to normalize data. (That is, data exported from the source program shouldn’t have to come out in a proprietary format; an XLSX or CSV file for Excel will be much more stable and easy to use.)

Either of these options creates a scenario wherein real project data is passed to the reporting application with minimal hurdles and failure points. If a change is made in the project plan itself, it’s easily shown in the timeline summary with little manual intervention and without rebuilding the entire chart. This stands in stark contrast to a scenario in which the user manually cuts and pastes from one application to another. If there’s no hook between systems — or if that hook is difficult to use — your Gantt chart can be made inaccurate before it’s even finished.

Best practices for visualization software integration

The reporting application should offer you the ability to apply customization in the visuals for the sake of clarification, while maintaining the integrity of the source file data. Think of it this way: Manipulating your activities and milestones into a different order doesn’t change the data, but it may add clarity to the audience for the information you’re asking them to absorb. A different perspective (order, grouping, coloring, etc.) of the same data may even provide a piece of information that otherwise wouldn’t have been present.

Adding color or changing the grouping of elements can deliver valuable information quickly.

Dragging or extending tasks horizontally should never be possible. That’s modifying the start and finish dates in the underlying data, and showing something completely different than what’s dictated by the project plan. The size and placement of a Gantt chart bar on the X axis are absolutely critical. If this can be modified in the timeline summary software, you’re at just as much risk as if you were using PowerPoint.

Tasks should never be moved horizontally by the visualization solution.

So, what should you be looking for in Gantt chart software? Ultimately, it’s pretty simple:

• Simple integration with the system of record, allowing for the easy transfer of accurate project data.
• An absolute lock on moving task bars horizontally. If they need to be expanded or moved, the change should be made in the underlying project data and merely reflected in the visual. The visual should never instigate such a change.

Putting It All Together

In this article, you’ve learned why it’s so critical that any visualization of your project plan or timeline needs to be true to the actual data. If it’s not, credibility suffers, and mixed messages can cause real problems for the team. You’ve also learned the hallmarks of the tools that place an emphasis on ensuring this kind of data accuracy. When you’re shopping for a project visualization solution, be sure to ask your vendor whether their tool is data-driven — or whether it will let that purple wall turn blue.

The original version of this article appeared as a whitepaper by Chronicle Graphics.

Image Source