1 Groupware and social dynamics : Eight challenges for developers Jonathan Grudin Why groupware applications fail: Problems in design and evaluation Jonathan Grudin Why groupware succeeds: Discretion or mandate Jonathan Grudin & Leysia Palen Social, individual & Technological issues for groupware calendar systems Leysia Palen

2 Groupware? l Applications that support interaction within groups of two or more people. (examples: electronic mail, co-authorship, video conferencing, voice annotation programs.) l Does not refer to major systems designed to support entire organizations. (examples: Manufacturing and order-and-inventory –control systems.)

3 Position of groupware in application space Single-user application Supports individuals Off the Shelf Mixed reactions. Use is discretionary. (Designed for discretionary users.) Groupware application Supports groups. Tailored to individual settings. Likelihood of mixed reactions by group members. Only moderate upper management support is available. Large Infor- mation system Supports organizations. Huge expectations Built or tailored to a specific setting. Lot of users, not all of whom may like or benefit from IS. Strong upper management support is crucial to adoption.

4 Multi-user systems and Multi-user applications. l Multi-user system = hardware + software. l Multi-user application = software. l The system has a higher cost, visibility and stronger commitment of upper management. l  high collective benefit is recognized  new jobs may be created to ensure success  pressure from management is high. l The much cheaper application program provides uncertain collective benefit and won’t have the same degree of management support. l  Application must fit into existing work patterns and appeal all people needed to support it.

5 Groupware and social dynamic: Eight challenges for developers 1. Work - benefit -disparity 2. Gaining critical mass 3. Social, political and motivational factors 4. Exception handling in workgroups 5. Designing for infrequently used features 6. Evaluation difficulties 7. Breakdown of intuitive decision-making 8. Acceptance managing

6 1. Disparity between who does the work and who gets the benefit A groupware application rarely provides the same benefit to every group member. Most groupware requires some people to do additional work. A traditional method of coping is to create new jobs or redesign existing jobs. Groupware applications will not have recources to change job requirements as much as when entrire systems are installed. Educating all users to the collective benefit may create willingness to do the work. Those hired with an understanding of new work requirements will be less uncomfortable with them than those living through the change. (code documentation)

7 1. Disparity between who does the work and who gets the benefit example: Automatic meeting scheduling l Concept: The person scheduling a meeting specifies a distribution list and the system finds a time that is convient for all. l Everyone must maintain a personal calendar l Everyone must be willing to let computer schedule their free time. (”Free time” is rarely really free.) l Benefits the person who calls the meeting. l Subordinates are required to do the additional work.

8 1. Disparity between who does the work and who gets the benefit Other examples: 1) voice annotations to documents (-listener +speaker) 2) project management (-group member +manager) Addressing the problem: 1) Create benefits for all group members 2) Demonstrate collective benefits 3) Reduce the work required (very difficult)

9 l Most groupware is only usefull if a high percentage of group members use it. l If everyone acts to further their personal interest, the result is worse not only for the group but also for each individual (example: db freeloaders) l Examples: 1) organisation-wide voice messaging system 2) meeting scheduling l Addressing the problem: 1) reduce work required of all users 2) build incentives for use 3) emphasize individual and collective benefits 2. Critical mass and prisoner’s dilemma problems.

10 3. Social, political and motivational factors. Actions of group members are (often unconsciously) guided by social conventions and awareness of personalities and unspoken priorities of other people. Unless information is made explicit, groupware will be insensitive to it. (Example: Managers’ ”free time” is rarely really free.) Groupware may be resisted if it interferes with the substle and complex social dynamics common to groups. (example: Groupware may erode authority structures.) Addressing the problem: 1) Recognize the magnitude of a problem and avoiding the common assumption of a ”rational” work environment. 2) Gain sophisticated understanding of users’ workplaces.

11 4. Exception handling in workgroups Improvisation and wide range of error and exception handling are characteristic of human activity. Many short-cuts and modifications are made by workers to procedures defined in the handbook.  The way things are supposed to work is different than the way they actually do work It is difficult to identify actual, standard procedures. Addressing the problem: 1) Avoid supporting rational ”myths”, learn how work is actually done. 2) Provide flexibility, software tailoring (difficult)

12 5. Designing for infrequently used features. People exaggerate the importance and frequency of the objects and events that they focus on.  For a groupware designer, every situation calls out for communication or coordination support. Groupware functions are however used less frequently than features supporting individual work.  Groupware features will fare better if integrated with features that support individual activity. (favourite authoring tool co-authoring tools)  Infrequently used groupware features must not obstruct more frequently used features, yet they must be known and accessible to users.

