What exactly is 'collaboration' - and who owns it ?

This article is mostly prompted by internal discussions within my group at work, but also because I have been reading Prof. Andrew MacAfee's book on Enterprise 2.0. Also in the bigger picture it links back to some posts from late last year on the TiMAF definition of information and information management, because your definition of what constitutes collaboration will impact on who the 'owners' are.

To set a little context, we have been taking about business ownership models for SharePoint (MOSS 2007) in our organization. Our CIO is very much focused on IT providing a service to the business and as such we always look for the 'business sponsor' or 'business owner'. For SharePoint specifically this an issue due to its both its broad feature set, and in no small way due to the Microsoft marketing which depicts it as a tool which 'the business' can use with a lot of help from IT.

So how about splitting up SharePoint's major features does that help? Well it may do, because it might be fairly easy to find the business sponsor for records management functionality, or for business intelligence features. I suppose document management might be more difficult to find a single owner because of its broad scope, unless you have an ECM strategy which in turn has a business owner/sponsor.

Collaboration however is a much more nebulous beast. What exactly constitutes collaboration may change depending on the organization or even the circumstances, and who might want to stand up as the business owner of something so ephemeral ?

At the Open University 'collaboration' was part of our ECM programme, but to be honest that was only collaborative workspaces, wikis, blogs etc not the 'communications' tools such as the Exchange email servers which belonged to a well established group. However we did 'own' collaboration to the extent that we wrote the collaboration strategy, and guidelines on which tools should / could be used for which collaborative endeavours. However as ECM Programme Manager I was also 'co-owner' of our corporate intranet, and in many organizations Corporate Communications (or whomever else) might step up and take the collaboration space because of its links to the intranet. On the other side of the coin I have worked as a consultant with Corp. Comms executives who vehemently insisted that any form of collaboration tool, web based or not, was well outside of their remit.

Throw in newer collaboration related 'phenomena' such as Enterprise 2.0 and things can get even more complicated. Prof. McAfee suggested in a recent post that overusing the word 'social' was a great way to kill your E2.0 initiatives before they even get started (make sure you read all the comments to get the full discourse). Those who decry “social this and social that” as over use of an empty buzz word seem to have forgotten the reason collaboration is so important is because we are social animals, and we like to work together (there are of course sound evolutionary reasons for this !).

So at this point I would suggest that part of the solution is to accept that there is no such thing as single amorphous blob labeled as collaboration – but many contextually different elements to collaboration, each of which may lend itself to a different type of technology or tool, to a different type of management, and even to a different loci for 'ownership'. As a starting point, lets look at the Wikipedia definition of collaboration:

“Collaboration is a recursive process where two or more people or organizations work together in an intersection of common goals — for example, an intellectual endeavor that is creative in nature—by sharing knowledge, learning and building consensus.” (click for the full definition)

If we then acknowledge that we must concentrate on people, process, content and context for successful collaboration, and that dividing collaboration into synchronous or asynchronous is too simplistic, how else might we categorize or collaborative endeavors towards our common goals?

The following five sub-categories are my suggestion for slicing and dicing it to help it make sense:

Messaging Centric Collaboration: The lowest common denominator or fall back position for many, this category includes not only the use of email for collaboration (with all the bad practice this entails, such as large CC lists and attachments) but also Instant Messaging and SMS texting tools.

Content Centric Collaboration: Working together to create or edit a particular item (or items) of information. A good example is the Document Library centred approach of MOSS 2007, where the discussion forum, project blog or even the wiki is used to provide collaboration around the creation of content in MS Office formatted ‘documents’. Other ECM or DM products generally support this mode of collaboration through commenting directly on documents etc.

Conversation Centric Collaboration: The focus is not any particular content item, but instead on free flowing, creative discussions, often between geographically dispersed teams or individuals. Also often used in a ‘knowledge management’ focused scenario, tools might include blogs, wikis and instant messaging.

Process Centric Collaboration: Enhancing a particular production process workflow by adding a collaborative element. This may include discussion with teams or individuals up or downstream in the process workflow, or the collaborative brainstorming of issues causing exceptions in the process etc. For example in the EMC Documentum workflow tools there was a feature that would automatically create an eRoom workspace, assign users to it and email them a message with a link to the workspace and information on the process exception !

Collaborative Management: The co-ordination of programs, projects or processes via collaborative interaction, for example using team workspaces, team calendars and collaborative project management tools.

My colleague Martin White, Managing Director of Intranet Focus likes these definitions (we used them when working together for the UN Secretariat) and he uses them with his clients. As I publish on this blog under a Creative Commons license, feel free to use them too - but this leads to my first question to any readers who would like to comment:

Does this way of splitting 'collaboration' into constituent parts look helpful to you ?

My second question links back to my mention of our internal discussions:

Who is the 'business owner' of collaboration in your organization ?

Information Management related definitions - UPDATED

UPDATE - please scroll all the way to the bottom to ensure that you read the comments left by James Dellow and Joe Gollner, they both add considerably to the conversation.

Back at the JBoye09 conference in Philadelphia in May, Eric Hartman introduced me to the creation of TIMAF - The Information Management Framework, and asked me if I wanted to write an article for their publication, something which due to the new job, I have still not got round to doing !

However TIMAF founding contributors Eric and Bob Boiko presented their Basic Principles Of Information Management at the conference, and Eric started a discussion on the TIMAF LinkedIn group.

The basic principles were posted as:

#1 IM is Communication
IM is there to help people ‘talk’ to each other.

#2 Information Exchanges Value
IM ensurses the exchange of value in information transactions

#3 Information has Audiences
Knowledge of your audience is essential for successful IM

#4 Information Flows
IM rationalizes the creation and life of your information

