Executives and managers need information to make the myriad of decisions that confront them every day. Staff need information to ensure that their actions are meeting the business’ objectives.
With computers everywhere, we’re drowning in information. Yet many businesses still feel they don’t have the information they need, where and when they need it. Often businesses turn to the idea of a dashboard as a way to deliver information.
ACE Dashboards has helped many businesses collect and distribute information, and we’ve learned a lot. In this white paper, we’re going to talk about a general process for developing good dashboards, critical success factors in the development of dashboards, and the advantages we bring when you engage us to develop your dashboard.
Example Dashboard
Our process is founded on the principle that good dashboards are a matter of effective collaboration and communication between the different people who have to work together to make a dashboard. Our process is centred on an visually accurate prototype as a key element in fostering clear communication. From there, we generate clear consensus about the meaning of the numbers or metrics that drive the dashboard between the business and technical people. Once the metrics have been fully defined, processes (automated or manual) can be set up to update them.
To support that process, we use technologies that allow us to work together with you to generate a prototype. The prototype is actually a functioning dashboard, without the data. The dashboard includes tools to help define the metrics, and provides interfaces to facilitate loading data automatically.
Our experience, process, and technology combine to make us a good choice to help you develop your dashboards.
Developing effective dashboards is a matter of collaboration between people with different responsibilities and experiences. Often dashboards are requested by management or executives. But the data is best understood by the operational people that create or consume it. And the technical folks understand how to store and retrieve the data, and how to do advanced analysis with it.
Finding a process that enables effective collaboration, allowing each person to focus on doing what they do best, is a critical success factor for developing a dashboard.
We’ve found that an effective process for developing dashboards is structured around three major activities:
A visually accurate prototype is critical to the development of a dashboard. It’s hard to argue about what was requested when everyone has been able to see and agree to a prototype. The more detail that can be included in the prototype, the better. But this has to be limited by the amount of effort that is reasonable to expend at this stage of the dashboard’s development.
A “visually accurate” prototype includes such things as:
The idea is that the prototype should be something that you can show to the intended audience, and have them understand and agree that the dashboard will be useful.
The principal challenge to achieving the above is the technology. While the web has advanced to the point where it’s relatively practical to prototype a web page, most dashboard software has yet to incorporate these advances. And general-purpose web page design software doesn’t take into account the unique nature of dashboards. In particular, it doesn’t make it easy to pull the KPIs out of the prototype.
Because one of the outcomes of the prototyping activity should be a list of KPIs required by the dashboard. At the very least, the prototype should implicitly show every number or series of data needed to display the dashboard. Some typical examples of KPIs include:
As you can see, the list can be very detailed. It’s pretty easy to prototype a dashboard that has 100 or more KPIs. Simply knowing how many KPIs are required is useful, because it’s an important measure of the scope of the overall effort to create the dashboard.
Just as importantly, having a clear list of what data is needed is a key element at facilitating the discussions in the next major activity: Defining the KPIs.
A good definition for a KPI can be as varied as KPIs themselves. A successful strategy is to focus on the following five parameters for each KPI:
The SME is the person who knows how to get the KPI. Typically there is a person, or a small group of people, who know where the data is and what it really means. If the KPI already appears in a report somewhere, the SME is often the person who produces the report. If the number is in a spreadsheet, the SME is often the person who creates the spreadsheet.
The source is the critical success factor for a dashboard. The source is a detailed description of where the KPI can be found. The exact content of a good description of source depends on the KPI, but common factors to consider include:
In the most extreme case, determining the source of a KPI might become a project to define the requirements for “big data” analysis of an organization’s data warehouse. Fortunately, in most cases, it’s not like that. The source can be determined reasonably quickly, as long as the right people are involved and they’re given time to do the work.
If you expect to develop an automated process to load the data into the dashboard, you need some way of verifying that the process is working correctly is essential. An existing report, a spreadsheet, or even a screen capture of a page from another application serves as a way of verifying the dashboard. If the KPI already appears in some other report or spreadsheet that gets published, the report or spreadsheet is the obvious verification data.
Although it doesn’t have to be the first thing you figure out, you will need to determine how often and when each KPI needs to be updated.
One particular challenge that may arise is that the requesters would like the dashboard to show data that’s more up-to-date than it’s possible or practical to retrieve from the data source. It’s important to have the discussion before a lot of effort is expended figuring out the rest of the definition, let alone trying to determine how to load the data in the dashboard.
Many data sources require a user name and password, or some other proof of authorization, in order to access the data. Typically, one set of access credentials covers a large number of KPIs. For example, a particular database may be the source of many KPIs, and only one username and password are required to access the whole database.
While the access credentials themselves may seem like a trivial item, it may be important to collect them early in the process. A request for credentials may discover data ownership or security issues that could affect the content of the dashboard, or the effort required to create it.
For example, a relatively benign KPI may reside in a database that also contains highly sensitive data, and the owner of the data will quite rightly not want to give access to the database. There are several approaches to deal with this situation, but the process of choosing one and making it happen will take time, so it’s important to know early enough to plan for any data access challenges.
Access credentials are kept separate from the rest of the KPI’s definition, because they should be available only to certain individuals.
The process of collecting the parameters is best driven by the organization that is creating the dashboard. Therefore, its unique to the organization. Nevertheless, certain strategies seem to apply to many organizations:
The people involved at this stage are almost always from the organization requesting the dashboard. They know the business, they know the audience for the dashboard, and they know where the data comes from.
Often organizations have trouble creating dashboards (or in more general terms, providing access to the right information) because the nature of the job requires input from a diverse group of people with different roles and responsibilities. The approach described in this white paper has proven to provide focus, which helps to bring everyone together and align them to what needs to be done to develop a dashboard.
There is one area where outside expertise may help: If you want to present advanced analysis of data. “Big data” analysis is somewhat over-hyped these days, but there is a time and place for rigorous analysis of data. If it doesn’t make sense to your organization to have its own data science group, using outside help is the next best thing.
A dashboard’s job is to present meaningful data in a timely way to the right people. So timely, accurate, updates of the data are essential. Loading data in the dashboard can begin as soon as the KPIs for one chart have been fully defined.
How to load the data depends greatly on the data source, the means of access to the data, and the update frequency. Some common patterns are:
Many charts will require a combination of the above approaches. For example, in a gauge that shows target versus actual sales, the target might be entered manually because it’s relatively constant. The actual sales might be pushed to the dashboard in real time from the order taking system.
If the KPI definitions were developed to the guidelines in the “Defining the KPIs” section, the work to automate the loading primarily falls to technology people. If your organization has people with the skills and time to do the work, it makes sense to have them do it. They probably know the data better than anyone.
If you don’t have people with the technical knowledge, or they’re too busy with all the other work they have to do, it’s reasonable to have ACE consultants do this part of the work for you. As long as the KPI definitions are complete, the tasks of the consultant should be relatively easy to define.
We take a unique approach to give you the dashboards you need. We offer a suite of services designed to facilitate the deployment of effective dashboards, built on our dashboard appliance. Our services are designed around the principle that we should do what we do best, while your people do what they do best.
When you engage us to develop a dashboard, the first step is to meet with a small group of stakeholders. We show some examples of dashboards, and walk through a brief demonstration of how we prototype. We expect you to describe in general terms what your challenges are in terms of distributing information to your organization. It’s important for us to understand the motivating factors behind your dashboard.
The next step is to have one or more prototyping sessions, scheduled at your convenience. The goal of these sessions is to capture a visually accurate prototype of the dashboard. The prototype is actually built with the same technology as the dashboard, so during the prototyping, you’re actually seeing the dashboard come together, albeit without data.
During the prototyping sessions, a large number of questions arise. Many of these questions are for people who aren’t participating in the session. For this reason, we actually prefer a series of shorter meetings, rather than one long meeting, to generate the prototype.
Between prototyping sessions, the prototype is available at a temporary URL that we will provide to you. This URL will be password protected so that only authorized people at your organization can see the prototype. Our customers find it useful to be able to refer to the prototype as they work through the design process.
All meetings are conducted remotely, with participants viewing a shared screen, and dialed in either by regular phone service, or using the meeting software’s voice service. We currently use Zoom for remote meetings.
Once the prototype is complete, it has to be made operational. You can choose to let us run your dashboard on our servers in the cloud, or we can deploy and support an appliance in your network.
For a simple monthly or annual fee, we run your dashboard on our servers. Cloud deployment has a number of advantages:
Disadvantages:
We provide a dashboard appliance (which is a virtual machine, not a physical device) that runs on your IT infrastructure. We fully support the device with upgrades to the software for security and operational defects.
Advantages:
(Some of the advantages above may be extra-cost options.)
Disadvantages:
Defining KPIs is best done by the people in your organization who know your business and your data. The dashboard appliance provides you with tools to help define the KPIs that were identified by the prototype.
The appliance provides pages where you can capture the information that describes and defines a KPI. The information is instantly available to everyone collaborating on the definition of the KPIs. In addition, some of the fields are also used by the dashboard to provide help information on the dashboard itself, so by filling in the defintion, you’re killing two birds with one stone.
Once your dashboard has been deployed, either in the cloud or on your premises, you have to load data. Out of the box, all the KPIs can be updated manually. The dashboard provides pages to allow you to input and modify the data on the dashboard. It also lets users upload CSV format files (like those exported from a spreadsheet program), into the KPIs.
While manual updating may work for some KPIs, it’s likely you want to automate the loading of data for many KPIs. You may have staff who can do this, or can learn how to do this. The dashboard comes with some documentation on how to load data.
If you don’t have anyone who can do the data loading, we can do it for you. We require completed definitions of the KPIs you ask us to load.
This service is optional.
Our senior analysts have many years experience gleaning insights from customers’ databases. We can help if:
Because of the inevitable uncertainty involved in this type of “discovery” work, we offer data analysis services on a time and materials basis.
This service is optional.
Because our dashboard is built with common off-the-shelf web technologies, your dashboard can do pretty much anything the web can do. Because of the technology and our expertise, we can provide you a customized dashboard, at a cost well below the typical cost of custom software.
This service is optional.
We do not sell dashboard software for you to set-up, configure, and program yourself. There are a number of well-established products that do so. Use your favourite search engine to find them.
We’re focused on helping organizations that want good dashboards, without the challenges that come from buying an off-the-shelf dashboard or reporting solution. Too many organizations buy some expensive software that promises to solve their reporting problems, only to discover one or more challenges:
Building a good dashboard is more about the people and the data, than it is about the technology used to implement the dashboard. By engaging ACE Dashboards, you get better dashboards due to our unique combination of process, communication, collaboration, and technology.