Working in data isn't just about writing SQL and knowing your way around the database. Communication skills and knowing how to gather requirements is just as important as being able to use your technical skills.
This post hopes to get you thinking about the right questions to ask when you are holding a meeting to define requirements and taking on a new project.
I find myself asking this almost every day for data requests big and small.
Your stakeholder may not know what is possible and what data you have at your fingertips already. On the other hand, they may have just enough information to be dangerous and simply come to you with a request to 'land this table' or 'pull these numbers by this afternoon'. Not all data is in the same place, easy to retrieve and the answer may not be in the data in the first place.
Before committing to starting a project or pulling data, ask 'what are you trying to achieve?' With this in mind, you can use the data to tackle the business problem, rather than just landing a table or pulling a list of figures that may not be what they actually need.
Data Science ReneeI now see it as a personal challenge to see how many different presentations I can sneak this slide into 😂
(It was a favorite from my early "Becoming a Data Scientist" talks)
This is "what every data analyst and data scientist should be able to do"04:35 AM - 28 Jul 2019
Each project needs a purpose with a team, manager or end customer in mind. This helps keep the team focused on who they are building the report for, and what goal they are working towards.
Creating a mission statement or user story helps to keep things on track. Using the format "As a ___ , I want ___ so that ___ " is a great way to lock down the WHO and WHY for stakeholders to sign off on.
It would be great to work on projects long term, tweaking every metric and adding reports as they are requested. But the reality is that there are many projects from all areas of the business that need attention.
Confirm with the stakeholders what the 'definition of done' is early on. Do they want a suite of reports, is one enough, do they simply want a number? If both the team and the stakeholders have agreed on what success looks like the project is less likely to fall flat.
Once the initial scoping session is complete it is important to confirm what has been agreed to, and what will be parked for now. This will help down the track with inevitable scope creep.
Email the stakeholder and any other relevant people as soon as the scoping session is complete and summarise what has been discussed and agreed.
Even if you have run a report 100 times before, it's important to make sure you understand what is being asked for before you commit to when it will be delivered. Life happens, databases change, security tightens rules around access, data governance policies are implemented ... all these things can mean your 'quick fix' is not so quick after all.
Make sure you have all the information before committing to a deadline even if you have done the task before. If this is a new task or report do a little research before meeting with the stakeholder. After you have their requirements and have done more planning, provide an estimate of when you will be able to provide the data they need.
One of the toughest realities to face up to on a data project is that sometimes you create what you think the stakeholder needed, and not what they actually needed. While this can be avoided by keeping the lines of communication open, a better way to tackle this is to create an MVP to show and tell where you are at.
Hold regular meetings where you show the stakeholder what you have done, what blockers you are faced with and what's coming next. This is not only a great way to keep everyone updated with progress but means you can avoid going down the wrong track by getting feedback early.
Even if you are not a Project Manager, keep these things in mind the next time you are on a Project. Keeping lines of communication open, making it clear what can and can't be done and getting stakeholder buy-in to make the whole process much smoother.
This post originally appeared on helenanderson.co.nz