I built 5 dashboards as a grad data analyst. Here’s what I learnt and what I’d do differently.

Posted on: February 2, 2024

Last Updated on: March 1st, 2024

Post Category: Professional Development

---

I built 5 dashboards during my first year as a data analyst.

Here’s what I learned and what I’d do differently…

This month marks my one-year anniversary at Quantium, and since starting, I got to work in the internal Finance team.

Some of the projects I got to work on included:

• process automation,
• developing and rebuilding our internal analytics data pipeline, and
• building reports/dashboards (using Power BI).

And some of the reports I built served pretty important business use cases.

I also did and learnt cool things as well, like:

• embedding a Power App into a Power BI report,
• refreshing a Power BI report after changes are made to a Sharepoint list (using Power Automate)
• applying conditional formatting on charts to implement visual best practices,
• using the Power BI REST API to automate data refreshes and do data governance, and
• building an data extraction tool for Jira.

But the processes I took to build these reports/dashboards weren’t so great.

I guess, objectively, they went fine, but given my newfound perspective, there are a lot of things I could improve on.

Like… imagine working hard on a dashboard (or any data product/deliverable) and not having it used as frequently as you intended.

That’s the situation I’ve experienced a few times during my role and I should take some responsibility for that – and try to avoid that in the future.

At the end of the day, building a valuable data analysis-piece is a collaborative effort – and when you don’t have an analyst who’s a good communicator, who can present themselves as someone who’s diligent and trustworthy, it falls apart.

So in this post, I’ll talk about the approach I initially took, then I’ll pick it apart and talk about the things I’ll be implementing to improve.

My initial approach to reporting projects…

Every project typically starts with a request and a quick follow-up scoping meeting.

First thing’s first, scoping meetings weren’t a comfortable thing for me. Specifically, the uncomfortable process of asking questions, messing up, making the wrong assumptions and getting (bad) feedback.

I got a bit afraid of asking (dumb) questions, and asking questions that disrupted the flow of the conversation. And coincidentally, this tends to happen in meetings where the requirements are not properly laid out – where the stakeholder wants something to be improved/created but is not sure what should be done, which makes it even harder.

Even though my manager was the one who collected requirements first, I still had a bit of trouble continuing the interaction comfortably. And that’s partly because I have not acquainted myself with the stakeholder. When you’re not sure what a person is like and how they will react to something, it’s hard to initiate/continue the conversation.

Anyway, back to the approach I took…

Near the end of the scoping meeting, I’d tell the stakeholder a rough date where I’d be ready to have the data prepared or share a first iteration of the report.

Regardless, I didn’t define a specific timeline for when things will be done, and I only provided updates whenever I had capacity to make meaningful progress. And honestly, that’s not so great, given that a lot of things can be thrown onto your plate when you’re a data analyst.

As an aside, there actually was a particular project (not dashboard-related) that I dragged out for 4 months when it didn’t need to be that long. To be fair to myself, this was a project I started 1-2 months into my role, where I was still getting acquainted with the data… but I found stretching out a project, when i didn’t have great confidence building a relationship with my stakeholder, is not a good practice going forward.

Generally, I *did* improve my approach later in the year with more recent projects… but I figured let’s standardise the stakeholder management/engagement practices I’m using.

So here are my improvement areas in a nutshell…

• Having comfortable and fruitful conversations with stakeholders, even when they’re not sure about what they want
• Asking questions – and not being shy thinking about it
• Getting acquainted with stakeholders ahead of getting into formalities
• Sharing more regular updates
• Setting up a timeline
• (Broadly) managing stakeholder expectations

And this is how I am going to improve going forward…

Before I get into the perspectives/methods I’m planning to implement, I would like to give a shoutout to Mo Villagran. Most, if not all, of what follows takes inspiration from her book ‘Data Insights Delivered’.

I came across it late last year, after it got recommended by one of my commenters on LinkedIn. And coincidentally I felt the description of the book aligned with what I was missing from my role as a data analyst.

So, if you would like to read more about what methods follow, I encourage you give the book the read.

Anyway, for each improvement area:

1. Having comfortable and fruitful conversations with stakeholders, even when they’re not sure about what they want.

Going forward, I’d like to approach meetings with a greater intent to listen and scope and understand, without flexing my capabilities or what I have built previously.

Not sure if it’s because I applied for too many data analyst roles, but I found it pretty easy to get into the habit of flexing the things I could build and how I *could* add value to a specific project given the technical expertise I already had.

And this is not particularly helpful given every data project is a different challenge.

Overtime, I learnt what matters most is the quality of the stakeholder engagement. Sure, I can build cool things, but can I build something that’s valuable (that aligns with business objectives), and have my stakeholder trust me to do it?

Because they are two totally different things.

2. Asking questions – and not being shy thinking about it

Going forward, I’d like to approach every stakeholder interaction with the mindset like they’re my business partner; I’m not working for them, I’m working *with* them, and the delivery of valuable analytics is a collaborative effort.

In Villagran’s book, she uses this idea of a data concierge. A data concierge is basically a point of contact between stakeholders and the data, and someone who puts the needs of their clients first.

And she recommends data analysts assume this role to enable more valuable analytics.

For most of my role so far, I kind of thought of myself as a data specialist, who just works with data in the corner and “does his magic”. And I wasn’t building the relationships that were needed to facilitate successful data projects.

So going forward, I would like to shift that focus from a (data-focussed) data specialist to a (results and impact-focussed) data concierge.

3. Getting acquainted with stakeholders ahead of getting into formalities

Going forward, I’d approach each stakeholder and chat with them in a less formal context, like go for a coffee and talk about non-work related stuff.

4. Sharing more regular updates

The common issue that inhibits me from sharing regular updates is that other projects just take priority.

I could have multiple projects on my plate, and some things are more urgent/important than others.

But not urgent doesn’t necessarily mean not unimportant to the stakeholder. Stakeholders would love to see progress regardless.

So going forward, I’d like to have a personal retro on a Friday afternoon, where I’d go through all the key projects on my backlog and write up a short Slack message or email sharing what progress I’ve made and what intentions I have going forward – to all the stakeholders I’m managing.

A worthwhile point shared by Villagran, in her book, is that regular updates help manage stakeholder expectations. When stakeholders particularly have tight deadlines, and you know it’s too ambitious, being transparent about how you’re progressing, and sharing your work on a regular basis, builds trust and helps your stakeholder relax deadlines because they see things coming along.

And even if you don’t know where to get the data from, it is worthwhile creating a wireframe or mockup, to share with your stakeholders as a proof of concept/progress.

5. Setting up a timeline

I tend to break down tasks and time-box them, and I think I should leverage that here.

While writing a timeline is not actual technical work like cleaning or visualising data, it’s a bit of progress towards the end state of the report (because *I think* it can be shared to ensure the trust of your stakeholder).

Going forward: for any project, after the scoping meeting, I’d like to break the project down into a potential timeline of tasks, then share that with my stakeholder.

Obviously the actual workflow will not align, because things just happen – issues arise that aren’t foreseen, managers give a pretty long list of feedback to go through, etc. So on top of this method, I’d be generous with the time allocated for each task.

6. (Broadly) managing stakeholder expectations

This ties with the points I made earlier, for sharing regular updates.

Closing remarks…

I’ll cut myself a bit of slack, since I’m still a graduate – I guess.

But I hope to stay in the industry for a while and climb up the ranks as a data analyst/scientist, and I think these sorts of reflections are fruitful for growth.