From around 25 years ago, computers began to replace paper-based processes for most office-based workers. Users grumbled and some (mostly at senior levels) managed to avoid using a computer altogether. The majority of office workers (who became known as ‘users’) just adapted to and eventually adopted the new work practices, often with the promise of greater productivity.
Over the past 25 years, if no other system was mandated for the storage of digital records, users mostly:
(a) created new content using desktop applications and stored it on largely uncontrolled and poorly managed network drives; and
(b) sent or received emails (often with attachments from stored on drives) and used email folders to store those emails
… in both cases with scant regard to business or corporate recordkeeping requirements.
The end-result of 25 years of these practices is network drives and email systems full of digital ‘stuff’, little of which relates to each other in any meaningful way (unless it all happens to be stored in a single folder, or folder-based structure, which is not common).
Many electronic document management (EDM) products have been released over the years, ostensibly to improve the management of electronic records, but organisations still grapple with getting users to use them. I suspect that one of the reasons for the poor take-up of EDM ‘solutions’ is that users are so familiar with using network drives and emails folders; it is just so heavily ingrained into the way we work, not to mention the way we manage our own personal records and other digital content on home PCs and laptops.
Interestingly, some of the EDM vendors have developed interfaces that look almost identical with network drive folders. My own personal experience with these products is that users often don’t understand the difference, or the value proposition, that comes with use of these systems.
Along comes SharePoint
SharePoint has been around for about 10 years now, but best practice document management in the product did not really emerge until SharePoint 2010 was released (see my other posts for further information).
What is, for me, interesting about SharePoint is the design of the user interface presented in standard team sites via a browser. Microsoft clearly did a bit of research (and understands) how users work, with document libraries on the left (looking a bit like network drives), as well as a number of other list-based options such as tasks, discussion boards, announcements and calendars.
Not infrequently, the initial user reaction to team sites is one of uncertainty and some degree of confusion – is it the intranet?. Depending on how an organisation delivers team sites, user reaction can be either enthusiastic (so much better than drives/folders) or negative (prefer to use drives/folders).
SharePoint team sites as communities of information
For most of the past 25 years or so, ‘collaboration’ has meant exchanging emails with attachments and/or accessing the same part of a network drive, structured in a way that ‘makes sense’ to the user or the team.
SharePoint also allows users to ‘collaborate’, but quite differently from how users have done it to date. In some respects, SharePoint is more in tune with social media sharing (open access to all, or to a trusted group), than with traditional ‘closed’ methods (i.e., via limited email distribution, or limited access to parts of drives).
SharePoint team site can be used to store documents (and photographs) in document libraries (with unique document IDs, version controls, check in/out controls, out of the box workflows, audit trails and custom metadata). It can also use the rows and columns of data in spreadsheets and small databases and store and present that data instead in lists (including discussion boards, announcements, calendars, task lists and custom lists). As the volume of information stored in the site increases, search becomes an additional valuable resource that brings a range of information together. That is, instead of a list of documents, users can see a range of other contextual data.
A single SharePoint team site starts to becomes a community of information.
Changing behaviours
In my view, the key to getting users on board with SharePoint team sites is selling its benefits, not the technology, and helping users understand how to ‘map’ current practices to the new environment.
One of the best ways to demonstrate the benefits of using SharePoint is to show how it is being used (differently) by other teams, and to emphasise the ability for site owners (not a controlling authority such as IT) to use standard features (not customise*) in team sites to meet the needs of the team. That is, the team identifies and implements ways to use it that makes sense to the team, within a few broad constraints to ensure consistency in use across the organisation.
But, despite the obvious benefits, deeply ingrained user behaviours can be exceedingly difficult to change unless that change is driven by users (preferable) or mandated (may have limited success). The SharePoint team site paradigm *is* a major change from using network drives to store documents and emails (with attachments) to collaborate.
‘Mapping’ current practices to SharePoint team sites in many ways underlines the weaknesses of current practices, and can include things like:
- Demonstrating the relationship between network drives and document libraries, using document sets or document categorisation to replace folders.
- Describing convincingly why folders are not a good thing to use (despite the apparently similarities with network drive folders). For example, they can be very hard to navigate, do not have unique IDs (like Document Sets), can be replaced by Document Sets with longer names (including the concatenation of network folder names), can results in very long URLs and so on.
- Showing how document metadata and views can completely replace the need for folders.
- Showing how a team calendar (or calendars) can replace white boards or similar.
- Demonstrating how an Excel spreadsheet can become a much more useful list of information, so that users can edit their own items rather than wait for someone else to stop editing the spreadsheet.
- Showing how a team discussion can not only replace email but also keep a record of otherwise inaccessible email trails.
- Demonstrating audit trails and site web analytics to show (and know) ‘who did or saw what’.
- Demonstrating the use of hyperlinks instead of emails with attachments to share information.
- Demonstrating features in document libraries that are absent from network drives (including unique IDs, versioning, audit trails).
- Demonstrating out of the box workflow that remains with the document.
- Demonstrating search, and in particular searches that return metadata-rich documents.
- Showing how the Recycle Bin keeps deleted items for three months (which, coupled with the audit trails, help to retrieve those items much more easily than requesting the document back from a back-up tape).
and so on.
*By customisation, I mean changing the overall look and feel of a team site by modifying the theme, creating new types of pages, adding documents to pages instead of to libraries, using folders instead of document sets, and so on. Customisation can lead to confusion which in turn makes users less likely to use the site.
Records about the world 