The facets of collaboration Part 3–The feature jigsaw

• The facets of collaboration Part 1–Meet robot barbie
• The facets of collaboration Part 2–Enter the matrix!
• The facets of collaboration Part 3-The feature jigsaw
• The facets of collaboration Part 4 – BPM vs. HPM
• The facets of collaboration Part 5 – It’s all Gen-Y’s fault – or is it?

Hi all and welcome to part three of my series on unpacking this mysterious phenomenon known as collaboration. In case you missed the first two articles (and I highly suggest that you read part 1 and part 2), I spent some 500 odd hours last year developing a SharePoint Governance and Information Architecture course. Amongst the sweat and tears of that particular endeavour, I researched many papers and online articles that attempt to look at the multitude of factors and variables that impact on collaborative scenarios where SharePoint might be leveraged. I also talked about Robot-Barbie, which represents the tendency for SharePoint features to be combined in such a way where the benefit gained is much less than the potential of the individual parts. Robot-Barbie solutions are to be avoided at all costs.

In part 2, I explained each of the facets using the model above, identifying four key facets for collaborative facets: Task, Trait, Social and Transactional.

An interesting use of the facet diagram is to plot where various tools and technologies are located and therefore, where their strengths may be. In this article, we will go through some of SharePoint’s collaborative components and see how they fit together.

The document is dead – long live wikis?

When I have asked people to draw where Wikipedia lies on the facets, the most common answer by far is on the trait side of the collaborative fence. This seems relatively straightforward. After all, the authors of Wikipedia articles obviously have a shared interest in the topic matter. Without an interest in the topic, there would be little incentive to take the time to write about it. Furthermore with Wikipedia, authors are highly unlikely to be working on the same project or task, since the author can be anybody in the world. But, authors are likely to be performing similar tasks in their respective organisations. A classic trait based scenario.

Wikis also are open and essentially unstructured, relying on authors to link to other content to build contextual relevance. By this logic, Wikipedia is a strong trait based collaborative system and the dominant process driving the use of the tool is insight more than process. Therefore wikis are socially oriented more than transactional. I would suggest that very few Wikipedia authors indeed would be driven by a process that mandating they update an entry.

Closer to SharePoint home, Look at the success of SPDevWiki as another example. If you were to plot it across the spectrum (and remember this is about collaboration using the tool, not individual use), it would appear in a similar position on the model to Wikipedia. People use SpDevWiki because they wish to develop and contribute to a repository of knowledge to help others in similar situations. This reciprocal behaviour serves to help the individual in their own endeavours.

But there is an interesting change if I ask people to simply draw “a wiki” on the model, rather than the specific example of Wikipedia (the mother of all wikis). The model tends to look something like the image below. Suddenly the scope of wikis expands more into transactional, but few people draw a wiki across the whole collaboration spectrum. As a result of this pattern, one question I make a point of asking people in all of my classes is whether they have ever seen or used a successful project management wiki. I have asked this question in London, New Zealand and around Australia, and the overwhelming answer is no. One respondent stated that his organisation had implemented a project management wiki, but conceded that he was the only one who maintained it.

The reason I continually ask this question is that I wanted to know if the pattern I had observed was common, as I can only base observation from my own client base. Using my clients, I have seen two occasions where wikis were particularly successful. The first was a wiki for programmers who worked for the same company and the second was a school, where teachers maintained a wiki as part of a SharePoint solution that we put in. Both of these examples are clearly trait dominant in that the authors were in a very similar role. Perhaps a gross generalisation is that wiki’s are best suited to trait/social based collaborative scenarios? If so, it raises an important issue. If a task based collaboration effort has a varied mix of participants, then using the model suggests a wiki may not necessarily be the way to go.

By the way, I have learned over the years that as soon as you make an assertion to rightness, someone will come along and prove you wrong. For example, I strongly advise people not to use the Microsoft pizza/pie diagram to introduce SharePoint to new users, but Ruven Gotz proves that it is perfectly acceptable to do so. Therefore in the example above I am only reporting on my observations, plus feedback from those who have attended my classes. I am not trying to prove right or wrong here as I know many will disagree with the diagram. But what I am interested in, if you can prove the assertion wrong, is what you did to make a wiki successful in the other quadrants?

Wikis vs. Custom lists

In typical SharePoint fashion, there is always ten ways to do something, each with their own pros and cons. Both wikis and SharePoint lists are flexible information repositories, that differ by the degree of structure imposed. Lists offer the creation of custom columns of different kinds, that allow tables of information to be stored and via the use of views, to make sense of the content. You get a few other niceties like datasheet view, attaching files, and export to Excel/MSAccess. In fact, many people like to adopt lists because they previously used Excel for storing information and Sharepoint offers similar functionality with improved data entry and multi-user support.

Someone once told me that more critical corporate data is stored in excel than any other database system in the world. I am not surprised in the slightest.

When asked to place where SharePoint lists fit on the facets model, many users tend to link it to transactional based collaboration that is equally task or trait based. Lists it seems, are well suited to tracking “stuff”, which lends itself naturally to transactional collaboration where process tends to govern interaction.

