How to Get End User Buy In on Your BI Project

business people looking at a laptop together

For your BI project to succeed, all stakeholders must have a say in its development. That includes the front line users of your application. Getting these users to understand the value of a new analytics product is a necessary part of your BI project. They, more than anyone, will adopt an analytics solution that delivers the data insights they need.

To get line of business end users to adopt analytics, start early and engage often.

Identifying User Roles

Start out with an inventory of who is going to be impacted by a new analytics system, and how they will be impacted. What are the different user roles? How do they interact with analytics now, and what new functionality will the solution give them? For example:

Line of Business User Role 1: currently has no ability to view analytics. After deployment, users with this role will be taken to a dashboard containing KPIs and a bar chart mapping daily activity upon log in to your application. These users will need to understand the relevance of KPIs to their work, how to drill into a bar chart to see details, and how to save a dashboard and share it with others.

Line of Business Role 2: is a team lead who currently receives daily and weekly spreadsheets via email. This type of user will need to understand how to navigate to a designer to create new reports, how to find existing reports, and how to add some simple visualizations to a dashboard.

Line of Business Role 3: this power user will want to understand how to create complex queries, stored procedures, and report and dashboard templates.

Identifying User Stakeholders

The core team of user stakeholders for your project may have different roles to play, depending on their strengths. Subject matter experts may be of most help during initial project phase. Others may be better suited to serve as points of contact, attend status meetings, or train users. Regardless of their roles, these users will need to understand the reasons behind moving to a new analytics and reporting solution. Concrete examples can help explain the value behind the changes, like:

  • On an existing report, you will be able to drill down for more detail, or see outliers highlighted in red.
  • A traditional grid-style report will be easier to understand when displayed as a visualization.
  • At first log in each day, a dashboard with the most important KPIs will be displayed.
  • Reports and dashboards will be viewable on phone and tablets, for access to analytics anywhere.


Your organization relies on a variety of channels to communicate. Your BI project will likely use all or most of these channels as it moves forward. For example, newsletters and a company intranet can have dedicated areas allocated to display project status updates and answer questions. As your launch date gets closer, you can use emails to broadcast important information to all users. Status meetings, whether they are small team meetings or company-wide ones, are another opportunity to keep users aware of the project status.

Managing Frustration

System changes are frustrating to users who rely on their applications to operate smoothly and consistently. Communication and the right team can help make your launch a softer landing for them. Consider rolling out functionality in stages, starting with a canned set of reports that match existing reports in production. Define training objectives early on; include a variety of training materials and styles to adapt to users’ different learning styles and timeframes. Finally, celebrate the change, don’t bludgeon staff with it. Highly productive users may be the most resistant to change, since they have to balance learning a new reporting system with commitments to their many other objectives.

download the ebook Overcoming the 7 Challenges to Embedding BI in Applications

Leave a Reply