Way back in 2000, a data driven digital dashboard was a concept created to display information in a more user-friendly, visually pleasing manner. I believe the idea grew from a few places: the seed was Kaplan’s and Norton’s Balanced Scorecard, the soil was deployments of large corporate software systems, the water was internal IT groups, the sun was the demanding user base and the fertilizer was the corporate sponsor.
Many things lined up at the right time to enable the right environment sprouting a new way of solving problems most businesses had:
- What do we do with all of this information we are collecting?
- How can I give it to the right people at the right time so they can better manage my business?
- Can we tell if providing this information is helping anyone?
The most popular analogy used a car’s dashboard as a way to help people understand what was meant by a data-driven digital dashboard: instant access to critical information.
You don’t have to understand the mechanics of an engine to know a red light means bad or that low fuel means to plan a refueling stop soon. The original intent of the dashboard was the same. Put critical information, that helps keep the business (car) running, in front of decision makers in a real-time basis. For some warnings you may need immediate action (red light) and for others you know what to do but may need a reminder (low fuel).
All of this sounded great. It touched the pulse of mid-level and senior management. Geeks were excited they could provide something to prove value. Accountants were thrilled they could show the financial implications of certain business events (inventory turns, overtime costs) without giving a P&L and accounting classes to every person. But it didn’t work
Initial Failures (circa 2001-2007)
- The idea was ahead of it’s time. Few companies had the necessary resources to handle the change. Hardware capbabilities failed to achieve instant always-on data feeds. Business staff didn’t understand relational data. The dashboard skillset was rare yet rapidly evolving.
- Companies weren’t ready for the demands of dashboards. Accountants didn’t want mid-month P&Ls. Operations didn’t want every swipe of every timecard displaying at a remote corporate office. Manual data massaging (rationalized lying) was no longer possible. Worst of all, we all discovered how bad our data was because of misguided ERP implementations and inadequate user training.
- Several vendors emerged with toolsets for developers. The toolsets quickly became dashboard development environments. These applications were meant to help deploy dashboards inside of companies with little IT help. The ideas were great but the execution lackluster.
- Smartphones. [Sigh] We could hardly handle live dahsboards within our own private networks, now we had to expose them to the public internet along side breaking news and questionable browsing habits? Not to mention the bottleneck of the wireless carriers.
- Drilldown. Many of the first and even second generation dashboarding solutions couldn’t handle multiple drilldowns. Drilling down several times to more detailed information was difficult. Returning a user to where she started was temperamental at best.
As we rolled into 2007, user sophistication was increasing. Hardware performance was improving. Networks were handling larger data sets. The economy was booming and innovation within dashboarding was at an all time high. It seemed everyone had jumped on the bandwagon.
When the economy crashed, demands for dashboards actually increased. I assume companies, as they cut staff, needed to automate data management more than ever.
The most important development of this time was a broad understanding of the need for business intelligence. Dashboards may have been the lens to see into the data, but business intelligence – everyone realized – was the way to make sense of all the data.
Too Much (2010 – 2011)
As companies focused on business intelligence and sorting all the information into usable chunks, dashboards took a strange turn.
Dashboards were being used for all types of things that no longer fit into the original intent. It wasn’t that people were pushing the concept in a good direction, either. Issues began to surface because demand was increasing to use dashboards for everything…including replacing transactional systems by posting data back to the source.
Sure, there were some cool achievements, but most advancements were over designs that lacked value. The improved acumen of the business, insatiable demand for more information more quickly, and better tools lead to an over development. Not every problem can be solved with a dashboard…or even technology.
See more here or a similar argument here.
Current State (2012 – now)
Dashboards appear to be coming into balance with the overall technology needs of the business. The applications continue to mature. Most dashboard app developers have jumped into mobility. There is also a mature offering of dashboard tools businesses can purchase and deploy.
Business people are also settling down on requests to solve everything with a dashboard. There is a need for spreadsheets and reports. And it’s not bad if your company uses several tools to communicate performance and exceptions.
Defining the business needs to drive the direction of business intelligence and then deciding on a strategy for how to distribute the information is critical to the success of any dashboard project. Dashboards are a tool, not a panacea.
- Like most tools, proper use of dashboards can be beneficial and overuse damaging.
If you had a failed dashboard project in the past, we’ve come a long way, and it may be time for your company to reconsider the use of dashboards. As you launch into a dashboard initiative, remember it’s ok to define the use of dashboards in conjunction with reports and spreadsheets.
Disclaimer & Back Story
Nothing in this post was researched. I’ve told my part of the story based on my experience with dashboards over the last dozen years.
Around 2001, for my first IT project, I was managing the budget for a new reporting concept that had been awarded to a small vendor. I was still very much a business guy at the time and this little IT project was the smallest of the CapEx I was managing. I didn’t spend much time on it. No big surprise, the project was a failure. But the concept was a custom written dashboard. We didn’t even know the term back then.
About 18-months later I was asked to revisit that project and see if we could try again. We did. This time we developed it in-house and had marginal success. Over the next two years our little home-grown dashboard was being used by all of the managers and executives in the company. It was time for iteration three.
By now there were a few dashboard development software systems available. We evaluated them, made a selection, and went dashboard crazy. It was during this project we really began to understand the need for business intelligence.
I’ve been involved with business intelligence and dashboards ever since. Neither is the focus of my career but both have served me well to help the companies where I’ve worked. Use them as tools to help communicate and monitor your strategy.
About the Author
Keith Rickles was President and founded 323 Technology Solutions. He is currently the Product Manager of Mobile Solutions at CommandAlkon and also runs the blog Keith Rickles. You can connect with Keith through LinkedIn or Google+.