Dashboards, Scorecards and Project Status (Oh My!)
by Kenneth Darter
August 22, 2011

“What’s the status on that project?” It’s a question we hear all too often. The stakeholders and sponsors of a project will want to know a project’s status almost immediately after it has been approved by management (sometimes, they need it before the project is approved). This status report might be called a “scorecard”, a “dashboard” or some other fancy name. No matter what it’s called, the project status report should show the audience a good picture of where the project currently is. There are as many different ways to show project status as there are project managers, but there are some guiding principles that should be followed in order to effectively communicate with the audience. There are also some basic metrics and graphs that the project manager can keep in their analytic toolbox and use on the report.

The status report is also an important communication vehicle that helps everyone learn what is needed for project success. Ideally, there will be a regularly scheduled meeting where the report is presented; this will foster communication between the project management and the project stakeholders. The project manager should engage the stakeholders and executives in that meeting and be ready to discuss actions needed to improve the project’s health.

The one-page report
The project manager should know his audience and tailor the report appropriately. Most of the time, stakeholders and executives are not former project managers. They do not get excited about gantt charts, long lists of risks or waterfall diagrams. Most status reports can be handled with a one-page report that contains a summary of the overall status and a few relevant graphs. Any more information than that faces the risk of getting lost in the shuffle. The reason this one-page report is often called a scorecard or dashboard is that it should be read in a glance, instead of requiring a long time to read and analyze.

The overall status of the project should be front and center at the top of the report (along with the “as of” date--nothing is worse than trying to explain a month-old status that’s no longer accurate). There are many ways to present the overall status, but something simple and direct is best. Showing green/yellow/red colors seems like a PMBOK standard, but the project manager should be sure to define what each color means. Another design might be to use the triple constraint and show how the project is faring in each area. A picture is always worth a thousand words--it can make a better impact than a paragraph of text with strange words like “scope creep” or “risk mitigation”. Good methods of presenting this information would be speedometers, traffic lights or a scorecard; it needs to be something that will connect with the audience and get the message across. Many of these can be created in Excel or a comparable tool. A few examples are provided below that were created in Excel or Word. For each example, there is a message that needs to be communicated.

Example 1: The Triple Constraint. The message--ahead of schedule is good, right? Nope. The project team has spent more time working than anticipated (schedule) but accomplished less than planned (scope). This project is headed in the wrong direction and the budget will be the next problem.

 
Example 2: The Traffic Light. The message: Right now, the project is on track, but there are warning signs that need to be addressed immediately--especially in scope control--before the project veers out of control.

 
Below the summary, the status report should include additional information. It is unlikely that this portion of the one-page report will be the same throughout the project. The project manager needs to be flexible and work with the stakeholders to define what is needed on a weekly or monthly basis to monitor the project. Information provided could be updates on procurement at the beginning of the project or testing status at the end of the project. High-level risks and issues should always have a place in the status report, but there may be times when they need more focus in a meeting. A corrective action plan may require its own status report if it is large enough in scope.

As above, here are a few examples for the analytic toolbox…
Example 1: The Risk Radar. The risks closest to the middle need the attention of management. In this case, resource shortage is very close to turning into an issue.

Example 2: The Pivot Chart. This is a small chart, but it presents a great deal of data. The audience can see at a glance where the problem areas might be. Contract 1 has a problem with late enhancements, whereas Contract 2 seems to have issues all across the board with late system requests. If that continues, then all of the “on time” requests will soon be late as well.

 
There are many other ways of presenting data on a status report, but everything should follow these simple guidelines. It should convey its message simply and quickly, and it should address the concerns of the audience. The project manager should be able to back it up with solid data. Lastly, and most importantly, the project team and the stakeholders should agree on its inclusion in the report and there must be buy-in on the method of collecting and analyzing the data (and any definitions or thresholds used to present the data on the report).

But what about this? And this? And…
At some point, the stakeholders are going to ask about something that is not on the report. This usually happens in the first meeting after everyone agrees on the report. Depending on the nature of project, it is likely that the status report will change during the project. Different phases of the project could require different metrics. It may be a perfectly valid point that something got left off that needs to be added immediately. In order to make sure that the status report is meeting the needs of the stakeholder, the project manager should plan regular checkpoints to get feedback and plan for revisions to the status report. These checkpoints are naturally part of phase changes, but could also occur at other times.

Discussion vs. Presentation
In many ways, the discussion in the meeting is more important than the report itself. Hopefully, the meeting is scheduled on a regular basis and the stakeholders have a keen interest in attending and giving it their full attention (as opposed to giving their attention to their smartphones). The project manager can help facilitate this by providing the most important information directly to the stakeholders on the one-page report that gives them what they need without wasting their time on unnecessary and confusing information. This is not the time to sugarcoat things, nor is it the time to scream about the sky falling; the best message is short and truthful. With the proper information at their fingertips, the stakeholders will stay engaged to the project and know exactly what their role needs to be in making the project a success.

Copyright © 2011 gantthead.com. Reproduced by permission of gantthead.com.

###