why dashboard is not all about numbers

Long ago I read an article about an apparently strange behavior: if you’re seeing a person looking at their watch and you immediately ask what time it is, just a small percentage can tell you the correct time.

Some researches tried to investigate what’s the explanation for this apparently strange behavior. The results were quite simple and easy to understand, once you see the explanation. Most people cannot tell the time after consulting their watch simply because that was not their intention. Researchers discovered that we’re consulting our watch in order to place ourselves in time relative to the activities we’re doing or expecting. We need to know if we’re late or in time, or how much time we have until something we expect.

This was an “Aha moment” when I realized, what I noticed in many situations, working on KPIs/ dashboards, process and project measurements that actual figures don’t mean anything at all. Even for the most significant and best designed KPI, what matters if the value is 63% or 87%?  In fact, the recipient wants to know if the status and/or perspectives are good or bad, how good and how bad, if it’s bad where it’s bad, what’s the evolution in time and where are they supposed to look into details in order to take some action. For this purpose, usually color and symbols could be a lot better than numbers alone: more intuitive, meaningful and easier to attract the attention.

Take a look at these 3 principles on how to use color to draw attention to data visualizations

It sounds obvious that a Dashboard, or any KPIs, metrics, measures are there in order to help the decision-making process. If we cannot take a decision based on them, these are simply useless. Unfortunately, many useless, but monitored measures/ KPIs are way too frequent.

example of dashboard without numbers

In the proposed simplified illustration, I tried to highlight some of the elements of interest for management, such as:

  • the status, which could be versus a baseline, versus last approved target, etc.; it could be about objectives, money, tasks fulfillment, whatever…;
  • the trend; evolution from last reporting period;
  • timeliness;
  • resources status;
  • risks and issues;
  • escalations.

All these should be highlighted per the entire scope (organization, business unit, function, project…), but also for each sub-domain. Ideally, these should be built to allow drill down on specific points and could also consist of several layers, like Business, Product / Project Management, Financial, Technical…

Of course, these are just an example and should be adapted to fit the specific business needs. Moreover, each measure/metric/KPI to be monitored should be documented, in terms of definitions, collection and calculation methods, frequency, responsibilities, and so on.

In conclusion, a dashboard is not all about numbers, contrary to popular belief. A dashboard is about providing easily understood and consumable information that incites action. Colors, symbols or graphics help the decision making to identify the points of interest for them, and then the numbers are useful for analysis, preferably through the drill down design.

In the presented design of a dashboard, an experienced decision maker could immediately notice, in a matter of seconds, that the domain is OK with two sub-domains which could need attention, the trend is positive, no serious delays, resources at acceptable level and there are a few risks and issues, some of them needing his attention. As a result, one will first review the escalations, then the other risks and issues and if there is enough time, will take a look at the details of those sub-domains with problems.

{"email":"Email address invalid","url":"Website address invalid","required":"Required field missing"}

About the author 

Daniel Suciu

Specialist in Process and Change Management, Business Analysis, Business Intelligence, Large Systems Integration, Program and Project Management, Software Development and Quality Assurance, with measurable results at the intersection of systems, technology, processes, people and data.
Experienced in cross-functional projects, working between business and IT/technology, between customers, internal stakeholders and partners/ suppliers, but also between executives and line management or between line management and execution level employees.
Learnt to use diverse frameworks and methodologies on business, process and data governance, risk and compliance (eTom, SID, TAM, CMMI, ITIL, Lean, Six Sigma, COSO, COBIT, 3LoD, GRC…) as a way to reach business goals, to add value to business.
More details on LinkedIn: https://www.linkedin.com/in/danielsuciu/

You may also like:

Nicole Hitner


What Is ad hoc reporting?

What Is ad hoc reporting?