Alice: Would you tell me, please, which way I ought to go from here?
The Cheshire Cat: That depends a good deal on where you want to get to.
Alice: I don’t much care where.
The Cheshire Cat: Then it doesn’t much matter which way you go.
Alice: …So long as I get somewhere.
The Cheshire Cat: Oh, you’re sure to do that, if only you walk long enough.
Lewis Carroll, Alice in wonderland
This short excerpt from one of the world’s most famous stories can serve as an excellent teaching tool for our BI and analytics implementations.
If you don’t know where you want to go, it doesn’t matter what way you go. Many BI implementations are just like that, the major players don’t know where they want to go. If I were to ask many BI team leaders and directors where they wanted to go, there is a chance that I would get some very interesting answers. If I were to walk into your BI shop and ask your ETL developer, what’s the purpose of your BI implementation, what would she say? What are the odds that she would lay out a well thought out plan of where BI is going in the company and the importance of the team and her role in it?
Your BI must have purpose. What is the vision statement for your BI and analytics implementations? The projects associated with it must have purpose. It’s likely you are saying to yourself one if three things:
- Oh crap, he got me on this one
- This stuff is for the birds, we just need to get work done.
- Hey, this BI Pharaoh guy is on to something here, I’m with him!
If you fall into the third group, good for you, and thanks for reading the article mom. If you are in the other two camps, read on.
There is good reason why many BI implementations are not living up to the hype. I’ve even seen very efficient teams that deliver features and reports on a regular basis still lack luster in the end and have less than stellar performance when it comes to user adoption. It is because of one essential concept is missing from the thoughts and minds of some data professionals. Fundamentally more important than what you do, is why you do it and how you do it. Business Intelligence and analytic teams are no exception.
We often focus on the what to do. It’s natural, it’s what we are graded on. It’s the stuff our bonuses are based upon, and the reason we are hired to begin with. Let me be clear, WHAT to do is extremely important and can seem like the most important thing because after all, it’s the deliverable, it’s the thing we see. However, I would submit that it is literally the tip of the iceberg. Just as 90% of the iceberg is underwater and unseen, 90% of the work associated with a great BI delivery is under the hood as well. It is unseen, and maybe that is the reason it is so often overlooked. Here is a concept that when done properly could take your implementation to the next level.
Asking Why
BI Teams spend a ton of time on the “what” of a project. Most project plans and agile user stories are centered around WHAT to do, WHAT to build. They are littered with tasks and acceptance tests for the what. Over my career I’ve been involved in projects where that was the only question asked: What do you want? There are two very fundamental problems with this approach, and it is ultimately the wrong question. At least the wrong question to ponder first. If you have been involved in the BI space or even the software development space for longer than 15 minutes, you will be familiar with these problems:
First problem: Customers don’t know what they want.
Second Problem: Customers have never seen what they want.
These two issues are important to internalize. If customers don’t know what they want and have never seen what they want, handing them essentially a blank blue print and asking them to draw a house and sign it in blood, is a recipe for a disaster. Which is pretty much what a user requirements document is.
So, if asking what do you want is the wrong question, then what is the right question? I’m glad you asked! I knew you would ask that, that’s why I wrote the next sentence. Customers may not know WHAT they want, but they do know WHY they want it. Understanding the why of a user demand is paramount in building a solution that people will use repeatedly, day in and day out. While the question of what they want may change 100 times, why they want it will remain a constant.
Imagine you want to go on vacation. You may consider many different locations to visit. If you are working with a travel agent, they are going to first find out why you are traveling. They need to know right away if you must be in Vegas for a convention, travel home to see a dying relative or just going somewhere in the world for leisure because you have some time off. You don’t need me to guide you in understanding how differently the agent will treat the situation given the “why” of the travel plans. For vacation, the time frame may be inflexible however the location is fluid. What to do on vacation may change 100 times, but why you are traveling will not.
Unlike Alice, you should know where you are starting, where you are going and then map the plan to get there. Your GPS works this way. You punch in an address and the GPS locates your current position and maps out the best plans to get there, even a timeline. But just like a GPS, the further away something is, the more the timeline is just a guess.
With your GPS, the result is that you “get there”, hopefully. Keep in mind there was a REASON you wanted to get there in the first place. To visit a loved one, job interview, business meeting etc. and it is this “why” that is missing from many BI and analytics implementations. I have personally watched companies spend millions of dollars on something no one, from the CEO down, could answer the question of “why are we doing this?” Believe it or not I’ve also seen a couple of instances where the question of “what” are we doing could not be answered either, although this is much rarer.
Ultimately, knowing why you are going somewhere or doing something helps to dictate the what. If you fail to define the why, the what will continue to move and the “there” won’t matter, because no one will use it anyway. At that point, you can change your name to Alice and just start walking, i.e. implementing, in any direction, because it won’t matter either way, to anyone.
