About Nathan

Nathan Black was on the founding team of OnePager, joining as a beta tester in 2005. The product was exciting — the lack of paycheck, exciting in a different way. So he went out into the world, working as a project manager, management consultant, and academic (he was most recently a research fellow in the Government Department at Harvard University). Everywhere he went, he saw a need for more and better project management, particularly by people who don’t call themselves project managers but end up filling that role on teams and ventures large and small. In 2014, he returned to OnePager as Vice President of Solutions. His primary roles are (1) helping customers use OnePager more effectively and (2) developing new versions of the software. He is passionate about getting project visualization and reporting right, and eager to hear from project managers (in title or in reality) who feel the same way! Nathan lives in Kansas City, Missouri with his wife Whitney and sons Ethan and Adam. They enjoy classical music, the outdoors, and politics. E-mail him at [email protected]

OnePager issued patent for Smart Text Optimization

We’re excited to announce OnePager was issued its seventh U.S. patent today, for Smart Text Optimization, a new feature available in version 7.0.

Numerous users of pre-7.0 versions of OnePager told us that their initial charts were full of text collisions, which required manual repositioning of labels to make them suitable for presentations. We honed an algorithm that sequentially applies a series of strategies to avoid these collisions, seeking to produce the best-looking output with the minimum user effort.

Our users’ feedback helped us refine this new technology, so thank you! Let us know how you’re using Smart Text Optimization and what improvements remain to be made.

OnePager 7.0: Seeking Beta Testers

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

OnePager Issued Patent for Non-Linear Time Axis

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

Introducing tips on Primavera P6 and more

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

If OnePager is Catching On at Your Company, You’re Not Alone

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!

Continue reading

Thanks for Helping Us #FixProjectServer

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 [email protected] 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.

If You Use Microsoft Project Server or Project Online, You May Be in Trouble. Here’s What to Do.

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.

Continue reading

The Quest for Graphical Excellence: Part 3 of 3

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:

Tufte's sketch of a "project management interface," aka project chart. From http://www.edwardtufte.com/bboard/q-and-a-fetch-msg?msg_id=000076

Tufte’s sketch of a “project management interface,” aka project chart. The entire chart is 8 panels (shown in tiny insets at the top), and the first panel is blown up to show detail. From http://www.edwardtufte.com/bboard/q-and-a-fetch-msg?msg_id=000076

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:

Sample project chart for executives

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:

Sample project chart for the Engineering team

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?

The Quest for Graphical Excellence: Part 2 of 3

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:

Graphical timetable example from Edward Tufte

From Edward R. Tufte, Envisioning Information (Graphics Press, 1990), p. 45.

  • 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.

Project chart with swimlanes (made in OnePager Express)

  • 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:

Project chart with tall late tasks and short on-time tasks (created in OnePager Pro)

  • 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.

The Quest for Graphical Excellence: Part 1 of 3

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.”

NATO in Afghanistan PowerPoint slide

Winning the war in Afghanistan, in one PowerPoint slide. Yikes. (From Elizabeth Bumiller, “We Have Met the Enemy and He is PowerPoint,” The New York Times, April 26, 2010)

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.

Project chart with low data-ink ratio.

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:

Project chart with increased data-ink ratio.

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.