Document management in online communities

One of the key differentiators between the community solutions developed by Jive Software and those from IBM and Microsoft (talking Sharepoint rather than Yammer) is the relative lack of focus on the requirement for document management.

That’s not to say that Jive platforms do not allow the sharing and management of documents – far from it – but that instead, these are simply embedded within the standard content types and information architecture of the platform rather than treated as a specific pillar of the platform itself.

Just as a user can create a native Jive document or discussion, so they can upload a file (e.g. a Word document) that can be previewed, downloaded, commented on, updated by others and managed from a version perspective. However, these files do not have a hierarchy beyond the place containers they reside within – there’s no concept of folders or libraries for instance. Files are primarily stored within Jive documents (or can be attached to other content types), and are managed using the same tags and categories that apply to all other content.

At the end of the day, in Jive communities, files are just one of the many ways in which users can collaborate. In many situations they are actually discouraged – group and team work can be much more effective when using native content types than when having to deal with the upload/download of sizeable files, the need for compatible editor support and so on.

This differs from IBM Connections in a pretty significant way…

File sharing was added to the IBM Connections product back the 2.5 release in 2009 alongside Wikis (back when it was still badged as Lotus Connections).

Initially, IBM seemed to envisage this support as being intended for lightweight social file sharing – the file management features were limited, meta data was very simplistic and all files were shared at a single level, relying on tags to provide any structure required. Right from the first implementations of Connections 2.5 it was pretty clear that this was not going to be enough for most IBM customers. Whether because users were typically migrating from Lotus Quickr or Domino Team Rooms, or because Connections customers tended to be large enterprises that had become conditioned to heavy use of document and content management platforms, users were adamant that they needed hierarchical storage architectures, heavy-duty file meta-data, complex library permissions and so on.

IBM responded to these demands by steadily adding more features to the Files feature in subsequent Connections releases. From the Windows Explorer connector to allow direct browsing of files from the desktop, through folder support (firstly for standalone files and then within communities), then the addition of industrial-grade Connections Content Manager (CCM) file libraries (built on IBM FileNet), to document editing and preview in IBM Docs and so on.  Looking at the Connections portfolio from the outside last year, it seemed as if almost every new Connections feature and enhancement was somehow related to the management of files in the platform! (I’m sure that wasn’t the reality, but that was how it read from the press releases and announcement letters.)

Personally, I find this difficult to comprehend (and I’ve had long and passionate discussions with both IBM product managers and IBM partners about this topic). I find files (particularly Microsoft Office documents) to be fine for point-in-time exports of collaborative content, workflows or decisions, but they are not supportive of productive team or community thinking, discussion or working in a general sense.

There are, of course, situations where files are necessary – for example a creative team working on an image or video that needs to be shared outside the organisation, or a finance team working on a complex report. However, in the vast majority of situations, my personal belief is that the content should be stored in a native form in the best application to support the act of working together around that information, decision or process.  For most general knowledge work, that should likely be a native document, question or discussion in the collaborative platform, rather than a proprietary file that then needs to be managed as a separate entity. In addition, I continue to propose that folksonomy almost always beats taxonomy when it comes to collaborative use cases, and therefore that tags and categories are more appropriate ways to manage information than hierarchical folders.

Sadly, but probably inevitably, I seem to be in the minority on this discussion. So many people (particularly those in their 30s and 40s) remain so subconsciously wedded to the concept of their knowledge being stored in a collection of files in a hierarchy of folders, all still named with long-unnecessary legacy three-character file extensions. It’s these folks that are demanding that IBM support this out-dated means of working within Connections, and thus it’s perfectly understandable that IBM is responding by supporting this left-over 1980s paradigm within Connections.

Why the difference between IBM and Jive customer demands?

Interestingly, in my time as a Jive Software strategist, I was rarely asked for similar file management features within Jive-n communities, whereas when working with Connections the requirement came up in virtually every workshop. There seemed to be a general understanding that a change in work culture was required in their organisations, and thus the deployment of a new community was more than simply a new platform, it required users to adopt new practices and work styles.

A second factor that often came into play is that most Jive customers also had another document management solution in place, whether for specific use cases, or for general access across the organisation – usually this was Microsoft Sharepoint. Typically this was universally detested by the users – described as unintuitive, hard to manage and impossible to search – but provided enough functionality that it could be left to handle the specific use cases where large-scale file storage was required.  This is less common in the IBM world where Domino is more common as the legacy team collaboration platform, and where Sharepoint can sometimes be seen as the enemy.  That’s not to say that I would propose anyone deploy Sharepoint specifically for document management (there are better tools out there if that is what is required), but simply that ‘good enough‘ is sometimes all that is needed for specific use cases that cannot be supported yet in the common collaboration platform.

But what if I want document management in my Jive community?

All that said (and I really do hope and believe that file management will no longer be an issue in 5-10 years time), it is good to have options and alternatives – no matter what your community platform of choice.  Therefore I am pleased that there is a new option for Jive customers… fme Document Manager for Jive.

This partner extension for Jive, gives a brand new way to explore your files stored in the community, allowing documents to be found more quickly, files to be uploaded in bulk, inline metadata editing and direct support for almost all office applications (rather than just Microsoft Office). This 10-minute demo video covers it well:

As I made clear above, I would love us to look to transition away from formal file and document management as our primary technique for collaboration. However, if this is still required for your use cases, then do take a look a fme’s product datasheet and contact either myself or fme direct if you need more info or to discuss the options available.

Thinking of launching your own online ESN or external community?

First of all, consider each and every requirement as an individual use case, that requires its own definition, configuration and community management. As part of the definition process, one of the key discussion points is to look at how the business processes and workflows can be best supported in the community – what content types, functionality and user interactions are required.  Only once these aspects are understood then look at what content types and/or files are required…

If formal document management is a necessity, then that ‘s the point at which to start considering whether something integrated like CCM or the fme solution is required, or whether those specific use cases would be better supported on a more formal and structured platform.

How do you approach this topic? Are you an advocate for document management, or do you believe that more open and unstructured collaboration is the correct approach? I’d love to hear from you in the comments below…