We need to install the tool X, said the CEO. How much does it cost, asks the CFO. Why do we need it, asks the analyst. There is not a best-tool-for-everything. Your own and unique context should determine the right tools for your company.
This post can be thought as a continuation of our previous
post called “The broken pyramid, or the hungry hungry hippos game”. In that occasion we discussed what happens when a company decides to
stop the data-related processes at the reporting step and
forget about further analyzing and predictive analysis. In this post we are going to discuss what happens when a tool is
chosen without contemplating the scenarios for its usage. This is another
major disaster. Let me recall four different stories I’ve faced in the last years.
The current tool is the worst you could ever have.
We were doing consultancy for an e-retailer in the European market. The company decided to open a new channel: Wines. For this sake, they hired an experienced Wine buyer and expert in its logistics (pretty fascinating, by the way). The guy, as we can imagine,
had no experience in the digital world, and
hardly used data for its strategy and daily operations (according to
Avinash, these ones should be immediately fired). It was a promising start! Right after he joined I was explaining him how to use our BI tool (Qlikview). He did not seem impressed. When I asked him why he answered: “SAP is the best tool for this kind of things”. Of course, we did not implement SAP. For the business complexity the company faced at that moment, Qlikview was more than enough. Actually, it still is. He never used Qlikview, he never used data. He was fired three months after.
The best-tool-according-to-the-CEO.
Another situation I can recall is when the CEO of another e-company came to me and said: I’ve been in a conference, and now I’m convinced this is the tool we need for A/B testing. I don’t recall the name, but it was not one of the most used tools in the market. The tool was very complex to implement, the setup of every test was a nightmare and we hardly managed to implement a single complex test successfully. And, of top of that, it was very expensive. Result: no more A/B testing because “it’s a framework that brings no added value” (sic). Pretty disappointing.
We have a great tool but lets try another one.
Another situation that needs to be avoided relates to the fact of changing of tool with no apparent reason. I remember another situation in which we were using Google Analytics for web tracking. The CIO came to us and said that he managed to get a free trial for another tool (Mixpanel). We were reluctant because the tool we were already using (fully deployed and operational) was enough for our present and short and mid-term needs. We were happy with it, users were empowered, lots of decisions were taken out of it, and we did not understand why we should try another one. We implemented Mixpanel while in parallel we were working with Google Analytics. Of course, we could not use all Mixpanel’s features and the final result, according to the CIO was: “Mixpanel is a bad tool”, which is totally inaccurate. The implementation of a tool requires time and focus. If you don’t have them, don’t start a new implementation.
I need this-and-that but I will use none.
Knowing and understanding the needs is as well a very complex task: we were doing that job for another company and I recall a CMO saying that he wanted a BI tool with real-time reporting capabilities. When I asked him why, he was not able to answer. He just wanted it, despite having no resources and no process defined for reacting based on information that arose from real-time data collection. Result: we implemented something (very expensive) that can be translated as “real-time”. It was hardly used. After tons of money spent and an extremely complex implementation, we came with a tool that had lots of features but were, by far, underexploited.
Based on these four (horrible) experiences, we can tell that the tool is the result of your needs, and it deeply depends on your own and unique context. The opposite will hardly work. This, however, is a very complex process, and you need to proceed thoroughly in order to get the best tool possible for your case. Communication with the stakeholders is the key: know their needs, know the current status, know a roadmap for the short and mid-term, etc. If you can’t do this by your own, I strongly recommend you to hire a consultant to do this job with an independent view.
To summarize, take always into account your context in the moment of deciding which tool to use:
– Talk to every potential user of the tool.
– Establish realistic needs.
– Stick to the tool unless a new set of realistic needs appears and your current tool can’t fulfil it.
And, last but not least, remember the 90/10 rule: 10% of your budget for tools, 90% for people exploiting them.
Good hunt! There is always a right-tool if you understand your context.
