Client projects are quite a big part of the Data School training. It’s a week-long engagement during which one member of the cohort is the project manager and the rest is actually working on the client’s requirements.

Two weeks ago, it was my turn to be the project lead. I hadn’t managed people before and wasn’t sure what to expect. To find out what it felt like, wait for my blog post on the experience itself. Here, I am listing the more practical lessons I’ve learnt. Make sure to check out Hesham‘s tips on the subject as well!

1.Think about the available time and plan out roughly the agenda for all days. List the time for each day, it will help both yourself and the people you manage to plan the work ahead.

2. Consider the mode of work, whether you prefer to give more structure or more freedom to your team (I prefer adding more structure rather than free-spirited approach but it’s something you need to decide yourself). Make it clear to the team what you’re expecting of them.

3. Prepare Tableau and Alteryx templates for your team so that the work is cohesive.

• In Tableau, make sure to use tiled containers and lock width/height of elements you don’t want to change and unlock those that can change so that the template can be resized.
• Use Format -> Workbook to specify the fonts for the whole workbook
• Save this as a packaged workbook
• Prepare colour palette based on the client’s colours in a format that you can paste into Tableau preferences file (check Sam‘s blog on adding custom colour palettes to Tableau).

4. Create a folder for the project with a few subfolders inside:

• Admin for general information: info/research about the client, project schedule, notes from the kickoff, client requirements, colour palette and templates themselves.
• Data with a separate folder for the original data you get from the client.
• A folder for each team member. It may also help to copy and paste the templates to each of these to minimise the risk of overwriting the master templates.

5. After the kick-off, try to rephrase the tasks/requirements so that it’s in a language that you can all easily understand (simplify and group the requirements given by the customer).

6. Dividing the tasks is a bit tricky. I used a random number generator, other PMs either asked the team what they were interested in or assigned the tasks themselves. Asking the team has the advantage of the team being potentially happier with their assignment but it comes with the risk of people doing similar tasks between different projects.

7. Once the tasks are divided, ask everyone to think about what the objective is – who is their audience, what questions might they be interested in and how to best answer them. Then, ask your team to think about the data they need – what fields, what format etc. and how to visualise it all.

8. While they’re at it, make them sketch out the dashboards beforehand. You’ll have an idea of what everyone is up to and this will also help everyone think about the data they need (see point above).

9. This is a good time to brainstorm the ideas together so that the whole team can verify the assumptions about audience and suggest more questions/things to focus on. If anyone thinks their task is too small, too big or maybe pointless, this would be the time to raise this and change the game plan.

10. Check in with your team to know what stage the project is at and how everyone feels about their tasks. Some ideas might turn out to be a miss and you’ll need to reassign some tasks, maybe consider doing something else. Unfortunately, you need to be flexible as the requirements and resources change during the project.

11. There will be questions, about the data structure, meaning, stakeholders’ expectations. If there are none, I would be worried…

Anyway, create a document that everyone can edit that’s dedicated to questions. Ask your team to write them in a format you can send directly to the client. That way when you get the response, you can just copy and paste it into that same document. That way it’s easier to keep track of what was already asked and whether it was answered or not.

12. Check in on the dashboards and give feedback. Make sure the values have an appropriate context so that when stakeholders look at the dashboard, the insights are clear.

13. Express your observations even on minor things (including formatting) and discuss them with your teammates. Allow them to respond so that you’ll know whether you’re talking about a conscious choice or not.

14. When asked for help, stay on topic.

Only once you answer the team’s questions, raise your own suggestions/observations (see above).

15. You might be asked various questions, some you’ll be able to answer. In case you can’t solve something, seek help elsewhere (whether in person or via collaboration tools).

16. During the presentation, don’t shy away from the challenges. Describe what was difficult and how your team dealt with it. You can continue with the tasks you did not have the chance to solve for whatever reason and then let the team wow the stakeholders with all the good work they did.