Dashboarding and data visualization are hot-button topics in the analytics industry, and for good reason. Effective dashboards can democratize access to data across an organization and help foster a culture in which data is used to drive more and more decisions with demonstrable business outcomes.
However, in my experience consulting with enterprises across a variety of industries, I’ve found that too often, dashboards are all hat and no cattle. In other words, the effort, time and money invested in dashboards too often result in disappointment and frustration.
To help you avoid this same frustration, I’ve outlined three common issues with dashboarding projects.
First, it’s very common to find that dashboards don’t have a clear role, or don’t uniquely address a need for stakeholders within an organization.
Second, and on a related note, the organizational conversation about dashboarding tends to immediately jump into a debate about tools — which tool has which features, and so on — before due consideration is given to the data sources “upstream” of the ultimate dashboard.
Ask yourself: Do you trust that data? Are data updates automated, or do they require manual upkeep? In short, is it even worth building a dashboard before addressing data “supply chain” issues?
Finally, organizations sometimes neglect to consider the alternatives to dashboards. Even reliable, easy-to-use dashboards commonly go unused — because stakeholders actually have better alternatives.
It’s critical to align with stakeholders on the role of dashboards. Doing so allows you to clearly define the scope of your efforts and manage the expectations of your stakeholders long-term.
It’s very common to get involved in dashboarding projects whose scopes quickly reach “boil the ocean” status.
In other words, dashboards are supposed to answer, in detail, every possible question and cover every hypothetical eventuality. Different stakeholders add different requirements, and the result is the dashboard equivalent of urban sprawl — dashboards that are crammed with charts and tables, making it difficult to get to the limited amount of stuff that’s important.
So what should the role of dashboards be? For enterprises with a central analytics team (or agency) serving a wide variety of stakeholders, dashboards probably don’t need to answer every possible stakeholder question.
Instead, dashboards should help stakeholders quickly and easily understand when trends in relevant KPIs are changing, so that they can, in turn, ask more informed questions. Armed with these better, more clearly defined questions, analytics teams can serve their clients much more effectively, with specifically tailored analysis and recommendations.
On the other hand, in an environment where analytics is more self-serve (i.e., there is no central analytics team to serve stakeholders), dashboards likely need to provide a deeper level of detail and interactivity. There’s probably also a commensurate need for user training so that data consumers feel comfortable using and getting value out of more complex dashboards.
Either way, before you get into a vendor selection process, and certainly before you start building dashboards, you should have a candid, realistic conversation about the role of dashboards. Nailing this down up front helps ensure that you’ll ultimately build something that your users actually want and helps you manage expectations along the way.
