OnePager is thrilled to announce we are a few weeks away from releasing our next beta version, 7.0.0. This new release will significantly upshift the reporting capabilities of OnePager, while making the user experience easier and the outputs more visually appealing to the consumers of OnePager charts. We are now looking for “a few good PMs” to beta test the release … more on that in a moment.Continue reading
Last October, we told you about the non-linear time axis feature of OnePager version 6.1. This new feature allows you to call out a portion of your timeline — making, say, the third quarter of 2019 wider than the second and fourth quarters, so the tasks and milestones from Q3 stand out. OnePager users had been asking for this feature for years, and have been enthusiastic about this new capability.Continue reading
Theoretically, we here at OnePager are experts on … OnePager. But, having been in the business of helping project managers present clear and eye-catching Gantt charts for many years, we have picked up a lot of tips and tricks along the way about the project and portfolio management (PPM) software that feeds data into OnePager.Continue reading
Something exciting is happening at OnePager: We are seeing tremendous growth in our user base. And, of course, we have you to thank for it.
From September 2016 to September 2017, we grew our user base by 20%. Then, from September 2017 to today, we grew by another 22%. That’s a total growth of 47% over the last two years!
Back in April, we asked for your help in lobbying Microsoft to complete the technology that allows OnePager to import data from Project Server and Project Online. We are pleased to say that with your help, we have succeeded in convincing Microsoft to change course.
Our petition has to date received 298 votes, making it the top vote-getter among the petitions posted for all editions of Microsoft Project (Project Server, Project Online, and Project Desktop). A number of OnePager users left comments alongside their signatures, telling Microsoft of the importance of OnePager to their business and the criticality of the needed fix. We can’t thank you enough for your help. There is no doubt that this unprecedented outpouring of support from our user community got Microsoft’s attention and elevated the priority of our request.
We are now pleased to announce that beginning with OnePager Pro version 5.3.11, OnePager will be able use the following custom fields to create timelines in Microsoft Project Server and Online. Previously, these fields were available only if Project was installed on the desktop.
- Flag1 – Flag20
- Text1 – Text30
- Number1 – Number10
- Date1 – Date20
- Start1 – Start10 (Start itself was always available)
- Finish1 – Finish10 (Finish itself was always available)
- Cost1 – Cost10
- Outline Code1 – Outline Code10
- The Project Summary Task (aka Task 0)
We will send a separate notification to everyone as soon as 5.3.11 is available for download, which should be very soon.
If you’re a frequent user of OnePager, many of these fields will look familiar. For instance, many users employ these fields to filter which tasks from their Project plans they want to display in OnePager — it’s how you turn a 1,000-line Project plan into a 25-line OnePager. The Text fields are also crucial, because they allow users to import custom data for use in OnePager’s conditional formatting feature. For instance, if I was collaborating with ABC Pharma and I wanted all tasks in the ABC Pharma workstream called out on my chart, I would put “ABC Pharma” in the Text30 field, then conditionally format all tasks with ABC Pharma in Text30 to be red.
Microsoft’s omission of these fields left a gaping hole in our usability that could only be worked around by installing Project on the user’s desktop — which, of course, defeats the purpose of using a cloud app like Project Server or Online in the first place. We are delighted that Microsoft listened to our customers and closed the gaps, which will make for a better user experience not only in OnePager but also in Project, and in other apps that integrate with Project.
We continue to work with Microsoft on a small number of fields that are still inaccessible to OnePager in Project Server/Online, including Baseline1 – Baseline10 (Baseline Start and Baseline Finish can be read), and Duration1 – Duration10 (likewise, Duration can be read). If you are having difficulty because of an inability to use these fields from Project Server/Online, please reach out to us at firstname.lastname@example.org and we will pass your concerns on to the appropriate Microsoft engineers.
Once again, we truly appreciate your support, and we hope you are as inspired as we are about what a few (hundred) good project managers can do! Please keep the feedback coming.
OnePager has been a proud Microsoft Partner for many years. We both build and integrate with Microsoft technology. So we are generally pretty pro-Microsoft. But in this case, we think Microsoft has messed up big time, and it will negatively impact thousands of our customers. That’s why we’re asking you to get involved.
To make a long story short, starting this year, it may no longer be possible to use OnePager to make graphics from Project Server 2016 without also doing a desktop installation of Microsoft Project Professional. That means our customers who want to pull project data directly into OnePager from Project Server or Project Online, without using Microsoft Project on the desktop, will be out of luck. If that bothers you, good — we discuss at the bottom of this post what to do about it. First, a little detail.
For the last two weeks, we’ve been exploring the ideas of data visualization expert Edward Tufte and applying them to project charts, aka Gantt charts. Two weeks ago I introduced Tufte’s theory of graphical excellence; last week, I discussed what Tufte has to say about project charts. This week, I’ll discuss what I have to say about Tufte.
He is, of course, a smart fellow, and has done project managers a tremendous service by coming up with an academic theory with applications to project graphics — the kind of task few of us have time to do (most days, I barely get through my e-mail). I think he’s absolutely right about maximizing data-ink and minimizing chart-junk. In other words, a good project chart has only the graphics it needs to tell the story of the project, and nothing else (no extraneous gridlines, colors, shading, etc.). He’s also a fan of horizontal swimlanes to organize project tasks visually, and so am I:
Where Tufte and I part company is on the value of simplicity. As we saw last week, one of Tufte’s principal objections to Gantt charts is that they are too simplistic. He really likes charts to show complexity — just think of the train schedule from last week’s post, or the project chart above (notice it’s just one of 8 panels meant to be mounted on somebody’s wall!).
Unlike Tufte, I happen to think simplicity of communication has an important role in project management. I’m sure many of the Japanese train engineers learned to make great use of that schedule, but to the uninitiated it is just a puzzling line drawing. Likewise, the chart above is beautiful to look at, but if I was the “Vice President/General Manager” of that company and someone put it in front of me, I would probably go ballistic.
“What’s the story here?” I would snap. “What’s ahead of schedule? What’s behind? What’s an overall percent-complete of this project that I can take to my manager?” Any of this sound familiar?
The point is, as I said last week, audience matters. In most cases, executives at large organizations only need and only want to see high-level details of a project:
Whereas individual contributors — engineers, scientists, testers, and so forth — need to see more detail, but probably only the detail that is relevant to their workstream:
Maybe somebody (besides you) should have to look at the whole gory plan, or maybe it should be trotted out in a quarterly meeting so people get a sense of, quite literally, the bigger picture. But the idea of visualizing the whole project plan for everyone at every meeting is, in my view, a waste of everyone’s time. It’s also a waste of your time, since there are software tools that make it easy to show different versions of your project plan to different audiences.
Another objection I have to Tufte’s theory, and its application to project charts, is that he seems to hate Gantt charts for their conformity. Gantt charts have, he said, “regressed to Microsoft mediocrity.” That could mean a lot of things, but one thing he says it means is that they all kind of look the same. They all have time along the top, and tasks/resources down the side.
Sure, but what’s the problem with that? The reality is, the average worker changes jobs 12 times in her career (and for millennials that number will probably be closer to 20). It is perfectly understandable that in many industries, project charts have an agreed-upon format. Otherwise, the new guy or gal doesn’t know what he or she is looking at. How’d you like to be a Japanese train engineer in your first day on the job, and get a chart like the one we saw last week? I would need to go find a secluded conference room to cry.
Like all theories, Tufte’s is imperfect, but better than what we had before (which as far as I can tell was nothing). He’s right that project charts should communicate clearly, without clutter; he’s wrong, in my view, that all project charts should be both complex and uniquely formatted. But that’s just my opinion. What is yours?
Last week, I gave an overview of Edward Tufte’s theory of graphical excellence: in short, that graphics should “give to the viewer the greatest number of ideas in the shortest time with the least ink in the smallest space.” We probably all agree that project charts should be graphically excellent — otherwise, they’re a pain to look at and a chore for stakeholders to understand. But what does Tufte have to say about graphical excellence as it applies to project charts in particular?
As it happens, Tufte has written extensively on his feelings about “project management graphics,” as he calls them, in a 161+-post thread on his website (linked at the bottom of this article). A few general principles can be distilled — we don’t agree with all of them (more on that next week), but they are nevertheless worth knowing about as a serious practitioner of project graphics.
- He hates most Gantt charts, aka project charts. About them, he writes, “The design of project charts appears to have regressed to Microsoft mediocrity: that is, nothing excellent and nothing completely useless.” Most project charts he sees on the Web are too simplistic, too spare, and too full of “chartjunk” (his term — see below). As an alternative, he recommends graphical timetables, such as this example below: the bullet train schedule in Japan, with time across the top and stations down the sides. I’m resisting the urge to editorialize here, since I will be critiquing Tufte next week. Until then, I present, without comment:
- If a Gantt chart must be created, he says, make it a wall chart, not a chart confined to a rectangle the size of your laptop screen or PowerPoint slide. “Computer screens are generally too small for an overview of big serious projects,” he writes. (We’ve debated the usefulness of wall charts on this blog: see a post agreeing with Tufte, and a dissent authored by yours truly.) At the heart of this argument is Tufte’s belief that project charts should convey complexity, not simplicity. He wants to see annotations, cost data, forward- and backward-looking schedule data, and so forth. That kind of detail just won’t fit on a screen, he says.
- At the same time, project charts must avoid chartjunk, or ink used not for the visual representation of data but rather the aesthetics of the chart. A big source of chartjunk is gridlines, which we talked about last week. Most project charts are better off with as few gridlines as possible, so the viewer can focus on the data rather than the grid.
Not all of the hundreds of posts on this project graphics thread were authored by Tufte. Dozens of project managers — and musicians, writers, and other people who care about project charts — have joined the thread (which started 13 years ago!) to weigh in on what makes project graphics excellent. A few ideas from the assembled commenters are worth highlighting:
- Swimlanes make project charts much easier to read. For example, if I have a project with resources Tom, Dick, and Harry, my chart could have three swimlanes, one for each of the tasks assigned to these three gents. See the example below.
- An alternative to cramming every piece of the schedule into one project chart (as Tufte advocates) is management by exception. Some project managers find it more effective to only emphasize tasks that are either behind schedule or over-budget. The project chart below does this — I made this in Microsoft Project and our own tool, OnePager Pro, by making tasks with the status “Late” 10 times taller than on-time tasks:
- Relatedly, audience matters. Some of your individual contributors probably do need to see every task of your 1,000-task project, but your executives certainly do not. Likewise, your engineers probably don’t need to see everything the marketing team is doing, and vice versa. Much frustration was expressed on the thread about walking the line between including enough detail for some audience members and avoiding excessive complexity for others. So the best tools for the job of creating project charts are those which can show a lot of detail to one audience and a high-level view to another.
So what do I make of all this, as someone who has looked at more project charts than I care to recall? I’ll turn a critical eye to Tufte and the other posters next week. In the meantime, here is a link to the full thread for you to read yourself.
In our line of work, we see a lot of project charts. We get them from customers, from potential customers, and yes, we make our own. Some look fantastic and tell stakeholders the story of a project. Others, unfortunately, fall short of their potential — unfortunate because million-dollar decisions can be made on the basis of these charts, and if they aren’t communicating effectively, those decisions may not be the right ones. Consider the infamous remark of General Stanley McChrystal when he saw the chart below on a PowerPoint slide: “When we understand that slide, we’ll have won the war.”
What makes an effective project chart? What makes a mediocre one? Of course there are many factors, but one of those most often overlooked is the chart-maker’s adherence to the theoretical principles of data visualization. Yes, they exist, and in this three-part series we’ll explore them.
Even though many project managers feel that making charts is a slapdash task, there really is both an art and a science to visualizing project data. A master of both the art and the science is Edward Tufte, Emeritus Professor of Political Science, Statistics, and Computer Science at Yale University, and exhibitor at the ET Modern gallery in Manhattan. Since 1983, Tufte has written six major books and dozens of articles in search of the principle of graphical excellence.
“Graphical excellence,” Tufte wrote, “is that which gives to the viewer the greatest number of ideas in the shortest time with the least ink in the smallest space.” Central to this principle is the concept of the data-ink ratio. Let’s say you have a 500 x 800 project chart, which means it has 400,000 pixels. Perhaps 320,000 pixels are related to the display of start dates, finish dates, baselines, percent complete, etc. — the actual project data you are trying to communicate to your audience in visual form. Another 80,000 pixels are related to borders, gridlines, background colors, legal disclaimers, and so-forth — stuff not related to your data, but that has to be there for your audience to look at your screen and say, “Oh, OK, it’s a chart.” That gives your chart a data-ink ratio of 0.8 (pretty good). A graphically excellent chart has the highest data-ink ratio possible.
Let’s look at an example. Below, we start with a chart that has a lot of gridlines. The chart is technically readable, but there are a lot of lines competing with the data for the viewer’s attention.
Notice, also, the repetition of the Category datum — it is used both as the row label and as the color in the legend. Sorting and color are two separate pieces of visual information, so there’s no reason they should be telling the viewer the exact same thing. Instead, in the revised version, we’ll remove the row labels (keeping the legend), while suppressing gridlines:
To the naked eye, this chart just “looks better.” But Tufte’s theory tells us there’s more to it than that. We’ve cut out non-data-related ink (also known as chartjunk), thereby increasing the data-ink ratio of the chart.
We don’t agree with Tufte on everything — in previous blog posts, we’ve clashed with him over whether legends are valuable, and over whether wall charts are useful project management tools. Nevertheless, Tufte is the undisputed giant in data visualization theory, and no good chart creator should be ignorant of his ideas.
Next week, we’ll explore what Tufte has to say about project charts, also known as Gantt charts, specifically. The following week, we’ll put on our critic hats and sketch out in a little more detail where we think Tufte is wrong. In the meantime, if you want to learn more about Tufte’s ideas on your own, here’s a link to his website.
As project managers gear up for the release of Project 2016, many are probably wondering whether their Project add-ins from the 2010 or 2013 editions will still work. As far as the OnePager Pro Gantt chart add-in is concerned, we have good news — it works!
Thousands of project managers have used OnePager Pro to turn their project plans into beautiful, easy-to-understand Gantt charts like the one below. The Gantt chart feature in Project itself is limited in its customizability, and Project Gantt charts cannot be versioned. By contrast, OnePager Gantt charts are fully customizable — you can change colors and fonts or sort tasks into swimlanes and rows, all based on the data in your plan — and you can create multiple “snapshots” of the same plan at different points in time.