Having recently got back into coding after a long time of managing analysts, I found myself doing exactly what I had told them not to do.
As part of a recent project with one of our clients, we have been analysing patterns of behaviour of their customer base - creating a RFV segmentation, developing buyer clusters and product associations.
All providing a great platform to flex my recently honed R skills. Thoroughly delighted to be wandering though lots of data and creating lots of models and charts - only to realise that I was drowning in the analysis, obsessing about the nuances of the data when things didn’t quite tally and losing hours trying to crack a particularly tricky bit of code that wasn’t actually needed in the end.
I had also become very protective of my/the data and not too keen to share what I’d learnt - I think in short it was because I hadn’t learnt much and I certainly didn’t have a ‘story’ to tell my colleague, let alone tell a client, what the output was telling them and how to apply it to grow their business.
Oh how I laughed! And then cried as I realised how much I had over-burned on the project.
So, I gave myself a talking to.
And reminded myself of what I used to say to my team to keep a project on track :
Always work to a brief that you have feed into and agreed that it is achievable with the data available.
Understand how the output is going to be used by the client, so you can prioritise the most important aspects of the analysis.
Determine whether it’s trends or financial absolutes a client is after - this can save hours of time by not having to obsess with the 0.01% differences.
Have check-in points with a key stakeholder/client to deliver the different phases of the project.
Sense check new thoughts or finding - it’s great that you’ve found something you hadn’t expected, but check in the priority of it before investing too much time.
If something is not working, doesn’t make sense or is not tallying up - take a step back and talk it through with a non-technical colleague - they might not have a clue what you are talking about but by talking through the steps in a simple/logical way often unblocks your thinking.
Always give yourself some ‘sense check’ time before you check in with the stakeholder - there is nothing more frustrating on both sides when you are thrown by a number that is obviously wrong and you hadn’t spotted it or know why.
Try to focus on the output - yes you are a genius for working out how to have done something particular tricky bit of coding but talking through the inner workings of it will quickly lose your audience.
However, it’s not all on the analysts shoulders, it’s also the responsibility of the project lead to make sure that there is a clear brief and hypothesis for the analyst to work from.
It was good to remind myself of these tips as I worked through this particular project, I am keen to get my teeth into the next one…