Archive for the ‘Sharepoint 2010’ Category

Can ‘traditional’ records management survive the digital future

December 23, 2015

At a conference last year I listened with interest to a panel discussion on the subject of ‘paper versus digital’. Perhaps the debate was only meant to be light-hearted but it was clear that quite a few records managers continue to manage paper records and see them as their primary focus. In almost all cases these records are the printed version of a digital original. In most cases those digital originals remain stored on a network drive (or a person’s USB), or attached to an email, or – if you are lucky – copied to the organisation’s electronic document management (EDM) system to become the ‘official’ version.

Only a month ago I saw a colleague, whose position title clearly indicates she is responsible for digital recordkeeping, asking about KPIs for the creation of paper files. Perhaps it was part of the digital recordkeeping strategy to examine this subject, but it underlined for me the persistence of ‘traditional’ recordkeeping concepts, that documents belong in containers, that may be files or groups of files (or series etc). This is not just an issue for records managers, but for end users as well who continue to ‘think paper’.

It concerns me that records managers persist with the concept that digital records somehow ‘belong’ in digital files, often directly connected with the descriptive ‘business classification’ system of function and activity (in the sense that the file title or metadata may include the function and activity).

This way of thinking reinforces the concept that these records belong nowhere else, or might have no context outside the container, which of course is not necessarily true. It is, of course, possible to cross-link documents to a different container, but at what point is this a manual exercise? And where does it stop?

Part of the problem has been that digital systems mimic in their appearance and functionality the concept of a file or folder. We see them on network drives, in email, and in the containers of EDM systems. These folders or containers provide a sense of surety, that a document has been ‘stored’ or saved in a specific file. The file, however, is no more than a visual construct; the document’s file/folder/container metadata is what causes the document to appear that way.

This is all the more obvious in some EDM systems that store documents in a file store (often folder-based) and the metadata about the documents in a separate database. Aside from the folder structure, these documents are more or less a bunch of uncontrolled documents with metadata links to the ‘file’ construct in the database.

Of course, keeping records in some form of business context is important both for the management of those records (short and long term) and for retention and disposal purposes. But that doesn’t necessarily mean that documents must be associated with ‘files’ that, according to some records managers (and paper filing theory), should contain no more than 300 documents.

All of this is unnecessarily restrictive and, for end users, results in additional work. It’s no wonder that EDM systems have lagged behind the more ‘traditional’ way that users store documents, in network drives.

We should, I believe, think of digital records as being self-contained and dynamic objects with their own metadata payload that may be relevant in multiple contexts, not a fixed object stored in another fixed object.

Enter Microsoft Groups

In 2015 Microsoft announced the concept of Groups, accessed primarily from Outlook. Conceptually, you could think of a Group as being more similar to an Active Directory Distribution List rather than a shared mailbox. It is also similar to Yammer groups, but with much more functionality.

From Outlook, a user can create a Group to work collaboratively. Group members can initiate conversations with other members of the group (including Skype discussions) and – importantly – share documents.

So, Microsoft is taking us into the world of Group-centred information collaboration. This is not an experiment on the part of Microsoft, it is part of the world of Office 365 which includes SharePoint Online and OneDrive for Business, Delve, and more, supported by any device to enable users to create, access and share content anywhere, anytime.

Now, not every organisation uses Microsoft products, but an awful lot do. And for those who do, Groups in Office 365 is the future. The impact on traditional recordkeeping practices is likely to be large.

By 2020 or earlier, users will create Groups via Outlook to collaborate. Within the Group they will store digital content (not just documents); documents are stored in SharePoint Online site collections which are in addition to any other Site Collections. That’s right – in addition to your controlled Site Collections, there will be a multitude of Group-specific Site Collections. Conversations that take place in the group are stored as items in the inbox of the Group mailbox. In other words, all the content (and perhaps context) will be based around the Group ‘subject’.

To access all this rich content users will have three main options: (a) be an active member of the group; (b) SharePoint search; and (c) Delve. Business intelligence and data analytics, or e-Discovery type products, may also provide a fourth line of access.

Likely impact on recordkeeping

The recordkeeping practices that I believe will be most affected are: (a) metadata, including the application of BCS terms; (b) container-based storage, and (c) retention and disposal. It may also impact the careers of records managers. There will be no control over the creation of new groups (there can be, but why?), so their information content (in Outlook and in the associated SharePoint Online site collection) will become, in many respects, the new containers for records, in addition to other site collections.

On a positive note, I believe users will adapt and adopt this new model of working rapidly. Users, many of whom remain glued to Outlook as a business ‘collaboration’ tool, will find that Groups provide them with the ability to store and share documents via the Outlook interface. They may need to get used to the idea of ‘working out loud’ in Groups, but I think that will happen fairly quickly.

