3 Do’s and Don’ts of User Adoption
User Adoption – if you build, it will they really come?
When I was a young consultant, I was put on a project where the client had purchased and installed Cognos Series 7 a few years prior, but had not gotten the results they had hoped for. My first day, I asked them how often and how many people were logging in to run their reports, and they just laughed. The environment had hundreds of reports that had been built as Impromptu Web Reports and PowerPlay Web Reports. They also had several PowerPlay cubes published (seemingly a different one for each group).
When we started digging in, it turned out that none of the things they had built were being used. Sadly, this is not a unique story. It’s not one that changes as the technology changes either. It’s one that I could repeat with different customer names over the last several years that I’ve been implementing IBM Cognos 8 and IBM Cognos 10. So, what’s really going on here? The business is funding these projects in hopes of finding that ever-elusive “full promise of BI”. Yet, most businesses are not actually using the tools that they’ve paid to implement. Too many IT groups have taken the Field of Dreams approach to their implementations, quoting the famous line from the film “If [we] build it, they will come”. The truth is that building it is not enough.
In this article, I’m going to provide an overview of three Gotchas that will kill user adoption and three Musts that can increase the odds of strong user adoption. By avoiding these gotchas and implementing these musts, you too can develop a high-engaged user community.
The DON’Ts
1. Data Overload
As IT organizations (the typical implementers of business intelligence solutions in an
organization), we often think that the more information we can provide, the better. We, therefore, find out what data source or data sources users are trying to get access to, and we work our IT magic to consolidate every field available into a beautiful model with business names and every possible combination of tables all displayed in one package. It’s really a marvel to behold, and we’re confident that every business user in the company will be thrilled to see it. The truth though is that they aren’t thrilled to see it. Most of them are overwhelmed by the amount of information that has been provided and as a result find it difficult to find the information that is relevant to them. The end result is that they either don’t try or they email IT every time that they need a report. Ultimately, data overload will take away from the part of business intelligence that IT loves the most (getting the business to do some stuff for themselves).
2. Too Much Bling
Mark Cuban famously said that, “A sure sign of failure for a startup is when someone sends me logo-embroidered polo shirts.” I’d argue that any new implementation that has a custom skin before it rolls out a report is just as doomed to fail. In the same vein, any report, dashboard, or mobile solution that focuses more on using the newest visualizations and flashy content, but not enough on the information they are trying to convey, will also likely fail. As analytics leaders in our companies, we have to remember that analytics is about making better decisions, faster. When you’re designing your solution, that should be your overarching focus. Should I use a bar chart or a line chart? It depends on what will better relate the information. Should I include all of the underlying data with a chart? Probably not, but it depends on what the user needs to make better decisions. The ultimate litmus test of anything you provide should be to ask the user first, “what does this mean?”, and second, “does this help you do your job?” If they can tell you what a report means in a short amount of time, and the meaning in the report brings them value in performing their job, you’re likely to get user adoption.
3. Payment without Buy-In
What is payment without buy-in? It’s when you get the business to fund . the BI initiative, but you fail to involve them in the process of implementing it. It’s not enough to just use the business money. Many organizations have budgets set in a way, where they have to spend the money on something or lose it, and analytics sometimes ends up being a “better than losing budget” decision. To get real buy-in, you need to put business users onto the implementation team. Trust us: we know how scary this can be. But ultimately, this one move will almost always address the other pitfalls of user adoption.
The Musts
1. Enablement
This is a big one. Enablement spans a lot of content, but the real goal is for a user to be able to easily work with what you provide them. Keys to enablement include training, support, and involvement. Training will depend on the intended use, but is important for all potential users. We recommend hands-on training when possible to make sure that your users are able to ask questions and learn from someone knowledgeable on the solution. Support on the other hand is ongoing. In this area, we recommend setting up internal user-groups. Consider a monthly meeting to show your users new techniques. You should also constantly strive to help your users increase their skills on the tools. If they get better, you ultimately have to do less. It’s the old “teach a man to fish” approach, and it works great with analytics.
2. Relevance
The information you’re providing has to be relevant to the user. We talked earlier about information overload. Well, what’s the opposite of information overload? It’s not information underload. It’s information relevance. The best way to ensure information relevance is to engage your end-users early and often. Ask them questions like, “what information do you wish you had that could help you make better decisions?” Try to focus on providing just the information that they need and no more.
3. Ambassadors
Everyone knows that a project needs a sponsor, but I’d argue that a project needs an ambassador. What’s the difference? A project sponsor says, “ok, I’ll pay for your project and let you put my name on it.” A project ambassador says, “this is my project, and I want to tell everyone I see about it and how important it is to our business.” Like with project sponsors, it’s important to have an ambassador at the executive level so that the message is communicated down and throughout the business. Unlike with project sponsors, you can develop multiple ambassadors. If you have a successful phase one rollout, keep some of the key people from your business user population on the next phase so that they can share with the new business users how great the solution was for them. Maybe try to engage business unit leaders to be ambassadors to their groups as you rollout your solution. Ultimately, the more ambassadors you have, the more feet-on-the-street you have in the business sharing how great your analytics solution is.
Conclusion
To summarize, if you build it, they probably still aren’t coming. The truth is that if you build it, you avoid information overload, you focus on more than the flash, you get business buy-in, you enable your users, you provide relevant information, and you create internal ambassadors, they should come. Ultimately, there are any number of unique needs within any given user community, but by incorporating the advice above, you can increase your odds of better user adoption and drive more business value.
Next Steps
If you have any questions or would like PMsquare to provide guidance and support for your analytics solution, contact us today.