A Framework for Stakeholder Engagement – Power BI Development Projects

Engaging stakeholders in dashboard development is integral to the success of the project. Yet many data and analytics teams struggle to appropriately engage their business stakeholders. For many teams communication with their stakeholders involve shallow communication where deep communication is required to appropriately understand the needs of the business and respond. Too many data teams are often 'solution tempted' and rush to solutioning before adequately understanding the business problem they are tasked to address. What's the solution? Effective Communication. In this article I propose an approach to effectively engaging stakeholders in Power BI dashboard development.

The Developer Persona & Role of the Developer

Find Common Ground & Build Rapport with Stakeholders: The best developer-stakeholder relationships happen when there is empathy and rapport between the two. Identifying shared experiences creates a sense of trust. When we have nothing in common with our stakeholders, we don’t have anything to talk about and it makes the requirements gathering phase of a dashboard project that much more painful. On the contrary, when a stakeholder feels heard and understood they will be a catalyst rather than a hindrance in the development process. Building rapport with a stakeholder requires developers to move from beyond simply asking about the weather to being genuinely interested in them as an individual. Grabbing a coffee to learn more about your stakeholder is a professional yet casual interaction that breaks down potential communication barriers. You get to learn more about as a human as opposed to your superior. Keep the conversations light and respectful, don’t get too personal but also don’t ask robotic questions. In these conversations, you learn more about their goals, what makes them excited about their job and what they don’t enjoy about their work. When a developer learns about their stakeholder in a deeper way they are building a foundation of common understanding that will benefit them in their many interactions with their stakeholders.

Understand Stakeholders’ Perspectives: Developers should develop a deep understanding of their stakeholders' viewpoints.  Having empathy for your stakeholders means trying to see the development project from their perspective so that we're no longer defensive and protective of our own ideas. We see their suggestions and feedback as equally important to our expertise. We become vested in making changes to our dashboards because we see their perspective. Ultimately, we see our success dependent on our stakeholder’s success. It does not necessarily mean that you will do anything they ask for. It rather means, that we are shifting our dynamic from one of ‘us and them’ to ‘we are all on one team’. You may still disagree with their perspectives but you will have a deeper understanding of their perspectives so that you can respond to their comments effectively.

“Ultimately, our job is to learn how to make our stakeholders successful, because if we can help them be successful, that will help us be successful as a byproduct” – Tom Greever, author "Articulating Design Decisions"

Demonstrate Positive Personality Traits: There are key personality traits that a developer should have to foster a productive engagement with stakeholders. Developers who are approachable and easy to talk are favored by stakeholders. They are appealing as opposed to developers who are stand offish and are difficult to deal with. Successful developers are likable and pleasant to talk with. Developers should also be confident, but not arrogant. Having confidence is crucial when engaging stakeholders because it communicates that they can trust you and won’t have to micromanage you. When a developer lacks confidence, this appears as uncertainty and causes your stakeholders to question your judgment and decisions.

Change the Dynamic: Instead of positioning your stakeholders strictly as approvers, developers need to reframe their interactions as providing stakeholders with information to present your work to their superiors or other leadership. Developers shift the dynamic from a position of subordinate-superior to one of solidarity and camaraderie.

When developers are likable, confident and have a high degree of empathy with their stakeholder’s, development becomes a lot easier. Stakeholders will feel more invested in the success of the project, they will take on opposition and clear their schedules for these types of developers. Therefore, the fundamental role of the developer is not just to develop a solution but also to develop strong bonds with the businesses’ stakeholders.

How Developers Can Communicate More Effectively

Engaging stakeholders effectively requires the right attitude and mindset. It also requires strong communication skills. That means strong listening skills and knowledge of how to formulate an appropriate response.

Ask Thoughtful Questions: Developers should ask thoughtful questions that lead to deep discussion about objectives and goals. See my previous article Requirements Gathering Framework for Power BI Development where I include a list of thought-provoking questions your team can use in their discussions with stakeholders. Once the question is asked, developers need to listen without interruption, hearing not only what they are saying but also what they're not. Uncovering the problem(s) they are seeking to solve. Techniques like note taking, asking follow up questions, repeating and rephrasing are all great ways to show your stakeholders that you understand them.

It is important to then allow your stakeholders to speak freely, do not interrupt: When you let your stakeholders speak without interruptions it demonstrates that you value what they're saying. Listen to learn, not to respond. Allow stakeholders to talk as much as they see appropriate. When you let them speak, you are telling them (without necessarily saying) that you appreciate what they're saying. When you make them feel appreciated, it builds trust and they'll be more likely to agree with you later.

Watch your Body Language: While your stakeholders talk, ensure they feel like you value what they are saying by maintaining eye contact and nodding your head. Listen to the way they explain themselves and the specific words they use. This will allow you later to mirror their communication skills. Many stakeholders won’t use technical jargon that developers are most comfortable with. For example, instead of using ‘tooltip’ they might say ‘pop-out.’ Don’t rush to correct them, rather use their jargon when you explain your solutions to them in the future. Its also wise to match their tone, some stakeholders are a lot more casual, they may drop the occasional f* bombs and express themselves more colloquially – mimic this. Other stakeholders are more formal, mimic their communication tone and style.

