Working on Business Intelligence projects continues to fascinate me. I know of very few other professions where technical and functional interconnect so seamlessly. Working on products that are of immediate use to an organisation and that can serve as a basis for various innovations gives me the feeling, day in and day out, that I am working in one of the most dynamic and most interesting professions.
This makes it that much more frustrating to witness that the hard work of BI project teams often leads to a product that is not accepted by the users. There are quite a few complex problems to resolve during Business Intelligence projects, but even if you make all the right choices —on a technical and functional level —you are still not guaranteed user acceptance. I paid considerable attention to this problem in a few of my recent projects, and for me, it’s clear: acceptance from users is not a self-fulfilling wish, but the result of close collaboration and a mindful approach!
Measuring the success of a BI project is a challenge in and of itself. The success, or the lack thereof, is determined by many factors that you (and your project team) often have no control over. However, if a project is initiated for the right reasons and the right choices are made during the performance phase, the end result would normally meet the users’ needs. With this in mind, I have no problem using the ‘percentage of use’ as the yardstick for a BI project’s success. After all, this number indicates how many of the (potential) users actually use the BI solution for their work and provides a good indication of the match between what the solution supplies and what the users need.
The experts might not agree on the exact definition for ‘percentage of use’, but that the percentages are horribly low in practice – 20 to 40% – is clear to all. This is obviously a major problem. The survey that was conducted by Gartner, in which this percentage (user adoption) is established at 32%, seems very accurate to me. In other words, upon conclusion of your average BI project, just 1/3 of the target group uses the solution to perform their work. Of course, you might ask yourself if every user really needs a BI tool, but this percentage is a clear indication that we lose many users in BI projects.
The English term that’s used in these types of surveys provides much better coverage of the situation. While we talk about the ‘percentage of use’ (percentage gebruik) in Dutch, which sounds rather clinical (the term is used, albeit with a little reluctance), they refer to it as ‘user adoption’ in English, and the term provides a much clearer indication of what is happening: are your users embracing the product and do they consider it a valuable addition, rather than a necessary evil?
Understand your user
Are you one of those BI project owners who aren’t happy with the ‘user adoption’ aspect once you’ve completed your project? It might be comforting to know that you are not alone in this as a project leader or manager. Also, you can certainly do something about this in your next project! Mind you, not by way of a modelling technique or application that automatically ensures you of a group of satisfied users. Acceptance (adoption) is, in fact, improved via the things that happen around the project. You won’t find the answer in the technique or solution, but in the way that you interact with the most important stakeholder, namely, the user.
Before I talk about solutions, I first want to touch on the causes of low user acceptance (also known as user adoption). What motivates a user to refrain from using a ’good’ product? Users are also just people, and they all have their own ideas and motivation, but you can divide those who don’t or hardly use your solution into three categories:
- The user who does not want to
- The user who wants to, but can’t
- The user who wants to, but doesn’t
If you are lucky, you’ll only have to deal with one of these groups in your project, but in most cases, you’ll encounter a mix of motivations and you’ll consciously have to go in search of a separate solution for each group. There is no ‘one size fits all’ solution that ensures that all users will be enthusiastic about your product in one fell swoop. Therefore, take the time to figure out who your users are, what they ought to be doing with your product, and why they aren’t using (or will not use) your product.
The user who does not want to
One of the most recognisable, but also most obscure forms of non-acceptance, is the user who does not want to. Many people don’t like change and users are no different. However, the reasons for resistance might differ. The primary motivating factor in most cases is a simple aversion towards new things. However, the situation is often more complex. The user might have bad past experiences, the product might be part of an organisational change (a change that’s not welcome), or perhaps the user sees the change as a threat to his or her own job.
It’s also good to remember that many users consider the nice BI solution simply as an extra new tool. Users are already expected to use a range of applications and portals, and when viewed from that standpoint, the BI product is simply a new (or additional) application in the daily work process.
Unfortunately, users do — to some degree or another — have a valid reason to refrain from using a product. However, this does not mean that you can’t change the group’s opinion! You simply have to do your best. How?
- Convince your users: prove to them that they can use the BI solution to solve their problems and to make their work simpler. Go to them and show them that the solution is not a threat, but rather a bonus. Use practical examples and show them how they can integrate your tool into their daily work process. Give users the opportunity to ask critical questions, listen carefully to their objections, and show them how the solution will anticipate and respond to such concerns (now or in the future).
- Get users involved in the development: it’s a big deal to users when they know that their colleagues were involved in the tool’s design and implementation. They’ll be much more likely to accept the product if they are assured that the product is based on the knowledge and expertise of someone that they know. Get ‘key users’ on board from the project’s very beginning and clearly specify their contribution during the development.
- Ensure that you have management support: managers can reward and encourage decisions that are made based on data analysis instead of a gut feeling. The BI solution is often initiated by management, to get the organisation to work more effectively and more efficiently. It is important for them to get users in on their train of thought and to encourage the use of the BI solution.
- Assure yourself of the best data quality: incorrect data is the simplest way to lose your users’ trust. Therefore, only show the results to your users when you are sure that the information in the system is reliable.
The user who wants to, but can’t
The fact that a user wants to work with the BI product, but does not do so automatically, implies that he or she can. In the simplest form, this ‘inability’ is due to the tool’s complexity or due to a lack of training. Regrettably, not all BI tools are user-friendly. In my opinion, that should be the most crucial criteria for tool selection. After all, what is a tool that meets all your functional and technical requirements, but that’s not used in the end?
Often times, the ‘inability’ also concerns the BI solution’s content. For some users, the information that’s relevant to them is missing, and for other users, the information is there, but they can’t identify with the definitions that are used. In all cases, the result is the same. The product is only used if the relevant data is represented correctly and fully. An extra training session will solve nothing if that’s not the case. So, what should you do?
- Get users involved in the development: get to know your users and get them closely involved with the project via demo- and advisory groups. Let them contribute their thoughts regarding the content and definitions and use their knowledge and experience to improve your product. Their contribution ensures that the product that’s developed is relevant to their colleagues.
- Use an agile development methodology: going agile brings with it many different advantages, but for me, it’s all about ‘client-oriented’ and ‘iterative’. For example, when you use the Scrum methodology, you are compelled to regularly deliver products that are tested directly by a person or group that represents the users.
- Provide proper training: you aim for a BI solution that doesn’t require training, but in reality, training is essential. Organise numerous training sessions in which you not only explain how the solution works but also show people how to use it by way of relevant examples. Allow them to experience it for themselves and also provide an online training alternative so they can revisit the training materials at a later stage. Don’t use your own skills as a measure for the users. Lower the bar and facilitate everyone with proper training and training materials.
The user who wants to, but doesn’t
The last group is the group of users who want to and can, but don’t get around to using the BI solution. If this group is your biggest concern once you’ve completed your project, you may rightfully be proud of the result. Still, it’s a shame that this group isn’t getting around to using the solution, and you obviously want to change this.
When a BI solution goes live, you will have sufficient opportunities to confront the users with the new solution and to make everyone happy with the possibilities. But, roughly ten days later, your introduction email will have disappeared amongst dozens of other emails that are at least as important, and everyone will continue with their daily tasks. If you want to make a lasting impression, you’ll need more than a grand introduction. Everyone is so busy, and as long as the users don’t feel the need to use your BI solution immediately, you’ll soon be forgotten. In addition, their world changes constantly, and if the BI solution doesn’t change with it, your product will soon become irrelevant. What can you do about this?
- Keep on communicating with your users: send updates about new functionality regularly and publish success stories of users who can do their jobs better thanks to the BI solution. You are your own product’s marketing department! Don’t give the users the chance to forget about your solution.
- Integrate the product into the organisation: compile a group that represents the users and get this group to play an active role in the collection of feedback, the further development of the product and promotion of the product’s use. Make sure that management is aware of the BI product’s existence and get them to actively encourage the product’s use. Make the product part of the department, for example, by displaying one of the dashboards on a big screen (or place a few prints at the coffee machine).
- Ensure constant continued development: you can always make minor improvements or adjustments that enhance the solution’s degree of user-friendliness. A great BI product is never complete but in a constant state of ongoing development. Do not focus on adding new functionality but take a good look at whether the product’s content still meets the organisation’s needs.
- Measure your success: you can’t act based solely on a gut feeling, and the same applies to your own BI solution. Measure the use per person, per component, and per report. Don’t become fixated on the ‘percentage of use’ (also known as user adoption), but look for trends, look for persons who have since stopped using the product, or use the data to find examples of loyal users.
User acceptance is not self-evident. Sometimes, your solution might be just what’s needed, it might be introduced at just the right time, and everything else might seem to happen automatically. But, in my experience, these types of occurrences are scarce. In most cases, user acceptance is the result of a mindful approach. An approach in which the user is the focus and one that starts even before the first design is ready.
In one of my recent projects, the client was strongly geared towards a client-oriented approach. From day one, the users were involved in the definition-formulation, dashboard-design and product-testing phases. We presented our progress every two weeks, and they gave us a list of points on which to improve. For us, the client-oriented approach was, first and foremost, a resource during the development phase, and we only noticed the positive effects of this approach when the time came to present the solution to the rest of the users. By incorporating the expertise of the users in our product, we ended up with a logical result and faced hardly any discussion concerning the content of definitions. The users that helped us during the development phase accompanied us to other departments in the organisation and served as ambassadors towards their colleagues. They talked about the development process, and, along with other users, kept us on our toes with targeted feedback and improvements. The same users are still involved in the continued development, and the organisation is not only happy with the solution but also really uses it!
Every BI professional knows the frustration of having put immense effort into a solution, only to have the users eventually ignore it. To me, these types of experiences prove that a good product doesn’t automatically lead to satisfied users. One way or another, you’ll have to earn user acceptance. It requires time and lots of energy, but I am happy to pay this price for a successful solution and a happy user!
Which 5 things will you change tomorrow to improve your BI solution’s user acceptance?