13 6. The underestimated difficulty of evaluating groupware. Multi-user application’s success is affected also by the backgrounds or personalities of other group members. Lab situations cannot reliably capture the complex social, motivational and political dynamics that affect use of groupware applications. Evaluation of groupware last longer. (Group interaction unfold over days or weeks.) Groupware evaluation methods are less precise. These obstacles to meaningful, generalizable analysis and evaluation makes it difficult to learn from experience. Addressing the problem: Include skills of social psychology and anthropology in groupware developement environments.

14 7. The breakdown of intuitive decision-making Decisions to develop unworkable groupware application are frequent. Why is that? Most product developement experience is based on single-user applications for which intuition can be more reliable guide. Decision-makers are drawn to applications that selectively benefit one subset of users: managers. Unwelcome extra work that is required of some users is underestimated. Addressing the problem: 1) Understand fallibility of intuition. 2) Set emphasis on user involvement in developement.

15 8. Managing acceptance l Groupware is very sensitive to aspects of it’s introduction. (example: Single user application that is liked by one of five can be a great success, groupware application however would be a big disaster.) l Identify group’s real problems (and actual work procedures) and match the computer solution to it. l Select appropriate pilot groups and individuals. (Systems can fail if placed on executive desks if secretaries or professionals are more appropriate.) l Ensure support from management. (Educate managers about groupware and risks involved.) l Prevent premature rejection by anticipating and dealing quickly with early problems. l Build support for adoption into the product itselft. (example: Consulting support & Lotus Notes)

16 Why groupware succeeds: Discretion or mandate? Interview study of recently adopted on-line meeting schedulers. l Participants: Microsoft Corporation, Sun Microsystems l Meeting schedulers were rejected 10 years ago but now they are widely used. l Microsoft developement division were observed for 3 months. Five interviews were made. Based on these, set of 40 questions were created and used in 12 interviews during 3-day period at Sun. l Purpose: Identify possible success factors.

17 Why groupware succeeds? Factors contributing to successful groupware adoption: l Organization-wide infrastructure l Functionality l Versatility and ease of access l Peer pressure

18 Why groupware succeeds? Infrastructure l Employees are networked l Strong technical support in installing and maintaining the software is provided l People are much more comfortable with technology Functionality l Applications are more mature (example: privacy options) l Strongly integrated with and desktop environments.

19 Why groupware succeeds? Versatility and ease of access l Tasks can be carried out multiple ways. l Features are easily accessed. Peer pressure l Refusing causes frustration in peers  pressure. l The application design can itself contribute to social pressure. (example: Integration to .)

20 Interview study of on-line meeting schedulers adopted recently. Conclusions l Groupware can succeed without mandated use if helped by the congenial functionality and interface features associated with discretionary use applications. l Critical mass of users may be attracted by features that provide individual benefits (e.g. meeting reminders) l After critical mass is acchieved social pressure by peers and others extends use. l Mandated use can also lead to or faciliate adoption of groupware.

21 Groupware Calendar Systems? l Online-calendars that can be shared accross network. l Individual users keep their calendars online and allow various degree of access (open, restricted, closed model) l Nonperson entities may own a calendar (conference rooms) l Collaboration is supported by simple sharing or viewing of other people’s calendars or by sending invitiations thgough the CGS.

22 Perspectives to GCS l Single user demands l Interpersonal communication l Socio-technical evolution

23 Single user demands l Temporal orientation –Determining day, month and year. l Scheduling (advanced planning) –Managing competing requirements, priorities and constraints. l Tracking –Recording present events for reference later. l Reminding –Reminding of future events. (recurring dates, related to-do) l Note recording / Archiving –meeting notes, product information, etc to associate them with a particular point in time for possible retrieval in the future. l Retrieval & Recall –Temporal association of information assists in retrieval and recall.

24 Interpersonal communication l Privacy concerns about information-based content –Personal privacy of information (example: medical appointments) –Social sensitivity (example: internal job interview) –Company security (example: appointment with other company) l Privacy concerns about time-based content –Personal privacy of time allocation (example: peer judgement about the quality of time) –Control of access to time (Control of scheduling own time) l Managing privacy –Access settings, cryptic & context-sensitive entries, omissions, scheduling defensively

25 Interpersonal communication l Reciprocity plays a critical role in GCS use. People are strongly influenced by what others are doing around them. (Willingness to keep open calendar is based on the security of knowing that everyone else keeps their calendard open too.) –Openess allows making determinations about schedules --> reduced interruptions and negotiations. l Beyond meeting arranging –Locating someone & assessing availibility –Meeting verification –Information retrieval (location of meetings) –Organizational learning –Synchronization

26 Socio-technical evolution l Technological constraints of CGS can affect use on large scale. l Viability of CGS depends on reasonable consonance with the organizational culture. l Decisions about technology’s early design arise out of social context. (example: open calendar model and organization culture) l New conditions of the changing environment put restrictions on what the technology could do, which has direct impact on the technology design (example: Removing execute-command when organization grows.)

27 Convergent perpectives