I received this today and I had to post it. In New Zealand recently, Paul McTaggart of Gen-i stopped me and complimented the governance and information architecture course that some of his staff have attended. I am truly humbled by the feedback that he just sent through…

Practical, relevant and seriously funny: These attributes are seldom seen together in a training session.

However, Paul Culmsee has practical, real world experience having worked on complex (wicked) projects which provides him with the background and understanding of what works and why.

Discover the immutable f-laws of SharePoint projects. Cry and laugh when you identify the reality of you own organizational platitudes, but breathe a sigh of relief when you see that there is a way out and that SharePoint Governance and Information Architecture can be achieved with everyone sharing the same understanding of where you are now and where you are trying to get to.

Paul also supports you new found realization of what needs to be done by providing you with the guidance, tools and methods that you can take from the classroom and apply to your complex (wicked) problem projects to make them work.

Basically it is all about people (gaining shared understanding), process (knowing how to get from here to there) and then the technology (SharePoint).

My team now uses the concept of shared understanding and the tools that the Governance and Information Architecture Class has provided to get customers “on page” before we design and code in SharePoint land.

Paul McTaggart

ECM Business Manager

Gen-i a division of Telecom New Zealand

Thanks for reading

Paul Culmsee

 

• 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

Hi all

Welcome to another exploration of the collaborative world through a lens called the facets of collaboration. If you are joining us for the first time, I am writing a series of posts that looks at how our perception of collaboration influences our penchant for certain collaborative tools and approaches. SharePoint, given that it is touted as a collaboration platform, inevitably results in consultants never being able to give a straight answer. This is because SharePoint is so feature-rich (and as a result caveat-rich), that there are always fifty different ways a situation can be approached. Add the fact that many clients do not necessarily know what they want and learn about their problem by examining potential solutions, we have all the hallmarks of a wicked problem in the making.

These wicked problems, underpinning SharePoint, often results in Robot Barbie situations (cue the image to the left), which is the metaphor that I started this series with. Robot Barbie represents everything wrong about SharePoint deployments, as it is symptomatic of throwing features at a platitude, pretending to be solving a real problem and then wondering why the result doesn’t gel at all. It is a pattern of behaviour that is similar to an observation made by the very wise (and profane) Ted Dziuba who once spoke these words of wisdom.

If there’s one thing all engineers love to do, it’s create APIs. It’s so awesome because you can draw on a white board and feel like you put in a good day’s work, despite having solved no real, actual problems. Web 2.0 engineers, in addition to their intrinsic love of APIs, have a real hard-on for anything having to do with a social network. For example, developing a Facebook application lets them call their shitty little PHP program an "application" running on a "platform," like a real, live computer programmer does. Make-believe time is so much fun, even for adults.

Apart from making me giggle, Dziuba may have a point. Elsewhere on this blog I have spent time explaining that there are different types of problems that require different approaches to solving them (wicked vs. tame). My conjecture is that collaboration itself is exactly the same in this regard. People who espouse a particular type of tool or approach as the utopian solution to collaboration are taking a one size fits all approach to a multifaceted area and even worse, treating that area as a platitude. Anyone who calls themselves an Information Architect and doesn’t at least give cursory examination to the dimensions or facets of collaboration is likely to be doing their stakeholders a disservice.

All of us have certain biases, and I am no exception. For a start, I am generation X – the so-called cynical generation. Apparently we whinge and whine about everything and then blame it all on generation-Y. Thus, if cynicism is the gen-X stereotype, then I will happily accept being the poster child. I mean seriously, all of you vanity obsessed, self interested generation y’ers, if you spend a little less time preening and more time thinking, we might get some wisdom out of you (see – I am such a cynical gen-X right now).

So let’s recap the facets of collaboration. The model I came up with identifies four major facets for collaborative work: Task, Trait, Social and Transactional.

• 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 last post, I used the model to examine the notion of Business Process Management versus Human Process Management and looked at some of the claims and counter claims made by proponents of each. This time let’s up the ante and talk about something curlier. We will examine the notion that social networking in the enterprise is the answer to improving collaboration within the enterprise. On first thought, it makes perfect sense, given the incredible success of Facebook, LinkedIn and Twitter. Nevertheless, there is ongoing debate about the use and value of social tools in the enterprise driven by their rise outside of organisational contexts. One particularly strongly worded quote is from Aaron Fulkerson, co-founder and CEO of MindTouch who doesn’t mince his words:

This class of software forces business users to adopt the myopic social visions imagined by the developers, which are nearly identical to their corresponding consumer web implementations. In short, social software is not solving business problems. In fact, these applications only serve to treat symptoms of the problems businesses face. They exacerbate the real problems within businesses by creating distractions and, worse, proliferate more disconnected data and application silos.

Ouch! Even within the SharePoint community there is significant variation of opinions as to the value of social. While I better protect the innocent and not name names, I have spoken with several well known SharePointers who think social is a giant waste of time, versus those who see real value in it. Irrespective of your opinion, you cannot ignore the fact that social is a significant game changer with effects still being felt. While web 2.0 has dropped off the Gartner hype cycle, its effect on particular sectors has been far reaching. Now it seems that all sectors have a 2.0 on the end of their name. For example:

• Enterprise 2.0
• Education 2.0
• Legal 2.0
• Government 2.0

Clearly, if things were just a flash in the pan, why are governments around the world trying to revitalise their public sector by utilising these tools?

Look at Microsoft as another example. They have, I think smartly, recognised industry trends and reacted to them via the introduction of a number of new SharePoint features, such as tagging/folksonomy via managed metadata, ratings columns, enhanced wiki capabilities and a significant investment in the capabilities of my-sites. Their clients now have the option to leverage these features should they choose to do so.

