Podcast #04 - Introduction To Project Management Dashboards
There has been a growing demand for Project Management dashboards. We have seen an exponential rise in the number of new dashboard engagements at MI-GSO | PCUBED. Jami Anderson is joined by Brent Wagner, Rana Haidar, Adysti Kardi, and Tom Burrell, who will each highlight the value of dashboards, their varying types, the team roles required, experience required, key questions to ask and lessons they’ve learned along the way. We hope you enjoy this introduction to Project Management dashboards.
Table of Contents
Jami: So hi everybody. My name is Jami Anderson, and I’d like to welcome you all to our first podcast, on this side of the Atlantic. So our counterparts overseas, in MI-GSO | PCUBED UK, have done a few podcasts since we’ve been quarantined, focused on knowledge sharing on all things related to project management, so that we can all come out of this a bit stronger.
Today’s topic is about dashboards. MI-GSO | PCUBED, for those who don’t know us yet, we’re a global project management consulting company. While we typically provide project management office operational support, we’re also often called in to digitize program status updates in the form of dashboards. So that’s really what we’re talking about today. I’m joined on today’s podcast by four members of our team, each at varying levels of excitement about the topic, so let’s start by introducing them.
First up, Brent Wagner. Brent is a senior consultant based out of our San Francisco office, with over six years working in data-driven analytics.
Rana Haidar is a project manager based out of our Detroit hub. She is currently leading a team to deliver an analytics dashboard for a leading OEM company.
Adysti Kardi is a consultant spending her first year working with dashboard analytics.
Closing out the team is Tom Burrell. He’s a business manager in our Detroit office for MI-GSO | PCUBED. Fun fact – he cut both his own and his dog’s hair during quarantine. Thank you, Tom. Appreciate that.
Tom: Absolutely, no problem.
Why Dashboards [1:48]
Jami: So why don't we kick this off - why are we talking about project management dashboards?
Tom: So, from my perspective as a business manager, I hear a lot of our clients have very similar challenges. Often, the biggest and most consistent driver for a dashboard is that someone doesn’t have insight into their business. And for operational personnel, sometimes they don’t have insight into the “why” behind they’re doing something, the “why” behind a program milestone .
So, the old way that people used to manage their business would be to walk around and meet with people to hear things are going, and then you spend all day focusing on getting updates from your teams, and in a sense, micromanaging your people, which, you know, in 2020, it doesn’t exactly sit well with today’s personnel.
The dashboard essentially allows you to have that insight and then to also focus on your own strategic initiatives, rather than having to go around and get constant updates from, from people on your team.
Jami: Thanks, Tom. Brent – what’s the value to you?
Brent: So, it depends on the need, but realistically when we’ve chosen to do the activity of taking this project, we’re looking for something. Either we want to know the facts or we want to learn something different from it.
A business area that’s willing to bring their data, centralize it, and view it in different ways, is looking to make positive changes. So I would say, you know, high business value in most, if not all cases.
Types of Dashboards [3:10]
Jami: I would assume that for as many different types of projects we have, there are that equal number of types of dashboards.
Tom: Yeah, so we actually focus on three types of dashboards: operational, analytical, and strategic.
So, an operational dashboard might give you an insight into at this moment – this is what’s being produced, here’s where on my line I have this specific issue.
An analytical dashboard is one where there might be by the hour, by the day, maybe a less recurring update, but is used for kind of interesting insights to analytics. So, that way, you can get some sort of output that could lead to a decision.
And the final would be a strategic dashboard. Strategic takes a global view of operations and analytics, and then also allows for some of that same complex manipulation, but used by someone who would have a more of a global view over the entire scope of the business.
Jami: Rana and Adysti, can you talk to me about the types of dashboard projects that you guys are on right now?
Rana: Yeah, for sure. For my project, I’m really involved in strategic dashboards, which we use at an executive and director level. And really how we position it, it’s your one stop shop, right? It’s your location where you go to see all of the key metrics that really drive your business.
Jami: That’s pretty cool. Adysti, how is yours different?
Adysti: So, I’m currently working on an operational / analytical dashboard for an automotive company, specifically for their engine and transmission testing labs. Basically, our dashboard measures the utilization rate of their resources to help track progress of day-to-day operations, as well as, like, the efficiency of the resources over a period of time.
Roles Required for Dashboard Projects [4:55]
Jami: Are there a set number of roles or types of resources that each project should have on the engagements?
Brent: So it varies, based on the current state that the client or business area is in. If they’re unaware of some of their facts, and they need help discovering those and gathering the data, it’s conceivable that some sort of BI architect, data engineer, or ETL developer could be used to gather centralized and normalized data and make it available to some of the other roles.
Jami: Really quick there, ETL, what’s that?
Brent: So, ETL stands for “Extract, Translate, and Load.” It’s sort of an industry term. So leading tools such as Informatica is really flagship. But we have more lightweight ETL tools, like Tableau which has implored a prep builder.
ETL really refers to you know, pulling, translating, and then loading and making it consumable.
[Back to the original question] So, I like to picture it – if there were three different roles to make a dashboard successful – as sort of a back end, a middle portion, and then a front end.
So, once the data is prepared, procured, and in a place where an analyst can consume it; they pick that up and look for interesting trends.
Likely they’ll dip their toes into visualization, just to see what things are looking like at a high level in the beginning and implore statistical algorithms. You know, these folks are commonly well-versed in R, Python, and other scripting languages.
And then the person who drives the value of these calculations and these various pieces of data is the dashboard developer, someone who understands the business requirements and the look and feel of the UI [user interface] that the client or business is looking for.
Rana: One of the biggest roles on these type of projects is really to have that business lead, or project lead role; which is just really an individual who both understands the business terminology, and is able to translate it into technical terms and vice versa.
It’s really that person that’s that liaison between the clients and your development team, just to make sure that what’s being asked for and what’s being created, is really what the business is requiring.
Experience Required [7:02]
Jami: Interesting. I can imagine that this is a very specialized skill, especially when I have to ask you what ETL stands for. So, how much experience did you guys all have prior to developing your first dashboard?
Adysti: So, I actually have less than a year experience but, I’ve been using the data tools and developing dashboards for over five years during my undergrad and grad studies.
I basically built a mini operational dashboard that tracks loan delinquency activities, but my current dashboard is much greater in scope.
I’m also a lot more involved in the ETL process, whereas previously the data that I needed were readily provided. And, I wasn’t familiar with the tools that my current client used, which is Alteryx and Qlikview.
Honestly I had to go through a lot of learning because the volume of data is much greater and I had to go through several training sessions. Bottom line, I think learning to develop a dashboard definitely requires a skill and experience. But it’s definitely doable. There are a lot of support communities out there to help you with navigating how to use the different tools which is really great.
Jami: How about for you, Rana? How much experience did you have in dashboard, and how’d you get into this?
Rana: I have a little over seven years experience with dashboard, but mine’s from a user perspective more than from a development perspective.
In my previous jobs I’ve always used dashboards to manage the business. I started with the development part when I joined M|P. It really required me to understand the tools needed to create dashboards, which is your Qlikview and your Alteryx, but also to understand the manufacturing business. So, it was a little bit of an onboarding when I first got into it.
Jami: Brent, anything different from your perspective?
Brent: Yeah. So, as it relates to the tools, if you have a good understanding of data structures, how to do some basic data manipulation; it starts to become pretty easy to go hopping between tools.
I’m a huge Tableau person. It sort of comes down to personal preference and maybe what need the business has. In our situation here, it comes down to what the clients like to use.
Power BI has put its mark on the industry now as a tool that is generally readily available to most folks that have Microsoft products already.
So, yeah, I think laying the groundwork for understanding how the data will eventually need to be processed and how it works will allow you to jump around from tool to tool, and for that matter, project to project. And as you start to build your portfolio – solving data problems becomes a lot easier over time.
Tom: I think the important thing there is solving data problems, but also bringing a customized kind of approach to it, or at least one that’s configured to the client environment – driven by their own business intelligence.
It’s not generating data out of thin air. It’s actually giving them insight into their client environments regardless of how, boutique or off the shelf we can become with the type of visualization.
The business intelligence and the project management aspects of it really drive home the value of the dashboard to the clients. Using the dashboard to make a decision, that level of maturity is why there’s a huge spike in this kind of a need.
Key Questions to Ask [11:00]
Jami: What are some of those key questions that we should be addressing upfront when we're kicking off a dashboard project?
Brent: I think to get an understanding – Tom alluded to it earlier – we’re not manufacturing data. So the first question is “How do I get a dashboard?” – because generally they’ve seen either a peer or another area using a dashboard.
And, my first response is “Let’s talk about the data. Let’s see where it is.”
Because that sort of informs you – it could be that the data is already in such a nice, neat, orderly state that you just need someone to slice and dice it. Someone who can make it look pretty, make it work and function quickly.
Adysti: From my perspective, it is really important to collect, as much as possible, all the requirements in the beginning.
Some of my questions would be:
How open is the data? How real time is the data?
What’s the source of the data?
Is it manually updated in a spreadsheet or stored in a database?”
Because, the way that we can connect and get real time data, like the method to actually extract the data, matters, and the data architecture behind it matters.
I think it is also important in order for us to design a good dashboard, we need to try and put ourselves in the user’s shoes to understand:
What are the key decisions that you’re trying to make?
To understand how we are going to design the charts and the user interface based on how the users will interpret this data and make decisions.
Jami: So we're ready to start developing the dashboard. How do you, how do we manage that development?
Rana: So, you know, there’s always best practices for each company, really what they use. But one of the biggest things we use is daily stand ups, both internally and also with our client, so that there’s a consistent form of communication. So we all know what we’re working on, where we need help.
We also use from a visual perspective, because we’re really a lot of visual type of people – we use a Kanban. We just kind of walk through every day where we are, and we color code it, and that’s really, it’s been a great amount of success.
Tom: Rana, to couple your point there. It’s really important that you have the client involved, and it’s important to all to understand that it’s never too late to make a change, until it’s, of course, too late to make a change.
But involving the client throughout that process, and having the stand ups be daily; keeping your stakeholders informed of anything that changes on the dashboard, is extremely important.
Brent: I would just add one thing to that. So if they sit on the dashboard and they think in the back of their minds, you know, “This thing it’s new. They’ve said this is a prototype. I hope that it looks like this.” Learning to coax those things out of them early is really, really helpful.
Whether encouraging them to please criticize, give us feedback. Whether it’s negative or positive early on – we’re not going to take it personally. This is something that we are building for you.
Lessons Learned [15:15]
Jami: What other key lessons do you guys have to share as you've run through your dashboard development projects?
Rana: One of the lessons that we’ve really learned is just understanding your gaps in the data. Understanding that every client and every company has a different architecture of how they maintain their data.
It’s extremely important when you’re trying to have data talk to each other to find some kind of a key. So, really understanding what’s missing.
What one data set may mean to one organization or a department within a corporation, is totally different than what it may mean to a different organization within that same corporation.
Really just putting the time and effort into the discovery and analyzing phase just makes the development process and the delivery so much easier.
Brent: My piece of advice is you don’t always have to wait for the business to ask you the right questions.
Approach with caution, but unsolicited insights where you just say, “Hey, check this out. I went ahead and in threw these spreadsheets together,” with whatever you can get a hold of. You can start to inject bits of intellectual property and I find that really enjoyable.
Jami: Adysti, do you have any other lessons learned that you want to provide?
Adysti: I think for me, documentation is key. Always try to document every little request that the client asks, especially for changes, just in case if the client forgets that they ever requested the change in the future.
Jami: You sound like a project manager that’s trying to control scope.
Adysti: Well,I think having that project manager mindset also helps with developing a dashboard so that it goes through a smooth process.
Brent: As you go down the path of developing, some guidance that I would give to, whether it be PMs or data developers – I would say the longer you can wait to show something final, it works better for the long term integrity.
You know, develop small pieces. Show them only what they need because the minute it’s in their hands, and something is showed as incorrect or false, it starts to eat away at the trust that they will have in the final product.
Jami: For me, I sat on the opposite side as a project manager “Wait, I thought we were told to, give quicker review cycles and quicker proof of concepts to get the feedback, and stay closer to the customer.”
But you hit on that key point in delivering small segments with high quality to make sure that you’re not damaging that reputation. So it’s really that, that balance.
Tom: Even without the output, you’re still are keeping the customer involved and in the loop. Whether it’s, biweekly or daily stand ups, you still are having that interaction.
Brent: Absolutely. What you show them could be a non-working live version, maybe a screenshot. Balance it accordingly – is something to keep in the back of your mind.
Jami: Absolutely. Any other key points, guys that we want to share?
Rana: I just wanted to say that I think one of the biggest things that you learn, is that it’s the job of that business lead and that team lead to protect that developer.
Something that we’ve really come across is to not ingrain them in so much meetings and so much clients interface, but really give them that time and ability to do their work.
It takes time away from your development team – every time they have to refocus on an activity or have to be pulled into meetings. So being very conscious of that as a team lead is an extremely important part of managing a successful delivery.
Jami: On that note, we will wrap up this podcast. Thank you guys for joining us today on this panel talking about digital dashboards. We hope that the information shared can benefit everybody that’s listening on our podcast and help us all come out a bit stronger.
If you have any additional comments or questions please let us know in the comments field on SoundCloud or you can contact us on the website at migso-pcubed.com . We’d love to hear from you.
We are here ready to help. And if you need a dashboard, please reach out to Tom Burrell. He’d be so happy to hear from you.