Groupware and social dynamics: Eight challenges for developers

Citation: Jonathan Grudin (1994) Groupware and social dynamics: Eight challenges for developers. Commun. ACM (RSS)
DOI (original publisher): 10.1145/175222.175230
Semantic Scholar (metadata): 10.1145/175222.175230
Sci-Hub (fulltext): 10.1145/175222.175230
Internet Archive Scholar (search for fulltext): Groupware and social dynamics: Eight challenges for developers
Tagged:

Summary

Published in the same year as Grudin's Computer-supported cooperative work: History and focus, Grudin's article opens with a similar version of the diagram used in that article.

He adds by suggesting that IS tends to be custom-written software built almost as a service while CSCW has struggled in part because of its different business models that has focused on off-the-shelf software. More importantly though, he points out that groupware has suffered in part because it has many of the problems that single-user applications suffer from in terms of usability issues, plus a whole set of new challenges introduced by the group-based nature of the tools. As the subtitle implies, his article focuses on eight of these problems.

1. A work versus benefit disparity: Groupware systems often require work from people who do not benefit directly from them (e.g., people adding data to a calendaring system so that the person doing the scheduling can benefit)
2. Critical mass and prisoner dilemma problems: Groupware cannot succeed unless a larger number of people use it at the same time and this creates a collective action problem.
3. Social, political and motivational issues: Groupware violate social and organization taboos or threaten political structures that existing in an organization.
4. Exception handled issues: Improvization and error handling common in organizations (see Suchman's (1983) Office procedure as practical action: Models of work and system design) are not built into workflow based groupware systems.
5. Unobtrusive accessibility: Often the features that support group processes are not used frequently but must still be accessible enough to be used.
6. Difficult of evaluation: We have trouble learning from failed groupware projects do to a lack of evaluation routines.
7. Failure of intuition: Intuitions in current software development environments are often poorly suited (or run against) the best actions in a groupware setting.
8. The adoption process: Introduction can require more care, planning, and effort that most software developers consider.

There are a series of reoccurring possible solutions as well that Grudin suggests:

1. The biggest is to add groupware functionality to existing applications.
2. Find and exploit niches were groupware is already succeeding.
3. Build on top of existing, successful, Is projects.
4. Build systems so that they benefit all members.
5. Do a better job of educating managers and developers about groupware.
6. Build a better (sociological) understanding of the decision-making processes in organizations to help design groupware better.

Theoretical and Practical Relevance

Grudin's article has been cited more tahn 100 times in the 16 years since it was published.