Last time I resorted to sensationalist headlines and claimed that you don’t want users to adopt SharePoint. You want them to adopt the business solutions that you build on the platform, and the secret to successful adoption is to make your solution useful and useable. This week we are going to see how to bring it all together and to create an adoption plan for your useful and useable SharePoint solutions.
This is article 19 in the series the Art of SharePoint Success describing my four part framework for ensuring long term, measurable returns on your SharePoint investment. The four elements of the framework are:
Your Adoption Approach
Table 1 presents a very simplified overview of my usual approach to adoption in SharePoint based projects. This is very similar to the approach that Microsoft Consulting Services use with their top 100 global clients.
Table 1: Simplified adoption strategy
|Phase||Example adoption measures|
|Awareness||Pens, posters, intranet bulletins, user workshops, creating a ‘brand’ for your solution|
|Availability||Easy first steps, sandpit environments, launch day events|
|Usage||Training, support desk, Stop Doing and Start Doing, Success Stories|
|Adoption||Service updates, new employee orientation, staff incentives|
As you can see, the approach consists of four distinct phases with a number of techniques associated with each phase.
In the Awareness phase the aim is to first raise awareness that the current situation, tools or working practices are undesirable and that change is required.
Once the need for change has been established, then the focus shifts to an emphasis on the solution that is coming, and on the corporate and personal return on investment which it will deliver. Use your existing corporate communication channels to get the message out.
Creating a "brand" for your solution might sound a bit clichéd but it’s one of the most powerful adoption techniques. Creating a brand enables you to position your solution in the mind of the users as being a specific business tool, with a specific business purpose and value proposition. It helps them determine when it’s appropriate to use your solution and when it’s appropriate to use another business system.
For example, your team collaboration service might be called “Collaborate” and your communities service might be called “Knowledge Net.” Run competitions with users to name them, and create logos to visually differentiate them. The marketing team will love it! I shudder when I hear comments like, “I put the document in SharePoint.”
The Availability phase is focused on making sure that people's first experience of the new solution is a positive one. There’s plenty of research to show that first impressions count when it comes to the adoption of new technologies. Easy First Steps is one great technique.
Create a simple one page set of instructions so that someone using your service or solution for the first time can quickly and easily achieve something useful. Creating a team site is a good example. There’s a big difference between someone sitting down to use a solution for the first time with a user guide thick enough to choke a donkey with, thrashing about for a few minutes and going away not sure what they have done, and someone who sits down goes through a simple to follow ten step process and does something cool. All you software developers out there will remember your first “Hello World” moment, this is the same principle.
Another useful technique is the Sandpit environment. This involves creating a complete copy of your service or solution in a non-live environment so that people can experiment without fear of doing anything wrong or breaking anything. Be careful that the purpose of the Sandpit environment is clear! You don’t want people using it for real work by mistake.
The Usage phase is the first few weeks and months of the solution being live in the organization. The aim is to encourage people to use the solution. The availability of materials such as FAQs, How To guides and a support desk are crucial at this stage.
Stop Doing and Start Doing is a fantastic technique for driving changes in specific behaviors. The idea is to create a set of hand-outs, or flyers that identify "bad" behaviors, such as sending emails to multiple people with documents attached, and suggest alternative "good" behaviors, such as creating a team site and storing the document there.
If you’re clever you can map these behaviors to your success metrics. The innovators and early adopters will naturally adopt your solution first, work closely with them to document and promote their success stories in order to win over the early majority. Using HR incentives like bonuses, or gamification techniques such as awarding badges or points are also useful techniques in this phase.
Finally, the Adoption phase aims to cement the changes into the fabric of your organization. Regular updates to the service or solution in response to user feedback, following through with staff incentives, and ensuring that an introduction to the service is part of your induction process.
Your Adoption Plan
Okay so now you’ve got the adoption approach all sorted out it’s time to wrap it up nicely in a written adoption plan. I always find it a good practice to have adoption as a distinct work stream within the overall project plan. It focuses attention and makes it easier to plan, track and manage the associated budget. If you’re a project manager then you can think of the adoption plan as a mini-project initiation document for the adoption work stream. Sometimes a well written adoption plan can be crucial in convincing the budget holder that the investment in the adoption effort is required.
My adoption plans usually follow this basic structure;
- Adoption plan aims and objectives
- Transition team
- Overview of the approach
- Adoption strategy
- Adoption project plan
- Success criteria
- Metrics, monitoring and reporting
- Risks and issues
- Appendix A: overview of selected approaches
- Appendix B: User profiles or personas
Section 1 should give a simple overview of what the adoption plan is trying to achieve. Not always as easy as you might think. Here’s an example for a project that delivers a portal solution for a specific business process. I’ve picked out some words in bold to highlight that each objective basically maps back to a phase in the adoption approach.
Our aim is to ensure long term usage of the <name of solution> by all employees involved in the <name of process>. We will achieve this high level aim through meeting the following objectives:
- Raising awareness of the perceived issues with the current ways of working amongst the target user group
- Raising awareness amongst the target user group of the intended corporate and personal benefits of the proposed solution
- Providing help and support for the target user group to encourage initial use as the solution becomes available
- Providing on-going help and support to the target user group to encourage long term usage
- Establishing permanent process, procedures and standards to ensure that the adoption of the solution is maintained on a long term basis
Section 2 identifies the individual members of the transition team, and defines their high-level responsibilities and ownerships. You might remember that when we discussed the costs of a SharePoint based project I identified the costs of the transition team as one of the most commonly underestimated operating expenditures. In section 3 I usually give a one page overview of the approach and the rationale for it. For those of you that can remember back to our discussion on the diffusion of innovations you’ll note that the phases in my approach below broadly map to five stages of the adoption process. I don’t just make this stuff up you know!
The adoption strategy in section 4 is the list of techniques shown against the different phases. For brevity I usually list the techniques in the main body of the document and then describe them in detail in the appendices.
The project plan in section 5 describes the activities and quantifies the effort in creating and executing the strategy. Don’t underestimate the amount of time, effort, and money that it can take to create user guides, FAQ’s, videos and other adoption collateral specific to your SharePoint based solution.
The sections on success criteria, and metrics and monitoring require some considerable thought. The trick is to identify specific behaviors that you want to see either increase or decrease as a result of the introduction of the solution and to forecast and track those. If you’re not clear on which behaviors you should be tracking then are you sure that you're clear on the purpose of your solution?
Finally it’s a good idea to define and profile the target user group. If you’ve been using user centered design techniques then you’ll have personas ready to go.
For Next Time …
Well that wraps it up for the Art of SharePoint Success framework! It’s taken 19 articles over 8 months and been read by millions (almost) around the world. It all seemed to make sense at the time, but are you actually any clearer on what you need to do? I thought not, so to round things off I’ll be back for an encore and next time I’ll be presenting the Call To Action.
Editor's Note: To read the first in this series by Symon Garfield: