I've been working with VisualSP a lot lately, now that my focus is on user adoption. One of my colleagues there recently collected a set of survey data about what organizations see as their biggest challenge. The clear winner was user adoption, and the next 4 were all topics related to that. I find this interesting, because it shows a growing awareness of the importance of user adoption.
However, in my experience strategies, policies, and budget decisions frequently don't match this awareness yet - especially at migration time. Adoption isn't really won at migration time, but it can certainly be lost there. Over the last few months I've heard many comments from my colleagues about organizations whose migrations have stalled. These stalled migrations never get the users onto the new platform to adopt it. Painful migrations turn users off so they hate the new platform before they ever get there. Out-of-date governance policies prevent users from benefiting from improvements in the new platform. The common thread here is that many organizations prioritize migration (and their role in it) rather than adoption.
How can we change that pattern? Essentially, it's a strategic shift in priorities and mindset to put adoption issues first. Remember, migration is just the process. Adoption is the goal. To finish your migration, you have to make life as simple as possible for the admin team. However, to succeed, you have to make life as simple as possible for the users. The two are not mutually exclusive. It boils down to acknowledging a few fundamental truths, and then adapting our approach to leverage them.
Every governance decision we make will effect our adoption rates for better or for worse. Frequently, the uncertainty we feel about new features leads us to be more restrictive in our governance than necessary. This can dramatically reduce the benefit the average user feels from making the move. If you want to improve user adoption rates, you need to not only improve the platform they're using - you need to improve the policies that govern it.
When you are planning a migration, things are going to change. That's the whole idea. Why not make sure the changes benefit your users. Simplify their lives. Simplify your processes. Re-examine your existing policy restrictions and see if they are still offering the value they used to. Moving to the cloud should help us change our perspective on governance and support. It should allow us to focus less on managing our platforms, and more on helping our users succeed. We don't accomplish that by crippling key features of the platform we're trying to adopt - just because they don't fit our old way of doing things.
Moral of the story - boundaries, best practices, and consistency are good for user adoption. Arbitrary limitations based on fear of the unknown are bad for user adoption.
Have you ever been involved in one of those migrations where everything grinds to a halt because we get too bogged down handling a few complicated elements that probably only effect a few people anyway? The pareto principle is a centuries old observation that each unit of work does not contribute the same amount of value. It's the idea that 80% of the users only use 20% of the functionality, or 80% of our time winds up going toward only 20% of our problems. The numbers aren't meant to be specific, they just highlight the need to prioritize our efforts where they will have the most impact.
In migration terms, this can be applied a number of ways to help accelerate progress, user adoption, and therefore ROI. For example, in most organizations at least 80% of all their SharePoint sites are nothing but a document library and very basic content. That's the easy stuff to move, and the easiest use cases for our users to benefit from in the cloud. It is likely that if you identify and prioritize these sites, then we can get most of them moved in roughly our first 20% of effort and duration and get most of our broad adoption gains up front in the project. Then we can focus more effort on deeper gains in the more complex areas where we see the most potential.
Moral of the story - don't let the easy stuff get stuck behind the hard stuff. Identify places you can get started, and then do it.
This is closely related to...
There certainly is a fair amount of complexity in a cloud migration project. However, you don't have to know all the answers up front. The agile manifesto used in software development preaches the concept of a minimum viable product - the simplest form of your solution that would accomplish the required outcome. Figure out what you really need to be productive and implement that first. Then add and change things later as you learn more from that early experience.
So, what are the things you absolutely need to figure out up front before you begin migrating? Of course that will vary based on your current environment and policy restrictions. Here are a few things that form the core:
This is not an exhaustive list - but that's the point. One of the lessons that agile methodologies have taught us over the years is that we don't have to know everything to get started. In fact, you can't know everything up front. Regardless of how much time you spend planning, you're going to need to revisit your strategy and decisions as you work. What you really need is a basic strategy framework, a big-picture vision of where you want to go without many of the details. Learn enough to make some early, core decisions. Then get started, get smarter, revisit your overall strategy when needed, and add more detailed decisions as you go.
Moral of the story - the value of getting adoption started early is vastly higher than the value of delaying everything to do extensive planning.
Another lesson we learn from agile methodologies is the value of the human factor. An agile team is not just made up of the techies - it includes the business owner. When techies and business users view each other like teammates and actually talk to one another, magical things happen. You may not be able to directly control how the business treats you, but you can control how you treat them - and that's just as effective.
In a migration scenario, you have many business owners - one for every site. I've seen this go a couple of bad ways. One, the admin team tries to ignore the site owners, dictate how and when everything will happen, and then hide behind ticket queues when things go wrong. Two, the admin team tries to delegate much of the work to the site owners, force them to participate, and then gets stalled when some owners don't play ball.
There is a middle ground. Why not setup a proactive, but flexible schedule of migration batches. Pre-populate it with sites from the results of your site inventory. Encourage the site owners to participate by:
Granting them that little bit of control makes a huge difference in how many view the migration (and by extension, how they view the new platform they are going to). This is true even for many that choose not to participate. If they do, then their perspective immediately changes to that of a team member. If they choose not to, they're pleased to have had the opportunity - and the sites migrate according to the schedule you setup originally.
During the batches, actually talk to the site owners. Tell them what to expect, why the move is a good thing, how they can participate, and what you're doing to make the process easier. Setup a live ‘ask-me-anything’ opportunity for site owners to ask questions and resolve any issues they find during the testing part of their batch. While support tickets have a valuable place for problems after launch, the team works most efficiently when they just talk to each other during the batch.
This kind of approach will be in stark contrast to what users have come to expect from most IT departments. I've seen this work in real life. I have written a detailed white paper about how we did this at Visa.
The good will you build with your users will have an immediate impact on your adoption rates. Your users will be more comfortable. They'll find more reasons to use the platform they like. They'll even encourage others to do the same.
{{cta('9686c552-88b6-4116-89e7-d605216844c8')}}
Fuel Employee Success
