Adopting SharePoint

There are a number of important activities to consider in order to drive success of the SharePoint implementation. These include seeking appropriate user input in the early stages, continuing to obtain user feedback for an extended period of time after deployment and being seen to act upon feedback, setting out a policy and set of standards for the way the solution is used, enabling a steering board to take decisions on the way intranet and the organisation should interact and, of course ensuring that users are appropriately trained.

Although SharePoint solutions are mostly intuitive to use the business processes that they model are often not; furthermore SharePoint introduces new capabilities which allow the adoption of new, more effective practices which users are likely to be unfamiliar with.

A good example is the replacement of familiar folder structures for storing documents with apparently flat document libraries containing hundreds or thousands of documents. The careful use of metadata allows this large quantity of documents to be presented in views that rapidly let the user find and focus on what they are looking for without having to trawl up and down to an arbitrary directory structure; this approach also eliminates the problems that are unavoidably associated with hierarchical taxonomies such as the case where a document could legitimately exist in more than one folder, or where people are excluded from accessing particular files because of their location and the permissions applied to folders.

Avoiding the old ways

A combination of training, policy, good practice guides and support our needed to transition users from the old ways of doing things to the new, more effective options. This is especially true in the early days of adoption in order to avoid users reverting to old habits or replicating poor structures that are difficult to later unpick. It is helpful to have a business analyst/evangelist who can actively promote the new ways of working through hands-on, day-to-day interaction with users in the early phase; this role also is instrumental in identifying undisclosed business needs and with confirming whether the decisions made on features and strategy are correct and effective. The role typically transitions to a more (no code) development focused one over this period of time.

Creating the new

One of the things we really like about SharePoint is a tendency to make people consider their existing processes. There is a reasonable view that if you don’t need to change things you don’t need to introduce a new technology. So conversely introducing a major platform like SharePoint should for things to change and not simply provide a new way of doing what you are already doing. If the introduction of a SharePoint solution doesn’t shake things up you probably shouldn’t do it!

Use the rollout of the new application platform to explain to people how things are going to change, to overtly deal with their reservations and persuade them of the value of doing things differently. Understand adoption curve (diffusion of innovation) and be ready for pushback and the tension between early adopters and Luddites. Decide if this addresses a business critical activity that needs an overhaul, a tool for creating cultural change in your organisation, is a new strategic direction, or is just someone’s pet project. In three out of four of these cases you will need to push staff into adopting the change and abandoning the old ways quickly; and you have the luxury of being fairly uncompromising on this, after all it is their job to do it the way the business mandates. The new ways of doing things that SharePoint engenders are genuinely powerful, create new capabilities and solve problems for users (even if they didn’t realise that they had the problem). Just remember that by adopting this slightly new way of doing things it may be somebody else you’re mostly helping rather than yourself. I’d like to think that we worked in organisational cultures where this is perceived as a good thing.