By Eric Eaton, former Lead Software Engineer, Visa, Inc.
In 2012, I joined the SharePoint team at Visa, a financial services company with about 20,000 employees. My role was to help employees use SharePoint, improving usage and adoption of the platform to improve the return on investment for the platform.
Up to this point, the company’s two on-prem SharePoint farms (with version migration in progress) had nearly 350 site collections and 100 unique site owners. Enthusiasm for the platform was low and adoption was stagnant.
We were very successful. Within four and a half years, the company saw 451% growth in the number of site collections (1,810) and 178% lift in the number of unique site owners (236). Over 2,700 no-code customizations—such as forms and workflows— were built. Subsequently, we applied our lessons learned more broadly with the Office 365 platform.
Here is how we did it.
Taking the simplest path
Our central goal was strategic simplicity – for the admins, but primarily for the users. Therefore, every decision we made, every solution we built, every service we offered was conceived through the lens of – ‘does this make life simpler or harder for our users?’.
One of the most impactful places this was applied was in governance.
Developing simple governance policies
When crafting governance policies for SharePoint usage, it’s easy to focus on central control and convenience for the SharePoint team – and minimize the functional needs of the users. It’s also tempting to create arbitrary limitations that conform to our own personal conception of what features are valuable.
The problem with both of these tendencies is that every single governance decision you make affects adoption rates – for the good or the bad. We decided that if we wanted adoption to grow, we had to prioritize the voice of the user. Good governance policies don’t create roadblocks. They bring order to chaos.
To make sure that we didn’t create complicated governance policies that would block or slow down adoption, we established a few guidelines for ourselves first:
- Every imposed limitation should have a compelling reason
- For every prohibited tool or process, an alternative should be provided
- “We’ve always done it this way” should not justify a rule
- Every rule should be clear enough to be fully understood by everyone
Using these guiding principles, we began transforming our governance to prohibit less and guide more.
One example of this strategy was with the use of SharePoint Designer. Like many organizations, we preferred to restrict its use. We debated the practicality of establishing a training path to allow some users to work with it. However, the vast majority of requests were for one purpose – custom workflows. Ultimately, we decided the best way to make workflows available wasn’t with SharePoint Designer, which offered other advanced functionality. We implemented Nintex Workflow as an alternative and established a training option where power users could gain access to that tool. We found that Nintex was more functional, simpler to use, and safer than SharePoint Designer would have been. Any requests for other functionality could be handled on a case-by-case basis – usually with the hands-on help of the SharePoint team.
Using simple adoption metrics
In order to demonstrate adoption growth, we had to establish a baseline and a way to measure change. We evaluated a handful of metrics applications including Cardiolog, Google Analytics, and other web usage tracking suites. None of these were a good match for our needs. They were either too complicated, poorly supported, or too focused on page content. Our use cases were predominantly collaboration focused – meaning we were heavy on documents, files, and lists. Our sites were also typically open to small groups, which was a substantial differentiator from the use cases of traditional web tracking software.
We decided initially to focus our attention on the number of site collections and the number of unique site owners. Given that our governance policy included a provision for easy site requests and a proactive way to help owners track and delete unused sites, we considered these counts to be “trailing indicators” of user adoption. Users generally would use existing sites before they requested to have their own. The fact that more and more people were asking to have their own sites was a strong indication that adoption was improving.
Over time we began to track other indicators that helped to see the type and depth of adoption in those sites. We built a series of Nintex workflows that interrogated the native SharePoint web services to find various types of use and no-code customizations. We could periodically run these workflows again to refresh our data and better see what features/tools were being used and where it was happening. We looked for customized list forms, form libraries, custom workflows, specific features activated, the creation of wiki pages, customized home pages, last modified dates, and a host of other use cases that indicated users were not settling for basic document library scenarios. This helped us to see what was most valuable to our user population, and then to adjust our help materials and governance policies to match. Eventually, this process was shifted away from workflows into PowerShell for better performance and more reliable scheduling.
The number of support tickets we receive was also an important indicator, but it was important to analyze the type of tickets that were being created. Break/fix or complaint tickets indicated problems that had to be fixed immediately. However, tickets that were making requests or looking for guidance indicated we were bringing more users to the platform.
High numbers of these ‘guidance’ tickets helped indicate that either our solutions or our help processes/materials needed to be simplified. Those two areas are addressed below.
Building simple solutions
To keep things simple for our team, we focused on building lo-code / no-code solutions. This made for shorter build times, less technical debt, and easy changes after launch. From the start, we prioritized problems that affected the highest number of employees and built visible, simple solutions to address them. We knew that if a user didn’t understand the options included in the solution, then the solution had no value. Every solution we created was made and re-made to be simple to build and easy to use.
Every organization has some tools or processes that employees hate. We looked for those, and then found ways to make them better. Sometimes those solutions were ones we owned, ourselves. For instance, users previously had to navigate a deep IT ticketing system to find the right form, and then fill out many blanks that most of them didn’t understand. We built our own simple site request form in SharePoint and then added workflow automation to streamline the site creation process and automatically track the site information in a master site list. The resulting solution simplified both the user experience and the admin workload.
We broadened our scope to find hated tools and processes from other teams and offered to help make them better. One example was an annual employee survey. Previously, this was a custom Net development project every year that was painfully expensive and complex for the HR department – and not always user-friendly for the employees responding. We reviewed the requirements and created a relatively simple InfoPath form with multiple views. Each view had a ‘Next’ button that conditionally took the user to the next relevant step for them based on what they had answered so far. It eliminated custom code, dramatically reduced cost, brought the HR SME’s into the process, automatically tracked the dataset in a list format for HR to report on, and simplified the user experience for every employee in the company.
As we published solutions like these for various in-house tools and processes, SharePoint’s reputation steadily improved with everyone from executives to entry-level employees. Other teams began to look for ways they could use SharePoint to solve their own business problems.
Providing the help they needed
This was the most important area of change. When I first began my efforts at Visa, I wrote and delivered ½ day training classes on various topics. These were moderately successful, but many users had difficulty with that learning format. It was hard to be away from their desk that long, and it was difficult to retain that much information long enough to affect parts of their daily work where it could help. Those classes also didn’t have much of a direct effect on the number of help tickets fielded by our team.
We realized that when we in the IT organization used the word ‘help’, we didn’t mean the same thing that our end users meant. We thought of support queues and training classes. Users think of a human offering personal, hands-on assistance – or sometimes an easy-to-consume self-serve resource. That disconnect meant that users were frequently dissatisfied with traditional support and training services. We asked ourselves the following questions:
- How can we make help as comfortable, accessible, and consumable as possible for users?
- How can we actually help users – as effectively as possible?
- How can we automate training, help, and support to reduce the workload on our IT team?
- How can we offer training in a way that reduces the time commitment for the learner?
Studies have found that, for adult learners, formal training accounts for around only 10% of their skills improvement, informal training accounts for 20%, and experience accounts for 70%. Hence, for us at Visa, it was crucial that we focus on the two areas that account for 90% of skills growth.
One of the first steps we took was to implement a contextual help system. We installed VisualSP, a plug-and-play add-on application to SharePoint. The VisualSP ‘HELP’ tab appeared in the ribbon on every page in SharePoint, ready to give relevant guidance within the users’ own sites and natural flow of work. Each help item on the tab was brief and focused on one user task. Many were in a video format, where a narrator walks them through the task. Others were web pages, rich text, or documents that were easily printable for quick reference. This allowed our employees to use SharePoint without prior knowledge of the application and without the time-consuming, frustrating process of contacting the IT support team or searching the web for answers.
We began to steer users toward these resources when they reached out with common how-to questions. In addition, the product’s content customization capabilities allowed us to easily build and add our own help items to the system to push common resources and answers to users that were more specific to the Visa environment, all within the context of where they might need it. This helped us remove the need for users to go looking for relevant governance, support, and process help.
As an example, Visa had dozens of ticket types to choose from in our system, including several for SharePoint. Many users struggled with finding the right form. We found ways to reduce how many types of tickets we used and then added a button to the HELP tab that directly opened the correct ticket within a dialog box. We also added other help items that were targeted to site owners, clarifying governance guidelines, documenting details of custom solutions, and easily linking users to resources like the new site request form.
To further improve users’ skills, we rolled out programs that allowed them to learn during live Q&A and coaching sessions. We scheduled weekly ‘Office Hours’ sessions, where we put 1 or 2 team members in a conference room and on a Skype bridge to offer live help – ask me anything. These events were extremely popular with our users. At times, people were happy to wait in line to ask questions, because they were also hearing other users’ questions that they hadn’t thought of yet – and the answers to them. These sessions had an interesting side-effect – they reduced the daily interruptions our team had to deal with. Many users would frequently hold their questions for a couple of days to come talk to us about them rather than email or phone us spontaneously through the week. The result was happier users and a happier support team.
We also actively searched for ways to provide live training events that were delivered in formats that better matched the users’ needs and scheduling limitations. We found that full-day and even half-day classes were difficult for users to attend. We started a ‘SharePoint’ camp day once a month, where we offered 4 separate demo sessions on topics targeted at different skill levels – SP101, Power User, and Site Owners. Users could attend any or all of them, depending on what was relevant to them individually. Each demo was no more than 45 minutes long and was followed by a 15-minute Q&A. Users usually don’t care much about features, they care about their pain points. Therefore, the topic for each demo was a common question or use case we wanted to encourage.
This encouraged our users to grow their skills in small, snackable chunks instead of committing to a longer instructor-led session. It also gave us an opportunity to reduce common tickets and encourage the behaviors and use cases that had the ability to improve ROI the most (for us and for them).
We also began to offer small-scale consulting services to teams within the company. When user questions/requests from Office Hours were too large to resolve in a shared Q&A session, we could take them offline and offer custom assistance for their team and scenario. Management allowed us to spend 20-40 man-hours (depending on the audience size and ROI possibilities) with a team to understand their business problem and help them build a solution with the no-code tools available within SharePoint. In that time-frame, we could also do enough knowledge transfer that they could likely own the solution themselves going forward.
We published schedules for both Office Hours and SharePoint Camp on our internal help site and evangelized them on almost every interaction we had with our end users. These services lowered the barrier to entry and the technology fatigue that many users felt, and the results were dramatic. Users quickly became much more comfortable with SharePoint as a tool. In some cases, this was because they actually grew their skill level. In other cases, it was just because they knew they had someone to talk to when they had a problem or a question. By tackling actual business problems in cooperation with non-technical teams that owned them, we were able to help many users see how SharePoint could help them in real life. These lessons were easy to remember and taught by dozens of power users and evangelists in nearly every part of the company.
Finding the four tenets to successful user adoption
It wasn’t all at once that we identified the formula described above. However, our guiding principle of strategic simplicity led us to ultimately identify those four focus areas where simplicity gains equated directly to adoption gains:
- Simple governance policies
- Simple adoption metrics
- Simple solutions
- Help that actually helps
These are not the only things to think about in a mature user adoption plan, but I have come to look at those focus areas as a formula that works – the 4 Caveman Tenets to User Adoption. Their effect is clear, and they can be implemented by teams themselves to adjust their own mindset and services – even if they don’t have the budget or headcount to do a more advanced and structured adoption program.
Another lesson we learned, was that it’s vital to stay focused on these 4 tenets. It was not easy to do that, though. Although we all saw the value in the changes we had made, we went through a period where we set some of those changes aside, especially under the ‘help’ category, due to an increased project load. We stopped doing SharePoint Camps and the 20/40-hour consulting services. We also slowed our Office Hours schedule in an effort to recover man-hours for development tasks.
Interestingly, the adoption growth rate started to drop, and our ticket counts began to grow – almost immediately. As long as our changes under all four tenets remained a priority, user adoption continued to grow. As soon as we neglected one of them, the growth line started to level off. This impressed on us the importance of keeping resources focused on adoption-related activities and strategies. Though it’s tempting to divert resources and attention to other duties, it is counter-productive for the users and for the SharePoint team, itself. Our team re-focused our efforts on all 4 strategic focus areas. This provided a foundation for us to successfully ease the change management process for both intranet and Office 365 migrations.
About The Author:
Eric Eaton has since joined VisualSP to offer guidance and services as a consultant to our clients. If you’d like to explore how that can help you achieve similar results, contact email@example.com.