Essential Lessons From Managing a DS Project

Stepping into a Project Manager role means trading the "idea person" hat for the "director" hat. I recently managed an internal data project focused on refining Salesforce Accelerator dashboards in Tableau. It was fast-paced, technically complex, and taught me more about managing people and process than any technical skill.

Here are the four essential lessons learned that transformed my approach to project leadership.


1. The Power of Consistency: Document the Small Stuff

Our deliverables were a suite of three dashboards - Executive, Team, and Sales Representative views - all built in a single Tableau workbook. While the insights were valued, the client feedback highlighted minor but critical design flaws: inconsistencies in decimal places, font sizes, tooltips, and axes.

The PM Lesson: Design Consistency is a Project Management Task. It’s easy to focus on the big-picture functionality, but client satisfaction often comes down to polish, if done incompletely they stand out can can hinder the quality of the insights.

  • Tip: Treat the Design Style Guide as a mandatory project deliverable, not an afterthought. Ensure documentation is detailed, covering every element (e.g. "All KPI font size: 28pt, Arial Bold; Decimals: 1 place, unless a ratio").
  • Action: Dedicate a specific Quality Assurance (QA) step late in the project cycle only for checking visual consistency across all deliverables.

2. Tailor Your Support: One Size Does Not Fit All

After the project, I recieved team feedback, while some team members appreciate the high-level goals and autonomy I provided, others felt they needed clearer, more hands-on direction.

The PM Lesson: Adapt Your Management Style to the Individual. Recognising and responding to diverse communication needs is vital for team morale and productivity.

  • Tip: Practice situational leadership. If a team member is facing a complex technical challenge, they may need deeper guidance or a resource referral. If a team member is running with a defined task, they need only check-ins on timeline and scope.
  • Action: Create a formal, anonymous feedback channel or dedicate five minutes in a stand up to asking: "What type of support did you need today that you didn't get?" I initially held back from asking for feedback due to time constraints, but quickly realised that a few minutes of feedback can save hours of course correction.

3. Trust Your Intuition: Address Stress Proactively

Looking back, I noticed signs of team stress but didn't act on them immediately. While I helped identify bottlenecks, I could have been more proactive in dividing and assigning tasks.

The PM Lesson: Proactive Workload Balancing Prevents Burnout. A PM's job is to manage capacity before it becomes a crisis.

  • Tip: Follow your intuitions. If a team member seems stressed or is consistently behind schedule, don't wait for a formal complaint. Proactively investigate the task and redistribute work.
  • Action: Encourage team-based support. Instead of relying on myself to distribute tasks, I should have encouraged those with more capacity to actively support struggling teammates. This builds resilience and ownership within the team itself.
  • Also: Explicitly encourage the team to seek external technical support when a complex technical hurdle is causing a complete block. Time is often better spent getting expert help than struggling alone.

4. Quantify the Problem to Maximise Impact

The final client feedback requested that the data team "quantify the issues found" and articulate decisions on the data model. We successfully delivered three dashboards and identified 27 hardcoded KPIs, but we failed to effectively communicate the impact of those findings.

The PM Lesson: Project Success is Communicated with Impact, Not Just Output. The team's investigation into the previous dashboards was somewhat a success, but the value was understated.

  • Tip: When presenting project outcomes, don't just list work done (e.g., "54 updated calculations"). Instead, focus on quantified value (e.g., "The updated data model reduced the risk of reporting errors stemming from 27 previously hardcoded KPIs").
  • Action: Ensure the project documentation includes a "Before & After" summary that clearly states the problem (e.g., "Error-prone hardcoding") and the solution (e.g., "Sustainable parameter-driven calculations"). This builds client trust and context.

Conclusion

This project underscored that successful delivery is a blend of technical capability and disciplined people management. While I achieved some success by bringing calm, ownership, and structure to a fast-paced environment, the biggest growth came from learning to be a more adaptive, intuitive, and consistent leader. The next step is clear: taking these lessons into future projects, focusing on design consistency and further analysis.

Author:
James Gastaldello
Powered by The Information Lab
1st Floor, 25 Watling Street, London, EC4M 9BR
Subscribe
to our Newsletter
Get the lastest news about The Data School and application tips
Subscribe now
© 2025 The Information Lab