Constraints for Developing Groupware and Obtaining User Acceptance

By Annette Haeussler, SAP AG – September 12, 2002

German version

Developers of groupware systems must take factors into account that extend beyond purely technical considerations: Legal, organizational, and, most especially, human and social aspects affect decisions as to which functionalities support human interaction best. This article is an abstract of my diploma thesis "Entwicklung eines Instant-Messenger-basierten Groupware-Systems zur Widerspiegelung des Online-Zustands (Awareness) anhand einer umfassenden Anforderungsanalyse für zeitlich und räumlich verteilte Ad-hoc-Gruppen (virtuelle Teams)" (development of an instant-messenger based groupware system to reflect the online state (awareness) based on a comprehensive requirement analysis for ad hoc groups separated geographically and located in different time zones (virtual teams)) and examines the conditions for user acceptance of groupware.

 

Conditions for Acceptance

The influence of a team member on the group and vice versa is characterized by two factors: the individual's perception of the behavior of the other group members and the group members' perception of his/her own behavior.

The participants in this behavioral and perception process seek or modify shared norms and values. A team undergoes three phases in the course of this development process. The first phase consists of orientation (collecting information and inputting it into the overall effort), followed by an evaluation phase (discussion and negotiation aimed at improvements) and finally the control phase (adapting and regulating personal behavior) [Bal50].

"If individuals see themselves as being a group then a group exists." (R. Bales [Bal50])

The shared norms and values of a group that regulate its members' social behavior toward one another and which are regarded as accepted behavioral norms may be different or less pronounced in electronic communications than in the real world. They are, however, always present in any interpersonal contacts and must be taken into consideration in developing systems to support collaborative computing, because the introduction of new technologies and processes into groups affects the existing relationship, perception, and power reproduction processes [Her01].

Grudin examined these challenges for the developers of groupware applications and described them as follows [Gru94].

Individual Group Requirements

Applications are still developed from time to time that prove to be virtually unusable. This has nothing to do with the design of the applications, but is due to the fact that the developers of the groupware do not know enough about a team's work processes. A groupware application must be tailored to the team's individual requirements and work processes.

Work processes can usually be described in two ways: the way things are supposed to work and the way they do work. Individuals can perform tasks in different ways. They can optimize their work processes based on experience. They can respond flexibly to unusual situations and errors. It is very difficult to transfer these features to a groupware application because electronic systems need to be based on "standard processes".

The challenge is to adapt groupware to the way people work instead of expecting people to adapt to the way groupware works.

Social and Politically Motivated Behavior

A groupware application must make allowance for social and politically motivated behavior. It is difficult to map the subtle and complex social structures of human interaction to computers, whose main purpose is to process data. Often unconsciously, our actions are guided by social conventions and by our awareness of the personalities and priorities of people around us.

If a manager's electronic calendar contains time that seems to be open it doesn't necessarily mean that other people can schedule appointments in that time without permission. If the system is misused in this way it will automatically be rejected. A priority-based appointment scheduling function will create similar problems, because who is going to admit in public that some of their meetings have low priority?

It is therefore essential to take the human factor into consideration as far as possible when designing groupware tools.

The Disparity Between Who Does the Work and Who Gets the Benefit

A groupware application never provides precisely the same benefit to every group member. Costs and benefits depend on preferences, prior experience, roles, and assignments. Most groupware requires some people to do additional work to enter or process information that the application requires or produces A groupware application is expected to provide a collective benefit; ideally, everyone benefits individually, but this ideal is rarely realized.

An automatic meeting-scheduling feature is useful for people who have to organize meetings, typically a manager or a secretary. But for the feature to work efficiently, everyone in the group must maintain a personal calendar. The system can only function provided they keep their calendars up to date. This is the reason why e-mail has met with such universal acceptance: Users benefit directly from the application.

The challenge of rendering a groupware system attractive to all its users lies in keeping the effort involved in maintaining the system less than the benefit that the individual user derives from the system.

'Critical Mass' or 'The Prisoner's Dilemma'

A further point is the issue of critical mass: If one out of five users immediately accepts a word processing tool it's a success, but it would be disastrous if only one out of five people accepted a groupware application designed for a team of five. With a groupware tool it is vital that as many team members as possible - ideally all of them -actively use it. The threshold value of the minimum number of active users required to make a system function is referred to as critical mass.

The problem, also known as the prisoner's dilemma [Rap65], is as follows: As long as anyone updates a groupware database, the individual team member's optimal strategy in terms of cost and benefit is to "freeload," but of course if everyone tries to freeload, the system is not used at all and no one derives any benefit from it.

Most groupware is only useful if a high percentage of group members use it. This makes the implementation of a new system difficult, since the people who start using the system right away (early adopters) cannot get the most out of it because not all team members are actively using it. There is a risk that the new users will give up in frustration and return to their old work habits before the critical mass of users is reached.

 

Conclusion: How To Achieve User Acceptance

Up to now, the developer's main job has been to design a program. In the case of groupware, achieving user acceptance is an equally difficult task.

It is helpful to bear the following points in mind [Gru94]: Identify a group's problems and match the computer solution to it. For example, geographic proximity of group members guides choices between voice and electronic mail, or synchronous or asynchronous decision support.

Identify appropriate work processes: The developer's tendency to focus on structured processes can be inappropriate for communication technologies that best support important (but often unrecognized) unstructured processes.

The selection of appropriate pilot groups and individuals also contributes to the success of the implementation. It is important not to overlook the technical requirements of the system environment.

In addition, users should be given support when they start to use a new application. The new functions have to be explained, the new system's advantages must be described, and if need be training courses must be offered to overcome reluctance to work with the new tool.

It is also advisable to be prepared for difficulties in the initial phase. A fast response to potential problems and appropriate support are essential.

Whether or not a system to support collaborative computing succeeds or fails depends entirely on its users and their acceptance of the system. Groupware is designed for people and should be developed with as much customer input as possible. Regular contact with the target group allows optimal recognition of users' needs and prevents developers going off on the wrong tack. A favorable side effect is that the users grow into the new system right from the beginning, recognize that it reflects their requirements, and accept it.

 

Bibliography

  • [Bal50]
    Bales, R. F. (1950):
    Interaction Process Analysis: A Method for the Study of Small Groups.
    Cambridge, Addison-Wesley Press
  • [Gru94]
    Grudin, J. (1994):
    Groupware and social dynamics, eight challenges for developers.
    [online]
    www.ics.uci.edu/~grudin/Papers/CACM94/cacm94.html
  • [Her01]
    Hertweck, D., Krcmar, H. (2001):
    Theorien zum Gruppenverhalten
    In: CSCW-Kompendium, Lehr- und Handbuch zum computerunterstützten kooperativen Arbeiten. [Hrsg.] Schwabe, G. / Streitz, N. / Unland,R., Seite 33-46
  • Rapoport, A. / Chammah, A.M. (1965):
    Prisoner's dilemma. A study in conflict and cooperation.
    Ann Arbor, University of Michigan Press

 

top top