So just as there are naysayers, there are the pundits. Many people cite the reasoning that these features are necessary to attract and retain the next generation of workers, who have grown up with these tools in their personal lives. Whether this claim is valid is debatable, but I have to say, I really like the Enterprise 2.0 slide deck below by Scott Gavin for a number of reasons. I think it encapsulates the 2.0 vision, underpinned by social/cloud technologies very nicely. I sometimes ask people to discuss this slide deck in my IA classes and discussion is equally polarising as social networking in the enterprise itself. Some people think it represents the vision for the future, and others think it is hopelessly idealistic and doesn’t reflect cold, hard reality. Take a look for yourself below…

And the survey says…

Using the facets quadrants, we can start to see patterns for success of these tools for the enterprise and whether Aaron Fulkerson’s argument has merit or whether Scott Gavin is on the right track. An interesting use of the facet diagram is to plot where various tools and technologies are located. in my classes, I ask people to plot where Facebook belongs on facets diagram. Guess where it is usually drawn? 

While some people will draw Facebook at various levels on the vertical axis, everyone pretty much describes Facebook (and LinkedIn)  as trait based, while being highly dominant on the social quadrant. As discussed in the last article, if I ask people to plot a crowdsourced tool like Wikipedia, the dominant characteristic is always trait/social. In other words, people maintain and update Wikipedia articles because of their interest in the topic area, not because it helps them get something done.

Clearly, big social networking technologies are successful in the "trait based social” quadrant. In other words, we tend to use Facebook more for common interest collaboration than to solve a task based collaborative issue (such as deliver a project). Another interesting thing about a lot of social networking technologies is that for many, our work-based collaborative life tends to be more task based, compared to our non-work which is more trait based. In other words, for a lot of us, our work life revolves around working with a group of people for a common outcome and if it was not for that common outcome, we wouldn’t necessarily have much in common (I risk falling victim to my own generalisation here – so I will come back to this later in the section titled “Why User Buy-In Is Hard”).

When you look at where Facebook sits in the quadrant, it begs the question of how well this type of tool (or the building blocks it is based on) would work in an organisation that is project (task) based and highly transactional. To that end, consider a project management information system, such as the basic one that Dux espouses in his book or the more complex one that Microsoft sell to organisations. Where do you think it belongs on the quadrant?

When I ask people to plot their project management information system, I typically get this response:

I speculate that the further away two tools lie on the spectrum, the more likely we are to have a robot-barbie solution if you blindly mix features that work well in each individual quadrant. The wiki argument I made in part 3 seems to support this contention. If you recall, in part 3 of this series, I mentioned that I ask every attendee of my classes if they had ever seen a successful project management wiki.  Irrespective of the location of the class, the answer was pretty much “no”. I noted that where I had seen successful wikis tended to be where the users of the wiki were linked by strong traits.

Looking Deeper

While that is interesting, I think the facets diagram tells you more than it intends. Obviously, it is clear that these project management systems such as MS Project Server are oriented toward task/transactional (“getting things done”) aspect of project delivery (ie, time, cost, scope, budget and the like). While some people might point to this and say “there you go – I told you all that social crap was a waste of time – bloody gen-Y and their social networking hubris”, I feel this is naive. If task based transactional tools are sufficient, then why do so many projects fail?

I have stated many times on this blog that shared commitment to a course of action requires shared understanding of the problem at hand. The act of aligning a team to project goals and developing this shared understanding is the realm of the task/social quadrant (the top left), where insights and outcomes come together. When I ask people to name tools that live in this space, few can name anything. Obviously, most project management systems are devoid here. Worst still, we subsequently delude ourselves to thinking that shared understanding can come from a few platitudinal paragraphs labelled as a “problem statement”.

Social networking pundits implicitly recognise this issue (and frequently butt heads against command and control type project managers as a result). But i feel they make the mistake in applying a one size fits all approach to collaboration and apply trait based tools as a panacea when they are not wholly appropriate. The social tools seem to fit exceptionally well into the top right quadrant, but not in the top left.

In fact the only tools that spring to mind that belong in the top left category are the sensemaking tools that my company practice, such as Dialogue Mapping.

Where’s the proof, Paul?

So I guess I am arguing that using social tools because they are the “choice of the new generation” ignores a few home truths about the nature of these tools versus the nature of organisational life. Just because Microsoft provide the tools for you, tells you that they are hedging their bets rather than having any more insight than you or me. So to test all of this, let’s use the facets model in a different way to back up some of my observations and suggestions in this post. Guess what happens when I ask people to plot SharePoint itself on the facets map?

When I asked SharePoint practitioners to do this, they initially drew SharePoint 2007 as a circle over the entire model. Once they did so, they would very often adjust the drawing to emphasise transactional over social collaboration as shown below.

 

When practitioners were asked to draw SharePoint 2010, they usually indicated a higher representation in in the two social quadrants, but favoured the trait based social over task based social as shown below.

What was interesting about this experiment is that very few people drew SharePoint over the entire facets of collaboration. Social collaboration with SharePoint it seems, only stretches so far. This leads me onto more conjecture, and now we get to the bit in the post where we name a giant SharePoint elephant in the room.

Structured tools for social collaboration?

Many collaborative tools purport themselves as operating in the social space. SharePoint 2010 clearly does so, principally due to the Managed Metadata service, pimped MySites with tagging/rating capabilities. But SharePoint’s core heritage is database/metadata driven, document based collaboration. If we go back to our definition of social collaboration as dynamic, unstructured, with sharing of perspectives and insight through pattern sensing, then social collaboration is clearly not a predefined interaction.

Yet, database driven tools like SharePoint, and its building blocks like site columns and content types require considerable up-front planning to install and govern. Many, many inputs need to be well defined and furthermore, unless you have learnt through living the pain of things like content type definitions in declarative CAML, SharePoint buildings blocks are difficult to maintain/change over time. SharePoint suffers from a problem of reduced resiliency over time in that the more you customise it to suit your ends, the less flexible it gets. In the case of social collaboration the problem is worse because we are trying design for outputs where the inputs are not controlled. Trying to turn something that is inherently organic and emergent to something that has an X and Y on it may be misfocused and destined to fail in many circumstances. The realm of well-defined inputs is the realm of transactional collaboration, where workflow and business process management thrive and change is much more controlled before SharePoint ever gets a look in.

