top of page
  • Writer's pictureKelly Adams

A Day in My Life: The Lifecycle of a Data Project

A person working on a laptop at a wooden desk, bathed in warm sunlight from a nearby window, with a smartphone and a white mug beside the computer

Working at as a solo data analyst at a startup has it’s own unique challenges and rewards. It’s different from other analysts I know who work at larger companies, who might focus on a niche within the company. In this post I talk about the entire lifecycle of a data project. From the initial stakeholder requests to the final presentation/sharing of the process. 


Get the Project

Projects usually come to be as requests from stakeholders or my manager. Since I'm still early in my career as an analyst, I handle a mix of ad-hoc requests and automation focused projects. Whether it’s crafting a SQL query for a one-time analysis or developing a more complex dashboard.  


My projects can be categorized into two main types: ad-hoc requests and automation. Ad-hoc requests might involve a SQL query or an Excel analysis, while automation projects focus on streamlining processes, like creating reports or dashboards. 

Meet with Stakeholders 

Once I get the request I do is meet with the stakeholders. This is through an informal meeting to go over the project requirements and objectives. Essentially it helps me clarify the “so what”? of the project, or why it matters to the business. After the meeting I write down everything the stakeholder mentioned requirements, definitions, or anything else. With this I have a written record of the project. Then I send this back to them to confirm these are the correct requirements. If it isn't then we work together to figure it out. 

Working on the Project

Before diving into the technical aspect (e.g. SQL or Google Looker), I take a step back and think about the project’s goal. One lesson I’ve learned is not letting the technical problem distract from the project’s business objectives. For example, when writing a SQL query, I focus on structuring it not just for efficiency but for clarity and reusability, considering how the query will be used for the business. 

Then I continue working on the request/report. During this time I continuously check in with the stakeholder with updates on the project. The project’s priority will determine how often I check in. I check in with stakeholders either via email or slack. But if I have more questions or they come up with new requirements we have a meeting.


After I finish my analysis or the project, I submit the project for review. This is an important stage for me to receive feedback. Sometimes adjustments need to be made by requirements or deeper analysis, this requires flexibility and a problem solving mindset. 


After a project is complete I finish my documentation, which is vital for accountability and future reference. It might involve detailing the reasoning behind a query or lessons learned for my own knowledge. Making sure the stakeholder is satisfied with the outcome is the final stage. 


Working through the lifecycle of a data project at a small startup has improved my skills tremendously. While working solo means I do a lot of work, it offers opportunities to see projects through request to completion. This has helped me improve not only my technical skills but also understanding the business context behind it as well. 


bottom of page