This week is my last client project. That sentence feels strange to write. For most of the Data School, the client project has been the beating heart of the week — the thing you brace for on Monday and stagger out of on Friday, a little wiser and a lot more caffeinated. So before I hand in my final workbook, I wanted to write down everything I wish someone had told me at the start.
If you're new to this: a Data School client project is a short, intense sprint. You get the brief and the data on Monday, and you present your findings on Friday afternoon, followed by a feedback session with your coaches. You'll do around eight of these over your time in the school. They're relentless, but they teach you more per hour than almost anything else — not just the technical craft, but the softer skills of presenting, scoping, and working with a team under pressure.
Here's how to survive them, and even enjoy them.
Monday is won or lost on the data
The single biggest lesson, and the one every cohort re-learns the hard way: spend most of Monday understanding your data. Errors you miss on day one cause enormous time sucks later in the week.
One cohort's project manager wrote about connecting to the wrong data source entirely at the start of the week — they'd pulled tables from the client's overseas affiliate rather than the actual client — and it cost them valuable hours before anyone noticed. Double-check the fundamentals. Confirm you're on the right server, the right tables, the right date ranges. It feels slow. It is the opposite of slow.
If you're working with large or awkwardly structured data, expect join problems. One DS student working on a company valuation had six tables to relate and watched her numbers multiply the moment she joined them, fixing it with LODs and table calculations. She also hit the classic trap where two IDs join onto a single ID and the whole view goes blank — solved by duplicating the single-ID table and joining each pairing separately. You may not hit those exact issues, but you'll hit something.
Nail the kick-off, then scope ruthlessly
The kick-off call is one of the most important moments of the entire week. It's where you interpret what the client actually needs, agree the scope, and set expectations. Come with questions. Leave with a shared understanding of what "done" looks like.
Then be ruthless about scope. When the schedule is tight — and it always is — a tightly scoped, well-executed piece of work beats an ambitious mess every time. Sketch your dashboards early (Excalidraw is great for quick wireframing) and show those sketches back to the client for feedback before you build. It's far cheaper to redraw a rectangle than to rebuild a dashboard.
If you're the PM, a small investment pays off enormously here: build a template and set the style guide up front. Lock in the hex codes for your categories, the spacing between charts, the fonts, the dimensions. When five people are building separate dashboards, that template is the only thing standing between you and a Frankenstein deck.
Run the week like a team
Quick daily standups keep everyone honest — just keep them genuinely quick. Even at five minutes each, a room of eight people eats forty-plus minutes, so protect that time. When there isn't room for a full standup, a PM checking in with each person one-to-one often gets a clearer picture of what's actually done.
Respect the room while you're in it: listen when someone's sharing, keep your hands off the mouse, and close the laptop when it's not your turn on screen. It sounds small. It changes the whole feel of a team.
And lean on the people around you. Your cohort all know the data, so they're your first port of call for bouncing ideas. Beyond that, the wider TIL is full of ridiculously talented people who genuinely have time to help — use them when a problem outgrows the room.
Build for handover from the first hour
Documentation is the thing everyone finds hardest and everyone regrets skimping on. It's painful to document while you're mid-problem, but it's vital when you hand the work over — usually the following Monday.
With a big team, files multiply fast: duplicates, half-finished versions, "final_final_v3." Agree on collaborative tooling and strict version control from the outset. When you're done, package everything — workbooks and workflows — into a clean final folder inside the project folder, so sending it to the client is a five-minute job rather than a frantic hunt. As PM, make it your business to confirm every single person has handed over their files before the deadline.
Present like it matters (because it does)
Present from one laptop. It looks more professional, it reads as a cleaner story, and it saves the excruciating "can everyone see my screen now?" shuffle — especially over a call. Uploading the team's workbooks to Tableau Server is a slick way to do this and quietly shows off the product too. Whatever you do, open and run everything before you start; big data takes a few minutes to load and you don't want the client watching a spinner.
Use your three hours on Friday morning to rehearse — ideally on the big screen, in the real space, in front of someone who isn't close to the project. That outside ear is gold for spotting where your story doesn't land. Rehearsing also helps you pick the good examples to demo live.
A few things that consistently help when you're actually up there:
- Have notes. It's far better to glance at a note than to flounder. They also just calm you down.
- Set the scene. Start by saying what your part of the project was and what you set out to answer, then explain any project-specific terminology or fields you created. It's all obvious in your head; it's brand new to them.
- Describe everything, especially over a call — point and narrate what you're doing on screen.
- Don't walk through every tool. Summarise what each section does; dive into the formulas only where it's genuinely complex.
- Show your progress. Save previous versions so you can say "we were here on Tuesday, and here's where we got to." That journey is often more impressive than the destination.
One more, learned the hard way by more than one PM: record your presentation. You'll want it later, and it's a maddening thing to forget.
Keep the good in view during feedback
The post-presentation huddle with your team and coach is where a lot of the learning actually happens. But because these projects are intense and the stakes feel real, that session can tip into pure critique. Make a point of naming what went well, too. You'll improve faster from a balanced picture than from a list of everything that broke.
Finally: have fun, and let it be okay
Genuinely — have fun with these. They're a rare chance to try new skills, both in the data and on your feet. If you pick a route that doesn't pan out, or you struggle to pull it all together by Friday, that is completely normal and it happens to everyone. As long as you learned something, you used the week well.
That, in the end, is what I'm taking away from my last one. Eight projects ago I thought surviving the week meant getting the dashboards to work. It turns out surviving it — really surviving it — means learning to scope honestly, ask for help, tell a clear story, and be kind to yourself when the runway gets bumpy.
Good luck out there. Check your data source twice.