SharePoint excels at transactional scenarios as this is its heritage – after all, the majority of its feature set is oriented to transactional collaboration. The fact that people are prepared to draw SharePoint as dominating across across the transactional half of the facets diagram illustrates this.

But this raises interesting, if not slightly heretical question. If we need to use information architects to get a collaborative tool deployed for social collaboration (to get those inputs defined), then are we pushing the solution into the transactional side of the fence? Recall that in part 3 of this series, I looked at document collaboration and noted that when asked to draw team based document collaboration, people typically drew it operating in the social half of the matrix (pasted below for reference). I also noted in part 3 that for team based collaboration, rules and process are much less rigid or formalised with regards to document use and structure. I then referred to a recent NothingbutSharePoint article where a large organisation’s attempts to introduce the usage of content types largely failed. Like the seeming lack of success of wiki’s for task based collaboration, maybe content types simply are not the ideal construct as you move up the Y axis from transactional to social?

Now do not assume that I am anti metadata/content types here as this is not the case at all. Content types rock when it comes to search and surfacing of related information across a site collection (and beyond if you use search web parts). What I am calling out is the fact that if the SharePoint constructs that we have at our disposal were the panacea for social collaboration, where are the best practices that tell us how to leverage them for success? Perhaps the nature of the collaboration taking place plays a part in the lack of take-up reported in the aforementioned article? Those who advocate highly structured metadata as the only true solution may in fact be pushing a transactional paradigm onto a collaborative model that is ill-suited to it?

The knowledge worker paradox – one of the reasons why user buy-in is hard

Finally for now I’d like to cover one more aspect to this issue. Last year, one of my students looked at the facets and said “Now I know why my users aren’t seeing the value that I see in SharePoint”. When I asked him why, he explained:

“Many of my users are transactional and governed by process – that’s their KPI. Here I am as a knowledge worker, seeing all of these great collaborative features, but I am not judged by a process or transaction. I don’t live in that world. I forget that someone whose performance is judged by process consistency is not going to get all excited by a wiki or tagging or a blog.”

I call this the knowledge worker paradox and it is reminiscent of what I said in part 4 where we looked at BPM vs. HPM. Each role on an organisation is multifaceted. For many roles, there is varying degrees of transactional work taking place. Accordingly some people are very much process driven just as much as they are social driven. Gross generalisations that make statements that “80% of people are knowledge workers or perform knowledge work” do not help matters. In fact they serve to feed the one size fits all mentality that has proven to be detrimental to projects when people fail to recognise that some projects have wicked aspects.

SharePoint people are almost always knowledge workers. Thus if you, as a knowledge worker who is rarely governed by transactional process, think that you have the vision to prescribe a SharePoint driven meta-utopia to meet transactional needs without having lived that world, then if your results are not what you hoped for then to me its hardly surprising.  My student in this case realised that he had been approaching his user base the wrong way. Like Jane in part 1, he did not take into account the dominant facets of collaboration for the roles that he was trying to sell SharePoint into.

When you think about it, the whole argument around records management versus collaborative document management is in effect, an argument between a transactional oriented approach, versus a social oriented one. It is the same pattern as BPM vs. HPM. In records management, the paradigm is that management of the record is more important than the content of the record. Furthermore, that record shouldn’t change. Yet with team based document collaboration, without content there is no document as such and furthermore, the document will change frequently and require less strict controls to grease the gears of collaboration.

Both records oriented people and social pundits commonly make the same mistake of my student, where they force their dominant paradigm on everyone else.

Conclusion

Food for thought, eh?

This is probably my last facets of collaboration post for a while. It is one of these series of articles that I feel has value, but I know it won’t be read by too many 🙂 Nevertheless, I do hope that anyone who has gotten this far through has gotten some value from this examination and sees value in the model to help users make more informed Information Architecture decisions for SharePoint and beyond. I certainly use it now in most engagements and hope that it can be improved upon as a tool, or somehow incorporated into some of the SharePoint standards or maturity model stuff that is out there.

Remember the most important thing of all though. Despite all I have said, it is still definitely all generation y’s fault!

Thanks for reading

 

Paul Culmsee

www.sevensigma.com.au

 

• 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 four of my series on unpacking this buzzword phenomenon that is “collaboration”. Like it or not, Collaboration is a word that is very in-vogue right now. I see it being used all over the place, particularly as a by-product of the success of x2.0 tools and technologies. Yet if you do your research, most of the values being espoused actually hark back to the 1950’s and even earlier. (More on that topic in my forthcoming Beyond Best Practices book).

As it happens, Dilbert is quite a useful buzzword KPI. Once a buzzword graces a Scott Adams cartoon, you know that it has officially made it – as shown below:

So back to business! Way back in the first article, I introduced you to Robot Barbie, a metaphor that represents all of those horrid SharePoint sites remind you of a cross-dressing Frankenstein’s monster. I had an early experience with a client who championed a particular vision for a SharePoint project, only to find little buy-in within the organisation for that vision. This, and a bunch of other things, got me interested in the softer areas of SharePoint governance, where no tried and tested best practices really exist. If they did and were so obvious, Microsoft would published them as its in their interest to do so.

This all culminated in when I wrote a SharePoint Governance and Information Architecture training course last year. I read a lot of material where authors attempted to unpack what collaboration actually meant. My rationale for doing so would be to hopefully avoid creating SharePoint solutions that were Robot-Barbie Frankensteins. The model that I came up with is illustrated below:

The basic model is covered in detail in part 2. But to recap here is the basic summary: This model identifies four major facets for collaborative work: Task, Trait, Social and Transactional.

• 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 last post, I used the model to compare and contrast the use of particular SharePoint features, such as wikis, SharePoint lists and the different aspects of document collaboration. With regards to the latter of these three, I l looked at the effectiveness of certain SharePoint building blocks like content types and site columns within the different facets.

In this post and the next, we will use the facets in a different manner. We will take a quick tour through some common philosophical smackdowns that manifest in organisational life. These smackdowns emanate because of the different viewpoints that people with particular job titles and respective bodies of knowledge have.

Any suggestion that a philosophy might be wrong or incomplete often calls into question the self-identify of the practitioner, which causes much angst among adherents. For this reason, I will leave the “agile is great” vs. “agile sucks” debate for another time, because if you search the internet for criticisms of agile you tend see really passionate programmers get all riled up and flame the hell out of you.

Instead, I will start with a relatively easy one…

Business Process Management v.s. Human Process Management

What does painting the Golden Gate Bridge and Business Process Management have in common? With both, you find that by the time you get to the end, you need to go back to the beginning again. I have personally seen organisations fill an office full of people and take literally years to define and then document key processes all in the name of various best practice frameworks or a regulatory requirement. They then find that, once a thick process manual is created, no-one actually follows it unless an auditor is watching or their performance-based remuneration is directly measured by adherence to it. Of course, I’m not the only one to notice this. In fact, the entire discipline of business process management has taken a bit of a battering in recent years.

If we consider a “process” as the means by which we convert inputs of some description into outputs, Business Process Management has long been the discipline that concerns itself with process optimisation. But in a pattern that is seen in all disciplines like Project Management and Business Analysis, someone will inevitably come along, tell you that you have it wrong or are not being “holistic” and invent a new term to account for your wrongness. In the case of BPM, we now have people arguing for various terms: such as Human Interaction Management, Human Centric Business Process Management, Non-Linear Business Process (thanks Sadie!) or Human Process Management. We will use the latter term, but they are essentially talking about the same thing.

So before we see an example Human Process Management (HPM), let’s review Business Process Management and see what the HPM fanboys are whining about.

Business Process Management

BPM is a structured approach to analyse and continually improve and optimise process activities. Process structure and flow are modelled via diagrammatic tools, allowing organizations to abstract business process from technology infrastructure and organisational departmental/jurisdictional boundaries. This abstracted view allows business to holistically examine process and increase their efficiency and respond rapidly to changing circumstances. This in turn creates competitive advantage.

BPM is often used within the broader context of process improvement methodologies such as Six Sigma (which if you have never read about it, will finally prove to you that all that high-school mathematics that you found mind-numbingly boring was actually useful). While BPM on its own provides excellent visibility of process via modelling them, Six Sigma also incorporates additional analytical tools to solve difficult and complex process problems. Thus, BPM and Six Sigma augment each-other, because process improvement efforts can be more focused via BPM modelling. Thomas Gomez, in an article entitled “The Marriage of BPM and Six Sigma", had the following to say:

“Without BPM, Six Sigma may flounder because executives lack the critical data needed to focus their efforts. Instead, the executives bounce all over the place looking for performance weaknesses, or they focus on areas where successful performance improvements provide only marginal results. With BPM, Six Sigma projects can pinpoint problems and address the underlying causes.”

But that is where the fun ends according to the BPM critics. BPM nerds have had to suffer the indignation of hurtful labels like “Sick Sigma” and stories of long term problems with innovation because of such initiatives. They cite examples such as  George Buckley of 3M, who wound back many of his predecessor’s Six Sigma initiatives.

"Invention is by its very nature a disorderly process. You can’t put a Six Sigma process into that area and say, well, I’m getting behind on invention, so I’m going to schedule myself for three good ideas on Wednesday and two on Friday. That’s NOT how creativity works."

Ouch! Its enough to make a BPM feel all flustered and defensive of their craft. Nevertheless the above quote echoes the main points made by BPM critics. That many processes are not structured, predictable or logical and therefore, BPM approaches force a structured paradigm when none necessarily exists (Mind you, many other methodologies do precisely the same). In an appropriately titled article “The H-Bomb of Business Processes: Humans”, Ayal Steiner makes a point that also cuts to the heart of tame vs wicked problems debate too.

“The modern idea of BPM stresses a well-defined business process as the starting point but this is not always the case. Therefore, in a project that involves new practices or a cross-functional learning among participants, BPM has always had a tough time dealing with the humans.”

The notion of the well-defined starting or ending point is one of the characteristics of a tame problem. Wicked problems are often characterised by poorly defined staring and ending points. In fact with a wicked problem, often participants cannot agree on what the problem is in the first place!

Critics like Steiner also argue that many roles within an organisation, tend to deal with more tacit, dynamic situations and as such spend a large amount of their work time performing collaborative human work, when compared to transactional business process work (knowledge workers is the prevailing label for this type of role). While the main area of benefit for BPM’s is its ability to increase the efficiency of a core business process, the sort of thinking required to re-think processes in a systematic manner involves collaboration and systems thinking (in other words, beyond the process in front of us and how it interacts and interrelates more broadly since the whole of the broader system is greater than the sum of its parts). This is a human-driven activity as it is based on humans collaborating and innovating.

Closer to SharePoint home, Sadie Van Buren noted this same distinction in May 2010 which was around the same time I started the development of my IA class.

Human Process Management

So if BPM is incomplete, enter Human Process Management (HPM). HPM is concerned with process that is not easily defined, nor well structured, where it is hard to prescribe the execution of the process based on some model of the business. With human process, it is generally known how to achieve an intended result, but each case is handled separately and requires tacit judgment (for both decisions and flow) as part of the process. There is not enough standardization between instances of the process that allows for a formal, complete and rigorous description of the process end-to-end.

