Join the Data School training program, each cohort will take on weekly projects to increase real life consulting experiences. The projects could be internal or external facing and it will be free for any external client (like a trial project with TIL). Usually each cohort have 8 people, so the project week will start in the second half of the training, where each person will take on the rotating role of project manager.
This blog will offer me a chance to share my experience of project managing.
This week's project is based a public available sample dataset of cycling company - Adventure Works. The aim of the project is recommend to the CEO of the company about current performance and the possibility being a target of acquisitions.
The dataset is available on a SQL server and there is no restriction of which software to be used. Everything is left open for the team to decide and the final presentation is on Friday afternoon.
The week overlaps with Learn What the Data School Learns, which implies various team member will not be available during the project time. So the task need to be assigned accordingly, with spare support available to jump in.
- Monday for exploratory analysis data, find relevant fields and design layout. 2.
- Tuesday & Wednesday allocated for the team to go more detailed calculation. 3.
- Thursday for adding interactivity and formatting. 4.
- Friday for final formatting, presentation prep and also spare capacity time for any unexpected situation.
The database is extensive, although there is a detailed schema and data dictionary, it is still difficult sometimes to understand the column relationship, in particular to duplication from the join.
- It is emphasized in the training session about Waterfall vs Agile vs Scrum method of development. Therefore I hoped to team member to start simple, then iteratively to add more. Though some preferred to have an overall design first then work accordingly to it. People have different way of working, it's hard to push for a single unified philosophy.
- Fixed schedule is hard to maintain in an ad-hoc base. Ideally there are two check-ins with the team each day (eg. 9:30am + 3pm or 11am + 4:30pm), the aim is to have a daily view on the task done and find issue in the midday rather than end of it. In practice it failed, public training session disrupted the planning most. People spend more time preparing for it than on the project.
- Oversight vs intrusiveness. Given it's a training and rotating role as pm, it is hard to exert significant control on the team. As it is not possible to strictly require people to report at the exact allocated time, then it is more about finding available slot for the individual check-ins. Ideally, for a small team working on a single project, it is always beneficial for team member to meet and report together to see other's progress rather than work in isolated silos.
- It is hard to convince people to manage the workload appropriately, there is a tendency in human to finish each task just in time, which is fine if enough slack time is planned, otherwise when one task spill over into the next which cause avalanche effect on the workload. It is pm's job to prevent that happen, though it is hard to achieve when gentle reminder is the only option available.
- Have at least one person to keep an overview of the direction of the project. It is easy when everyone concentrated on their worksheet or dashboard and loss sight of the end goal, went down a rabbit hole in search of a particular table calculation. It is helpful when there is someone who can visit to make sure that doesn't happen (depends on how much hands-on pm want to be), it also offers opportunity for people to bounce ideas off if there is lack of ideas.
- Unexpected timeout due to unforeseeable circumstance. Multiply team member had to take time out due to sickness, the non-availability caused significant difficult to organize regular team catch up session.
Looking for more guides, tips and tricks in Tableau or Alteryx? Go check out the other blog posts from the Data School.