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.
The solution:
The solution to this was to borrow one of the fundamental values of Agile development (develop working software over comprehensive document.) The goal is to deliver a working version as early as possible and then build incrementally on top of that. (see image below).
In the traditional approach, at every stage from requuirements, to design, to implementation to verification; all the end user has are written updates e.g. discovery documents, email updates etc.
In the agile/incremental delivery approach, at every stage, there is a tangible product (no matter how basic) the user can interact with. This product is then incrementally improved until the final product is delivered.
Here is a specific example of how this is different from the previous approach in the context two dashboard build projects I was involved in.
| Waterfall Approach (at least in the department I had worked for) | Agile Approach |
|---|---|
| Dashboard builds were usually done mostly in isolation after delivery, there was a huge gap without any direct communication after discovery. | From the first week after discovery, there was a tangible product. In week 2 there was a powerpoint prototype, in week 3, View 1 of the dashboard prototype had been built with a subset of the data while the rest of the historical data was being sourced. |
| During the build stage, there were minimal meetings with business users/end users. Sometimes weeks would go by before any correspondence. The correspondence was usually a verbal or written update. | Weekly touchpoints were setup, sometimes as short as 15 mins per week. Each week a visual or set of visuals were displayed, the visual prototypes were made available online for the users to interact with. |
These small changes made a huge difference. Here are some of the major benefits I noticed from this approach:
- It built trust between the data team and the business. The frequency and the honesty of the communication made a lot of difference in this regard. On some weeks when there was no progress from the previous week, that was communicated, and the reason for the lack of forward movement was communicated as well.
- It gave the business a sense of ownership, the end users felt like they were a part of the building process. They saw the dashboard grow an evolve from a prototype to single visualization to the multiple views on the dashboard. By the end of this process, it was their baby, they watched it grow into a full blown adult (they grow up so fast 😪)
At the end of the day, in combination with the visual prototype which ensured that both the business and the data team knew what the finished product would like; at the end of this project. The interest and adoption and repeat usage of said dashboard was such as the world has never seen (ok a tad exaggerated. Such as the department had never seen).
For future dashboard builds , consider delivering something tangible as early as possible in the process (a visual prototype, an actual visualization on the dashboarding tool etc). Give the end users something to use and play with as soon as possible and build on top of that.
Leave a comment on the results you see.
Have a productive day ✌🏿
Side note: Traditional is not a bad word, neither is waterfall. Waterfall methodology is better in certain contexts. E.g. in Civil engineering, when building a house, a skyscraper, a bridge, you don’t want to be agile. You don’t want a mini-bridge or a mini house and then build on top of that. Everything must be done in sequence. Surveying, soil analysis, foundation, walls, roof etc. There is no way around this. Keep this in mind based on the context.