in

Dot Net Mafia

Group site for developer blogs dealing with (usually) .NET, SharePoint 2013, SharePoint 2010, Office 365, SharePoint Online, and other Microsoft products, as well as some discussion of general programming related concepts.

Kyle Kelin on .Net

May 2012 - Posts

  • The Factors that Influence Adoption in Corporate Applications

    As an Account Manager for an IT consulting firm, my customers rely on my firm’s resources and myself to provide advice and guidance on some of their most difficult challenges. A development manager might need to improve his or her team’s build process or a CMO might need help leveraging mobile technologies to promote his or her brand. While the challenges vary by title and company, one challenge that has been reoccurring lately is how to increase user adoption and specifically user adoption for employees for certain applications inside their enterprise.

    Why is user adoption so important to these customers? The answer is pretty simple. These customers are investing a large amount of money on these application deployments and adoption is a key measurement of success and ROI.

    Why not just mandate them? There are three reasons executives avoid mandating systems such as SharePoint which are:

    1. Employee unrest

    2. Technologically difficult

    3. Increased cost

    Employee unrest is a bit tongue-and-check but many IT executives might not want to spend the political capital necessary to force users to use the new system. Also they may not be 100% convinced the system will meet everyone’s needs. Secondly the technology might be very challenging to prevent users from certain behaviors. For example suppose you wanted users to stop attaching documents in e-mail and instead store those in your ECM solution and link to them. How would you do that? Well the actual preventive measure would be easy just set the attachment size limit in Exchange to 1KB. However, this will present a problem when the user needs to e-mail the document to an external party who doesn’t have access. What if it is an attachment type that your ECM solution does not support? You can see there are many exceptions to just this one behavior. Lastly, there is the technology and training cost associated with a mandatory rollout. Optional rollouts are much easier in terms of costs and planning; just ask any ERP consultant.

    Once we’ve understood that adoption is important and we are going to use it to measure the success of our project, the next step is to understand what factors influence adoption. There are eight factors that influence adoption. Some of these are factors you can influence with your project’s adoption strategy while others are personal factors that can vary by employee. These factors you should be aware of but will not be able to influence directly.

    The factors in order are:

    1. User Involvement

    2. User experience

    3. Perceived Value

    4. Communications Quality

    5. Training Quality

    6. Peer Influence (needs to be communicated)

    7. Leadership and organization pressure (How involved are they?)

    8. Technology comfort and tolerance for change

    User Involvement

    This is the number one factor in the adoption of a new system so you should pay close attention to it. The more your users feel involved in the designing of the system and the decision making process the more positive they will perceive the system and adopt it. In fact those with a high degree of buy-in will influence other employees to use the system creating a bit of a grass roots campaign.

    The first approach we take to involving users is at the beginning of the requirements gathering process by creating and sending a survey. Send this to as many users as feasible, but be sure the people you ask are strategic. Typically, you only have a fixed amount of time so you have to make sure that every person you involve counts. The next step is user interviews. Since you cannot involve everyone, I usually recommend adding the most thorough responses to the round of user interviews. Finally be sure you communicate progress back to the survey respondents and interviewees so they know that their input was incorporated into the system.

    User involvement does not stop once the project is deployed. Be sure to solicit feedback after launch. I also recommend having a feedback link on every page of the site.

    User Experience

    Do not mistake User Experience for branding. While branding is an important part, UX focuses on all aspects of how the users will experience and interact with the system. This also includes the functionality of the system. Over the past several years, I have found many small UX improvements to established applications (e.g. SharePoint, Documentum, Dynamics CRM) that save the user time and make the system easier to use. An example of these improvements are pre-populating fields based on the user or previous selection. The investment of these improvements is small and save the organization training cost as well as improve the user experience thus improving user adoption.

    Perceived Value

    The Perceived Value factor is actually perceived value compared to perceived cost. This is how humans not just employees make most decisions. If I take the time (cost) to learn and do this, will it make my job faster / easier / more rewarding (benefit)? It is important to note that I said perceived value and benefit. This is what the employee thinks not what you think. You might know if the user takes the time to learn the system it will improve their productivity. However the employee has to truly believe the benefit in order to change their behavior.

    Communication and Promotion Quality

    While communications and promotion are related, I’m going valuable to address them separately. Communication requires a sender, a message, and an intended recipient and is defined as the action of distributing information. How you announce the system, prepare users for it and keep them updated on the progress is communication and is vital to your adoption strategy. I recommend that most communications should focus on the features of the system and how these features will benefit the user. Keep in mind most users only have the ability to process 1-3 new features at a time so if your system has lots of discoverable features (Office, SharePoint) it is a good idea to send out tips and tricks as part of your communications plan.

    While promotion does communicate, an idea or ideas about the application, it does it with a bit more flare. The message should be direct and simple and again focus on what is in it for Joe User. The amount of flare and pizzazz will vary by organization and industry. Here are some examples of promotional activities:

    - Have a launch event that includes some prizes.

    - Commercials. You can do these fairly inexpensively.

    - T-shirts, stress balls, pens, or other promotional material

    - Show screencasts or videos in high foot traffic locations

    Training Quality

    In my experience this is the most ignored adoption factor on the list. I see far too often system projects with a million dollar budget yet have a training spend of $10,000. Some symptoms of a low training budget might be lower user satisfaction in the system or a higher than anticipated number of support calls.

    Your project should have a training plan and at the minimum it should state:

    - Who your users are and organize them into groups

    - What details each group needs

    - What the appropriate training medium is for each group

    More than likely you will want to have more cost-effective training for end-users. Webinars or Computer based training programs are cheaper than in person training for a large number of users. Another strategy I have seen effective is creating short videos with specific content that explains how to do something. Embed these videos throughout the system. For example you could place a video that explains how to search for a document next to the search bar in your system.

    One training strategy I’ve found effective is “train the trainer”. If the target user base is large and geographically dispersed you could train certain power users in each geographical area. These power users could therefore train end-users without your involvement. The benefit is the trainer is closer to the user and the user can use them as a resource after the training has completed. Just be sure to sample the training classes from time to time to ensure the material is being delivered how you intended.

    Besides cost concerns, another reason for lack of training is employee time. The key is being sure the training is effective and you convince the doubters that this will save more time in the long run. I usually recommend doing this in the communication plan. The communication plan should tell the users how the system will benefit them and also the benefits of the training.

    I often get asked should the training be mandatory or optional. I’ve seen companies make granting access to the system dependent on employees taking training classes or online courses. I disagree with this for the simple fact that if you are deploying an off the shelf product, a certain number of employees will have already had exposure to it at past companies. Besides, if you do a good job addressing the other adoption factors, employees will be lined up to take training classes.

    Training is one aspect that differs between wide-spread consumer facing applications and enterprise applications. Training on consumer applications is usually not possible because of the number of users that would need to be trained. I do not think that Facebook will be creating a training course on how to post to a status update anytime soon. Although with everything people post maybe they should come out with a “What not to Post to Facebook” course.

    Peer Influence

    It is pretty obvious that users influence other users. How do we harness that power for our system deployment to increase the user adoption? The level of peer influence is affected by organizational culture, industry, and employee proximity to one another. Many of these are beyond the project team’s control but there are two things that can be done, find the influencers and nurturer them. Find the influencers in training classes, during requirements gathering and through employee surveys. Doesn’t matter where just find them. Once you have your list, cater to them by providing additional support and training. You should also update them on how their suggestions are being implemented.

    It is important to dispel the misconception that these influencers are in official mentoring roles or leadership positions. An Influencer can be Betty at reception because she has been in the department 20 years and knows where to find any document or the guy in accounting that can do anything in Excel. As part of your adoption plan spend the time to identify the true influencers for your system and do not just rely on the organizational chart.

    Leadership and Organization Pressures

    Leadership and organization pressure is similar to peer influence but originates from management and the executive level. This factor is interesting, because in my experience, leadership cannot influence user adoption. However, the lack of leadership support can negatively impact it. Take for example if you have a Launch Event and the highest level employee in the office skips it to catch up on email. Employees will infer from their action that the system is not a priority and they will consciously or subconsciously deprioritize the tasks required to adopt the new system. So be sure during your system rollout that you have senior leadership buy-in and involvement.

    Comfort with technology and tolerance for change

    Technology comfort and tolerance for change are two personal factors that affect adoption. However, your project team will not be able to directly influence or control these. No matter how great the system, the training, and communications there will be a small percentage of your work force that is technophobic and resistant to change. The good news is once you’ve got those in the larger group using the system the technophobes will come around.

    If you focus on these eight factors at the start of your project, during your project, and after deployment I can promise you the system will be used by more users than without these factors. Be sure prior to rollout you have a baseline of expected user adoption. This can be from the previous systems or if that data is not available other unrelated systems. After the launch of the system you should measure the usage of the system. Comparison of these two numbers will help justify the cost of the project and possibly even your salary.

2015 dotnetmafia.
Powered by Community Server (Non-Commercial Edition), by Telligent Systems