Working in data isn’t just about writing SQL and knowing your way around the database. Communication skills and gathering requirements for projects is just as important as technical skills.
This post hopes to get you thinking about the right questions to ask when taking on new projects.
What are you trying to achieve?
Key stakeholders
The definition of done
Clear communication
Managing expectations
Minimum viable product
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, and easy to retrieve. The answer may not even be in the data in the first place.
Strategy
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. As opposed to just landing a table or pulling a list of figures.
Key stakeholders
Successful projects have a purpose with a team, manager or end customer in mind. This keeps the team focused on who they are building the report for, and what goal they are working towards.
Strategy
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.
Strategy
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 the team and the stakeholders have agreed on what success looks like the project is less likely to fall flat.
Clear communication
Once the initial scoping session is complete it is important to confirm what has been agreed to. This will help down the track with inevitable scope creep.
Strategy
Email the stakeholder as soon as the scoping session is complete and summarise what has been discussed and agreed.
Managing expectations
Even if you have run a report 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, governance policies are implemented. All these things can mean your ‘quick fix’ is not so quick after all.
Strategy
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 the requirements and have made a plan, provide an estimate of when you will be able to provide what they need.
Minimum viable product
One of the toughest realities to face up to on projects is that you created what you thought was 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 where you are at.
Strategy
Hold regular meetings where you show 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.
Even if you are not a Project Manager, keep these things in mind on your next project. Keeping lines of communication open, making it clear what can’t be done and getting buy-in makes the process much smoother.
Photo by Jeffrey Czum from Pexels
