Know the winners - internalize their failures

When we say that we should learn from winners - do we necessarily mean learning the winning ways. Of course, it is important to know the winning path. But, not without learning about all the failures & setbacks that created the winner.

If a person has never lost, it's a dangerous pit in which he is falling into. I can just pray that it doesn’t get too late when he loses - too late to remember the art of fighting back.

A winner is to be seen as a book - as a philosophical guide, where the win is just a milestone and not the destination. And his life is the journey we should seek after. We keep talking of the essence of 'not' reinventing the wheel all the time. That is true even when we learn from others' failure - but here we need to be very careful. We should not dare to undermine the scenario, the environment and the exact proceedings that lead to a certain success or failure. A new scenario & your efforts might well be a harbinger to success.

Remember, "Success lasts only till you fail - and then you start learning!"

I am excited to know some of your success stories (ahem - your failures). You are welcome to share as comments.

What not to do when you are asked to solve a problem - Part 2

You are given a task by your lead to complete. It's a problem that you must solve. How do you go about it.

A few weeks back, I had talked about how frustrating things go when the solution you provide and what is expected doesn't match. Click here for the article.

From the collective experience of my peers, my team mate and me, I would rather follow the seemingly long steps mentioned as under

1. Go through the task yourself once before you discuss it with your lead (assuming you have received a mail from him) [30min to 45min] 
1. Make a note of what you understand and the questions that you want to ask 
2. Get the following (you may be completely wrong - and that’s the point!): 
• You must understand why you need to do something, i.e., how is your task going to help 
• Insist on this if your lead doesn’t want to answer this the first time 
3. Attempt to first create a rough sketch of the solution expected 
1. Eg if a report (or a presentation) is required, make a rough sketch with the following: 
• The flow of the story --> flow of the slides in a deck 
• A table with various columns that will be displayed as an output 
• The various input options that the report is expected to have 
• Any charts/ graphs with the axes labeled clearly and the type of chart 
2. If an analysis is required, keep a rough note of the following: 
• First and foremost - what do you want to build --> a descriptive analysis or a predictive model or is it a prescriptive framework 
• Other details that must be thought out at the very start (Out of scope for this topic) 
2. Go with your notes to discuss with your lead [30min to 45min] 
1. Make the necessary changes to your notes and confirm your final notes with your lead 
2. Give your inputs now (Get creative - but revisit the Objective if needed): 
• Is there anything else that could be a value add to the customer 
• Can we do this differently 
3. Ask your lead, if you need to confirm this with your client 
• Sometimes, it's better to take the customer's input right at the start - to make sure you are at it 
• Make changes to your notes accordingly 
3. Discuss with your lead regarding the DATA [15min-30min] 
1. If you have the relevant DATA - tables, columns, etc 
• If not, how to get the data (Contact any other team mate? Request approvals?) 
• Discuss definitions and formula to calculate certain new 'measures' 
2. What should be the scope of the data - time interval & any other 'filters' on the data that you must apply 
3. Any special business rule to follow - to change the part of the data 
• You must be thinking that you have taken up two hours already and you haven't started with the deliverable. But trust me, if you have followed this process, your job is half done already. And the rest of the path is as smooth as it can get. And if you haven't followed this process, you are playing a 'finding a black cat in a dark room game'! You might end up with a perfect solution, but not always.
4. Make a note of the 'time to delivery' & understand if it is an ad hoc or a continuous project [15min] 
1. If it is not an ad hoc report, no need to concentrate on automation, etc. 
2. The priority should be to get the work done & validate it for quality 
3. If it is a project, your lead will surely come up with a project plan (including timelines) 
1. Review the same and raise concerns if necessary 
2. Make sure that internally you have a 'milestone' tracker to refer to 
5. Start executing the plan
1. Revisit the task objective and your notes whenever required 
6. Make it a point to review the solution with your lead at the half day mark once 
1. To give yourself a chance just in case things might look even uglier later 
2. Less rework later means faster delivery 
7. Solution delivery to client 
1. If you have already taken the customer feedback of the plan, your job is much easy here 
2. Customer gets exactly what he has agreed upon 
1. Be open to make those 'finer adjustments' to the solution 
2. After all, customer is God ! 
3. You get your peace back! 

Assumption: Your lead has the last word.
However, if you have experienced that your manager [or any other senior member] gives you end of day feedback on the solution and expects the solution to be changed, make sure he is invited to the review meetings with your lead. If this isn't the case, bring this up during your meetings with your manager.
So to answer the question, 'what NOT to do when you are asked to solve a problem?':

Do NOT start solving the problem immediately!

Give it a thought - if you are the kind of person who hate unnecessary rework :)

