PROJECT MANAGER (PM) EXPERIENCE AND TIPS FOR FUTURE DATA SCHOOLERS

On my 7th week at the Data School, I was Project Manager for DS12. It was DS12’s second client project for MOO Business Services (MBS). The total time that DS12 were given during that week for this project was 15 hours.

I did not know what to expect other than just simply assigning roles, being the mediator between the client and DS12, and checking if everyone is doing OK.

Overall, the experience was great; it was really good to be given responsibility. However, there were a lot of things that I had to learn the hard way!

Monday (9AM), this is usally the time where the client will brief you on their company and what the project objective is. It is also time for us to ask questions to clarify any misunderstandings within the dataset(s) or to ask for their opinions on what they’d like to see at the end of the week. The briefing would either happen with the client visiting the Data School or a phone call.

FIRST MISTAKE: I assumed that the client would come into the Data School for 9:00 since I was not told otherwise. However, it turned out that they were waiting for me to call them while they were in their office in Norfolk! I had assumed that Andy and Carl (Data School coaches) would have told me in advance that the client would brief us via a phone call.

TIP: NEVER assume anything! I had found out the hard way there and then that you should always triple check everything, even such things as how a briefing would go down. I should never have assumed that my coaches would tell me anything because naturally they’d have other commitments to worry about. This is the sort of thing that a PM should already know!

Another thing that I had to learn on the go was the true meaning of being efficient with time within a group project! Since this was our second client project, DS12 was still learning how to be more efficient in decision making and scoping work. One issue we had was that we wanted to do anything and everything possible with the datasets given. The one thing we all had to learn was how to say no to topics that we really wanted to investigate but were not able to accommodate the time. Ironically, I think this is something that comes easier to handle with time.

Always check on your team and see if they are OK and are on track. Sometimes people do not tell you if they’re stuck or need to ask questions to the client unless you ask them. It is OK if people in your team are stuck and you yourself don’t know how to solve their technical questions, but it is always good to know who to refer them to. Luckily the Data School has a wealth of people who are incredibly talented in both Tableau and Alteryx and very experienced on how to tackle client projects and answer their business questions.

One last thing that I would advise is to be assertive (if you aren’t already). I struggled with this from time to time. This was especially apparent when asking the team to relay questions that they would like me to ask MBS in a timely manner so that they can respond in time to help us make our progress in work more efficient. There were a lot of times where I would ask, but hardly anyone would actually pass on their points or questions in time, or even confirm that they had no questions to ask – which was quite bothersome. The fault was mostly on my part because I had never really been firm on when exactly I had expected everyone to respond. I just assumed (or mostly hoped) that everyone knew I meant by the end of lunch or by the end of the next break and etc.

TIP: When assigning a certain task such as posting questions, make sure that you’re concrete with your expected time rather than hoping that everyone will understand that you mean ASAP. No matter how many times you ask out loud, not everyone will respond unless you give them an actual deadline. This may sound so obvious, but you’d be surprised. Also, tell them that if they have nothing to share then they should also confirm that; because as funny as this may sound, you don’t know what you do not know, right?

The weirdest part of my week as PM was realising how little you do! Everyone else is working so hard on cleaning the data, figuring out what is the best way to tackle the clients’ problems and then dashboarding away. Whereas I mostly stood by and ensured that there was a constant dialogue between DS12 and our client, passing questions and responses back and forth, and also checking if everyone was fine with their task, and sharing ideas. After a while I realised that this is pretty much what a PM does; while you may not do a lot of work, you bare a lot of responsibility and you are of support by any means for your team.

I hope this was useful for any and all future DSers out there!