Last week, it was my turn to be the project manager for an internal client project. Having seen my colleagues act as project managers and learned about the ways in which to approach this, I thought that I was prepared. Although can you ever be completely prepared? Here is a look into the things I learned and useful questions to ask.
Prior projects were for external clients and generally, all of them had similar requirements with a focus on creating dashboards with data given to us. There was a great focus on the analysis we could carry out through the dashboards. I have learned that clients typically like having a high-level overview with KPIs that then drills down to a more comprehensive analysis that allows different people in the organisation to ask and answer questions.
Kick Off Call and Asking Questions
I have learned that it is really important to ask questions here. Taking an area that you have very little to no clue about and producing a dashboard from the data given is not easy. Especially as clients use terminology that makes the most sense to them and therefore, you really need to ask to be able to understand. I know that we encountered many abbreviations that were not explained at all. We also had issues with the requirements and of course, the data. Here are some tips and things to ask:
Ask about what things mean within the data if a data dictionary is not provided.
This is where you encounter those abbreviations that they assume you already know about. Some clients are organised and do provide a data dictionary and if this is the case, use it to support your understanding of the data. If they've left things out or you're still not sure, now is the time to ask.
What are the top 3 key questions that you would like to answer?
Typically clients can point you into the direction of key areas they would like to explore such as marketing. These areas can be too broad however and leave you with too much to explore within a short time frame. By rephrasing the what they would like you to explore into key questions can really help you immediately identify key columns and dig straight into the relevant analysis. This doesn't have to be the top 3 of course and you can amend this according to the time that you have available.
Who would be the typical users of this dashboard?
Knowing your audience will allow you to think about whether the dashboard needs more explanation for usage, or terminology for example. Typically, we would add information hover icons to explain things. Also, if the dashboard is used by a CEO or head of department for example, they may simply want to see a high level overview. Alternatively, if someone from the sales team wants to dive deeper into the products that are selling best, they may want more than just that high level. Knowing the users will allow you to strike this balance.
What version of Tableau/ Server etc are you using? Is there a typical device size for what you view this on?
Knowing whether they typically use Tableau Server, Tableau Desktop or anything else including data preparation tools is very important. The version the client uses is the version that you want to be using too. One client wanted to replicate the idea of a pack. Using Tableau Server, we achieved this through linking dashboards through buttons and having a landing page. Therefore, showing the potential of what you are using and how it can aid the client is very useful. Make sure that if you are doing any data preparation, you've ensured that the client can access this too. There is no point in spending your time to tidy a dataset in Alteryx when they don't have it.
Asking about the device they are viewing on will help you when it comes to creating the dashboard but also considering best practices in terms of speed, access and functionality.
Understand where the data is connecting from. Ask if you're not sure.
Some clients will provide you with excel spreadsheets and in this case, they may simply want to see the capabilities of Tableau. This is quite straightforward to plug into Tableau. On the other hand, some clients use connections that you may not be familiar with. Understanding how the connection works within Tableau and what you are able to do, or even limited to do is very important. Especially before promising that things are possible. This ties into my next point.
Manage expectations. Don't promise things before you know that they are possible - however experienced you are.
This is a very important point. It's quite easy for you to start telling the client that actually, what they're asking for can be or should be possible. Especially if you have created many dashboards and encountered similar requests before. Just remember, that each client project comes with its own challenges. Most of which, in that kick off call will be oblivious to you.
Managing expectations was something we learned as a cohort, and the hard way. Making sure that both you and the client know of the time in which you are carrying out the project is important. This will help you manage the time effectively and understand the priorities that need delivering. I noticed that actually, the majority of clients thought we had the whole week in which to work towards their project. When telling them, they were surprised at the little time we had and immediately communicated their priorities rather than everything.
Post Kick Off Call
This is the moment you digest the information that has been thrown your way. If you're still unsure of things, asking others in the team to help clarify at this stage is very important. As a team and with the help of the project managers direction, you can start formulating a plan. Again, here are some things that I learned:
Don't assume the data is perfect
Look at the data before the kick of call. In particular, look at the structure. Understanding the structure of the data will help you understand what can and can't be done when it comes to what the client would like from you. Decide if you really need to alter it. If you don't, you can focus on the analysis. Of course, this depends on what the client wants, and if the data is something they have asked to spend some time on, then of course do this.
Take your time to understand the data and criteria post kick off call
This is so important! Don't rush into things. To all project managers out there - spending the first day to plan, understand and start exploring the capabilities is not at all a waste of time. When you think your team is comfortable, and you have a plan, start building. This first day will lead to more questions being formulated. It's the task of the project manager to clarify these things.
Future proof and sense check
Make sure that your calculations are dynamic. Ensure that you are checking the results against the data given.
My Own Project and Management Style
My project management week was an internal client project which differed slightly as dashboards did not need to be churned out. Nonetheless, I had a fair amount of work to do and understanding to gain in order to support my team. I learned that:
Active communication is key.
I found it harder to check in on my team when I was project manager, simply because of the task details requiring them to independently get on with things. I did however ask people to update a post so that I was aware of what they were doing. I included calls so everybody could update one another too. I would communicate anything useful by sharing posts and making myself available if they needed a hand in any way.
Listen to the team.
Everybody seemed to be making progress at different stages and so the ideal plan that I created in which everybody would have a plan completed by the first day and certain things done by the second didn't exactly work. It's important to adapt your plans. I therefore pushed people who I thought were in a good position to do more, and then encouraged those who had issues to move on so long as the criteria was met.
Helping answer questions.
I was very active in finding answers to questions to allow my team to get on with things. The clients were also very helpful. I took advantage of the help that they offered and encouraged the team to do the same.
These are small things that I learned alongside all of my previous weeks working with my team to support the above tips.
Overall, project management styles differ for different people. I've learned different things from my peers and myself. I hope that these tips can be used as a starting point to help others in the future.