The obvious downside of human processes, say the critics, is that they are far too fluid and dynamic to be made part of an Enterprise BPM system. As a result, these processes tend to be handled through email, which in turn contributes to information overload and poor information worker productivity – precisely why we look to tools like SharePoint in the first place! The implication of HPM is that we need to shift emphasis to tools and practices that help us deal with unstructured or ad-hoc processes (and the information created/used during that process) more so than tools that deal with the well-defined world of BPM.

To be fair to the BPM crowd, these above criticisms will be seen by BPM practitioners as naive, since from their point of view, the less structured side is simply a part of the entire BPM spectrum. They argue that critics do not properly understand the principles and philosophy of BPM in the first place (Agile and PMBOK defenders say essentially the same thing when defending from critics). Supporting this counterargument is a key theme for BPM success that is regularly emphasised. That is, the critical pre-requisite of clarity of purpose and shared understanding of the end in mind. Mohamed Zairi, in a paper called “Business process management: a boundaryless approach to modern competitiveness” stated:

“The achievement of a BPM culture depends very much on the establishment of total alignment to corporate goals and having every employee’s efforts focused on adding value to the end customer.”

Therefore the BPM crowd are arguing for the same human process that HPM base their criticism on. Developing a culture of alignment to corporate goals is very much a human process. Are the HPM fanboy criticisms well founded or is it more a case that some BPM guys forget about strategic goal alignment and optimise process in isolation?

What do the facets say?

Clearly, there is a natural tension between these two polarities of BPM and HPM and this often plays out in organisational life in how we collaborate to deliver organisational outcomes. While there have always been process nazis, the emergence of social collaboration platforms that do not have a great deal of formal structure (think tagging and folksonomies) has led to a great deal of debate and self examination in BPM circles and beyond. Understanding these traits is critically important on the use of SharePoint tools, because SharePoint – and in particular SP2010 offers features for both BPM and HPM aficionados. Putting the two together however might risk Robot Barbie scenarios.

Straight away, it seems that the transactional vs. social axis of the facets of collaboration neatly explain the Business Process Management (BPM)/Human Process Management (HPM) challenge. Both areas are concerned with producing an output or getting something done. Therefore I have drawn BPM and HPM leaning toward the task side of the model. HPM proponents argue that human process is unstructured or semi-structured, dynamic, intertwined and borderless, which fits in well with the task/social trait of process and insight. BPM naturally fits into the lower transactional half where inputs are well defined.

 

While I would agree with the assertion that many processes are ill-defined and rely on tacit knowledge to be completed, HPM proponents go further though. For example, Ayal Steiner who I quoted earlier, argues that “analysts are now realising that human processes account for 80% of the business processes carried out in most organisations”. That is a big call, in effect, arguing that the majority of workplace interactions occupy the social quadrants above. I disagree. From my experience, most organisational roles have extremely varying degrees of transactional vs. social collaboration and some roles are in fact dominated by transactional collaboration. Perhaps there is some confirmation bias going on here, where knowledge workers who put in collaborative systems tend to think that everyone are knowledge workers too.

Here is an example. Mrs CleverWorkarounds used to be a medical nurse. When I first showed her this model I asked her to describe where nurses would fit in terms of their collaboration. She indicated two areas.

• Firstly, nurses are strongly linked by trait and transaction. This is because they all have a minimum degree of knowledge and skill. As stated in part 2, the key tell-tale sign of a role with transactional collaboration is how easily individuals performing that role can be replaced by someone else with similar experience at short notice. Supporting this, if a nurse is sick or unavailable, a replacement nurse can be called in to perform the same tasks.  Collaboration between nurses according to Mrs Cleverworkarounds is quite transactional as well. Routine and process consistency via tracking the status of patient care is a critical task – patient status is everything. Thus, data driven tools with version history and well defined inputs make this form of collaboration easier. In fact, Mrs CleverWorkarounds taught herself InfoPath and SPD Workflows because she was so convinced that automated forms with consistent audit trails via workflow would make her job easier.
• Yet at the same time, the sort of collaboration between nurses and patients is completely different and highly social in nature. No process is going to govern the interaction between nurse and patient. The type of care and counselling to get someone well is going to vary the type of interaction. A broken leg is one thing, health problems from say – alcoholism is something else entirely. The latter has much deeper symptoms than just the illness as presented. Here the focus is on patient well-being and goes beyond status of meds, when doctors have visited or accurate handover notes from one nursing shift to another.

State machine workflows?

Interestingly, even seemingly well-defined business processes tend to have ad-hoc and dynamic aspects to them. When there is an exception to the standard process, those exceptions tend to be handled in a relatively ad-hoc, case-by-case manner. Microsoft developer Pravin Indurkar cited an example of a seemingly transactional purchase ordering system.

“Often the business processes contain a prescribed path to the end goal but then there are a lot of alternate ways the same goal can be achieved. For example, a purchase order can contain a prescribed path where the PO goes from being created, to approved, to shipped, and then to completed. But then there a multitude of other ways in which the PO can be completed. The PO can get changed, or back ordered or cancelled and then Reopened. All these paths must be accounted for.”

Indurkar studied the purchase order system of a small business and found that apart from the one standard traditional order fulfilment process, there were about 65 different variations on the same process depending on the nature of the order. This is when BPM diagrams start to get scary. If you think that this workflow below is scary, then be more scared. It is page 12 of a 136 page process!

Naturally, trying to hardwire such a large number of alternate paths is very difficult and traditionally, there were two ways in which this was dealt with;

• Either the business process was hard wired to accommodate all the paths as shown in figure 1, which made the implementation of the business process extremely complex, brittle and hard to maintain.
• The alternate paths are simply not dealt with and any situation of the ordinary was dealt outside the domain of the process. This meant that tracking and visibility were lost because people would create manual systems to track such out of the ordinary situations. The facet diagram below illustrates this:

