Collaboration: what makes a project a candidate for collaboration?
One of the questions facing us as information professionals is, when do we collaborate, and when do we work alone? In some cases, we won’t have the choice. Some external force, perhaps a manager or funding agency, will tell us we have to collaborate. In other circumstances a new task brings with it the question, “do I tackle this on my own, or should I seek out collaborators and approach the problem as a collective?”
The rule for deciding when a project is good candidate for collaboration can be formulated in economic terms: one collaborates when the benefits outweigh the costs of doing so. Such a model is deceptively simple, because costs or benefits can be hard to measure, subjective, or intangible. Costs and benefits can accrue on multiple axes, with costs in one dimension being compensated for by benefits on another dimensions. The personality of the prospective collaborator is a key factor, especially in artistic productions and academic research. (King and Snell provide an in-depth description of process of screening and selecting collaborators in the natural sciences). Except in certain highly structured settings, I suspect most people use a heuristic approach rather than a formal cost calculation when deciding whether to collaborate, with the decision being highly influenced by personal experiences and prejudices about collaboration.
Mary Frank Fox and Catherine Faver divide the costs of collaboration into process costs and outcome costs. Process costs are incurred in the ongoing operation of the process, and in particular of maintaining a team, with its required channels of communication and transactions (costs which may be measured in time, money, or emotional wear and tear on the participants). Outcome costs refer to any reduction in the value of the final product relative to the value that would have been realized without collaboration. Examples of outcome costs include a team of scientists who let themselves be “scooped” by a rival investigator, or a wiki page that is unreadable because of differences in objectives and writing style among the authors.
One type of process cost occurs from the diminishing returns of adding additional members to a team, as Frederick P. Brooks illustrates in his classic book on software engineering, The Mythical Man Month. When knowledge workers are added to a project, the contribution per worker decreases and in some cases becomes negative as time spent on communication and coordination outweighs the contribution of the new additions to the group. This situation becomes exacerbated when people joining the project must master a new body of highly specific or technical knowledge before they can contribute to the project, which means each prospective collaborators have a lengthy period of learning in which their peers have to dedicate time to mentoring them.
Thus one has to weigh the network effect (where the value of the network increases with the number of connections) against the costs of those connections, and the potential of interference effects (as for example, having so many cooks in the kitchen at one time that they are tipping over each other’s sauce pans and blocking access to the refrigerator). Collaboration is most effective when the task can be partitioned into sub-tasks, or when the team members have complementary, rather than redundant, skills (see again King and Snell)..
Web 2.0 applications tilt the balance in favour of collaboration; they lower the cost of participation and widen the pool (mixed metaphor) of potential collaborators. However, there are still likely to be tasks where sustained, concentrated effort by a single person is the most effective approach.
Sometimes an organization may choose to undertake a project in a collaborative model, and deliberately incur extra costs or delays in doing so, because of longer term objectives. For example, the organization may have goals such as:
- fostering a culture of collaboration within the organization
- building teams that will be expected to work together on other projects in the future, and will be able to profit from the experiences gained and relationships build whiled working on the initial project
- building a feeling of ownership in the end product (for example, a tool or process), by including the end users in the development
- obtaining funding by including participants from a potential funding agency
- engaging the clientele of an organization as participants, to retain loyalty, increase mindshare, or recruit brand ambassadors
Works cited
Brooks, F. 1975. The Mythical Man-Month: Essays on Software Engineering. New York: Addison-Wesley
Fox, M. F., & Faver, C. A. (1984). “Independence and cooperation in research: The motivations and costs of collaboration.” The Journal of Higher Education, 55(3), 347-359.
King, Z. & Snell. S. (2008). Knowledge Workers and Collaboration: the HR Agenda. Paper for the Centre for Strategic Management and Globalization’s mini-conference on HRM, Knowledge Processes and Organizational Performance. Retrieved from http://www.printedelectronics.net/documents/CBSconferenceKingSnell.pdf 1 August 2011.