#5 Information has Structure
IM is based on Information Organization

Generally speaking, I don't have any issues with principles 2 to 5, but it would not be overly dramatic to say that I do not just disagree with principle #1, but I dislike it , with a passion! (as anyone reading my comments in the LinkedIn group will see).

Recently Joe Gollner of Stilo joined in the conversation, and basically lent his support to #1 and linked to some of his blog posting to support his position. This is a particularily excellent one:
The truth about content.

Possibly in a fit of pique, on the LinkedIn discussion I promised Joe a full 'rebuttal' of his position - yes, ever so slightly regretting that term of phrase now..... I am not sure if I am actually academically equipped to rebutt anything written by Joe, but I am going to use lack of time (and energy - noticed how I have not posted for a while?) as my excuse for not deconstructing Joe's article piece by piece. Please do click on the link above and read it in full, Joe has obviously got a lot of experience in 'content management' and publishing. Instead I just thought it would be easier to provide my reasoning why as to why I really don't like "Information is communication" - and provide some definitions and a working theory of my own, especially as we have recently had a very similar conversation in the office; "what is the difference between document management and content management?"

So, why is information and communication different ? I don't believe the act of communication is what turns data into information. I also do not agree with the sub-premise of the Principle #1 that "Information Management is there to help people 'talk' to each other". Let us consider some definitions in order to put my arguement in context:

Both Joe in his post, and some of the responding comments mention "Working Knowledge" by Tom Davenport and Laurence Prusak - I am a 'fan' of the rather practical definitions given in this book and they are the ones are generally refer to, and starting at the bottom of the DIKW pyramid, they suggest data is: "Data is a set of discrete, objective facts about events".

So a datapoint in a dataset of sales figures, i.e. that you sold $6 million worth of hockey kit in the first quarter, is an actual, substantive fact, but it is not information yet. Well sure it is you say, knowing that you sold that much in a certain period is in fact useful information.

Not really - its simply collected data. To turn the data into information it needs to be processed (by a computer or a human brain) in a contextual manner.

Is $6 million more than the same period last year, or less ? does it consist of more items, or less? Is the profit margin greater or less? Is it more than our competitors or less? By merging it with other data, by disagregating it, by collecting further data to back it up, by extrapolating it, or exploring the effects of the data in various models, we are contextually processing the data and adding value to it. Some data needs more processing and polishing than other data in order to expose its intrinsic value.

This is linked to IM basic principles #2 and #3 - the same information may have more value to some target audiences than others, and depending on that target audience and the intrinsic value of the information, any transactions involving that information, including communicating it to others may increase its overall value.

So - "Information Management is Communication" - no its not. IM covers a lot more than this simplistic statement conveys, it is transformation of data into information in the first place (or maybe that should be out of scope?), the categorization, structuring, storing and retrieving of information, which may or may not include communication. Contextuality can be preserved by providing metadata and linking to other contextual information (or data sources). As for "IM is there to help people 'talk' to each other" again this is too simplistic and vague. Does 'talking' involve decision making? In an organizational context, IM should be about informing decision makers, providing them with as much information as possible to make informed business, technical or investment decisions. In my experience we often get a lot of talking, but no 'action' (remember the old BT adverts - "it's good to talk" - well yes it is, as long as there is an actionable outcome !)

This leads us back to DIKW, Data -> Information -> Knowledge -> Wisdom. I believe good information management is an absolute necessity for a knowledge management enabled organization.

A part of IM is often 'content management' and as I noted earlier, we have internally been discussing the definitions of content, and I include this in this post, because again I appear to differ in my opinions from Joe (although at the end of the day, is it just semantics ?)

Joe suggests in 'The truth about content' post that content is a nebulous concept, one that surrounds data, information and knowledge. However now its my turn to offer a more simplistic approach. I consider content to be "unstructured information" as opposed to "structured information".

Structured information is that which can be built up from data in a structured manner, synonymous to the rows and columns of a database, for example that which is kept in RDBMS based applications such as a CRM. It is information and not simply a collection of data because it can include many data points from different data sets, metadata and other contextuallising elements brought together and processed to "paint a picture" of me as a customer.

Unstructured information is that contained within words, pictures, sounds, various possible computer file formats, but information which does not sit well in a construct of rows and columns. This might be stored in in Email archive (Outlook .PST hell anyone?), a shared area on a LAN, or in a 'content management' system. Within the category of 'content' we can have sub-categories such as:

• Documents (text in SGML, .txt, X/HTML, PDF, MS Office, XML and various other formats)
  
• Digital Assets ('rich media', images, videos, audio files etc)
  
• Records (any content which is evidence of a business transaction)
  
• Web content (any of the above to be 'published' to the web....)

Each category spawns its own 'management' system - so we have Electronic Document and Records Management Systems (EDRMS), Digital Asset Management Systems (DAMS), Web Content Management Systems (WCMS) etc.... the acronym soup is endless ! Some vendors will tell you they sell "Enterprise Content Management Systems" (ECMS) which manage all unstructured information - but I prefer to think of ECM as a strategy, rather than a single product.

For the sake of our discussion at work, I tried to capture this into a single (and thus not all encompassing) diagram:

Click on the diagram for a bigger more readable rendition.

Of course nothing ever stands still and all definitions can change, grow, be edited to fit the context etc. Technology also runs ahead at a good pace, and thus blurs the lines. Surely if your text is in an XML 'document' then it is in fact 'structured' information (as in Structured Authoring) even though it is stored in a file system by the CMS (which in turn is storing all the Metadata in a database.......). So while I may not agree with Joe on his definition of content, it is a minor thing, but to my fellow members of the TIMAF group, I just can't reconcile myself to that basic principle :-(