In Indurkar’s article that I quoted with the purchase order example, he argued that the solution to this sort of problem was via state-based or state-machine workflows which SharePoint has supported in a basic fashion, out of the box since SP2007. This kind of workflow, if you are not aware, is when the workflow waits for one or more events to move it into another state. There is no sequence as such, because this new target state can be any of the defined states in the workflow. This makes state workflows reflect the unpredictable nature of process variations.

Thus, it could be argued that BPM is not incomplete as what the HPM fanboys think, but that critics have a less than holistic understanding of the craft?

Conclusion: A Process Analysis Tool…

To be honest, I don’t want to answer the question of which fanboy is right because it is a bit of a zero sum game. When you think about process, many seem to have elements of transactional and social in them (just like job roles). For example, an “Approval” decision diamond in a business process diagram will determine the path a process takes. Apart from stating the fact that this process is a gateway where a decision is made, this says nothing about whether the activity of making that decision is transactional or social. In some processes the decision may be made by a rigorous data driven process (like a point-score based credit check for a loan applicant). In others it may be on gut feel (such as choosing the right applicant for a job position).

So to me, whether you are the most regimented process nazi or the most cowboyish non-conformist hippie, modelling a business process according to its ratio of transactional to social facets is probably very useful indeed to complement a BPM model. It help us understand how much tacit judgement is required in a given process and whether modelling every variation in a sequential workflow is worthwhile. Check out some examples on how this could be done below. In first example on the left, a business process where the majority of the steps are performed by tacit judgement might look like something like how I have drawn, with a task based social dominance. If the process in question indeed looks like this, then attempting to document every minute variation on the paths the process can take might not be worthwhile. Perhaps documenting the broad process (within the constraints of any compliance regime requirements) might be a better idea. In the second example, the process seems to be oriented around a repeatable set of choices (task based transactional dominant). As a result it may be worthwhile formally documenting these variations.

 

By combining these “process diagnostics” with the actual diagram, we might now offer additional insights into how the organisation really works with a certain process and do crazy stuff like produce something akin to my mockup below:

Hell, throw in a RACI chart and now you start to see process accountabilities as well!

Of course, you could always remove the task/trait axis if it is not needed and simply use a sliding scale. Nevertheless, what this shows is that the facets of collaboration model offers an extra dimension to any process being modelled and would help many to better understand the nature of the process being modelled, as well as strategies for improving that process via SharePoint.

Thanks for reading

 

Paul Culmsee

www.sevensigma.com.au

p.s If you are a real trainspotter/glutton for punishment and want to dive deeper, google “Human Interaction Management” and “Role Activity Diagrams”

 

• 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.

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

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

 

• 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

I have a friend, lets call her Jane (not her real name), who was a huge web2.0 fan. Seriously, if it was a wiki, blog, tweet or anything remotely sounding like RSS, Jane would wax lyrical about how it was the answer to all that was wrong with the silos of the old world and if only people would get with this new paradigm and embrace the social revolution, collaboration within her organisation would markedly improve. After all, look at the popularity of sites like facebook, wikipedia and twitter. Jane also had a very strong vision for what this new world would look like and had spent a lot of time and money investing in customising SharePoint to meet this vision.

Much to Jane’s dismay, her project failed miserably. Her organisation ultimately wanted something much more boring – a solution to help them manage their files better. All of this “new-age gen Y social crap “ was of little interest to the masses.

Janes story is actually a very common pattern with SharePoint projects. As it happened, Jane had committed probably the most cardinal sin of information architecture. She had projected her ideals onto an organisation that did not necessarily subscribe to her view. Therefore SharePoint represented her vision and little else. Few others shared it and to this day I think she blames the culture organisation she worked for. I say that she did not do enough to develop a shared understanding of the problem, and shared envisioning of the solution.

Now most of us know that SharePoint can be a platform for going gung-ho social if you wish, given that it has features like wikis, blogs, folksonomy and RSS. But it can can also be a platform for structured business process via features like workflow, BCS, information management policies, content approvals and the like.

So that raises a really important question. Why is it that a particular collaboration feature (such as a wiki) might be total nirvana for one situation and can be a project killing fatal flaw in another? Since SharePoint has a ton of collaborative tools in its toolkit that can be rolled up in different ways, when do certain features work well together and when do they completely suck balls together? Why do some people have such wildly differing views on the nature of collaboration and what potential solutions should look like? Why do some people look at the SharePoint feature-set and say “meh”, while others are totally charmed by it?

This was a question worth pondering and I did look into this in some detail while I was creating my SharePoint 2010 Information Architecture course. In this short series of posts, I am going to introduce you to a way of looking at the wide spectrum of activities that all fall under the guise of this term called collaboration. This mental model seems to help paint a more realistic picture of the collaborative world than the simplistic views that Jane and her ilk use. It goes some way to many of the questions that I raised above. Furthermore, the model has been very well received at my courses. Maybe there is something to this?

Introducing “robot barbie” – the yardstick for SharePoint information architecture

Say hello to Robot Barbie, my all-time favourite SharePoint metaphor. I use this picture in all of my classes and talks, such is its persuasive power.

I first saw this picture via a talk that Joel Oleson gave. The story behind it was that Joel came across this very real toy in a market somewhere in Asia. When Joel asked the storekeeper what the idea was behind the toy, the reply he got was along the lines of:

“Well, boys like robots and girls like Barbie. Therefore, if we put Barbie’s head on a robot, then logically both boys and girls will like it.”

Hmm.

Now I don’t know about you, but I can’t see that boys and girls would suddenly drop their respective robots and Barbies and start playing with this ugly hybrid. In fact, when you look at the result, it is this bizarre, somewhat disturbing combination of features that brilliantly demonstrates the folly of taking two things that work really well alone and expecting that by combining them, things will work even better. Instead, we have a combination that is much less than the sum of its parts and unlikely to satisfy anybody.

