Display changes decisions
Anyone who has worked with project management systems knows that the way you display data can dramatically affect the decions people make from it. This is why we often see GANTT charts with critical activities in red. I’m reminded of one of my very first sales of project scheduling software back in the 80’s. I don’t dare share the name of the organization but it was a large utility. We’d made this sale a few days earlier and now I got a call for “technical assistance”.
“I have a big problem. All my tasks are red,” the hapless client reported.
“Oh, that’s not a problem at all,” I replied. “Red tasks just mean that you are looking at the critical tasks. These tasks have been marked as red because they are on the critical path.”
“That’s another thing,” said my new client. “That word ‘critical’. That’s not going to work for us.”
There was a moment of silence. I was speechless. (For people who’ve met me you will know how unusual this is.)
“Perhaps the word ‘priority’ would be more appropriate,” I hesitantly replied. “Yes, that’s excellent!” said the client. “Now, what can you do about changing these colors? I need to get rid of these red tasks”
For those of you who have grown up with critical path methodology you might laugh. “This person needs training,” you might say. But I learned something very important from the interaction. My first reaction was to think that we needed to get in there right away and train people to distinguish between red tasks and blue tasks but I realized that the problem wasn’t his, it was mine. His perspective was that red tasks were a problem and that he’d have to take action to eliminate all the red from his report before he could give it to management. If you’re familiar with the critical path algorithm, this was going to be a problem because there are always tasks which are critical.
The challenge for the user wasn’t trivial. Even if I had trained him, he knew that his management would not appreciate the distinctions of critical vs. non-critical and would see red tasks the way a bull sees a red cape – they’d want to charge at them with as much force as they could muster.
When data moves beyond highly skilled users and into the hands of people who will only interact with it only occaisionally, choosing the display mode of the data is extremely important. In this day and age, the desire of management to get “real-time” dashboards and “live displays” of projects can lead to unhealthy project environments. Let’s consider the following very simple dashboard:
The situation here seems quite straightforward. Project 1 is running very late, Project 2 is slightly late and Project 3 is on time.
Showing this display instead of a complex barchart might be very appropriate to management. This display will draw attention to the schedule of Project 1. What should be done? Most managers would now query the project manager of Project 1 to ask why the project is late and what can be done to get it back on time.
That’s great so far. But next week when management sees the same report, is the same action appropriate? Probably not. Just having displayed the dashboard once has changed its context. If we display the identical dashboard with identical results next week, management will be likely to ask a very differerent question: “Have things improved since last week?” The display doesn’t show this.
So, we have the same data, the same author of the data, the same display, the same reader of the data but the reaction is quite different. This is because the context is very important. The manager of the project system has a couple of choices now. He or she can make a report that shows a year of icons for this display so the time factor can show management when the task becomes red and then goes back to the yellow caution and hopefully then to green. Or, they can try something like this:
Now both Project 1 and Project 2 are significantly behind schedule but we’ve added a new indicator to the graph. Now the trend of the scheduled delay is displayed. The eye naturally goes to the two red Projects: Project 1 and Project 2 and then to the right where we see that the trend for Project 1 seems to be improving and the trend for Project 2 seems to be getting worse. Also a concern is now Project 3 where the schedule is still on time but the trend is very much in the wrong direction. It looks like resources have been pulled from Projects 2 and 3 to work on Project 1 which is improving at the cost of the schedule of Project 3.
This is all still pretty good at the moment but you can see how the paradigm of such data expands exponentially. There is nothing quite so attractive to senior management than colored dashboard indicators and there’s a whole industry of people making indicators and formulas to drive them. In the simple example above, new indicators might be ordered up in a heartbeat. Was the improvement in Project 1 actually done at hte cost of Projects 2 and 3? What was the relative return on investment of working on Project 1 instead of 2 and 3. Perhaps this Red indicator caused us to move resources from our most important client to our least important internal project. How was the move of resources to respond to the red “X” in Project one aligned to our strategic goals? What did it cost?
Before you know it we’ll have a page full of symbols, curves, flashing lights and glowing buttons. There are a few other things missing from the whole display that are often overlooked. They can be summed up as timeliness and completeness.
Are we looking at all the data? Perhaps the project schedule is showing late but only half the tasks have been updated and when the data is all collected, the indicator will turn green. There’s no indicator in this simple display about how complete the data is or isn’t.
Is the data up to date? Perhaps Projects 2 and 3 were updated yesterday but Project 1 was only updated 90 days ago. Should they even be displayed on the same page? The data might no longer be relevant when compared from one project to another yet there is no indicator on the display that the data is all homogenous.
When we create display systems such as dashboards and summary reports we have to consider these things. I have a couple of basic rules about dashboards:
- Less is moreJust because we can measure a thing doesn’t mean we should. Imagine a page with 500 colored indicators with 100 different shapes being used. That’s obviously visually stimulating but will it be useful? Almost certainly not. Yet, a page with one color on it (just red for example) isn’t useful either. That tells you to get into action but not where.
- There must be actionEvery indicator should be able to have a related action to it. E.g. If the traffic light is red and the arrow beside it is red, then the VP must call the project manager immediately and review an action plan for getting back on track.
- The indicator must have qualityWe have an expectation that project data that is reviewed by management has already been approved in some way. Yet management often asks for real-time dashboards that shows data long before it’s been reviewed or approved. Showing the quality of the data by either showing the level of approval, completeness or timeliness right on the dashboard or through some other process is key to being able to count on the decisions that will be made from the data.
- The indicator is made for a particular audience.Making graphics dashboards with colored, animated flashy graphics is fun and, in this day and age of technology, not that hard. Designing such a display that makes an organization more effective is much tougher. So, every display we make is written with a particular audience in mind. Who will read this display and what is their context for the data.
The way you display data and what you display can make decisions and action possible that was impossible in the past. By the same token, a badly designed display can cause decision makers to make the incorrect decision inadvertently. So, think about what action such displays will cause as you’re designing them.
Whenever I am involved in the deployment of an enterprise-wide system I’m reminded of an analogy attributed to Buckminster Fuller (You remember Bucky. He’s the fellow who came up with the idea of geodesic domes.) Anyway, the story is about turning a ship. You see, when a ship is very large, say the size of a super-tanker, the size of the rudder to turn it must be correspondingly large. The problem is, that a ship such as this underway causes so much water pressure on the rudder, that the force required to push it against the water to turn the ship is incredibly large. So, someone very clever invented the “trim-tab” A trim-tab is a little rudder on the rudder and it seems that if you push that rudder in the opposite direction you want to go, the main rudder can be moved outwards with almost no effort at all.
One of my favourite advertisements for project management software over the last couple of years shows a harried project manager with his head in a photocopier trying to clone himself in a desperate attempt to get more resources for his project. It’s a sentiment almost everyone in the IT community can sympathize with lately. If there is a CIO in the country ready to say “I’ve got more than enough resources,” I’ve yet to meet him.
Integrated project management environments are the envy of almost every executive in the country. In virtually every computer publication available there is talk about corporate environments being single source. Yet another TLA (Three-letter-acronym) has crept into our lexicon; ERP. It stands for Enterprise Resource Planning and generally describes large, centralized corporate systems which include not just the traditional financial systems but also production systems including project control. Companies like SAP, Baan and PeopleSoft have been promoting single-stop providers of project control environments. The year-2000 issue has prompted many companies to replace their corporate systems wholesale and this has further fueled interest in a centralized environment.
We’ll look back on 2009 philosophically one day but there are many who are happy to see it come to an end. When we started 2009 we had challenges in various sectors of the project management community. But there were signs of things improving. The US had just elected a new president; a man full of hope and promise. The world’s auto industry was challenged but help would be on the way with a new administration.
“What-if?” These are the two words most heard in the project management industry. Everyone on a project has his own “what-ifs”. Each member of a project team has his own perspective. But what everyone is referring to here is targeted at the same thought process. This is an aspect of contingency planning.
Over 90% of our new clients already own project control software. It’s a tough statistic to come to terms with generally and it implies a particular environment in which, in our firm, we live most of the time. If you’ve been involved with the implementation of project control systems in the past, you know that it is often the case that you are replacing a system rather than installing and implementing into an unsullied environment. The nature of the project management software industry is that it changes quickly and, unlike many systems, there is often huge returns on investment for getting the latest, fastest algorithm to calculate critically required project resources.
In the dawn days of project management software, there was no such thing as “Desktop” systems. Indeed, there was no such thing as a desktop. The use of early project management systems were done entirely in mainframe or very centralized environments and by personnel who were very specialized as well. Given the extreme cost of setting up such systems, it was only on the very largest of projects or most complicated of project environments where they were found.

