As Erin Stevens wrote in her three part series: “in order to build a culture of self-service analytics, you need two things: the right tool, and the right support.”
At Tableau, we use the Drive methodology both internally and with our customers to drive real-world return on investment. One way to ensure continuing ROI on your Tableau investment is to take an Agile approach to your visual analytics.
Visual analytics is fundamentally different from traditional business intelligence or reporting. As such, a traditional waterfall approach using Tableau can stifle creativity and blur insights, possibly even resulting in failed adoption.
The key to bridging the traditional approach and Tableau’s rapid-fire analytics approach is to implement a repeatable analytics cycle framework.
Why You Should Adopt an Analytics Cycle Framework
So what does an analytic cycle framework look like? Here is an adaptation of the intelligence analysis cycle used by the US intelligence community to standardize and facilitate intelligence collection, analysis, and dissemination.
As a member of the Naval Special Warfare Intelligence team, this intelligence cycle is what kept us focused with repeatable results. Drawing on that framework, here is my adapted framework:
Notice first that this is a cycle. One of the advantages of Tableau is the ability to cycle quickly. So each stage of the cycle can last anywhere from five minutes to days, depending on the type of question or questions being asked and the availability of data that can answer the question. Let’s take each stage of the cycle and expand our understanding of what each stage entails.
Ask the Right Question(s)
The first step involves asking the right question. This is not as straightforward as it might first appear. Too often, the problem domain or question to be answered is not clearly articulated. Instead, the typical response is to begin asking for “report requirements.”
Let me give you an example. I once visited a customer for a joint dashboard-development session with about 15 people. I asked them what problem they were trying to solve. They spent about 90 minutes trying to explain what the question is they were trying to answer.
When we finally figured out the right question, it was clear why they’d struggled to get there. They had a row-level view of the data, not a business perspective. The lead business analyst later told me that he’d learned one of the most valuable lessons ever–to ask the right question.
In this example, the discussion had devolved into the typical bottom-up create-something mentality. Framed a different way, in private plane flying, we call it “getthereitis.” Most IT folks and business analysts are taught a work-breakdown approach, breaking the problem down into discrete steps then trying to pull it all together at the end. In contrast, most scientists first develop a hypothesis or research questions, then figure out how they are going to test it.
The late statistician W. Edwards Deming famously said, “You can’t manage what you can’t measure.” But he had an unfortunately less-famous corollary to that, which is: “Be careful what you measure, because that’s what you’re going to get.” In other words, if you’re not asking the right question, you might not be getting the results you expect!
Conclusion
In part one I’ve covered a general analytic cycle. I’ve also articulated the reasons and value proposition for adopting a cycle that will enable and empower knowledge workers across the enterprise. Finally, I covered the starting point of the analytic cycle: asking the right question. In part two of this series I will cover the remaining steps of the analytic cycle and summarize the value proposition for self-service visual analytics.
Copyright 2016 by David L. Fisher, All Rights Reserved.