Recently, I led a Search Discovery Educational Community (SDEC) conversation about BI platform adoption. You can join the SDEC and check that out here. This article provides a summary and lays out an implementation strategy to ensure the successful adoption of your new BI platform. You can adapt many of the concepts discussed in this post for any platform.
BI Platform Implementation Strategy: Adoption Phases
You can break the adoption process into five phases, and each of these phases will have a striking resemblance to the Software Development Life Cycle (SDLC) phases. The process for adopting a new BI Platform can be somewhat complex and requires dedication throughout the project duration.
Introduce - “We have gathered you all here today to talk about our new BI Platform.”
During this phase, the team needs to determine who will be impacted by the new BI platform and what those impacts will be. Once you have identified the primarily affected individuals, meet with them and consider the following:
- Is this person part of the department that will be using the new platform?
- Is this person responsible for current reporting from the data sources that are to be connected?
- Is this person likely to be consulted during the project as a Subject Matter Expert (SME)?
During this stage, you will be meeting with team members identified above and lay out the timeline, phases, and tasks for the project. Additionally, you should walk through a RACI matrix about each person’s roles and responsibilities during the project. You should be able to answer the following questions as part of the overall expectation setting:
- What are we doing?
- Why are we doing this?
- When are we doing this?
- Who is involved in this?
- How are we doing this?
- What is the cost of not changing?
- Why is now the time to change?
Engage - “A critical success factor in platform development.”
During the understanding portion of the process, it is crucial to focus on not building a solution you think people will want but instead building a solution that people will need.
It is not unusual for a group of individuals who are tasked with implementing the BI platform not to be the end-users of the platform. So what ends up happening is that a solution is built that aligns with the expectations of the platform implementation team but not with the end-users.
To avoid this, it’s important for the BI implementation team not to guess or infer what end-users will need but to understand it. Engage with the end-users of the platform to understand 1.) the use cases for how they would leverage the platform, 2.) the struggles they have with the current solution, and 3.) what they need to see in the platform that will make them use it.
Although it would be great to have 100% buy-in from the start, we know that is not realistic. It is important, though, to get buy-in where and when you can. Since people will be at various levels of how bought-in they are, continue to engage with them. If people directly part of the project team are not bought in, it is critical to create a plan to keep them engaged and address their concerns and questions that prevent full buy-in.
Not everybody will see the immediate value in the platform changes, so it is important not to dismiss their feelings.
On new BI platform implementation projects, we often discover a handful of folks who are very set in their ways. Maybe they’ve gotten very used to creating their reports in Excel or have become accustomed to the manual processes needed, for example. Sometimes, they have even spent years developing and honing their current approach. Instead of dismissing these people, it is important to work with them through this process to help them see the value of this change.
Build - “If you build it, they will come”
Once the implementation starts, keep the momentum going. DO NOT go down to the proverbial basement to not be heard from for a few months. Keep everybody involved by providing status updates about the project. Be sure to highlight and celebrate key milestones. When a new data source is connected, let the team know. When a dashboard is being built, let the team know. Keep them posted on the status and on the timeline.
Don’t wait until the end of this phase to show your work. Instead, continue to engage with end-users throughout the process. Showing them the process will allow them to feel connected to the project and will enable them to provide feedback that can be incorporated before this phase ends.
For example, consider that you build a dashboard that shows metrics weekly, based on requirements that you got in the engagement phase. But, when you review this with the end-users, you learn that they only report on metrics once they have data for a whole month since there is a lot of variability over a month.
It’s a straightforward change to move from showing metrics weekly to showing them at a monthly level. When you check in for feedback, you’re not only making a project that will be more user-friendly, you’re also able to demonstrate to end-users that the platform can be easily adjusted to meet their needs.
Also, tell end-users when a requested modification is outside of the initial scope but assure them that you’ll add their requests to the project backlog.
Apply - “Let’s go for a test drive”
Even though change is a scary word, it doesn’t have to be. For example, if your company has a process in place for reporting (or for reviewing key metrics), consider what it will take to change that process. It’s okay not to jump right into the deep end, but set realistic expectations for when the process will be fully changed.
An excellent example of this would be if your company sends weekly emails regarding marketing performance and then does a large monthly read-out on marketing performance. Instead of immediately changing to “all reporting needs to be done using the new BI platform,” consider a scaled approach: In the first month, all weekly reports are done from the new BI platform, and the monthly reporting stays in its original format. Then, in the second month, all weekly reports can be done from the BI platform, and so can the monthly report.
Change is much easier to digest in small bites.
Frequently, the most significant barrier to adoption is training. Ongoing training is vital because it ensures that the end-users see the various ways to use the platform. Since not all users of the platform are at the same skill level, here are some things to consider:
- You might need to have multiple training sessions per year on the same topic as a refresher course or to train new hires or people new to the platform.
- You might need to have different training courses based on the various users of the platforms and their roles. For instance, you might need a training session specific for users (i.e., people who will be doing ad hoc data analysis within the platform) and a training session specific for basic dashboard consumers.
It is important to know your audience and develop a training curriculum that evolves as your company’s use of the platform grows.
Hot on the heels of implementation is iteration. As people use the dashboards, new requests will inevitably surface. As a result, it’s impossible to develop for all requirements in the first pass. Instead, focus on creating a solution that can be used as efficiently as possible while maintaining a backlog of requests.
We often get an initial collection of requirements which includes the list of metrics people want to report on, the dimensions they want to be able to filter on, the types of visuals they want to see, etc. However, until this has been fully implemented and put to the test, there will likely be requests for changes. Therefore, both the implementation team and the end-users need to understand that the first version is not the final version.
Embed - “The more, the merrier.”
Often, the initial implementation of a BI platform is limited to one department, a few use cases, or a limited number of data sources. Therefore, after the initial implementation, you need to be able to expand the platform’s footprint. How?
- You can look to expand within the same department and broaden the business cases.
- You can look to expand within the company and find other departments that may have similar business cases.
The expansion of a BI platform can take many different directions from the end-users to the data connections to the created dashboards.
Many BI platforms have multiple releases a year. These releases can include significant behind-the-scenes performance improvements or tiny incremental changes to how visualizations are built. Ensure that the platform owners are aware of these enhancements and leverage them where appropriate. Consider sharing release notes with power users or even creating specific release notes for your users, highlighting key enhancements that they should be aware of.
Yup, training is on here again. Unfortunately, time and time again, we have seen a lack of initial training OR a lack of ongoing training being a significant barrier to adoption.
Not only will new people start using the platform as part of the expansion, but new features and functionality will be introduced. Ensure that as the platform evolves, so does the training.
As BI platforms introduce multiple new visualization templates or new data transformation functionality, we see that those new features may go unused unless we train people. Worse, the platform may be misused.
This post gives you a good idea of where to start for launching successful BI initiatives. However, please feel free to reach out to us in the form below for more support on this.
Looking for more Business Intelligence posts? Try these: