There's a lot of buzz surrounding performance dashboards these days. Most people at all levels of an organization naturally want to know exactly what they need to do their jobs better, at a glance, with most of what they need right in front of them. There aren't many who will tell you they prefer to assemble Excel spreadsheets, reports, graphs and PowerPoint decks manually rather than analyzing the data, deriving insight from it and making better business decisions, faster. Well, I certainly wouldn't.
Performance dashboards are visual and interactive displays of the most critical information you need to make better decisions, laid out strategically within the confines of a screen.
People are hungry for "bespoke, slick and stunning visualizations and highly interactive dashboards". I hear this all the time - "we're looking for sexy data visualizations - we don't think our existing dashboards are doing the job because visually they look dull, flat, and well they're boring".
There's really nothing wrong with they're saying - we tend to gravitate to things that are well put together, engaging, visually interesting, memorable, and well, beautiful. I'd rather be driving a Porsche than a tired looking minivan. They'll both get me from point A to B, but I'd sooner forget my experience in the latter. Functional data visualization purists will tell you that the fluff and the glitz gets in the way - and they're usually quite right - but they also often forget that not everyone is a number-crunching line-chart enthusiast, and things that are boring and visually visually un-engaging tend to be forgotten and sadly ignored.
People who are looking for the latest widgets and funky chart types and thermometers and speedometers are often the same ones who attribute the fact that their dashboards "aren't doing the job" because of the particular technology they're using. And in many circumstances, this may well be the case.
The issue I usually and frequently encounter is that their perceived problems - the lack of visual appeal and excitement, and the need for better technology and software - are actually far from their biggest problems.
And that's a big statement coming from someone like me who works for a company that, in part, specializes in pushing the envelope for data visualization technology.
Their biggest problems - those that are all-too frequently missed - are much more fundamental. Here are some critical success factors that most people who are responsible for initiating dashboard projects, in my experience, tend to miss:
Effort - You Reap What You Sow
Dashboards that fail usually fail because they're not useful. If dashboards are merely seen as eye-candy - the icing on your organization's business intelligence cake - that's exactly what you're going to get. A sugar rush that'll get you a lot of excitement at first, and very little adoption down the road.
Good dashboards bridge the gap between strategy and execution in an extremely succinct manner, and are highly and necessarily focused. This can take a lot of effort. As with anything involving communication, it's easy to babble, but it's very difficult to be concise. This is why executive summary dashboards built for top-level business leaders are sometimes the toughest to design and execute.
Being concise in this manner requires expertise in knowing a business or functional area's critical business drivers, or key performance indicators (known as KPIs). Boiling down an organization's vast array of metrics to a small and deliberate number of KPIs is almost always more difficult than most people realize.
Think of a good dashboard implementation as a good website project. You've got all of a few seconds to capture somebody's attention and get your message across in the most powerful, efficient and memorable manner possible. Don't make people work to figure out your value proposition and key messages - a cluttered vision will totally go against what you're trying to do. Good websites aren't designed by accident - it takes time to draft and flesh out your communication and creative plans, layouts, content, planned sequences and storyboards, etc. The same challenges exist with dashboard projects.
It'd be awesome if there was some magic button you could press to automatically create a dashboard that is somehow aligned to your organization's strategic initiatives. It's real easy to just use cookie cutters to duplicate concepts from one organization to another, but the reality is if you want these projects to truly succeed in a manner that'll actually make a difference - take the time and effort to do things right.
Data Visualization Expertise
Data visualization is probably one of the most misused and misunderstood forms of communication in the business world today. "Slick and stunning" data visualizations are useless if they aren't used effectively, accurately and in a highly deliberate manner. Good data visualization certainly does not happen by accident, and when people think that their existing dashboards are "missing the mark", the problem is actually often related to some misunderstanding of how data visualization is supposed to work.
There are volumes of great and important books on the subject, and I always encourage people who are involved in these initiatives to make sure they've at least got the basics down. The challenge I always have is that most people think they know how to properly visualize data, when really they don't. I once fell into this bucket.
Good dashboard or data visualization technologies certainly make the process of building good dashboards easier, but no technology is a replacement for expertise in this area. Visual Studio doesn't make you a good software developer, Excel doesn't make you a good analyst, a Steinway won't make you a good pianist, a Porsche won't make you a good driver, and a top of the line camera does not make you a good photographer (if only!).
We often get RFPs with huge laundry lists of features, bells and whistles that people want, but I find in a lot of cases one could easily tick off all of the checkmarks successfully and still have a failed implementation. Technology is an important consideration, but it is far from the most important.
I'll certainly be spending more time covering data visualization topics in greater detail in the near future.
Planning
Successful dashboard projects almost always involve good planning.
Here are the toughest dashboards to execute: the first dashboards you're going to try and build, and cross-functional executive summaries.
Dashboard projects often fail because people often and frequently underestimate the effort required to build good dashboards, and the folks who build them often find themselves having a hard time managing changing scopes and high expectations. Data visualization is unfamiliar, poorly understood, and prone to a lot of subjectivity, and the people that will use them are naturally very subjective. Project timelines can get delayed, and momentum, excitement and funding can very quickly fizzle. Some people have gotten themselves into such big messes with long and drawn-out projects that the initiatives themselves get canned even before the first dashboards see the light of day.
Here's a bombshell: the first version of any dashboard you build is probably not going to be very good. I apologize if this might offend you, but I think this applies to everyone, dashboard novices and experts alike. I don't have real stats here, but it's just something I witness all the time.
You can gather all the requirements you want at the most granular level of detail, have the best mock-ups, sketches and design guidelines, and even read every textbook on data visualization ever written. Dashboards are naturally visual, and it's very difficult for the end-users that you're building these dashboards for to be able to picture and project all of their requirements before they see anything, get a sense of the shape of the data, understand how to interact with the dashboard, and start developing preferences for their user experience.
As such, I feel that dashboard projects are necessarily iterative. Budget for a bunch of different versions in your project plan, and build the review process into your timelines. You'll likely have a bunch of iterations before your dashboards are deployed, from initial review to quality control to user-acceptance testing, so plan for them and expect changes to come. Experience will help you avoid derailing your project with every stakeholder review, but there's simply no way to avoid change.
My advice is to break your projects down into manageable phases, where each phase is relatively self-contained (individual functional areas for example, like sales, marketing, finance, etc.) and where the data required within each phase doesn't require a daunting amount of alignment and consolidation. Deliver each phase rapidly in order to constantly and consistently demonstrate value and create opportunities to adjust your design philosophies and best practices with each successive rollout.
It is critical that you ensure the right stakeholders are present during your scoping or review meetings. This however should not be equated with bringing as many stakeholders as possible to every meeting. Big meetings tend to complicate project plans in a big way with far too many ideas and insufficient focus - especially when you're in the brainstorming stages of a project. I'd recommend starting with a few focused individuals who have a strong sense of what needs to be done, understand the critical business drivers well enough to be able to succinctly describe what they are in chronological order and in plain English, and have the ability to explicitly define the relationships between action, performance indicators and results. Coming up with at least a number of mockups and sketches and submitting them for review is often far more efficient than walking into a meeting with a whole bunch of high-level stakeholders with a blank canvas, a truckload of ideas that are going in twenty different directions, and conflicting sensibilities with regards to data visualization best practices.
The best organization-wide implementations are often run by a few key project participants that have insight into the entire initiative, from end-to-end. This level of continuitiy is important not just for consistency, but to help project future complications with data alignment and consolidations and factor them into overall plans. Different stakeholders from various functional areas might be required from phase to phase, but there should always be one or more key participants who have insight and experience with all of the phases.
Another interesting revelation: good dashboards are usually never finished.
This really shouldn't be too surprising. Good dashboards link strategy with execution. Organizational strategies change all the time, along with their respective KPIs. Dashboards naturally need to be changed regularly to stay relevant and concise. It's best to treat dashboards as ongoing works-in-progress - this also tends to make delivering the first few phases a lot easier, knowing that they might not have to be completely perfect the first or second time around, because there will be opportunities to revisit them in the future.
To sum things up, the visual appeal and technology you plan on using for a dashboard implementation are obviously important considerations, but in my mind, ensuring that a sufficient amount of effort is being planned into a project, putting the right people with the right expertise on the project, and planning for small phases that are each iterative and deployed rapidly should drastically increase your chances of delivering a successful implementation, in my opinion.
About the Author
I am a consultant at Dundas Data Visualization, and I help people understand their data so they can make better decisions, faster. Follow @nelsoncng on Twitter and check out my blog for thoughts and ideas about data visualization and performance dashboards: http://datavism.com.