News :: May 21, 2019

Dashboard Development – 5 Insights to Speed and Clarity: Purpose

Dashboard Development - 5 Insights to Speed and Clarity: Purpose

Published on March 18, 2019 via LinkedIn, by Jeremy Kuhlenbeck

Next up in my 14-in-2 dashboard development series is the 5 insights for speed and clarity.  So let’s jump right in.

(Btw, as I started writing this out, I realized that five in one post would make for a very long read.  Stick with me over the next few days and weeks to walk through them one at a time.)

“The most difficult thing I have ever had to do was tell my boss that a project needed to be shelved.”

1.    Purpose

I know, you think this is a copout here.

Purpose cannot possibly be an insight – can it?  A defined purpose is an absolute must, and this is where you are going to have to talk through the tension and build trust with your boss (more on that in a bit).

What I mean is, many projects start out with an extremely vague purpose:

“I need you to build a dashboard for our warehouse data…. I need you to build a dashboard around our food industry data… I need you to build a dashboard on our executive finances.”  

These are NOT purpose statements.  What these are, actually, are inroads for your company, your boss, or whoever is paying you to keep you and your company employed.

Therein lies the tension. Our companies need to always be drumming up new business, so they will find every sliver of an opportunity to get you in the door.  Once you are in the door, however, it’s up to you to know how exactly to establish the purpose for your work (See BIDS Methodology on… and, it’s up to you and your boss to know how to pull the plug on a project that cannot find its purpose.

The most difficult thing I have ever had to do was tell my boss that a project needed to be shelved. For whatever reason, be it the data was not ready, the business rules, calculations, or formulas were not yet established by the business… it’s important to know when a project is not ready and note what is the responsibility of the business SMEs and what is the responsibility of the developer.

Build your relationship with your boss.  Build trust so that when you tell him or her that the project lacks direction or purpose, together, you can come up with a way to politely shelf that project and pivot to another.  Then, your team will have to find a way to help the leaders on the shelved project get ready for another run at it in the future.

So how do you find a project’s purpose?

Well, in the coming days and weeks I’ll discuss the remaining insights. These insights tie in so tightly to purpose that we will see it develop as we go through them all.  For now, let’s look at some situational examples of purpose at a high level.

Real World Example #1

Food Industry Store:  Company XYZ

Company XYZ is excited to bring you and your team in and establish some dashboards to help them drive insight and make better decisions regarding their food industry sales and usage. After a couple of meetings, you were able to determine that they have two main issues and one missing metric.

  • First, data is siloed into two areas, the transactions of the stores and the cost of labor for those employed at the stores.
  • Second, the current decision-making process for products is based on the metric / key performance indicator (KPI) of sell-through percentage or essentially the turnover of products put on the shelves each day.
  • And last, they are not yet analyzing the profitability or margin of their products.  Sell through percentage is their current gold standard.

From these discussions, we can determine that our goal is to correlate a “true-er” cost of goods sold by bringing together the vendor price for each product and the labor cost of the employees for the stores.  Together, with the sales cost and sell-through percentage, we can help identify profitable and in-demand products.

Boom.  Purpose.

An interesting byproduct here is that after seeing the data in a dashboard for a while, the company can begin to develop core values for new products they introduce to the stores. If a product doesn’t meet a minimum margin threshold, don’t bring it in… turnover is slow, I don’t care how amazing the product is, don’t keep it around.


This is where people like you and me can get tripped up.  Just because you are a brilliant thought leader, that doesn’t mean you are supposed to come into each situation bringing your own formulas or calculations (but double check everything they give you).  I know this sounds weird, but I have seen it over and over, the developer gathered requirements to do a certain calculation, didn’t ask the business SME for the formula, went back to their desk and decided to figure it out on their own. Why?  Ego, assumption, or lack of communication – because it was not comfortable to push the issue or simply due to the developer assuming they already know how to get there.

The business has most likely been doing some reporting for a while now.  They have their formula or know how they would like it calculated once you bring the data together.  Their SME is with you precisely for this moment (let’s hope that they have benchmarked with the industry standards – you can lead them into that if you feel they haven’t).

Using the BIDF spreadsheet from will help greatly in this metric requirement gathering process, but your job here is very specific.  You identify the metric, in this case, Cost of Goods Sold (COGS) with Labor.  Write that down, and then ask them how they calculate the labor costs into the cost of goods sold.  If they do not have the calculation on hand, let them know you will need them to get that for you in order to include this metric. They own whether or not this metric is added to the dashboard by doing their homework and bringing back the company’s preferred formula.

Again, I’ve seen so much wasted time in this specific area of a project.  Some developers are less of the “communications type” and more of the “data type”.  They feel that it is more comfortable to try and figure it out on their own than it is to let there be an awkward silence in a meeting with the SMEs or they just don’t feel comfortable giving the SMEs homework.  I DON’T CARE.  YOU WILL WASTE TIME or possibly fail if you don’t push out of your comfort zone, communicate clearly, and let the business know what you need from them.

Continue on with this same KPI and formula requirement gathering process until you are done gathering all the KPIs.  Try to keep your KPIs down to three to five.  Engage the SMEs in open discussion on their thoughts on the importance of each metric to get them to hear their coworkers’ opinions.  Let them come to the conclusion on which three to five are the most important.  Also, don’t fret if you only have one or two.  You can definitely build a dashboard with great insight around just one or two metrics.

In my real-world example here, I was able to bring the siloed data together for the first time for Company XYZ.  What was fascinating was seeing the stores that had hit their preferred goal for sell-through percentage and and then layering on the profitability and labor costs metrics. When we added the product profitability and cost of labor for the first time, the company realized that sell through percentage on its own was extremely misleading.

Some of the stores that hit the sell-through goals had either labor costs or products costs that were well above their industry standards.  The decision and dashboard from that point forward were to always have these three metrics displayed together – COGS with Labor (e.g. Estimated Revenue), Sell Through Percentage, and Food Cost Percentage. These three provided the clean and clear insight they needed.

No alt text provided for this image

Real World Example #2

Accounts Payable:  Company XYZ

Company XYZ loved what you did when you built their dashboard for Estimated Revenue, Sell Through Percentage, Food Cost Percentage, so they brought you back to help with the Finance side of things.

In the finance group, it was determined that most vendor contracts require interest to be paid on invoices over 30 days old.  The company would prefer to not pay more than they have to, so obviously avoiding interest charges was important.  Now we are finding our purpose.

We were able to determine that the goal of the dashboard would be to guide the accounts payable personnel to interest-bearing invoices that needed to be paid off.  Since there were already a few, we set a goal for this metric to pay off 15 percent of all interest accruing invoices by the first of the next month – every month.

Additionally, assist these same individuals by identifying the count and cost of invoices that are coming due over the next 10 days.  This information would provide the margin they need to get ahead on payments before incurring any interest.

To round things out, we added a third metric for more margin and provided the count and cost of all invoices coming due in the next 30 days.  Somewhat duplicative, but a good, aggressive mindset.

In this real-world example, I ended up developing the solution in Tableau.  The bottom third of my dashboard consisted of three columns, a list of Past Due (Over 30 Days) invoices by invoice number, an “actionable goal” dynamic calculation for Past Due invoices, and a list of the invoices that are coming due in the next 10 days.

No alt text provided for this image

The dashboard user was able to select or shift-select multiple invoice numbers in the past due column which would then update the actionable goal column.  If the goal is to pay off 15 percent of all interest-bearing invoices, the user would see instantly what percentage of the goal the invoices they selected would cover.  If two invoices were selected and they were at eight percent, they could shift select more until they saw that they hit the goal.  They were then able to write down those invoice numbers, take the necessary payment action, and know they accomplished what Company XYZ had tasked them to do for the month.

They were also able to look at that third column and identify if they had enough financial margin to start paying invoices in advance of accruing interest.

Final Thoughts on Purpose

For speed and clarity, make sure you have a project document that starts with a purpose statement – work on this together with the SMEs so they can see the progress or lack thereof. Conduct a couple of initial meetings, and if you are not able to come to a clear and concise purpose statement, you will have to re-evaluate and decide if you are on track to developing the purpose statement or have that difficult discussion with your boss about shelving the project.

“A clearly defined purpose statement is your first priority.  It will either build your project momentum or get you out of a project within the first week.”

Purpose = clarity. Lack of purpose will always lead to scope creep.  A clearly defined purpose statement is your first priority.  It will either build your project momentum or get you out of a project within the first week.

How to use your purpose statement:

In your subsequent meetings, use the purpose statement that you jointly developed with the SMEs as your boundary or safeguard against scope creep.  Because the purpose statement was a joint effort, your SMEs now have buy-in on the goal and will be better receptive to “parking” those additional thoughts and ideas they come up with for potential future projects.

Quotes on Purpose:

“Without a purpose, your story will fail to connect with the audience.”  –The Anatomy of a Data Story by Nicole Hitner

“Execute. Execution is the only thing that matters but how do you execute?  It starts with having clear goals. You need to know exactly what it is that you’re trying to accomplish. If you don’t know what you are trying to accomplish you are never going to get there. That is simply the clear truth.”  -Tom Bilyue as a co-founder of Quest Nutrition, the second-fastest-growing private company in North America on the Inc 5000 for 2014 (ok, its says goals but translate that as purpose)