Let me know your thoughts and share with your experiences about how not 'giving a bit of thought' before you started solving a problem turned out to be a mistake you could have avoided.

Happy Solving
The Analyst Charioteer

What not to do when you are asked to solve a problem - Part 1

You are assigned a task that you need to complete in the next couple of days. You know that time is not the luxury that you have. You start off answering the question by pulling out the data required; calculate the metrics; design a visualization to enhance the report; mention some of the insights you found from the analysis and share with your lead. Now the lead comes back with a few inputs/ suggestion which you go back and work on. Finally, after a day and a half's work, you share the results to your boss who lashes at you and your lead saying you haven't answered what our client wants and rather you are just giving some information. You have a few more hours left and you don’t even know what was wrong. Do you start again from scratch? Do you change how you approached the problem at hand. You pull your hair in despair. How many times have you faced a similar situation? Have you learnt from it. This post is for the 'humans of the Analytics World' who has committed the heinous crime of overlooking the objective of a problem. The elite rest may choose to skip this post.

To be continued in Part 2

Trilogy of the Averages

If the law of averages holds good in our day to day cases that we see, should we not name it something else! :)

Long ago, the curriculum in the Indian intermediate schools introduced us to 'average' for the very first time. When it was mentioned of five persons with weight 68kg, 71kg, 75kg, 73kg and 70kg, we learnt to calculate the 'average' weight of the persons to be 71.4kg. Close enough! We kept creating the sphere of averages around every dataset we saw then and we were never less proud of the outcome.

A few years from there and we cam across the terms 'mean', 'median' and 'mode'. 'Mean' had nothing mean about it. It was the common man's average with a glittering new name. We learnt to adept to this new term quickly and use it at discussions just so that we bring an air of intellect along with it.
We learnt that mode was nothing but the most frequently occurring value in a set while the median was the middle term in a sorted set. We were no less than statisticians now that we know the 'trinity'.

It always troubled me, that MEAN is not the 'real average' in most practical scenarios. And I also knew that median fits into the role better (to define averages) in most of the datasets that I had handled till then. However, the why of it was what I had always wondered about. It was not until I started playing with numbers professionally that I had an answer to it.

I had started rejecting the notion of taking the mean and would rather go ahead with median in most of the analysis in the many projects I was involved in and it never fired back. Was I just lucky or was there something going which I couldn't figure out?

I realized it was all about the variance in the data that called the shots. Real world marketing data would have lot of variance. Averages fail miserably there. Take an example of a dataset having the revenue of the merchants in a region. The variety (or variance as statisticians call) is huge. Let me help you imagine. Consider this region to have around fifty small merchants having revenue of a few thousand. Additionally, there are a couple of mega merchants in the vicinity with revenues close to a million. If we find the mean of the group, we would get an average that is close to four times to the scenario if we didn't have the two mega merchants. Do you realize how disturbed the mean value is? What happens if we take the middle term of this data set. You move much closer to the 'real' value. Bang on. Don't just start applying MEDIAN in all business situations. Lets look at one more scenario before deciding the pick among the trinity.

Consider a service company that has service tickets to track all its services. The overall range of duration of ticket closures is found to be between 3 to 48 hours. We already understand, in cases of such high variation in data, its safer to ignore mean value. Had we considered median value, the middle term would have been nine hours. When we closely observe the durations, we see that most of the tickets are getting closed in three hours. Let's assume that the business wants to benchmark their closure standards to measure performance. What would they consider - 9 hours or 3 hours ? They would do well to set three hours as their benchmark closure time. Won't they? Hence, MODE gets an upper hand in this scenario.

I haven't got into the quartiles & the range - looking at which we decide whether there is a need to 'clean' the data before we proceed with any analysis. This, I will take on some other day.

I like to make an analogy of the trio of averages with the Hindu Trinity. We have the Lord of Creation, Brahma. He has created everything, full of knowledge, respected by all, and yet doesn't have a temple to Himself. It's like the mean. It all started here. And yet it is often best to not choose mean in real life!

The remaining duo of Vishnu & Mahesh, the Lord of Sustenance and Destroyer of Maya respectively is all powerful, followed by millions, feared by many and loved by all. And yet you make a fool of yourself if you choose One over the Other. Its like the duo of Mean and Mode. We need to carefully understand the data and the business problem that we are trying to solve before jumping on to pick one out of the duo (in some cases the trio).

I will end this post by reminding the readers that Analysis is more Art than Science - here, nothing is an absolute right or an absolute wrong. It all depends on what you want to achieve out of the analysis. Statistics on the other hand is hard numbers. The irony is numbers do lie!

Happy Analysis!! :)