Distill the health of your organization or department down to a few key performance indicators (KPIs).

For example, one of your key indicators might be customer acquisition. A good business intelligence dashboard would show you at a top level perhaps the number of new acquisitions for a time period, with the number being in green if the number is favorable vs some metric or red if it is unfavorable. From there the user should be able to select the indicator and dive more deeply into the underlying data. A drilldown on customer acquisition might involve looking at how many customers you acquired through cold calls, through inbound marketing, through tradeshows.

If you are at a high level of an organization the drilldown into your key indicators might take you to the key indicators of another department. In the example of customer acquisition, the CEO might be looking at overall customer acquisition, then drill down into new customer acquisition through inbound marketing, which might be the key performance indicator of the marketing department. In turn the key performance indicator of the marketing department might drill into inbound hits on the website and inbound hits via a newsletter, which might be the key performance indicators of two employees within the marketing department. In this way each user can monitor easily their key indicators while being able to go several layers deeper into the data to explore why the key indicator is as it is.

Design simple reports using charts, color, and size to indicate key trends.

An appropriately designed report never forces users to “dig” for important information; the information is made apparent by good design.

A good rule of thumb is to build one simple indicator (often using color or shapes to indicate whether that number is improving or worsening), then a graph to display trends in the indicator, and then finally, if necessary, tabular data to show all the supporting information that informs the graph and indicator. This allows a busy user to see whether the key indicator is “good” or “bad”, then if they have time to look at the longer term trends and the supporting data.

People love to check in regularly to see whether their key indicator is red or green, whether the arrow is pointing up or down, whether the face is happy or sad. Give people these visuals so that even if they have only one minute each day they can get a quick status check on their areas of concern.

Drilldown from your key indicators to the data that support and inform them.

For example, one of your key indicators might be customer acquisition. A good business intelligence dashboard would show you at a top level perhaps the number of new acquisitions for a time period, with the number being in green if the number is favorable vs some metric or red if it is unfavorable. From there the user should be able to select the indicator and dive more deeply into the underlying data. A drilldown on customer acquisition might involve looking at how many customers you acquired through cold calls, through inbound marketing, through tradeshows.

If you are at a high level of an organization the drilldown into your key indicators might take you to the key indicators of another department. In the example of customer acquisition, the CEO might be looking at overall customer acquisition, then drill down into new customer acquisition through inbound marketing, which might be the key performance indicator of the marketing department. In turn the key performance indicator of the marketing department might drill into inbound hits on the website and inbound hits via a newsletter, which might be the key performance indicators of two employees within the marketing department. In this way each user can monitor easily their key indicators while being able to go several layers deeper into the data to explore why the key indicator is as it is.

Develop a data pipeline that ensures key data is loaded regularly.

One of the top reasons why business intelligence projects fail is that the data informing the dashboards is not refreshed on a regular basis. The work that goes into producing the actual display of data to end users pales in comparison to the work that goes into ensuring that all that information ends up accessible on a regular basis to the data store that feeds the dashboards.

This step is perhaps of all the steps the most “technology dependent”, so if you have limited technology resources then those resources should be spent primarily on this step. A savvy non-technical business person can define key indicators and even develop the look and feel and flow of reports, but the stuff of developing a data pipeline involves identifying the key data stores where the data resides, writing extraction code and formatting code to move the data into other data stores, and automation/job scheduling to ensure that this process happens on a regular, predictable schedule. The work involved in creating this data pipeline is significant, but it is crucial to the long-term success of a business intelligence initiative. Without this backend work data dashboard will be full of stale information which will lead key stakeholders to give up on the project.

Deploy reports in an accessible way.

Like the previous step, the work involved in this step is often overlooked or left to “figure out at the end”. However, how your end users get their reports is critical to the whole business intelligence process.

Strategies for distributing reports run the gamut from “have the IT folks send me the data once a week” to a cloud-based, authenticated portals where users can obtain the reports and even make changes to the key parameters. The easier it is for end users to get timely reports, the more likely it is that the overall data intelligence project will succeed. It’s best to think about distribution at the very beginning of a project as some platforms allow for easy report distribution and handle authentication, while others do not.

Platforms such as Tableau and PowerBI allow developers to create easy authentication schemes and distribute reports to users in cloud-based platforms. However, the accessibility of these reports comes at a price – with any cloud based platform security breaches are possible and so extra caution should be taken when distributing reports with sensitive company information. However, ad-hoc or self-hosted solutions have their own set of problems, particularly on making sure that end users can access data when they are away from the office network or on devices with different form factors than their workstations.