DEV Community

loading...
Cover image for How to run successful projects

How to run successful projects

helenanders26 profile image Helen Anderson Originally published at helenanderson.co.nz ・Updated on ・4 min read

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.


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 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.

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, rather than just landing a table or pulling a list of figures that may not be what they actually need.


Key Stakeholders

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.

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 both 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, and what will be parked for now. This will help down the track with inevitable scope creep.

Strategy
Email the stakeholder and any other relevant people 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 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.

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 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 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.

Strategy
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

Discussion (1)

pic
Editor guide
Collapse
freddyhm profile image
Freddy Hidalgo-Monchez

Great post Helen! The cost of not asking continuously 'What Are You Trying to Achieve?" has led to so much over-engineering or unproductive work in my experience. I found that stepping back frequently and assessing direct value for stakeholders has helped a lot. It's just too easy to nerd out on tools/processes and lose focus on the bigger picture πŸ˜…