I attended the Business Intelligence symposium at the University of Cincinnati business center (more Info here). There were three sessions in the symposium:
- 84.51 explaining how they were structuring their analytics development program to meet the needs of the growing analytics market
- Andy Kriebel on what are the fine lines that differentiate a good analyst from a great analyst. He also gave us a glimpse of his workplace (The Informationlab – http://www.theinformationlab.co.uk/) – More about this in a future post, as I was particularly fascinated by this part of his presentation.
- Procter and Gamble
I should say I particularly liked the session of Andy the most. For starters, his presentation was amazing. And by amazing I mean, not even for a moment you thought of anything to complain about the powerpoint deck he made. No extra text, no unnecessary colors, correctly driving the story, brilliant sync between the horizontal and vertical logic of the presentation. So much so that one of the beginning slides was Rachel (of F.R.I.E.N.D.S fame) showing the middle finger from a movie I like – The office space (go watch it if you haven’t already).
Moving on, some of the points he focussed were indeed what an aspiring analyst should be thinking about if he wants to be a great data analyst (or atleast if he wants to very good at what he does). The points are as follows:
A good analyst is
- not a yes man
- knows basic coding
- has good business acumen
- knows basic stats
A great analyst on the other hand
- understands the story behind the data
- is interested in what he/she does (don’t think of it as a job)
- is curious and imaginative
- understands the context
- builds good visualisations and tells great story from them
- can decipher the message
- is methodical
- can spot trends and themes
- is a great story teller
All the above points completely resonate with anyone who is passionate about analytics. These are also the points that were particularly stressed upon in my ex-company. Although many often fail to understand these in the context of solving an analytical problem and just try to finish their job, be done with it and go home for the day.
One point missing from the above for me was about identifying the patterns in the problems themselves and leveraging the solution of one or more previously solved problems in their company.
Understanding the interconnectivity of the problems is according to me an important aspect going forward as you keep on adding to the list of problems you have already solved using analytics. Not being able to do so will not only possibly lead to a suboptimal solution to the current problem at hand, but also might rob you of the opportunity to think about what other problems can be solved due to the solution of the current problem at hand. Both these aspects not only improve decision making in the companies but also have an immense impact on their attitude towards tackling future problems.
Treating any analytics project as a standalone entity is one of the major negatives currently in the analytics market as per my understanding. Another negative which I would try to talk about in a different post here is – the ability to reject/change the solution which you are trying to find for the problem at hand.
What I essentially mean by that is – often we get a problem to solve, and depending on the company we are a part of or the processes we follow, we set about solving that problem. In doing so, we already have an idea of the kind of solution that might be waiting for us at the end of this project. But, how many of the analysts out there have the ability, rather the courage to look back at what they have done, take a pause and think if they need to rethink about the solution they have been chasing. I have more thoughts on this which I will try to put together in one of my future posts.