One thing is sure – change is inevitable.

Advertisements

Folders uninterrupted – the enduring problem of folders

November 19, 2015

In September 2014 I presented to the Records and Information Management Professionals Australasia (RIMPA)’s annual conference in Adelaide, South Australia, on the subject of folders and how it is possible to manage digital content differently using products like SharePoint.

Last week a couple of people in completely different parts of the company I work for demonstrated clearly the problem of folders on Outlook and network drives. The first had at least 100 folders and sub-folders in her Outlook where she said she ‘filed’ everything so she could find it again. The other person showed me a newly created section of the network drives with hundreds of new folders and sub-folders set up by someone who didn’t like or get the existing agreed folder structure that has been in place for many years.

In both cases I asked the same question – how do you find anything? The answer, in most cases, is that the person clicks on folder names that they created or are familiar with, until they find what they are looking for. Search was usually relegated to last ditch attempt to find things but was not considered to be very helpful or accurate. Both individuals lamented the duplication of information in folders, duplication they often didn’t know about until the inevitable clash of versions that occurs regularly.

At a workshop/presentation I did for another organisation recently, I was told that the organisation relied heavily on what are called ‘titling conventions’ to enable the information to be found. That is, the names of files, folders and documents follow a pre-defined model.

In reply to my comment that such titling was surely less valuable when you could search for the content in their document management system, I was advised that they didn’t yet have the ability to search by the content of documents (a resource issue). They could only search for content based on titles, once again reinforcing the need for folders (with unambiguous and consistent titles) to find that information.

Breaking the habit

I have said many times, folders are a very hard habit to break. Given the generally poor ability to search and find content in email and network drives (and in some EDRM systems – still), search is relegated to second place and folders and pre-defined titling conventions continue to dominate where content searching is not available.

For at least fifteen years, working across a range of organisations, I have had the ability to search within the content of digital records. This includes being able to search for the content of scanned documents that have been subject to OCR or optical character recognition. In this digital age I’d be very disappointed if the only way I could find content was by navigating labyrinthine folder structures on email or network drives.

I have fewer than five sub-folders under my work email inbox. I use those additional folders to route specific content such as junk mail, SharePoint notifications or personal email. I don’t save anything to a network drive and only use SharePoint to store and retrieve records and other corporate information. Why? Because search is really good.

I know this is not common practice around the organisation. Common practice is to create and maintain multiple folders and squirrel useful content away in network drive folders. It’s been that way for 30 years.

I don’t think folders are going to vanish from the landscape anytime soon – they are no more as unlikely to vanish in the next 10 years as email, although both are slowly morphing over time into something different, particularly as ‘collaboration’ tools, search, and the presentation of information via analytics engines are introduced.

Content finds you

Facebook and Google are successful for a reason – they both present content (including advertising) relevant to the user based on her or his digital content. A simple analogy is to compare the corner store where you know you can go to get milk with the ability of digital devices to remind a user they need to buy a specific type of milk because (a) their internet linked refrigerator has noticed that milk is running low and (b) they regularly post to social media (or even in a single email) about their preference for this type of milk. It’s creepy, but it works .

Many contemporary office environments are not much different – users know they find their digital content in the folders (the little corner stores) they created or have learned about. But they don’t know how much other interesting or directly relevant content is there and they don’t bother looking because they know it will be a poor and time-wasting experience.

They don’t know what they don’t know.

My experience over the past five years with SharePoint (and with similar products before it) is that users are resistant to ‘having’ to store documents in a different location to what they are used to (i.e. network drives).

Users worry their content will be lost, it’s ‘yet another place’ to store and find content, and the user experience (compared with folders) is alien. This doesn’t stop them consigning endless information to social media and being the recipients of targeted advertising and suggested friends based on their content. The difference between the two is so extraordinarily different it is sometimes hard to believe that users do this, checking in on Facebook’s content-driven feed while ‘navigating’ through endless folders, many with names that are about as vague as you can get.

Where is this heading

In the last weeks Microsoft has outlined what is sees as the future of the office and their Office. Three key elements of that future are:

  • SharePoint (on-premises and online) and OneDrive. These two will not replace folders completely but will give users a much better (and more importantly, more mobile) experience with storing and finding content.
  • Office 365 Groups. Groups of people who have a common interest and can communicate across platforms, whether it be via email or other collaboration tools including SharePoint or Yammer.
  • Analytics as the way we will harness and access our information, via interfaces like Delve that serves up relevant information based on the user’s digital content. Just like Facebook.

Does Delve deliver on the ‘Semantic Office’?

