Previous Post: How to Make Dashboards People Actually Use 1

From the same studios that brought you “How to Make Dashboards People actually Use Pt 1” comes this riveting tale of suspense, intrigue, frustration, betrayal and triumph. The long awaited SQL (sequel) (pun intended) is finally here….

Alright enough drama. The previous post spoke about a problem most business teams/operators have with data teams, and that most data teams have with business teams. A dashboard, automation or data related related request is sent to the data team. The data team builds it, but more often than not these things happen:

• The business teams receive a different outcome than what they expected, and the solution ends up not being used.
• There is infinite scope creep: “Can we view it this way”, “can we add this view”. 6 months to one year later, you have a dashboard with 20 views and no real value extracted from all the work that has been put in.

This typically results in a return to silos (everyone having their individual excel sheets), and a frustrated and demoralized data team.

This is bad for a number of reasons, the primary issue here being one of “waste”. The lack of adoption and repeat usage of created dashboards mean:

• All the hours of work that the Data team and business team invested in the dashboard initiative goes down the drain.
• Money is being left on the table. Organizations pay a lot for Data Visualization software (e.g. for Tableau Pricing is 75USD per Creator, 45USD per Explorer and 15 USD per Creator - all prices per month). The organization I worked for had 10K plus employees. Not sure what enterprise pricing would cost, but going by this user based model, you are looking at minimum $180,000 per year if all employees needed view access.
• Lost opportunities: when done right, proper data analysis and visualization can uncover insights which could save your organization millions of dollars ( I have seen this done in excel and in tools like Tableau).

So, how can organizations stop leaving money on the table? How can lack of adoption and lack of repeat usage of dashboards be addressed? What can we done to ensure dashboard projects do not end up in the abyss? In the sea of forgotten fellows, in the outer darkness ?

In addition to Collaborative Prototyping ( see previous post How to Make Dashboards People Actually Use 1). Another fundamental change that greatly increased adoption, interest and repeat usage at my previous organization was an “Agile Mode of Delivery”:

Agile Mode of Delivery:

Here is some context to preface the definition of this phrase. There is a popular saying “Culture eats strategy for breakfast”. This proves to be true, no matter how good a plan or strategy is, the recurring habits and accepted behaviors in any group determines the outputs or results that ensue.

Depending on what industry, or department, or business unit the dashboard or data product is being built for, there are certain mindsets, habits (culture) that hold sway. E.g. in Supply Chain, most leaders are used to Capital intensive projects (things like Warehouse builds or renovations, transportation fleet purchases or revamps etc.)

These projects adopt the mindset of traditional waterfall project management methodology i.e. tight dependencies (one thing has to happen before another thing does, there is no room for much concurrency). However, data teams primarily work with software which favors an Agile project management approach. Software success is usually largely dependent on user preferences, which can often change on a dime.

In most projects that follow tradition waterfall project management methodology e.g. Civil engineering projects, safety is prioritized, customer needs and satisfaction are secondary. In majority of software projects agility and adaptability are prioritized.

This causes a conflict, when data teams interface with a business or team with this fundamentally different mindset, there can be tension.

What was observed in this scenario was that the dashboard build process was being done with a traditional waterfall approach. The requirements were given, the data team goes and builds for weeks and months and then delivers the dashboard at the end of that time period.

From the time the work begins, all you have is a discovery or requirements document, and then at the end of the period a solution is presented. For the time frame in between, the team doing the build is working in isolation.

With the pace at which the world changes today, the needs when the project was initially documented could have completely change in the weeks or months the development work was ongoing.