image credits: John Kars photography | Grad Australia
Thoughts and fears going into Project Week
One of the most exciting aspects of our training at The Data School, besides the obvious analytics, is that each of us gets to be project lead for a week. However, I have to confess I was dreading even the thought of being team lead on a project week. I have had previous experience leading teams but in a very different context. I loved that experience, and I think it went well, but it’s been a while, and I never thought of myself as a natural leader. In fact, I had to work very hard in order to get good at it. I had lots of ups and downs and made some mistakes along the way, which is a great way to learn, even if painful. But still, my biggest fear was that I’d forgotten everything I’d learned with that experience.
Along with the natural fear of disappointing my colleagues, there’s always the well-known impostor syndrome.
I’m lucky to have been placed in a cohort with very knowledgeable people who have all sorts of different experiences and backgrounds. That is one of the reasons why this has been an incredible learning journey. However, when impostor syndrome kicks in, you get the inevitable feeling that you don’t belong there, or that you’re not adding value to the team.
I’d like to say that there’s an easy solution for that, but as far as I know, there isn’t. The best way I found to deal with those feelings is to try and rationalise. It’s difficult but a good exercise because most of the questions popping up on your head will not survive the test of logic. I also try and remember past achievements like that time when my viz got good feedback from the client, or when I ran my first Alteryx macro.
In this blog post I’ll reflect about the biggest challenges we faced as a team, how we addressed them, and came up with great results.
Given the fact that we’re working for external clients, there is only so much I can disclose on a public blog post, so the content referring to the task itself is purposely vague. However the challenges faced and the way to overcome them is applicable to pretty much any other situation.
If you’re looking for further readin on this, I highly recommed Alex Simpson’s blog post on best practises on Client Project Weeks.
How do we approach this?
One of the biggest challenges the team faced that week was that the client asked for some predictive analytics for one of the deliverables, which was something we had no experience with. Also challenging was the fact that most of the data had been encrypted so it was difficult to have the usual checks like ‘is that average value aligned with what would be expected?’. Finally, even though the client was very clear in terms of the type of deliverables and insights they were looking for, there was no clear path to get there since the major challenge was the predictive analytics part.
On the positive side, the dataset was pretty clean; we had a good data dictionary and an open channel of communication with the client for any questions that might come up.
But the question was still up there – how do we approach this? We couldn’t see a clear way of making the journey from point A to point B, nor could we picture what point B might look like at this stage.
Lessons Learned
I think the biggest lesson I learned from this experience was: before you tackle the big problem, always try first to understand what your goal is. Writing this, it sounds like the silliest, most obvious piece of advice I could give, but it’s actually something that is often ignored. Due to the pressure of the timeline for these projects, and the fears I had going in, I completely overlooked the most basic step.
While we were searching for a way away from the chaos, one of our coaches asked us: what is the business question you’re trying to answer? What do you know about the business – is it on an upwards or downwards trend? Where do most of the revenue come from? What do the clients look like in terms of demographics? All very basic questions that we still hadn’t answered. He brought our attention to a chart that we’d seen before (in one of its multiple forms) of how to approach a data problem (image credits: kaggle.com).
We took this image and kept referring back to it throughout the week. After we answered the basic questions about how the business was doing, and we clearly stated the business questions we were answering, tackling the predictive analytics problem suddenly didn’t seem that big of a deal anymore.
With a well-defined course of action, we were to split the tasks among two smallter teams – one focussed on the predictive analytics, the other one focussed on building the dashboards that would be the basis of the final presentation.There was an incredible effort by everyone to share their findings along the way and we were able to come up with a final product that the client really appreciated.
Final thoughts
As good as your dashboards are, what’s going to make them a real asset for the client is the delivery. The final presentation is the most crucial part of the week. In little over an hour, we have to sum up the work of eight people in one week.
It’s vital that there’s a story with beginning, middle and end, and that the people listening are with you for the whole time. Preparing is a must, so do as much of it as you can before the big day, gather the feedback from your peers and apply it. We had two dry-runs before the final presentation, and because of that ended up changing the order in which we were presenting, as it told a better story.
My final advice would be: practise listening — another obvious one, like defining the business goals, but forgotten many times as well. Often the best ideas come from the people around you, especially if you’re surrounded by talent like I am at the Data School. Brainstorm and promote healthy discussion as much as you can, and amazing things will come out of it.