Many years ago I wrote on this blog about what I called at the time the ‘Semantic Office’. In that article I asked whether we will one day experience a time when we can truly harness the digital content in our business systems to link and present relevant information to users based on the same methods found on the internet at that time (for example in eBay, Amazon etc).

I think Microsoft has finally figured this out with Delve. My guess is that, by 2020, Delve or a version of it will be the most common ways users first access their content.

So where does this leave folders?

Folders aren’t going to go away anytime soon. I’d like to think that Microsoft took a close look at how they could deprecate folders in email and drives and realised that this was akin to giving up on email – it wasn’t going to happen.

Instead, Microsoft decided to introduce new tools that can capture and – more importantly, perhaps – present information in completely different ways that digital natives expect and even take for granted. As someone said recently, when a large group of young people were asked to send an email, many responded with ‘what’s email, why can’t I Inbox you?’.

Change is happening, slowly, along with the culture shift that must accompany it. For every older ‘paper native’ worker that retires, a younger digital native commences work in the workforce, bringing with them new expectations both in terms of work experience and tools they use.

Just like the clacking of manual typewriters in offices was eventually replaced by the slightly smoother sound of electronic typewriters, and then the click-clack of keyboards hooked to the back of computers, the silent touch screens of the future will eventually dominate and then themselves be replaced by something else.

Habits are hard to break, but change happens.

Managing documents in SharePoint 2013 and SharePoint Online – what’s changed?

September 20, 2015

We are in the process of upgrading our extensive ‘out of the box’ SharePoint 2010 environment to SharePoint 2013 and, at the same time, setting up a limited SharePoint Online presence. So, what’s changed in relation to managing documents as records?

In SharePoint 2013, the short answer is ‘not much’. However, there are some new things that will change some parts of our technical design model. The things that have remain unchanged include:

  • Document libraries as the primary ‘container’ to store documents, using folders, document sets, or metadata-based categorisation, to ‘group’ documents.
  • Document IDs, set in the Site Collection Administration – Document ID settings section.
  • Document versioning (major/minor, major, or none), set in the Library Settings – Versioning Settings. Other settings in this section, which we generally do not use, have also not changed: Content Approval, Draft Item Security, and Require Check Out.
  • Use of Content Types (and disabling of Folders), enabled via Library Settings – Advanced Settings, and then added in the general Library Settings – Content Types area. All other options in this section, which again we rarely use, are still there: Custom Send to Destination, Search visibility, Offline Client Availability, Site Assets Library, and Dialogs. The old familiar ‘Datasheet view’, which we use to ‘bulk upload’ or update metadata has been renamed ‘Quick Edit’.
  • Almost unlimited metadata options via pre-defined Content Types or library-specific columns, both of which can point to the centrally controlled metadata in the Managed Metadata Service or local ‘look-up’ lists.
  • Multiple list views, each with their own linkable URL.
  • The ability to copy documents, via drag and drop or copy/paste, using ‘Open with Explorer’. This, coupled with the ‘Quick Edit’ option, allows documents to be copied to SharePoint document libraries in bulk and metadata added easily.
  • Access controls that can be applied right down to the document level.
  • The ability, from a document-specific drop down menu, to view or edit the properties of a document, check it out or in, view the version history (and restore versions), run workflows, download a copy, share (the former ‘manage permissions’ – see below), and delete (where enabled).
  • Out of the box simple workflows for Review and Approval.
  • Site collection audit trails, accessed via the Site Collection Administration area. Unlike some other products, SharePoint audit trails are not ‘attached’ to individual documents, but are centralised in one place.

So, all in all, not much change really, except for the ‘Share’ option. In many respects, the way the simple ‘Share’ has been designed is a more intuitive process than ‘Manage Permissions’. When you add a user you decide if that person should have Edit or Read privileges. If you maintain the default Owner, Member and Visitor groups, then those with Edit rights are added to the Member group, those with Read rights are added to the Visitor group.

For more complex permission management, including to stop inheriting the default permissions (or to add them back, which is now called ‘Delete unique permissions’), or creating new groups, you need to select the ‘Shared With’ option from the drop down menu and then select Advanced.

What about disposal/disposition management?

Again, not much has changed in relation to document libraries or lists. Out of the box, your options are as follows:

  • Using centrally defined, document-based, Content Types, using Information management policy settings. Not a bad idea if (a) you have a way to ensure that these Content Types are always added to libraries, and (b) you are happy to manage the disposal of documents one by one.
  • Changing the default Information management policy settings option in document libraries from ‘By Content Types’ to ‘By Libraries and Folders’ and then applying retention policies on the folders you create. The main negatives of this option are that it means you have to use folders, and you have to manage disposal by document.
  • Leaving documents in document libraries, and having a way to review these, across the farm, in a centralised manner. This requires some kind of script to be written to (a) list all libraries across the farm and (b) work on the basis that the ‘Last Modified Date’ is the last action on any document in the library, but it seems the more logical and simplest way to achieve the outcome you seek, and keeps all the documents in the same container.