Practice Explicit and Implicit Listening: Just as your body language communicates how well you are listening to your stakeholders. Note taking is another powerful tactic when engaging stakeholders. Taking notes implies you value what they are saying, that you are attentive, smart and a good communicator. It also serves to have a paper trail and document what logic went into the original decisions.

Lead with Yes: Many developers when faced with difficult asks from stakeholders will jump to list all the reasons why it won't work. When this becomes the norm however, it portrays you as someone unwilling to pivot or be flexible. Instead of jumping to no, say yes and figure out how it can be done. If its truly not an option at least pause briefly or follow up later, this shows that you have considered their ask and understood it before you rejected it. Also, take the opportunity to present alternatives that accomplish the same objective.

“How well we communicate is determined not by how well we say things but how well we are understood.” – Andrew Grove, American businessman

Present Options: Developers can demonstrate their expertise by presenting various options in advance. Wireframes and mockups can be very effective to show alternatives that your stakeholders can critique. We want to equip our stakeholders with the knowledge why our recommendations are the best way forward. Instead of only presenting them one option and not be willing to show them alternative solutions. If you come to the meeting with no alternatives, your stakeholders are going to Google it from their phone and suggest the first option they find.

Communicate Expectations: A lot of developers struggle to commit to a timeline, and as a result have a timeline imposed on them that more often than not is unrealistic. As part of your status updates with stakeholders clearly explain at a high level your process and key milestones. Use a horizontal timeline visual to show them where you are and what it to come.

Not all Stakeholders are equal

Not all Stakeholders are alike and vary in terms of the degree which they impact your dashboard development. Some stakeholders have a high degree of impact on the success or failure of your dashboard, others simply need to be involved in an advisory and visibility perspective. Understanding which type of stakeholder you are dealing with determines the degree in which they need to be kept reprised and involved in key decision making.

Primary Stakeholders: Highly influential and impactful stakeholders need to be kept satisfied and actively involved and managed in the development process. This means ensuring this type of stakeholder is involved in all the feedback sessions during the iterative development lifecycle. Factor in, if this type of stakeholder has extensive domain knowledge, this means that they should be involved even more so. For example, involved in defining key performance indicators and being leveraged in translating business needs to technical specifications.

Secondary Stakeholders: As for stakeholders who don’t have a lot of influence and are not as impactful, they should be informed and kept up to date about the degree of completion of the dashboard. If they have strong opinions on KPIs or the dashboard itself, their opinions are less crucial to accommodate. They still should be heard but decisions should not be made by them in isolation. Rather their ideas and feedback should be escalated the key stakeholders to determine whether the feedback should be incorporated or actioned.

The ideal meeting structure

Once the dashboard build is underway, it is vital to schedule a recurring cadence with primary stakeholders to keep them informed on the progress of development as well as surface potential issues or roadblocks. I recommend that status update meetings should be scheduled between 2 – 4 weeks apart (but not more than that.)

The value of the time of your primary stakeholders is high and so it is critical to ensure that the meetings are effective and straightforward. This month’s article is accompanied with a Template PowerPoint presentation that you can use for these meetings. (Please DM for access)

To ensure the meeting achieves the objectives it is recommended to include the following:

Dashboard Objectives: Restate the dashboard’s objectives and the expected business value that was captured during the requirements gathering stage of the project. Don’t worry about sounding repetitive. Too often dashboard projects lose sight of their original  intent, and it is only after deploying the dashboard does the development team realize how much they have deviated from the original goals of the dashboard.

Outstanding Action Items from Previous Status Update Meeting: Summarize in bullet points all the action items that came out of your last status update meeting and highlight if any are still unaddressed. We want to avoid lingering issues that can potentially derail the project pre-deployment.

Expectations from the Meeting: State what you need from the stakeholders to keep the development moving forward. Any issues or roadblocks should be clearly outlined and proposed next steps should be identified. In the interest of time, you want to make sure not to have too many disparate expectations, issues should be prioritized in terms of immediate impact on the project. If something is too premature for them to weigh in on, delay this and prioritize decisions that are relevant to the project at this stage in the development. For example, you might expect feedback on the wireframes, but it's too early for them to comment on specifics of the dashboard.

Timeline and determination of ‘where we are in the development process': Your stakeholders need to see visually where the development team is in the development process. A timeline visual or progress bar can be very effective. If the development cycle is behind schedule, this needs to be brought up and explained in an efficient way.  Stakeholders will be very interested in monitoring the progress of the dashboard and if consistently we are overpromising and under delivering, its their role to reset the development team and reprioritize or expand the initial scope and timeline if necessary.

The Solution is Effective Communication

In conclusion, effectively engaging stakeholders in dashboard development is crucial for its success. The focus of this article has been on the necessity of structured and strategic communication between data teams and business stakeholders. To overcome many of the dashboard failures, data teams must prioritize understanding the business problem first then solutioning with stakeholders engaged and included. I hope this article has provided you with a few tactics your data team can implement!