Using Collaboration Products

Occasionally I get a problem that is so ornery that I have to write. This particular problem is a professional one rather than an academic one. It's about getting people to actually use collaborative products. Now, I know a lot about various collaboration products and a great deal about how people actually use information and--more importantly--imbed that information into artefacts like documents. But I have a problem. I suspect that if I tackle this problem head-on it will squirt out the sides of my focus. Instead, I've elected to eschew the research note format and tackle this one in the backwater of my blog. The blogger UI offers the type of unassuming editor that's ideal for knuckling through these kinds of ornery questions. So with a bit of Arcade Fire for accompaniment...


Can you build a collaboration environment and have nobody come? Absolutely. In several cases I've heard of people have implemented SharePoint in their organization in order to foster collaboration. They have found that either the product doesn't get used or that it gets used only for document management (in an odd twist that I'm sure has firms like Open Text and Documentum scratching their heads). So the question becomes: if you have collaboration tools--we'll use SharePoint as an example--how do you get people to use it?

I suppose the first place to start is to draw up the terms of engagement. What do actually know at this point? Collaboration is about the interaction of three different things: 1. people, 2. systems, and 3. information. I'm going to work from the bottom of this list to the top.

Information. As I've written before, "information" is a loaded word and really not appropriate in many circumstance. It is a holder word that always points to something else. Information is just an ambiguous cloud with semiotic pointers to other things. These things can be either documents or activities, real things. People use information simply as a means of getting from one place to another or as a means of completing a task. A project focussed on simply collecting information is doomed to failure since it lacks the practical grounding of documents and tasks. Perhaps the easiest approach is to focus on documents (explaining the upsurge in document management). The second approach is focusing on tasks (explaining the increasing popularity of BPM... whatever it means).

The issue with tasks is that the real work of a knowledge worker may not be directly mapped to those business process maps so loved by managers. Real work is not a flow diagram. Sure, general abstractions and legal sign-off points may be part of task completion but knowledge workers are bricoleurs who must forage and glean to complete their tasks. In many ways, the stringent processes established by a bureaucracy serve as hedges to enclose pastures of information and vectors of innovation. We can think of the systematic failures of initiatives such as automating aircraft control operators. Real work processes are too organic for systems to contain.

So far I've taken a very academic approach to this question. But the question for operators is what to do about it. The first step is to perform some sort of knowledge audit. What documents do people actually look for? What tasks to they actually need to complete? From this perspective, the Human Information Behaviour (HIB) literature is a good starting point. We can extend Dervin's model of "stops" and "gaps" to provide a taxonomy of terms to shape the discussion. Furthermore, the micro-moment time-line approach could also be a good method for extracting information. Instead of asking: "What information do you use?" ask "What was the last problem you had at work? How did you solve it?"

Technology. Collaboration systems are great things, particularly if they actually get used. Technologies aren't inert elements of an environment. They have a very real impact on organizations and individuals. In short, technology structures how individuals interpret the world and work with it. This structuring in turn, perpetuates or locks in that perception and use. But technologies aren't just about affordances. They are also about limitations. And these limitations also have an impact on how people use the technology. Again, I'm falling into a lot of academic talk (or "greek-fed polysyllabic bullshit" in the words of recently deceased Clifford Geertz).

So what does this mean to a practitioner? Well, the system has already baked certain perceptions into itself. People may be using the technology for exactly what it has been designed to do but are not using it for what it wasn't designed for. So... how to design a technology that supports the not-yet knowable? Just how can the technology be sufficiently organic to do what the operators want? I'm not sure yet.

People. And now, on to people who are--obviously--the most important element of a collaboration tool. Without people collaboration just doesn't happen. People are very dubious elements in any kind of process flow diagram (perhaps I could use the process flow diagram as a tool for articulating these concepts). So what profiles of information users are there in business? I just don't know. I can, however, make some assumptions and guesses. And then maybe I can find the regressions... or not.

1. Sand baggers. People who are just using the tools to do their jobs. They are nine-to-fivers just trying to get their jobs done. The current system is good enough. They are not interested in providing feedback to the designers and they may not be motivated to do so. If there is nothing in the professional development plan nor in their compensation plan then why should they bother?
2. Power users. These individuals are recognized for having very particular skills. They have attained either social status through the use of intellectual potlatches or perhaps through a managerial sanctioned "power user" role. They may be tasked with responding to questions in a public format but much of their interaction is based on informal relationships and physical presence. Many of the skills they seek to inculcate may be tacit rather than explicit in nature. Power users should be encouraged to share the knowledge in public forums.
3. Babblers. Certain individuals have a propensity to provide information but it may be of limited value to the organization. They may even be reprimanded for internal spamming. The enthusiasm of these individuals should be recognized since their inputs may act as nuclei for additional input.
4. Snipers. The individuals most prone to respond negatively to the input of babblers is the sniper. Their actions should be censured through management intervention. Snipers have an important role in providing constructive feedback. Destructive input, however, shuts down group dynamics within a collaborative environment.

Some questions that need to be addressed:

1. How does the organization define collaboration? What are the organizational goals and ambitions and what is the intended interaction of people, technology, and information. Is collaboration simply a catch phrase for "other things that we're not doing."
2. How do people work now? What are their biggest problems?
3. What are the starting points? Community abhors a vacuum. Content must flow from something else. The nuclei could be existing documents--although the feedback often occurs in the context of track changes. Other starting points may come from publishing common problems or even war stories (although most companies don't have a corporate bard). Avoid the "my pet cat" scenario.
3. Can the power users be converted?
4. Can the snipers be controlled?
5. Can the sand baggers be encouraged?
7. Who are the super-stars?