Dashboard reporting is popular because of its short, sweet, and to-the-point graphical interface that usually fits into one page; but it has its pros and cons depending on the use you have for it on your project. Dashboards have surfaced and evolved in recent years, with several organizations finding them invaluable for a quick overview of projects or even portfolios of projects under the purview of a PMO (Project Management Office). Still, some people want more and what they are basically requesting is a good old status report. When having the options, which would your stakeholders choose? It is important to know since your communications strategy will be based on what should be best for those individuals.
Project Managers all over the world are renowned for having to keep on top and generate a large number of reports, artifacts, and documents. When it comes to reports, we produce several types, all providing a different perspective of our project. One key to being successful at this is to truly understand and determine what your stakeholders are after and for what purpose. Not all reports will fulfill the same needs. Evaluation of the need is done via the discussion that comes with the creation of a communications plan and, more importantly, a communications matrix.
Once you’ve defined your strategy and developed how to implement it, you will need to confirm with your stakeholders their exact needs for communications throughout the project. You will also need to make considerations for the out-of-the-ordinary issues that might prompt the need for other communication events, especially during implementation or through some more critical moments.
The first key perspective to consider when defining the need for information requires you to look at the context of time. Keeping this in mind, we will see the following develop:
- Dashboards show “live” data mostly without narrative but in a more graphical way using tables, charts, gauges, traffic lights, and links to other documents such as spreadsheets, project management software, etc. These can be purchased already configured out of a box or programmed in-house and maintained by the organization.
- Status reports will show you the “now” or current from the last time we reported on our project. Status reports can be all-encompassing (the entire project) or brought down to the level of an issue. It is not rare to have weekly status reports disseminated through our project network, especially during execution. In this one report, you need to be able to situate your stakeholders as well as provide them with information to make decisions. The main purpose of a good status report is to keep your team productive, efficient, and accountable while giving a chance for everyone else to get a look at what is happening and hopefully engage them in the process.
- Progress reports look back in time as to where we have been or how it came about. In a lot of organizations, this is used more as a PR or marketing report that likes to tut horns and exclaim the progress of our projects. They will often establish a relation to our planned baselines and be at a high level in terms of details.
- Forecast reports look ahead and try to give a projection or prediction as to where we will be considering x, y, and z. In most cases, our focus here is on timeline and budget alignment or presenting a view considering our variances.
Crafting reports that suit the needs of our varied stakeholders has often been a topic of conversations or blogs. It seems that everyone wants something different when asked, and it is up to the PM to turn down the countless modifications requested by individuals. A thing that I was told early in my career was to start with as generic and simple of a model as I could, adding a few elements along the way but trying to keep the reports as tailorless as possible. These modifications and overall tailoring for one, two, or several individuals can take up a lot of time. Determine with the group what is needed and what is superficial and stick to that model. You can incorporate some dashboard features to make the status report livelier, but again keep it simply, simple (KISS) but targeted.
What makes a solid status report?
Great status reports are first and foremost concise, honest and clear, containing mostly an overview of the key elements of the project. If a person truly wants detailed information, there are tons of artifacts that can be provided to them from which the data was gathered. A deeper review process will require that data, but for a weekly “heads-up” such as a status report, our point-in-time review, we do not want to end up with a Tolstoy novel. It should be based on current information at a level high enough for stakeholders to gather information to start their decision-making process. One final key trick: don’t focus simply on the negative information, have a section that talks to successes as well, keeping the report balanced helps in getting it read.
Therefore, I do not believe that the correct tool here is a dashboard. A good dashboard, yes, will contain a lot of data, but this data will be better suited to compare results, timelines, or goals achievement. There is a gap left with the use of a dashboard in the lack of supporting information provided to get a person to possibly base a decision upon. A few more steps would be required in the process to get there. As well, most dashboards are meant to simply display or convey data neatly and clearly without the presumption of having to make any decisions other than being given the information.
The next time you are put in front of a report-type decision, look at your stakeholders to provide you with a clear purpose of how they intend to use the report. Once you have gathered that information, you will be able to better find and tailor a template that will suit their needs and that of the project. After all, this must work for all involved.