It remains surprising to me why Microsoft does not provide the option to set a disposal period on an entire document library.

Of course, SharePoint 2013 now allows you to set a disposal period on a Site, but this isn’t likely to work for sites that contain a range of diverse content that may be useful over a long period of time.

So, what about SharePoint Online?

The first thing to remember about SharePoint Online (SPO) is that it’s not SharePoint On-Premises. Seems obvious, but the natural instinct is to wonder if or how the two environments can be connected. In most cases they can’t, so it’s not worth thinking along those lines. SPO is a way to manage content in the cloud in addition to, or instead of, on-premises.

SPO has all the same document management features you find in SharePoint On-Premises, described above – document IDs, versioning, content types, metadata, multiple list views, open with Explorer and Quick Edit, access controls, document-specific menu options, simple workflows and audit trails.

O365_SPO_LibraryRibbon_DocMenu

The options for disposal/disposition management using SPO ‘out of the box’ (should that be ‘out of the cloud’?) is the same as for the on-premises version.

You didn’t mention Records Centers …

Records Centers (or in Australia, Centres) were in many respects designed to be the ‘send to’ archival repository for other sites. Great idea if it works in your world, it doesn’t work in ours. The main drawbacks are that documents ‘sent’ to a Records Centre are in fact copied. Custom metadata is lost, versions are lost, audit trails are lost. And, you can retrieve the document.

But Records Centres (or in the US, Centers) can be useful on their own as a repository of specific types of records that aren’t accessed too much. We have several Records Centres and we use them in a separate web application for specific purposes, including to store scanned documents. We don’t use them as they were originally intended for the reasons stated above.

And yes, you can create Record Centers in SPO, too!

Sentencing and disposing of records in SharePoint 2010

August 28, 2014

This article applies only to on-premises installations of SharePoint 2010. 

SharePoint’s ‘Records Centre’ was, in theory, a place to send records from various sites for long term storage, sentencing and disposal. The idea was that you could automatically, via Content Type rules, or directly, via the ‘Send to Records Centre’ option, transfer records out of team (and other) sites into the Records Centre. 

While the theory made sense, in practice there were several problems with the model, not the least being that ‘transferred’ records were not actually transferred but copied and effectively re-registered as new records in the Records Centre. They also lost previous versions, and so on. 

We needed to find another way to manage the sentencing and disposal of records. SharePoint 2013 has the (information management) option to apply a sentence on an entire site, which is great if you want to do that, but in most cases the requirement is to sentence parts of a site, including whole libraries or lists. 

As our document-based records are stored in document libraries, and these libraries generally (but not always) have names that make sense (if you can stop people using the generic ‘Shared Documents’ default library), it seemed a good idea to focus on how we could apply retention and disposal policies to document libraries. 

The first problem is visibility of all those libraries, created across multiple site collections. The only way to see all of them was to be the SharePoint Administrator or have Site Collection Administration privileges across all sites. But it was cumbersome to have to open every site to see what was stored in them. 