Lists also tend to need more up-front work where a wiki usually does not. Before content can be effectively added to a list, you need to define columns or content types in advance and hope that you get it right. Information Architects routinely get paid to help do this. Remember that transactional collaboration is the world of well-defined inputs, because process governs the interaction. As such, project delivery (a transactional/task oriented process) often uses list based techniques because of the improved ability to track, slice and dice information, when compared to a wiki. Dux Sy’s book on using SharePoint for Project Management is a good illustration of this approach. Wiki’s do not even get mentioned in Dux’s book. Why is this? Perhaps the tracking of time, resources, costs, risks, constraints and work performed is best delivered via lists? Certainly, more fully fledged PMIS systems like Microsoft Project Server are highly database driven and designed for transactional work.

It is then quite interesting to overlay SharePoint lists and wiki’s together. Is it possible to make a more educated call as to when one option is more suited than the other? Take a knowledgebase scenario which could easily be either a wiki or a list. Perhaps the decision as to use wiki or list should be based on the nature of the collaboration? If a bunch of people linked by trait are creating a knowledge repository, a wiki is a proven approach – Wikipedia shows this to be the case. But if this is for say, a more transactional scenario such as a call-center, where KPI’s are based around quick turnaround and resolution of common problems, a list approach might be better?

At this point I can feel the heat of offended Enterprise 2.0 fanboys. Please understand, I am not anti wiki’s or anything 2.0 – we use these tools in our practice. Furthermore SharePoint blurs the above distinction anyway. Columns can be added to wikis and they leverage SharePoint’s version history too. In other words, you can make a wiki look and feel somewhat like a list. Furthermore, SharePoint wikis can be integrated with information management policies and workflow. When you add those additional capabilities to the mix, you might draw things differently. Nevertheless, I think this is a useful exercise because it might offer insight as to why certain portal features rarely, if ever get used in certain situations.

Document Collaboration – Transactional or Social?

Finally for now, document based collaboration seems to fit into any quadrant (and is therefore quite tricky at times). This is because the “document” is simply a medium of collaboration (as is a wiki for that matter).

For one extreme, take the example of a quality management system (policies, procedures, manuals). Given that a QMS is usually part of a compliance regime, requiring audits and demonstrated conformance, document collaboration is fairly rule-based and managed via well defined and understood process. Therefore, we are talking transactional work. In this world, SharePoint features like content types, metadata, policies and workflow are fairly easy to define and implement.

But a QMS, via policies and procedures, guide the behaviour and decision making in organisations. So while transactional, it is oriented towards trait based. This is because a QMS is rarely installed to deliver a single project, but to guide delivery of many projects. One thing that might be guided by a QMS is the creation of a legal contract that outlines the scope and responsibilities of two parties undertaking a project. Documents such as contracts, while also usually transactional, are task based they outline a legal commitment to achieving an agreed outcome.

Contrast this with a team collaborating via documents. A team can be driven by an outcome or common interest (department) and as a result covers both the task and trait based quadrants. Often the rules of engagement are much less rigid or formalised with regards to document use and structure. Thus, a lot of team document collaboration is more social and trying to fit this into an overly strict or complex taxonomy can do more harm than good. I noticed with great interest that recently, certain SharePoint elephants in the room are starting to be named. The recent articles on NothingButSharePoint entitled “SharePoint Content Types: Is this a lost cause?”, highlights what I mean. In this article, repeated attempts were made to try and harness the value and power of content types into a large enterprise. However despite the effort, they were rarely used.

To me, this highlights the characteristic of team collaboration – particularly knowledge workers. If collaboration is not a predefined interaction, then content types, which by definition, force us to go to a lot of effort to define inputs when those inputs are not necessarily known. Perhaps the nature of the collaboration taking place played a part in the lack of take-up reported in the aforementioned article? Those who advocate metadata as the only true solution may in fact be pushing a transactional paradigm onto a collaborative model that is ill-suited?

As a general rule, in transactional scenarios, the classification of the document is of more importance than the content of the document. This is the records management and compliance paradigm, where the fact that the document is controlled is the key driver. However, in team collaborative scenarios, the content of the document is usually more important than the metadata classifying it. From a team members point of view, metadata that helps to indicate content is more important than metadata that indicates compliance.

As documents age however, the value of the content tends to diminish and the value of the classification increases. Balancing the need for compliance against the need for collaboration is a key document management challenge irrespective of the tools and systems that underpin it. There is a large smackdown looming between the worlds of compliance vs. the world of government and enterprise 2.0 and I will eventually write on that topic.

Once again, the key point here is context. Some document oriented collaborative scenarios are highly structured and well suited to well-defined taxonomy and metadata. Others are somewhat less so. Perhaps a tool like this helps to work out when certain information architecture decisions are applicable when it comes to document collaboration?

Conclusion

You might have noticed that this post has more questions than answers. In doing a model, I never said I would provide more answers. Instead, more of a frame or perspective to ask certain types of questions that many SharePoint practitioners have increasingly be asking (as evidenced by the content type post above). In the next post, I will conclude by using the facets to examine several common arguments seen in organisations, where people in particular roles are in effect, predisposed to having a bias in one or more of these facets. We will also look at SharePoint as a whole, as well as examine what we can glean about user engagement and buy-in.

Until then, thanks for reading.

Paul Culmsee

www.sevensigma.com.au