The term itself causes confusion, with different people applying different meanings to it. Even those that do agree on the term often struggle to define exactly how to achieve it. It can all result in a bit of a muddle.
Here at BrightStarr we approach the area with confidence. Before we even discuss user adoption, we ensure anything we build adheres to the following:
1. The system must fulfil a specific user need
Put simply users adopt systems they either have to use, or that they want to use. If everyone at a company needs to use SharePoint to fill out timesheets (and often users have to fill out timesheets to get paid) then SharePoint will be adopted.
Similarly if you build an engaging discussion community that users want to be a part of, SharePoint will also be adopted.
2. The system must provide a good solution to a given problem
This point follows on from our first point. If you build something engaging, users are more likely to use it. If the system is well designed, logically thought out, even fun to use, then users will adopt it.
Of course we also understand that sometimes adoption needs a little push. Often our projects will include specific activities to help seed adoption. Users might receive formal training, clients might provide 'drop in clinics' to help content authors, or a competition might be run to name the system being built.
The most important thing to remember is; adoption starts with a good system that users have a reason to interact with. Without that, subsequent activities are pretty much pointless.