I put this problem to our SharePoint Administrator and developer (Eric Fang – blog here: http://fangdahai.blogspot.com.au/) . Using PowerShell scripts, Eric developed a method to display all document libraries across all Sharepoint sites in a list. The list updates on a regular basis.

NOTE: You cannot create this type of list ‘out of the box’, it requires PowerShell scripts, and that will need to be maintained over time. This is not a skill that is normally found with most SharePoint Administrators. 

The list displays:

  • The library GUID
  • The library name and URL
  • The site collection and sites, including URLs
  • The number of items stored in each library
  • The date the library was created and who created it
  • The date any item in the library was last modified

The first, immediate, benefit we could see from this method of displaying libraries was the number of libraries that had been created but not used. We could immediately see the ability to reduce the number of libraries, especially if these had not been used for a given period (say, one year).

The next benefit was the ability to group libraries by site collection. As many of our site collections map to business functions, we could start to see the volume of content that was stored for each function, by library – many of which were created to store documents created through various activities.

For example, a common document library is ‘Meetings’. We can now filter the view to see all libraries that contain documents relating to meetings. We can also see types of libraries that have specific retention and disposal requirements.

While the list of all libraries has provided an excellent way to view all our libraries, we are now working on a method to apply retention and disposal actions to these libraries. One way to do this would be to add an extra column in the list for retention and disposal information (class number, class decription, disposal action, expected disposal date, approved by, etc).

Once a disposal action had been applied to the list, we can then review it when the disposal action became due to determine if the library could in fact be destroyed. If it can be destroyed, it would be possible to export the original library metadata columns to a spreadsheet to keep a record of what was destroyed, and when.

Life without folders – SharePoint 2010

June 4, 2014

For a generation now we have been using folders on network drives, in home computers, and in email systems, to categorise and store digital content. We now do it in the cloud too.

They are a hard habit to break because they make so much sense.

Almost everyone in work today uses folders to categorise, store and retrieve digital content. The extensive use of folders in drives and email systems has presented significant challenges for records managers, both in the management of the records contained in them as well as the implementation of recordkeeping systems.

Let’s be clear – users love being able to categorise information in a way that makes sense.

It’s hard to imagine life without folders. Or is it? The last time I looked, one of the biggest social media systems in the world, Facebook, didn’t offer folders.

What are folders, really?

But folders are no more than a virtual construct, like containers in almost every recordkeeping systems. What you see on the screen is a folder (or directory) or container, but it isn’t a real folder like a physical folder that contains paper documents. Documents that appear to exist within a virtual folder include a pointer to the folder in their system-generated metadata.

Folders in SharePoint 2010

The primary way to group digital content in SharePoint 2010 is by storing them in document libraries. Document libraries are the highest level of aggregation possible so, in a way, they are similar to the highest level folders in a network drive.

In almost all cases, the initial, instinctive user reaction to a document library is to want to categorise the content using folders. Newly created, out of the box, document libraries include the ability to create folders, just like on network drives, and so many users start to replicate the structure of their network drives, or copy the entire content from the network drives across the the library using the ‘Open with Windows Explorer’ option.

But, very quickly, users discover that folders in SharePoint libraries have no navigation clues, no way of knowing if you should navigate up or down to find content. Before long, enthusiasm wanes in the trough of disillusionment and users go back to using network drives and the SharePoint site becomes a ghost town.

SharePoint’s neat little trick – making folders vanish

As noted earlier, folders are no more than a virtual construct. In SharePoint, users can make the folders disappear by creating a view (or modifying the existing one) to change the ‘Folders’ setting from ‘Folders’ to ‘Flat’ to show all items without folders.

As soon as the user clicks OK after changing this setting, all the folders vanish and only the documents stored in the folder structure appear. (Note, this does not work in libraries with Document Sets because Document Sets are regarded as documents, and so both appear).

With careful guidance, and subject to the volume of documents in the library, users may then query whether folders are even necessary. Or they may ask if there are alternatives (yes, categorisation or document sets).

In my own experience, once they see how to work without folders, users seem to quickly abandon the previously strongly held belief that folders are the best way to categorise documents and use either categorisation or document sets instead.

Planning access controls in SharePoint 2010 team sites

October 15, 2013

A key factor that needs to be considered when planning for the creation of team sites for the management of records is access control. Getting this right (or as close to right as possible) early on for team sites with sub-sites will save a lot of potential pain later on.

Team sites will normally have three levels of access permission:

  • Site owners. Full control. One to three for each site collection.
  • Site members. Contribute rights, i.e., add/edit/delete.
  • Site visitors. Read only access.

There are generally three ways to manage access controls in team sites that have sub-sites:

  • Inheritance, broken as required. Top level site owners control all sub-sites, site members and visitors can be the same.
  • Independent, within a site collection. Different site owners/members/visitors between the top site and sub-sites – although the site owners could be the same.
  • Independent, separate sites but linked. Different site owners/members/visitors for each site.

Inheritance model

This is the default access model for team sites with sub-sites and is enabled when a Site Administrator creates a new sub-site without choosing ‘More options’ on the ‘Create’ Team Site dialogue page. Site owners control the top and sub-sites, site members and visitors are the same unless inheritance is broken on any part of the site (sub-sites, libraries or lists, or documents).

  • The benefits of this model is that site owners control all the site collection and both members and visitors can be the same.
  • The negatives relate to the effort involved in restricting access and giving unique access to sub-sites, libraries/lists, or documents. For example, to provide access to a specific area, a person who is not part of the default members or visitors group must be either added to one of those groups, or added individually. When they are added individually by user name, their user name appears across the entire site collection; they will be able to navigate ‘up’ (and down) but they won’t see any content in any page, library or list. Another negative is that, once selected, it is not possible to revert to the independent model (unique permissions); it is only possible to break the inheritance model and create new security groups which is a bit messy.

Independent model, within a site collection

The option to select this model must be selected when the new sub-site is created by clicking on ‘More Options’ after the Title and URL name are entered. A new dialogue box opens with a section ‘Permissions’. This notes ‘You can give permissions to access your new site to the same users who have access to this parent site, or you can give permission to a unique set of users’. It adds, ‘If you select “Use same permissions as parent site”, one set of user permissions is shared by both sites. Consequently, you cannot change user permissions on your new site unless you are an administrator of this parent site’.

There are two options:

  • Use unique permissions
  • Use same permissions as parent site (the ‘inheritance’ model above).

Again, there are positives and negatives to this model:

  • The benefits of this model are that you can have unique access permissions on sub-sites, removing the requirement to break inheritance or worry about what users with access can see on the other parts of the site collection. Each sub-group within a team can have their own site that cannot be accessed by the other parts of the team – although you might consider giving other parts of the team visitor access, with the sub-group having ‘contribute’ rights.
  • The negatives of this model are in the requirement to manage multiple access permissions for the top level site and sub-sites. Consider a common team environment – normally only a couple of people will be the site owner. If the site collection has multiple sub-sites with unique permissions, each of those sub-sites will have their own site owners. Of course, you can assign the same person to the site owner of each sub-site, but it is still a degree of overhead you don’t get with the inheritance model.

Independent model, separate site collections

This model simply consists of either of the first two options, with separate site collections added as links either on the global (top) or current (left hand side) navigation. End users don’t know that these links are completely separate sites unless they look at the URLs.

  • The benefits of this model are the same as the benefits for the second option above (independent model). Each site collection has its own unique permissions. It also allows you, if you restrict team sites to one sub-site level, to have sub-sites on the linked sites, to get around that restriction. Separate site collections could have either ‘open’ access to everyone, or ‘closed’ access.
  • The negatives of this model are also the same as the negatives for the second option above. Generally, however, there will usually be a good or compelling reason for having a completely separate site collection linked to the primary team site, and this often relates to the proposed site audience. For example, members of the team may be involved in a project; the (separate) project site can be linked to the main team site, but only those members of the team site with access will be able to see it.

In summary, it is important to consider access controls carefully, understanding both the benefits and the negatives of each option, then plan and implement accordingly. Otherwise, if there is a requirement to change the access type, this could be difficult to implement later on and the sub-site may have to be re-created.

Implementing SharePoint to manage documents – changing user behaviours

September 10, 2013

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.

Is your SharePoint team site a ghost town?

May 24, 2013

One of the best ‘unknown’ (to end users, anyway) features of SharePoint 2010 and SharePoint 2013 is ‘Site Web Analytics’, hidden away under Site Settings. This, out of the box, feature provides useful information such as the average number of site views per day, the average number of unique visitors per day, trends, as well as a listing by user names of the top visitors and the number of their page views. It’s a great way to see if a site is being used.

The default date range for Site Web Analytics is the past 30 days but the settings can be changed to the last day, week, month, quarter, half-year or year. Custom dates can also be set, and these reports can be exported to a spreadsheet for further analysis, including through scheduled reporting sent by email.

So, what does this have to do with the subject – is your SharePoint team site a ghost town?

Simply, Site Web Analytics tells you if your team site is being used – by your team. If it’s not used, then it’s a ghost town – and you need to understand why and consider changing or deleting it.

In many cases, the reason a SharePoint site becomes a ghost town is because users simply neither want nor know how to use it.

What makes a document management system popular?

My experience implementing and using many other document management systems (TRIM, Documentum, iManage, Alfresco) over the years, along with considerable anecdotal evidence, suggests that, unless there are legal or regulatory requirements mandating it, end users tend to baulk at using a document (and records) management system, especially if it:

  • Requires more than 20 minutes to learn. Some EDMS systems require hours of training – for end users!
  • Duplicates what they do already with network drives. More often than not it requires ‘saving’ an existing born-digital record to the recordkeeping system (AND leaving the original where it was stored).
  • Stores records of a business activity away from other, potentially rich, related records that are not documents.
  • Provides no obvious or little tangible business value for the user – it’s a ‘compliance overhead’.

A popular document management system is one that:

  • Users can start using the system with very little training. It should be intuitive and make sense at first glance. I often use the example of Facebook – no-one ever got training to use it and yet a billion people registered to use it.
  • Reduces (not necessarily eliminates) duplication of effort. Network drives can still exist to create and manage ‘working documents’ instead of final versions.
  • Can keep records in context with other related records such as calendars, lists, tasks, announcements, social networking messages, and so on.
  • Provides tangible business value for the user, with minimal effort. It’s hard to break the network drive habit but simple things like unique document IDs, versioning, hyperlinks, and the ability to email a link instead of a document help to break that habit.

What can turn a SharePoint team site into a ‘ghost town’?

Microsoft clearly put a lot of human-computer interaction (HCI) effort into the user interface design of SharePoint team sites (along with all their other products). Team sites in SharePoint 2013 are a design improvement over SharePoint 2010 but still maintain the same essential look and feel, which is:

  • Document libraries and lists on the left hand side navigation. It’s no coincidence that this is exactly where network drives and email folders are accessed from.
  • An editable main page that can be modifed as required to present additional information or options, including via webparts.
  • Default and modifiable views of documents and lists.
  • A simple search option on the top right.

Over 25 years of network drive use has conditioned users to navigating for documents from the left hand side, searching from the top right hand side, and seeing information presented in the middle of the page. Change this paradigm and you start to lose users.

I believe there are two main reasons why users don’t or stop using team sites (described further below):

  • The ‘plain vanilla’ out of the box functionality in a brand new team site.
  • Site pages that have been customised to the point where end users cannot work out how to navigate or access their information.

Out of the box generic functionality

Out of the box team sites include the two features which, if not addressed or re-configured (a 2 minute job), can negatively affect take up rates:

  • ‘Shared documents’ under ‘Libraries’. This to me is a ‘bookmark’ library that should be removed almost immediately and replaced with a library that has a name that makes sense, ideally named after a business activity. Otherwise, ‘shared’ is like ‘general’ in a network drive. If users have only one, generically-named library to choose from, they are unlikely to use it (compared to the rich tapestry of their network drives).
  • Folders. Unfortunately, while SharePoint folders look like network drive folders they don’t work the same way. They create unnecessarily long URLs and are often impossible to navigate. It’s not uncommon to hear users say they cannot find documents in a site because they cannot work out how to navigate folders (as they don’t include a + to guide navigation). My recommendation is to turn them off under Advanced Settings after the library is created. However, users inevitably want a way to categorise or group documents in a document library. Document Sets generally make sense to users and get quick take up but you can only have one level. A good site has a reasonable number of smartly-named document libraries – perhaps no more than 10, grouped as required by Headings – using Document Sets instead of folders. Another form of categorisation is using categories in the document metadata and then creating a view that groups the documents by those categories.

Customisation

Too much customisation of site pages can also turn users off. As noted above, it’s worth keeping in mind that Microsoft spent a lot of effort (and probably dollars) on designing their standard team site user interface. Some of the common modifications I have seen on ‘ghost town’ sites include:

  • Using themes that make the site look completely different from all other sites. It’s important to maintain consistency in themes.
  • Using unnecessarily large font sizes on the page.
  • Using too many images or graphics on the front page.
  • Assuming the text or content on the page is actually of interest to the target audience. I usually suggest that Site Owners (note, there should never be just one) agree among themselves; if this is not possible, test the proposed page design on a user who has never seen it.

Avoid ghost town sites – keep users coming back

Remember, most users are familiar with using network drives and folders. Use document libraries with sensible names that are obvious to users, don’t use folders, and keep the front page content simple and easy to view, and you are more likely to attract users back again and again.

Managing Physical Records in SharePoint 2010

May 7, 2013

It is sometimes said by records managers that one of the drawbacks of SharePoint 2010 (and SharePoint 2013) is that it doesn’t manage physical records, or at least not very well.

This article describes how to manage physical records in SharePoint 2010/2013 using a list that includes barcodes.

Up front and out of the box, the main limitations are the ability to: (a) print labels for paper files and boxes (including labels with barcodes) (b) attach a portable scanner to scan barcodes and (c) maintain a chronological history of file movements. These limitations may not be a problem for many organisations seeking a low-cost way to manage mostly inactive files and boxes, especially if they currently use an Access database or Excel spreadsheet to do this now.

Options to address each of these limitations are discussed in this article.

Metadata options

There are almost no limitations on the type of metadata you can use to describe physical records. I would suggest having the following metadata:

  • Title (e.g., name on the file or box)
  • Record Type (drop down list – file, box, etc)
  • Reference ID (manually entered unless you use the default ‘ID’ option, possibly with a separate ‘year’ column)
  • Date created (date first registered, default system date)
  • Start date (start of date range)
  • End date (end of date range)
  • Business Owner
  • Current location (can be a custom list of pre-defined locations)
  • Date at current location
  • Record status (drop down list: active, inactive, missing, destroyed etc)
  • Internal barcode (if one exists)
  • External barcode (usually the one provided by a storage provider)
  • Records description (description of contents, usually of a box)
  • Box number
  • Box barcode (may be the same as the Internal or External Barcode)
  • Retention schedule (can be from a pre-defined list)
  • Disposal action (can be from a pre-defined list)
  • Date to be destroyed (manually entered based on retention schedule and disposal action)
  • Destroyed? (checkbox)
  • Date destroyed (manually entered date)
  • Legal hold? (checkbox)

If physical files are registered in the system, then only details of the box and disposal action would need to be entered. When the box is ready to be sent offsite, details from the offsite storage provider’s label (often provided in advance) can be entered in the external barcode and other metadata (including current location) updated.

An optional barcode can be obtained by checking ‘Barcode’ in the Information Management Policy settings for the list item. Once checked, the barcode appears when the item is displayed in view but not when it is edited or exported.

Printing labels

All list metadata (except the barcode) can be exported to an Excel spreadsheet, which can then be used to print labels. Microsoft provide details how to create and print labels for a list in Excel here:

Scanning

Using a portable (or attached) scanner to scan barcodes and update your records register, especially with a new location (or during a physical records audit) saves a great deal of time instead of entering details manually. It is possible to scan directly to an Excel spreadsheet however several steps may be required to match or validate the barcode with the details in the SharePoint list.

For example, if series of files are being scanned to a box (or location), the usual practice is to scan the box (or location) barcode first, then scan each individual file. If scanning directly to an Excel spreadsheet, you would do it the other way around – have the list of existing files in the spreadsheet, then scan the box or location barcode to the cell next to the file number. This detail can then be copied and pasted back to the SharePoint list.

Chronological movement history

The only option to maintain a chronological movement history, out of the box, would be to add versioning to the list. This means that each time the item is edited, a new version is created, keeping the previous details. The movement history will not display in a single view in the list but clicking on ‘Version History’ will show any changes made in single view. Only ‘major’ version numbers are supported in lists (i.e., 1, 2, 3, 4).

SharePoint 2010 – Send to Records Center / Centre

March 27, 2013

SharePoint 2010 includes the option to send a document from the site where it was stored to the Records Center (Records Centre in Australia), and other locations. The option is set at the Central Administration Web site under General Applications – Configure Send to Connections. See http://technet.microsoft.com/en-us/library/ee424395(v=office.14).aspx for the details of how to configure this option.

The ‘Send to action’ list offers three options when a document is sent to the Records Centre (options which are then available across the farm):

  • Copy the document (which simply makes a copy)
  • Move the document (which appears to remove the document entirely. Microsoft state that ‘users will no longer be able to access the document from its original location’, suggesting it is not actually deleted from the original location)
  • Move and leave a link (see below)

Microsoft state (in the link above) that this option will ‘… delete the document from its current location, move it to the destination repository, and leave a link at the current location indicating that the document has been moved’. If Document IDs have been enabled, the Document ID will disappear next to the document icon, which then shows a hyperlink ‘hook’ to the document in the Records Centre. A user clicking on that link will be advised that the document has been moved.

The impact of versioning, and metadata, on ‘Send to’ moves

There are a number of issues, and potential problems, with the ‘Send to ‘ move option that need to be understood. Some of these might be sufficient to decide against using the Send to Records Centre option (or even using the Records Centre).

  • Versioning. If versioning has been applied to the document library, and versions exist, only the most current version will appear in the Records Centre. The Document ID will be the same as the current version. However, any previous versions remain in the original library. In one sense, it is good to show previous versions, however any of these previous versions can be restored. When this happens, the version that is restored now appears, with the original document number (and a ‘hook’ still on the icon). The logic of this appears to be that, if a previous version is restored, the version that has been sent to the Records Centre is no longer the current version. However, it remains – with the same Document ID – in the Records Centre.
  • Metadata. Any additional, local metadata that has been added to the Content Type in the original Site Library will disappear when the document is moved. Metadata in Content Types stored in the Content Type Hub will remain.
  • Created date. The ‘Date Created’ field in SharePoint is the date the document was created in SharePoint. When the document is sent to the Records Centre, it is assigned a new ‘Date Created’. The date created field on the original document remains unchanged.
  • Permissions. Any permissions that may have been applied to the document, via inheritance from the Library or Site, are removed and the document inherits the permissions of the relevant library in the Records Centre.

The implications for ‘Send to Records Centre’

The issues documented above could affect planning and decision making regarding use of the Records Centre and the ‘Send to’ functionality. Some issues to consider include:

  • Loss of versions when the document is moved
  • Ability to restore a previous version (and confusion about which is the current version)
  • Loss of metadata applied locally to content types
  • Changes to access permissions

If any of these are concerns for the organisation, consideration might be given to leaving documents in place where they were stored and managing them in that way. The Record Centre could instead be used to archive and apply retention policies to content from network drives.