User adoption is critical to the overall success of any IT project…but that goes double for self-service BI projects because at the end of the project the users will be expected to actually use the tools to generate their own BI (reports, dashboards, scorecards, analysis) and facilitate fact-based decision making in a rapidly evolving business climate. If they don’t use the new tools now at their disposal, then the business will never realize their return on investment. It doesn’t matter how big and bad your servers are, how agile your data model is, or how fast your queries return data….if the users don’t like the tools they have to work with, then the project was a complete waste of time and money!
So how do we, as developers, architects, and project managers, mitigate the risk of poor user adoption in projects that include a self-service BI component?
The long answer involves project management and change-management ideologies…boooooooooooooooooring.
If you’re like me and have a short attention span (probably due to the amount of time spent on the internet) then you’re interested in the short answer. If you’re dealing with a Microsoft shop then you’re in luck because I have an answer: AdventureWorksDW2012. Yep, the same fictitious bike manufacturer we all know and love.
Here’s the typical format of a Microsoft DW/BI project:
- Data Warehouse (SQL Server + SSIS)
- Semantic Model (SSAS Multidimensional and/or Tabular, MDS, DQS)
- BI Portal (Sharepoint, PerformancePoint, SSRS + Power View, Excel/PowerPivot)
- Client Workstation (Excel/PowerPivot)
For a project like this, it could be a few months before the first release and opportunity for users to test drive the system … which in my opinion is too long. Setting up a small user environment (SQL Server, SSAS, Sharepoint) on a single server with the AdventureWorks dataset can be done in a just a couple of hours. Yeah, the sample data might not mean much to the end users (unless they happen to work for a fictitious bicycle manufacturer), but that’s not really the point. The point is to build familiarity…and for most people that means use over time.
By the way, I strongly encourage you to incentivise your users to spend a little time each week playing with the new tools/features. This is an excellent opportunity to apply some principles of gamification…for example, hold competitions where users compete to see who can create the best looking PowerPivot dashboard, Power View report, etc. The collective group can then vote on the winners.
And no, this absolutely does not absolve you from formal training at the end of the project. However, when that time rolls around, your users will now be familiar enough with the new tools and functionality that they won’t dread the training and they’ll get more out of it because they’ll probably come ready with “how do i” questions.
So don’t wait for the first release, start building familiarity as soon as possible.