The definition of a dashboard is the panel facing a driver of a vehicle or the pilot of an aircraft containing instruments and controls. It’s the thing you look at when you are trying to drive a car or fly a plane. At a glance, you should be able to see the key pieces of information so that you understand your vehicle’s status. This is what I want from my project management dashboard, with a quick glance I should know how my project is doing. If you do a search on project management dashboards, however, that is not what you will find. You will find gauges, Gantt charts, project schedules, and even text messaging dialogs complete with pictures. They show all the widgets a clever developer can cram onto a screen. The thing is, just because we can do something doesn’t mean we should. Let me explain …
A dashboard, any dashboard, should tell a clear, crisp, story that simplifies any complexity without loss of information. If we apply this concept to a project management dashboard, with a single glance we want to be able to understand our project status. Status, however, is something much larger than just a discrete data point. The transformation of data into information, something with substantive meaning, requires giving the data context. Refer to From Data Literacy to Transliteracy for more information on this subject. We want to understand the state of the project in the context of time; past, present, and future. This is the story we are trying to tell. We want to tell more than just where we are today, but the path that we took to get here as well as the road we anticipate to our final destination. This is putting the project state in context. The dashboard shown above provides the context of our project’s status, the story of our project.
Let’s begin by looking at the three graphs at the top of the dashboard; Earned versus Planned, Actual versus Earned, and Schedule Performance Index (SPI) versus the Cost Performance Index (CPI). These three graphs combined succinctly tell us the current status of our project. When we look at the Earned versus Planned graph we see the trend of actual performance compared to planned performance. In the lower right-hand corner of the graph, we see a scheduled variance of a negative $15,000. The graph tells us that the project is trending towards delivering less than planned. In terms of cost, the Actual Costs versus Earned Value graph shows that we are trending towards delivering less value for more cost. The final graph SPI versus CPI provides us an understanding of the schedule and cost performance trends not in terms of absolute numbers, but in proportion to the size of the project. For a more detailed explanation of these graphs refer to my previous post, Earned Value.
Compare this clear, concise story told by these graphs to other methods of reporting project status. For example, I have seen multiple project managers report status by showing a Gannt chart with a vertical red line indicating the current date. They then report on the status of each of the tasks crossing that line as well as reporting on any tasks that have not completed that should have. So, these alternate images do not tell the complete story, there is a narrative that has to go with them. In addition, it does not provide a big picture view of the project. Imagine a Gannt chart, some of the tasks have completed, some haven’t, and some are ahead of schedule, but what does that mean to the overall status of the project? Is it good? Is it bad? What has been the trend over time? Again, the story is not complete, the viewer has to assemble the pieces to come up with their own conclusion. A conclusion we can only hope is accurate.
While the upper half of the dashboard provides us with insight into how the project is performing, the lower half evaluates the overall environment. Think of it as a fighter jet, the upper half is telling us the status of our craft, while the lower half is looking across the horizon to understand what obstacles lie between us and our destination. To that end, we want to fist understand the issues facing the project. We have presented these as a stacked bar chart. With one glance, we can see the distribution of the issues with which we are faced. In this particular example, we see that most of the issue are to the left of the chart, meaning that they have a low severity on the project. Of course, we will have to deal with each of these, but their level of severity gives us their relative degree of urgency.
The final chart on our dashboard is a Risk bubble chart. The chart plots risks by severity versus probability. As risks move from the lower left corner of the chart, low-probability / low-severity, to the upper right, high-probability / high-severity, they pose a greater risk to our project. As we examine the cluster and size of the bubbles on this chart, we develop an understanding of the level of risk faced by our project. If, as shown on our dashboard, the project is experiencing relatively low risks with the bubbles mostly in the lower left quadrant of the chart. The hot area of the chart is in the upper right quadrant. These risks are the most severe with the highest probability of occurrence. We, therefore, need to either eliminate the risks where possible or have a sufficient mitigation plan if they should occur.
The project management dashboard I have presented here is one that I prefer to use when managing a project. I have found that updating this dashboard and making it accessible to the entire team, along with links to more detailed information, is helpful in keeping all project participants up to date on the project status, including project sponsors and business users. It is also helpful as an introduction to the weekly status report. Individual project managers may have their own dashboard. The most important point, however, is that the dashboard crisply and succinctly tells the story of the project at a glance.
Pingback: Big Data Dashboard Design – a Challenge | Meditations on BI and Data Science