Robot Barbie is a very powerful visual metaphor for SharePoint information architecture because SharePoint is full of Barbies and full of robots. In fact the global SharePoint information architecture mantra should be “avoid robot barbie”. To that end, when I show this image to clients or conference attendees, I ask them the question, “So is your SharePoint implementation a robot-barbie solution?”.

Many people will admit to varying degrees of robot-barbie. How then to avoid it?

Research into collaboration itself

The only SharePoint person I have met who goes to a university library to research more than me is Erica Toelle. In this section I am attempting to make her proud – hehe 🙂

Since these questions around collaboration came to me while I was developing an Information Architecture course, I became curious as to whether academics, authors or bloggers had ever actually attempted to deconstruct collaboration itself into its core elements (in effect, performing an information architecture exercise on collaboration itself). Surely understanding the some of these elements would help us gain some hints or insights into how collaboration works and in turn, help us avoid Robot Barbie?

So I hit the journals and did some digging. As it happened, some academic research had been undertaken over a long period of time, trying to codify this lofty ideal called collaboration. As expected, authors looked at the issue from various angles. Some looked at it through the lens of the type of conversation taking place, some via the nature of the problem solved, some through “business activities”, some via the characteristics of group doing the collaborating and others examining the underlying purpose that drove the collaboration in the first place.

Some of the more interesting writing that I examined in developing my own model included:

• A Taxonomy of collaboration in support of information seeking (Golovchinsky, Pickens, & Back, 2009)
• Three domains of problems (Talley, 2003)
• Know the Four Types of Conversations (Banathy & Jenlink, 2004)
• The Art of Focused Conversation: 100 Ways to Access Group Wisdom in the Workplace (ICA series) <- A great book I already owned
• Understanding Groups’ Properties as a Means of Improving Collaborative Search Systems (Ringel & Teevan, 2009)
• Beyond Document Collaboration (Hollis, 2007)

I read all of these papers in detail and then converted the arguments made by each into IBIS and created a single (admittedly very large) issue map to try and draw out any patterns from them. I would group all of the various concepts in the map together in different ways to try and elicit some sort of insight. This proved to be quite a frustrating process because of the various different ways each writer tackled the subject matter. The map was huge and I was at first, unable to find a pattern that worked for me. All of them seemed to have some interesting elements, but they all seemed incomplete or over-thought in some way.

In frustration, I gave up and slept on it. During the night my subconscious must have kept working to unscramble the map because the next morning, I had my model within a few minutes. I looked at the map again and saw a pattern immediately. It was in essence, a combination of some work by Chuck Hollis and interestingly, Microsoft Research (The last two of the above references).

Meredith Ringel Morris and Jaime Teevan of Microsoft research wrote a brilliant paper called “Understanding Groups’ Properties as a Means of Improving Collaborative Search Systems”. For the record, anyone that is looking to leverage user profile data via mysites should read it. In this paper, Morris and Teevan divide collaborative groups into trait or task, based around the longevity of a group. They also use group identification in the form of group membership being implicit or explicit. For my own purposes, the implicit vs. explicit membership of a group was not overly relevant so I discarded it. But I found the notion of trait and task based groups fascinating.

Morris and Teevan characterised task based groups as short term and comprised of people with a shared goal and working together to achieve that goal. (They are describing every project team right there). Trait based groups on the other hand were comprised of users who were related through shared traits of long term interests. Here was the quote that really made me sit up and take notice however. They also suggested that trait based “group members may not be consciously collaborating on the same task, but may be highly likely to repeat or augment tasks already accomplished by other group members” (Love it – they are describing every discussion forum right there).

So I had my first dimension of collaboration. Task vs trait.

In 2007 Chuck Hollis of EMC wrote a really insightful blog post entitled “Beyond Document Collaboration”, where recognised that via the advent of social media, organisational collaboration was changing and that “different collaboration models are emerging, each one with entirely different value propositions”. Hollis identified three such models and labelled them transactional collaboration, document collaboration and social collaboration.

Hollis described transactional collaboration as “workflow, or business process management, or something else” and was characterised by “humans are largely automatons; repetitively processing the output of one function for input by another function.  Not much spontaneous creativity interaction here, nor is it usually encouraged!”. Hollis then spoke of document collaboration and explicitly mentioned both Documentum and SharePoint. He finished with social collaboration, which he described as “It’s not predefined interaction.  It’s not a structured workflow.  It’s something entirely different than the other two collaboration models”.

After reading that post, I thought Hollis was definitely on to something but I felt his descriptions didn’t quite encompass what I was looking for. Like the Ringel/Teevan paper, I felt that elements of Hollis’s breakdown didn’t quite fit for me. After I had slept on it, it dawned on me that document collaboration was the odd one out. I liked his distinction between transactional and social collaboration, of structure and predictability versus a non predefined interaction because the social dimension to me was describing knowledge work. But document collaboration did not work for me at all. A document is simply a medium, as is a wiki or a forum. Structured, process driven collaboration can still use documents, and so can relatively unstructured social collaboration. They just use them in different ways. The same can also be said for whether the collaboration is task based (ie outcome driven) or trait based (interest driven).

So I discarded document based collaboration and in doing so had my second dimension.

Making a model

Out of all of the material that I researched, I found that these four dimensions or facets of collaboration (task, trait, transactional, social) helped me explain most collaborative scenarios and understand why Robot Barbie solutions occur. Of course, the great thing about distilling it down to four dimensions is that I then I got to do what academics live for. Make a 2*2 matrix!

Academics simply love doing this, because it helps them deal with over-analysing everything that moves and justify all that R&D that they do! :-). In all seriousness though, people love creating 2*2 or 3*3 matrixes to explain concepts for the simple reason that they make good mental models to help us understand reality. After all, one of the key purposes of information architecture itself is to help users create mental models of a site (“Don’t Make Me Think ”).

