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
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.
- 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)
- 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.
- Social, political and motivational issues: Groupware violate social and organization taboos or threaten political structures that existing in an organization.
- 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.
- Unobtrusive accessibility: Often the features that support group processes are not used frequently but must still be accessible enough to be used.
- Difficult of evaluation: We have trouble learning from failed groupware projects do to a lack of evaluation routines.
- Failure of intuition: Intuitions in current software development environments are often poorly suited (or run against) the best actions in a groupware setting.
- 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:
- The biggest is to add groupware functionality to existing applications.
- Find and exploit niches were groupware is already succeeding.
- Build on top of existing, successful, Is projects.
- Build systems so that they benefit all members.
- Do a better job of educating managers and developers about groupware.
- 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.