Jan 19 2011
- 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?
In my first post in this series, I introduced you “Jane” and a true story about her missteps when implementing popular social networking technologies within her organisation. We then asked some deep and ponderous questions, before meeting Robot Barbie and the crazy world of SharePoint Robot Barbie solutions. Finally I outlined a simple mental model that I developed that I have found to be quite a useful method to look at collaboration more holistically and help with the user engagement and information architecture aspects of SharePoint governance.
Now before we start, I want to make a four points to pre-empt the type of replies that I anticipate from putting this model out there.
- Kailash once told me that the problem with models is that their creators fall in love with them. They forget that they exist to help us to understand the reality around us, but this doesn’t make them reality. For that reason, I do not love my model and see lots of flaws. I also look forward to seeing better ones that people come up with. The key point is this: No model can ever capture the total sum of variables combine to make a collaborative situation look or feel a certain way, all it can do is approximate. This is my attempt at approximation.
- Imagine watching the Matrix movies without the car chases or kung-fu. It would be long, full of nonsensical dialogue and you would come out saying “I have no idea was that all about”. Mental models are a little like that too. This model is designed to be simple and explainable within 2 minutes. Any concept that takes more than a beer to explain will forever be in the realm of academia and get little real-world use.
- Some people (particularly scientist types), will look at a matrix like mine and automatically think that is measuring something. This is because there is an X and Y axis and usually, their presence indicates two variables that can have a range of values. In my case though, I was not thinking about an axis in that way. I just saw that each of the facets identified (task vs trait and social vs transactional) seem to me to be the extreme ends of an axis that I as yet, have not worked out . The point is, matrixes don’t always work for these people and they tend to avoid drawing quadrants with explicit lines because of the implicit suggestion that a situation falls into one quadrant or another. If you are of this persuasion feel free to develop it in a way that works for you. I think when we hit part 3, you will see that I use the model in different ways.
- Remember that this model is about collaboration. By definition, this involves more than 1 person. I was not thinking of individual people when putting it together. It assumes a bunch of people interacting and each facet I guess, highlights a dominant collaborative trait.
So let’s examine each facet in turn
Task Based Collaboration (Outcome driven)
Task based collaboration is typically characterised by short(ish)-term groups, comprised of people with a shared goal or common outcome (i.e. a "project”). The membership of a task based group is typically fairly diverse because it is the outcome drives the members’ attention and participation. Members are chosen because of their ability to play a part in achieving the outcome and it is not necessarily true that they have a say in that outcome.
The dominant characteristic of a task based collaborative group is that members do not necessarily have shared interests beyond the outcome being delivered. A SharePoint project team is a good example of this, because of the multidisciplinary skill set required to deliver it. Outside of that project, people may have vastly different interests and skills, and may have nothing in common beyond the outcome being sought. Some organisations are like this, where the people you work with you do not necessarily have any social interaction with beyond the interactions required to get the job done.
When you look at the matrix below, the top and bottom left quadrants are therefore driven by outcome. (i.e. getting something done).
Trait Based Collaboration (Interest Driven)
Trait based collaboration is comprised of users who are related through shared traits or long-term interests. As I stated in the first post, members may not be consciously collaborating on the same task or outcome, but may be highly likely to repeat or augment tasks already accomplished by other group members. Therefore, trait based groups tend to come together to share their learning and experiences. It is the shared interest that drives the members’ attention and participation. There is no deadline as such, or a specific task being shared among the group.
Examples of trait based groups are special interest groups (fans of a particular musical group) and occupational groups (via job role or even department). When you think about it, Facebook is the mother of all trait based collaborative platforms because members almost overwhelmingly are there connect with people who have a shared trait of some fashion. Also consider a community driven site like NothingButSharePoint or a conference such as SharePoint Best Practices. Both are excellent examples of trait based collaborative scenarios. We use these collaborative environments to gain insight and learning from sharing experiences with like-minded individuals.
When you look at the matrix below, the top and bottom right quadrants are therefore driven by interest.
Transactional Based Collaboration (Process Driven)
Transactional collaboration takes the form of a business process where various people or groups interact to get something done. In this scenario, inputs and outputs are fairly well defined and the process is repetitive by nature. Think of airport baggage handling as a great example. This is a process that has to be run efficiently and consistently. As a traveller, I want baggage handlers to be making sure my suitcase is on the right flight. I don’t want them all sitting on say, Yammer or MSN to co-ordinate the delivery of baggage. But I sure as tell want them to be able to tell me the status of my bag pretty much instantly.
One interesting characteristic of transactional based collaboration is that the people in the process can often be “swapped out” with other people, because transactional process is designed to be well defined, optimised and easy to follow consistently. It is the process that drives the members’ attention and participation, and governs the interaction between participants.
As stated in part 1, another characteristic of transactional collaboration is that it is usually not a place of spontaneity. Consistency is key to success and processes are designed to run with a minimum of variation and margin for error. As a result, this is the sort of stuff that well defined business rules, metadata and rule-based workflows handle well.
When you look at the matrix below, the left and right bottom quadrants are therefore driven by the process that governs the collaboration.
Social Based Collaboration (Insight Driven)
Social based collaboration is an interesting one. Truth be told, I knew that this one would have the greatest connotations because of the wildly different interpretations of the word social. From the point of view of my model, I offer the following explanation.
Social collaboration is the other extreme of transactional. This is usually characterised by more ad-hoc sharing of perspectives and information. It is realisation or insight through pattern sensing via group interaction, rather than structured business rules. It looks beyond the process and attempts to get to the ‘big picture’ of an issue, problem or constellation of problems.
Therefore social collaboration cannot really be a predefined interaction in the transactional sense. It is not a structured workflow, a rule or something with well defined inputs. But it is the place where tacit knowledge creation, development and exchange typically occurs. It is where hard decisions sometimes have to be made and where innovation tends to come from because it is the shared insight that drives the members’ attention and participation. It is the world of wisdom of the crowds – collaboration in all its messy glory.
As a simple example of what I mean, even the best business process modelling guru will never be able to document the process a board of directors would go through when performing strategic decision making. If for example, someone worked out the business process diagram that would tell any organization how to develop the next iPod or to master the stock market, then we wouldn’t marvel at Steve Jobs sixth sense for product delivery or Warren Buffets ability to consistently out-perform the market.
Therefore in the matrix below, the two top quadrants are therefore driven by the insight gained from the collaboration.
Hopefully after that explanation, each of the quadrants start to make more sense. The facets of collaboration can be summarised as follows:
- Task: Because the outcome drives the members’ attention and participation
- Trait: Because the interest drives the members’ attention and participation
- Transactional: Because the process drives the members’ attention and participation
- Social: Because the shared insight drives the members’ attention and participation
In the next post, we will use this simple model to examine several common scenarios and see what insight we can glean from looking at collaborative tools and situations through this lens.
Thanks for reading
- The facets of collaboration part 5: It’s all Gen-Y’s fault – or is it? (0.500)
- Seattle is go! SharePoint Governance and Information Architecture class (0.500)
- Confessions of a (post) SharePoint architect: Black belt platitude kung-fu (0.500)
- A different kind of SharePoint Governance Master Class in London and Dublin (0.435)
- More SharePoint Governance, Information Architecture and *Sensemaking* Classes Planned (0.435)