This is the fourth post in my series about Caveman User Adoption. The first was an overview of 4 Caveman Tenets of user adoption that together create an environment where SharePoint and Office 365 will grow organically. This article is a deeper dive on the third tenet – Simple Solutions. The core idea here is to solve common pain points with something that is satisfyingly simple. Don't design the proverbial solar-powered rocket launcher with GPS and cup-holders when all the users really needed was a club. Clubs are easy to replicate. They cost little to maintain. They have a short learning curve. They are satisfying to use. When you've got a new club - everything looks like a nail.
When users see a tool solve a real-life pain
point with something simple – they start to
think about how it might help them do the
same thing elsewhere.
NOTE: This is not to say that there's never a place for a big complex build in SharePoint or Office 365. I've seen many of those over the years that were important and well-done. That type of solution is just not what you're targeting when you want to boost general user adoption of your platform, as a whole. They typically require a dedicated dev team, sometimes their own dedicated environment, and they take a long time to implement.
So, how do you get that simple trend started? There are a couple of ways.
Target large audiences
In every organization, there are processes and tools that everyone universally hates. It might be because of obviously missing features, poor infrastructure, little to no UX design, over-engineered process flows, or whatever. Unfortunately, organizations get stuck on these awful solutions because they don’t have any obvious replacement available, or it’s assumed that it would cost too much money to replace.
Look for those pain points. The bigger the audience, the better exposure your solution will get. Figure out some simple way you can reduce (or maybe even eliminate) the pain point using out-of-the-box SharePoint or Office 365 functionality. Then comes the important part. Don’t ask for a budget. Don’t find reasons why it’s not practical or why it’s someone else’s job. Figure out who currently owns the pain, and volunteer to help fix it. If they’re skeptical, offer to do a simple proof of concept. Beware of over-engineering here (the proverbial solar-powered rocket launcher). Remember, the goal is to make things simpler for the users – not to amaze them with vast, shiny complexity.
If we’re being completely honest – for many of those universally hated things, we’re probably the owner anyway. That makes it easier for us to replace them with something better – especially if we’re about to roll-out a new SharePoint version or move to the cloud. Some changes are necessary, and users generally expect that. Make sure those changes are an obvious simplification for them. The other good thing about these options – is that the audience is usually the entire company.
Here are some examples of this type of simple solution with a large audience:
Site Request Form
I know, I know. We in IT love a good ticketing system – but we are usually the only ones that love it. If people currently have to submit a ticket to request a new Office 365 group or a SharePoint site – they probably hate it. It probably also offers very little automation for you to fulfill those requests. How about allowing users to create their own Groups / Sites on the O365 SharePoint home page and in Outlook like the products are designed to do? If you really feel it’s necessary to centrally govern the process of creating them – then how about building a simple site request form using SharePoint and PowerApps, and then use Flow to either auto-create the site or otherwise start a human workflow that gets things done quickly.
Site Lifecycle Management
One of the typical concerns about allowing self-serve site / group creation is the proliferation of unused sites. That issue can be managed pretty easily. I’m a fan of tracking a master list of sites in SharePoint. This can be populated by the site request form mentioned above, or by simple automation (PowerShell and / or Flow) that records sites as they are created, along with some basic info like owner names, size, date created, and so forth. Then you can create a PowerApp or a web part page that shows a user all the sites they own. You can even build a Flow that prompts them to review the list regularly and tell you if they still need all of those sites. Since you’re building it yourself, you can be as aggressive or as diplomatic as you want with that process.
Project Management Compliance Portal
One organization I worked with had a portal where they required all official project management artifacts to be uploaded and stored for compliance purposes. The problem was, that portal was very slow and painful to use. As a result, users went there only when they were forced to at the end of a project. We built a simple solution where a PowerShell script automatically ran daily and created a SharePoint site collection for each project as it was started. The site template had document templates and workflows that simplified the official process handed down from the PMO. Users loved it because they never had to request a project site, and the new design was much easier to use. They started living in those sites through the entire project.
I worked at one organization who had some emotional baggage from previous big-bang migrations that created lots of problems. They’d also tried to do softer moves where they worked with site owners to move sites individually, but they had a hard time getting them to participate – which left the project stuck. We created a simple SharePoint scheduling tool that assigned batches of eligible sites to specific weeks and then allowed the site owners to reschedule their own site(s) to a different week if they wanted – but didn’t allow them to opt-out. Site owners felt like they were in control, but there were inherent limits to how long they could put things off.
Your organization will obviously have its own unique pain points, but these ideas are pretty applicable to most organizations. Look for issues like these and think creatively. With a little brainstorming and a simple no-code build, you could be the fixer and give large swaths of users a good impression of your platform. Sure, it will take some of your time, but the time it saves the organization and the reputation it builds for your platform is well worth it.
Target smaller audiences
Obviously, you are not going to have the time to build a solution for each team in your organization. However, you might be able to start offering small-scale help to users that have a business problem and need help solving it.
I used to lead a ‘Solutioning’ team at Visa that focused on helping people apply SharePoint and Office 365 to everyday problems. We did lots of different things to deliver on that mission, but one of the most interesting was our no-code build services. Users could bring us a problem or an idea for a solution, and, if it was plausible, we would spend 20-40 hours on it. We would refine the idea / requirements a little, build a relatively simple solution, and then coach the owner on how they could maintain and improve it on their own.
That kind of service had a significant effect on adoption rates. As those users started to see how quick it was to build something on the fly, they started to improvise their own solutions. They requested more sites for other purposes. They used platform features they never would have before. They increased their teams’ productivity because they could start solving their own technology problems.
This core principle of user adoption is all about two things – finding big problems that need simple solutions, and helping power users build things to solve their own problems. It’s not easy to find time to do these things, but it’s worth it. It amounts to a different support model - one where you support your users more than just supporting a platform. The good news is, if your organization is moving things to the cloud, your overall administrative burden should begin to lessen. As you need less time to support the platform, itself - it should be possible to spend more time helping the users get value out of it.
This shift in support model is an important one, but probably not a quick one for most IT departments. You have to find a way to begin to prioritize this type of service, meaning you re-align roles to let someone focus on these types of activities or add someone new to do it. In my experience, the more administrative burden someone continues to bear, the less they are able to do this kind of thing. Personal bandwidth is part of the problem. If you have fires to put out and big things to build, then individual team problems are just not easy to keep on the radar. That’s not all of the problem, though. We all tend to see technology through our own perspective. If that perspective is admin focused, then it’s very difficult to put yourself into the user’s shoes, which makes it very difficult to solve their problems in a way that is helpful for them.
If that describes you and your team, you may need to find some external help that’s willing to work in these smaller, less formal engagements. Most of us are used to thinking about consulting as this big effort that will last months or years, require a project manager, and have a 6-figure budget. That kind of engagement still fits many scenarios – but it doesn’t have to be that way. SharePoint and Office 365 are platforms that also lend themselves to smaller engagements like what's described above. This type of small-engagement model is a win for both the admin team and the users. It provides flexibility and agility, and also allows the organization to benefit from outside expertise that is focused on actually being helpful.
I've worked with many other SharePoint and Office 365 professionals that highly value this type of approach. What do you think? Have you done anything similar before in your organization? What kind of pain points have you fixed with simple solutions?