So here is my complete model. In part 2 I will explain how I use this model and the insights that it gives in preventing robot-barbie outcomes.

 

 

Thanks for reading

Paul Culmsee

www.sevensigma.com.au

Note: For those of you who do not wish to read my usual verbose writing, then skip to the last section where there is a free web part to download and try out.

Unless you are a complete SharePoint nerd and world events don’t interest you while you spend your hours in a darkened room playing with the SP2010 beta, you would no doubt be aware that one of the most significant collaborative events in the world is currently taking place.

The United Nations climate change conference in Copenhagen this month is one of the most important world gatherings of our time. You might wonder why, as a SharePoint centric blog, I am writing about this. The simple answer is that this conference in which the world will come together to negotiate and agree on one of the toughest wicked problems of our time. How to tackle international climate change in a coordinated global way. As I write this, things do not seem to be going so well :-(.

Climate change cuts to the heart of the wellbeing expected by every one of us. Whether you live in an affluent country or a developing nation, the stakes are high and the issues at hand are incredibly complex and tightly intertwined. It might all seem far away and out of sight/out of mind, but it is clear that we will all be affected by the outcomes for better and worse. The spectre of the diminishing window of opportunity to deal with this issue means that an unprecedented scale of international cooperation will be required to produce an outcome that can satisfy all stakeholders in an environmentally, economically and social bottom line.

Can it be done? For readers who are practitioners of SharePoint solutions, you should have an appreciation of the difficulty that a supposedly “collaborative tool” actually is to improve collaboration. Therefore, I want you to imagine your most difficult, dysfunctional project that you have ever encountered and just try and now multiply it by a million, gazzilion times. If there are ever lessons to be learned about effective collaboration among a large, diverse group on a hugely difficult issue, then surely it is this issue and this event.

Our contribution

My colleagues and I became interested in sense-making and collaboration on wicked problems some time back, and through the craft of Dialogue Mapping, we have had the opportunity to help diverse groups successfully work through some very challenging local issues. I need to make it clear that much of what we do in this area is far beyond SharePoint in terms of project difficulty, and in fact we often deal with non IT projects and problems that have significant social complexity.

Working with people like city planners, organisational psychologists, environmental scientists and community leaders to name a few, has rubbed off on myself and my colleagues. Through the sense-making process that we practice with these groups, we have started to see a glimpse of the world through their eyes. For me in particular, it has challenged my values, social conscience and changed the entire trajectory of where I thought my career would go. I feel that the experience has made me a much better practitioner of collaborative tools like SharePoint and I am a textbook case of the the notion that the key to improving in your own discipline, is to learn from people outside of it.

We have now become part of a global sense-making community, much like the global SharePoint community in a way. A group of diverse people that come together via common interest. To that end, my colleague at Seven Sigma, Chris Tomich has embarked on a wonderful initiative that I hope you may find of interest. He has enlisted the help of several world renowned sense-makers, such as Jeff Conklin of Cognexus and David Price of Debategraph, and created a site, http://www.copenhagensummitmap.org/, where we will attempt to create a global issue map of the various sessions and talks at the Copenhagen summit. The aim of this exercise is to try and help interested people cut through the fog of issues and understand the points of view of the participants. We are utilising IBIS, the grammar behind dialogue mapping, and the DebateGraph tool for the shared display.

How you can help

If you feel that issue mapping is for you, then I encourage you to sign up to Debategraph and help contribute to the Copenhagen debate by mapping the dialogue of the online sessions (which you can view from the site).

Otherwise, Chris has written a simple, free web part, specifically for Copenhagen which can be downloaded “Mapping tools” section of the Copenhagen site. The idea is that if you or your organisation wish to keep up with the latest information from the conference, then installing this web part onto your site, will allow all of your staff to see the Copenhagen debate unfold live via your SharePoint portal. Given that SharePoint is particularly powerful at surfacing data for business intelligence, think of this web part as a means to display global intelligence (or lack thereof, depending on your political view 🙂 ).

Installing is the usual process for a SharePoint solution file. Add the solution to central admin, deploy it to your web application of choice and then activate the site collection scoped feature called “Seven Sigma Debategraph Components”. The web part will be then available to add to a page layout or web part page.

The properties of this web part allow you some fine grained control over how the Debategraph map renders inside SharePoint. The default is to show the Debategraph stream view, which is a twitter style view of the recent updates as shown in the example below.

Stream view is not the only view available. Detail view is also very useful for rationale that has supplementary information, as shown in the example below.

By the way, you can use this web part to display any Debategraph debate – not just Copenhagen. The Debategraph map to display is also controlled via the web part properties.

For information on how to change the default map, then check out this webcast I recorded for the previous version here.

I hope that some of you find this web part of use and look forward to any feedback.

 

Kind regards

 

Paul Culmsee

www.sevensigma.com.au

I thought that this article was topical given that I am writing on how organisational culture and behavioural style impacts the sorts of collaborative tools that individuals and organisations gravitate to and find useful.

The reports cover 11 common Web 2.0 technologies that can potentially find value in the enterprise:

• microblogs,
• prediction markets,
• social networking,
• widgets,
• blogs,
• RSS feeds,
• wikis,
• forums,
• podcasts, and
• social bookmarks.

http://www.destinationcrm.com/Articles/CRM-News/Daily-News/Wikis-Grow,-Podcasts-and-Social-Bookmarking-Slow-51507.aspx

The short version for those who can’t be stuffed reading it?

• Microblogs – too early to tell
• Forums, Podcasts and Social Bookmarking are not seen as strategically valuable to enterprises.
• Wikis are popular and well adopted, blogs also popular (but less than wikis)
• Social networking tools are finding value in certain demographics but have not really taken off yet

Do readers agree with their conclusions?

I have to say that regarding forums, a lot of clients ask for them and many always seem to be blank 🙂