Our website is not supported on this browser
The browser you are using (Internet Explorer) cannot display our content.
Please come back on a more recent browser to have the best experience possible
Over the past year, our clients have benefited immensely from the insights that digital dashboards provide. After you realize you want one, though, the next steps can seem daunting. However, with the right guides, they don’t need to be.
Following up on MI-GSO | PCUBED’s Introduction to Project Management Dashboards podcast, Jami Anderson, Tom Burrell, and Brent Wagner return with newcomers Emily Grindstaff and Brianne Goodwin to discuss why you could benefit from a digital dashboard of your own.
Emily Grindstaff: Without the ability to take some sort of action, the dashboard is providing information, but not value. And that’s the differentiator. Information plus action equals change, and the right change equals value for our customers.
Jami Anderson: Hi, all! And welcome back to All Things Project Management, our podcast about, yep, all things project management. Last spring, we did a podcast on an introduction to project management dashboards – roughly a year ago today. There’s been a tremendous focus on digital dashboard development in past year for us. So, we thought we’d follow up on our introductory session with a look at digital dashboard development. Here with me today on audio, not in person, because of COVID still, we have Tom Burrell, Brent Wagner, Emily Grindstaff, and Brianne Goodwin.
Now, Tom and Brent were with us last time. Brent is a senior consultant based at our San Francisco office with over seven years working in data-driven analytics. Brent recently had a baby and is learning that there are no tools which enable better productivity than a solid nap time.
Brent Wagner: Thanks, Jami. And yes, naps are extremely important. Thank you so much for having me on the podcast again.
Jami Anderson: Tom is a business manager in our Detroit office, with a passion for digital dashboards. Last year, Tom had just learned how to cut hair out of necessity, both his and his dog’s. Anything new to share?
Tom Burrell: Not necessarily. I’m just happy to finally be going back into a barbershop to get my hair cut. So, I feel very fortunate for that. Thanks, Pfizer. Appreciate it.
Jami Anderson: Yes, thanks to Moderna, too! Joining us this time is Brianne Goodwin, a project management team leader who’s currently building a digital dashboard for an automotive OEM.
Brianne Goodwin: Hi, Jami. Thanks for having me on today.
Jami Anderson: Of course, Brianne! And Emily Grindstaff is a principal consultant with many years of experience straddling the line between IT and business solutions. She’s a PMP certified project manager. And a Prosci certified change manager.
Emily Grindstaff: Hi, Jami, glad to be here.
Jami Anderson: So, Emily, you actually coined the name of our podcast today. You highlighted a key challenge our consultants have run across in the past year.
Emily Grindstaff: Yeah, basically. today’s podcast is going to answer as the question of, “Hey, my executive just came into my office and said, ‘I want a dashboard.’ And my question is, ‘Now, what do I do?'”
Jami Anderson: Yes. I’m guessing they saw a beautiful dashboard our team put together for another department, or maybe a recent case study on the benefit to decision-making, and now want one for themselves. So, first question goes to you, and was probably the first question out of your mouth and response back to the executive – why do you want a dashboard?
Emily Grindstaff: Yeah. So, looking at why you want a dashboard – leadership needs a high-level, strategic view of how the organization is performing in order to make decisions that move the team in the direction defined by its strategic goals. A well-defined dashboard will provide the aggregated metrics needed to determine, set, and monitor that direction over time.
And while the metrics used may differ from company to company and dashboard to dashboard, what they should all have in common is their alignment to the broader strategic goals of the company, and their ability to show the direction that the team is currently moving.
For example, if you compare dashboards today to some of the past Lean and Six Sigma strategies, you’ll notice a correlation. Just as balanced scorecards are used for the selection of project metrics that cover both financial and non-financial metrics, as well as lagging and leading measures across four areas being financial, customer, internal processes, and employee learning and growth, a dashboard should look across the same areas in the aggregate and at a level that equips leadership with the information needed to make informed decisions.
Brent Wagner: It’s a good point, Emily why a dashboard – aka, why use business intelligence tools to analyze your organizational data. I think you touched on this briefly – cost saving, financial transparency can identify gaps in spending and uncover positive and negative trends, which helps shape compliance policy.
There’s also the opportunity for faster and better decision-making through operational excellence. The ability to get rapid insights on current operations can be a powerful tool in the hands of those making decisions in a moment’s notice. And also, for identifying new opportunities, new products, services, programs, and projects are made possible by gauging customer and business needs using current and historical data insights.
Jami Anderson: Okay. I’m hearing you loud and clear. The key benefit of dashboards is that they allow you to use your data to drive decision-making. So, talk to me about the different types of dashboards.
Tom Burrell: Yeah, so, like I said in the last podcast – in general, we consolidated our delivery at MI-GSO | PCUBED into three types of dashboards.
Those are operational, analytical, and strategic. So, just to give a quick gloss over of those for those who weren’t able to join us in our last podcast session. An operational dashboard might give you a glance at hindsight of what has happened and visibility into what is happening at this moment.
So, this is our current output and the dashboard shows where I may have an issue or a flag. Like for instance, why do I have lower output than I have before based on my historical analysis over the past couple of years? So, essentially, an operational dashboard really gives visibility and visualizes your delivery.
The second component is an analytical dashboard, which is used to provide insights into the business by leveraging data analytics. I will say this about MI-GSO | PCUBED, I think we’d do a great job of recruiting and maintaining talent in the data analytics space. It’s becoming a massive enabler for what we’re doing around not only digital dashboards, but also around digital PMOs.
We’re really digitizing our overall operations, and through data analytics, this explains more of the why behind that flag that you might see on the dashboard. So, it can give some visibility and more of a reason on why your output or productivity could be higher or why it was higher, as well.
So, in that way, you can really get some sort of output that could lead to a decision, as Jami referenced earlier. So, this is typically used by middle management who might be looking to make those decisions operationally.
And the final would be a strategic dashboard, which again, provides that foresight into organizational delivery. So, that strategic piece takes a global view of operations and analytics, and then allows for the user, who’s usually an executive in this case to help steer the organization toward their goals while leveraging this all-in-one tool. So, in essence, it provides the proper foresight into their business that an executive might be looking for, who isn’t as involved on a daily basis.
So, two final important points on that – these different functions are not possible without the other. So, you can’t have an analytical dashboard without operational, you can’t have strategic without analytical and/or operational, but you really may not need anything more than an operational dashboard and a base visualization of your delivery, if that makes sense.
So, if you have great data that’s stored in Excel or stored in a database and you just want it all condensed into one area, an operational dashboard might be all that you need. On the other side of that, if you have very unclean data, visualization might not do the job because you might not have the data clarity in order to make a decision off of what you’re seeing.
So, there’s a lot of different examples of that for some common types of dashboards and applications, but really we focus on our stakeholders and answering this question with really ultimate precision – who is the dashboard for, really, and what information do they want to get out of it? So, the user intent is really vital and making that determination as we’re scoping these types of projects, and that in the end will help drive the type of dashboard – operational, analytical, or strategic – that the user needs and wants as well as the team formation that M|P helps put in place and that digital PMO to really deliver the tool, as well as some of the business solutions around it.
Tom Burrell: So, Brent, what are some more of the more common types of an applications of the solution as it relates to a digital dashboard or a digital PMO?
Brent Wagner: Yeah, so some of the key dashboards that we develop here relate to milestone tracking, basic understanding of when your milestones were hit or missed, resource loading and leveling, financial allocation and forecasting, very important to our executive stakeholders, portfolio overviews, to get an understanding of everything that’s going on within your organization. And then you can drill into your project performance overviews of each individual project solution and technology.
Adaption monitoring – so, we’ll target select users who have been identified as key for certain software solutions that we could deploy. We’ll track their usage over time and make sure that they’re happy, and if we see a dip in utilization, we try and make the adoption of technology more seamless with those types of dashboards. Risk and issue mitigation is another key type of visualization. And then master data management and overview of the KPIs and measurements that are agreed upon throughout the organization.
Jami Anderson: So, the types of questions or issues that they want to get out of the dashboard determines the type of dashboard. Okay. Gotcha.
Brianne Goodwin: Exactly. So, it seems as though that would be relatively straightforward. They’re asking for a dashboard, so they must know why, but in real life situations, it’s much more likely that the client has rightly identified a number of the impacts resulting from tool or process issues within their environment, but they haven’t yet honed in on the cause.
And it would be our role to help them uncover the ailments that are actually causing those symptoms. And that will provide the direction necessary for dashboard development kickoff, figuring out the root causes of those problems that led your executive to this point, involves performing an assessment of that business environment and extrapolating that into some base concepts for what the tool will need to do. And it’ll define the dashboard type that you’re going to be aiming for.
Jami Anderson: So, last time we talked about key questions and Brent, you led off with wanting to see the data, see where it’s held.
Brent Wagner: Yes, Jami, I’m a solution architect. It’s hard to ignore that type of question.
Brianne Goodwin: And here, we’re talking about intent questions as opposed to those data questions.
So, is the client trying to place a magnifying glass on the bottlenecks that they’re seeing? Are they in need of some means to justify their business needs such as equipment or resource adjustments within their organizations? Do they need a way to temperature gauge or do they need a lens into the daily operations of their team?
You should be asking them penetrating questions that go beyond their immediate need to say fix problem X, because they’re just tired of seeing it. For example, have you tried to mitigate this issue before? What went wrong when you tried to deploy that solution? And Brent, as the solutions architect, will want to pry into why they’re using the systems that they have in place.
If it’s simply because that’s the way things have always been done, they may be working with levels and levels of these legacy systems and processes that no longer suit how the business or how the industry is moving. Understanding those questions that they’re trying to answer and documenting that really early on, that’ll allow you as the project manager to begin formulating your plan for development, and it will help prevent scope creep by defining those barriers of the dashboard’s intent really early on.
Jami Anderson: Thank you, Brianne. So, you’ve really started to articulate a series of steps for me that I can go through to develop a dashboard, starting with that assessment or initiation phase.
What are those common steps to go through to develop a dashboard?
Brianne Goodwin: So, for us, there are four steps – there’s define, innovate, improve, and then scale. From your initial assessment exercise, performed during that initiation or definition phase, you should be able to compose a really basic structure for the diagnostic part of your project.
Eventually, you’re going to be neck deep in ideas, and possibilities, and all of this feedback from your stakeholders, especially once they get engaged and really excited when they start to see some of the results, and then you’ll be in need of really clear questions for them, make sure that you’re asking the right questions during those interviews to prevent getting off course, or your dashboards, edges are going to become blurred because you’re trying to take too many paths at the same time.
Each organization, each entity will have not only unique goals and hopes for the dashboard, but they’re going to be categorized in different ways. Tapping into that user intent and really clarifying with your executive stakeholder is the goal of your definition process.
And then the next step will be to use all of that information on expectations, corporate structure. Business needs and using that to break out the best project approach for your dashboard development. Especially now, a lot of time, people are looking to Agile. So, can you perform this project? Can you deliver an entirely Agile manager? That would be an ideal choice if there’s little understanding of what the end dashboard will need to look like.
Or are you better off operating in a traditional or a hybrid project approach? And the team that you eventually build is going to be dependent in part on those factors. Never underestimate the need for a team with powerful soft skills in a situation where a previously unchecked process is going to be evaluated and vetted for the first time.
Jami Anderson: Brianne, that’s really clear for me. Tom, what are some of the things that we should avoid in these early stages?
Tom Burrell: Well, as you’re defining performance indicators, and as you’re looking into the business and the user intent, I think that’s a really important point to make. But also then displaying that data that might be inaccurate really early in the process. It’s definitely that failure mode that I think we can all speak to you from experience – the customer knocking on your door saying, “You know, I want to see this, but where’s my data?” The issue is with that type of an approach in a traditional type of a project, we don’t get that data until we go through the proper process phases, you know, that Brianne just outlined.
So, this has an effect on our client’s trust upfront, and it’s really a great way to prove our value and earn that trust once we emphasize that we can’t simply just show their data right away. And as a business manager, we really need to give our technical consulting teams time to analyze and accurately represent data before we show it to a customer, and also making sure that that customer understands our experience going the other way, and how things have been broken in the past.
Jami Anderson: Garbage data in, garbage data out. It doesn’t enable solid decision-making. Yes, great point, Tom, on taking the time accurately to represent data as project managers and being embedded in our client’s organizations, that’s one of our key value adds. We know the status, and we know what should be coming out of the dashboards and have that ability to step back and look to identify any potential red flags.
Jami Anderson: So, Brianne, once we’ve done the initial defined phase, what’s next?
Brianne Goodwin: Once you have that team and your kind of kickoff goals in mind for what exactly is needed and how you might get there, you’ll need to block out those vital stages of the project, not only for allocating your resources, but for time management, and for when you’re going to be demoing and delivering work packages.
That’ll include nailing down how you’re going to capture and maintain your performance trend data, supporting the maturation of those valued key performance indicators, and how you’re going to manage the continuous improvement of the dashboard itself because they grow and evolve over time. You’ll enter this phase of building, assessing, and then learning from your completed work to provide more and more functionality to the client.
This is the innovate, improve, and scale step mentioned earlier. For example, in one of my recent projects, there was a plethora of data in different formats, and that meant the client and their functional partners had limitations on their visibility into their daily operations and how those activities stacked up in a month-over-month or yearly trend.
The information that they did have on this, and they were capturing quite a bit, but it lacked the detail on the delays that they needed to see in order to grasp a full picture of their performance. None of which we understood when we first came on site. We needed to build incrementally and then innovate. Before we got to that state of clarity.
Brent Wagner: Yeah, Brianne, a key part of innovating and improving is changing the question you’re looking to answer with the data based on what it’s telling you. Decision-making is never static. It flows, changes with the project issues. So, you constantly have to revise and pivot the question you’re asking of your dashboard to tie back in with the data so that you can make actionable insights.
Insights such as how many projects do we have running right now? Why does certain projects perform better than others? Which areas of the business have the highest performance and why? How many external market forces impacting my current book of work? What level of performance can we expect? If we maintain our current business model? If our organization was willing to make changes, what levers could we full and how effective might they be? And you know, what are our largest gaps in spending in performing?
Brianne Goodwin: Exactly. So, closing those loops, everything that Brent mentioned really bridging the gaps and the entire process up to this point is what you’ll base your key performance indicators on. And you’ll define those in collaboration with the client.
We had to decide exactly how much of the historical data was valuable to maintain and questions like that are going to lead you up to your final KPIs that are a combination of everything that you’ve learned up to this point.
You should be able to lay out how you’re going to reach stakeholder sign off during development, what kind of strategic reporting cadence will work for the organization. And that’s where all of the research that Brent mentioned on the organization structure and the environment and culture there is going to come into play and you’ll want to know how frequently you’re going to release these work packages up to the client.
It’s important to make sure that you’re monitoring your communications and your sign-off very closely. Never allow a key stakeholder to remain in the dark on a project or the milestones or forks in the road. It’s a really common mistake to have the plan set up and your goals clearly defined. And then letting that decrease the frequency with which you check in with the users.
And then you’re sort of left to resolve this mismatch and the expectations that naturally happen over time. All those tool and corporate limitations, the decisions that were based on those limitations, should be formally presented and documented during your reporting cadence, and your client should actually learn a lot about their business from this process, as well.
Tom Burrell: And when you’re mentioning a reporting cadence, I think it’s important to let the customer knows and just can take into consideration how much change is actually undergoing when you go through these processes to help define the dashboard, because not only are you talking about a reporting cadence, they might report monthly to their clients.
But if we’re delivering in a bi-weekly fashion, as Brianne mentioned with these drops of features or new visualizations, it’s important to ease them along in that Agile journey. Because again, you’re dealing with a lot of, “I’ve been doing things this way for my entire career. And I want to continue to do that that way as much as possible.”
So, kind of helping to, to mold our delivery around how the client actually delivers, but then also bringing them along on our journey as well as that kind of thought leader around Agile delivery.
Jami Anderson: Okay. So, we’ve talked a lot about developing the dashboards. However, putting myself into the shoes of the end user or customer, what do I do with this data as a user?
Emily Grindstaff: Yeah, so, Jami, for you, as a user, you probably want to think about why your manager asked you for a dashboard. Like we said at the beginning, for me, dashboards are all about providing the right level of information to the right decision-maker at the right time. That’s why we have different types, for example.
The challenge from a change manager perspective is helping keep the dashboard users, the consumers, or the people that run the report and look at the outputs, understand how to take action based on the information now put in front of them. A lot of times, this is a journey for most of our clients and most organizations.
The journey kind of goes like this – the business creates a dashboard with multiple levels of information. People at each level are trained on the mechanics, meaning how to use the dashboard and run the reports. But then in many cases, the training ends. The problem here is this leaves the user wondering what to do with the information now that they have it.
That’s where change management comes in, for me. The training needs to go beyond the technology, and it needs to tie into the business so that everyone knows what action to take based on the information on the dashboards that they used.
Without the ability to take some sort of action, the dashboard is providing information, but not value. And that’s the differentiator. Information plus action equals change, and the right change equals value for our customers.
Tom Burrell: Yeah. I think it’s a great summary, and this is all just kind of encompassed by driving decisions using data. So, it’s all about data to decisions. You’ll see a lot of content that MI-GSO | PCUBED puts out that has that tagline in there, and that’s on purpose because that’s what we’re setting out to do as an organization is, is really getting the users to adopt, you know, to our deliveries, in this instance, a dashboard as a centralized source of information, and really how to then use the data.
Brianne Goodwin: Yep. That’s a good point, Tom. Your executive or your client should be refining their understanding of their business throughout the entire process of guiding your development team through that development process, and the training that Emily was talking about, as well as from the data that comes from the final tool.
Once they reached that state of using the dashboard. They should be able to pivot themselves towards those strategic objectives that were mentioned at the very beginning of the podcast. And that data is going to be what fuels their ship.
Jami Anderson: So, thank you to each of you for joining us today and sharing your insights on “I want a dashboard, now what?”
I would also like to thank our listeners for taking the time out. If you’d like what you heard, please give us a rating and subscribe to our podcasts. You can also let us know in the comments what questions you have around dashboard development, so that we can answer them in an upcoming session.
We hope you can join us next time. Bye for now.
A monthly digest of our best articles on all things Project Management.
Our website is not supported on this browser
The browser you are using (Internet Explorer) cannot display our content.
Please come back on a more recent browser to have the best experience possible