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 take on a new project.
What Are You Trying to Achieve?
I find myself asking this almost everyday 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. They may come to you with a request to ‘land this table’ or ‘pull these numbers’. 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.
Successful projects have 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.
The Definition of Done
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 for now, 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 tighten 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.
Minimum Viable Product
One of the toughest realities to face up to on a data project is that you created what you thought the stakeholder needed.
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 next. This is not only a great way to keep everyone updated with progress, but means you can get feedback early.
Photo by Gratisography on Pexels