Crtitical Success Factors of Groupware Implementation

CSCW (or groupware) tools and the research about them has been around for decades already. Today it is hard to even find a work community that would not utilize these tools at least to some extent. Still, comprehensive use of groupware is limited to special fields. I wanted to know, what are the reasons for the successful or unsuccessful implementation of groupware? Hung-Pin Shih's article Predicting Groupware Use from the Perspectives of Workflow, Information and Coordination gave me an excellent framework.

There are widely recognized benefits in the use of groupware, but also unintended consequences. In this paper Shih explores groupware implementation and goes through several other studies that relate to his work. He suggests that group members are most likely to achieve high outcome quality of groupware use in cooperative work through work-flow routinization, information integration and coordination fit. In other words, groupware should offer ways to reduce repetitive activities in order to save the energy for more creative work.

While the conclusions from Shih's own research are pretty predictable, his findings from other research are interesting and provide answers to my question. These are also managerial issues: the implementation of a new groupware can be a critical move.



Table references:
[15] J. Grudin, “Why CSCW applications fail: Problems in the design and evaluation of organizational interfaces,” Proceedings of the Computer-Supported Cooperative
Work, Portland, Oregon, USA, 1988, pp. 85-93.
[17] J. Grudin, “Groupware and social dynamics: eight challenges for developers,” Communications of the ACM 37(1), 1994, pp. 92-105.
[22] H. Karsten, “Collaboration and collaborative information technologies: a review of the evidence,” Database for Advances in Information Systems 30(2), 1999, pp. 44-65.
[23] S. Kelly and M. Jones, “Groupware and the social infrastructure of communication,” Communications of the ACM 44(12), 2001, pp. 77-79.
[31] W.J. Orlikowski, “Learning from Notes: organizational issues in groupware implementation,” Proceedings of the Conference on computer Supported Cooperative
Work, ACM, New York, 1992a, pp. 362-369.
[38] A.M. Townsend, A.R. Hendrickson, and S.M. DeMarie, “Meeting the virtual work imperative,” Communications of the ACM 45(1), 2002, pp. 23-26.
[46] C. Yu and D.C. Yen, “Extranet and groupware,” Journal of Computer Information Systems 40(4), 2000, pp. 32-40.

Thoughts about GSS

In the last lecture there was talk about Group Support systems and how some of them even need separate facilitators, who before meeting plan the meeting and what tools to use and during the meeting uses the tools. This whole facilitator-idea made me wonder whether all the fancy GSS really help the meeting. I mean, if you need a special trained professional just to run them, wouldn't it just be easier to hold the meeting in a old fashioned way?

Of course, I can see the benefits of - for example - computer counting votes or other manual things that would take plenty of time if conducted manually. But if I imagine a system that would do that or other similar simple tasks, it hardly seems like a system that would need a facilitator to run it. Of course, this is all just thoughts based on how I imagine GSS's work. I don't have any personal experience with GSS's, and I don't really know what kind of tools they provide or how hard they are to use.

Other thing that raised a thought was study by De Vreede et al.[1] where they studied causes for GSS meeting failures. Most of the failures had something to do with problems with goals and far less common were the ones with problems with technology. So most of the problems seem originate from the participants, not the tools. Just like in Jami's post here, it seems that it all comes to the people using the tools.

References:
[1] G.-J. De Vreede, R.M. Davison & R.O. Brigss, How a silver bullet may lose its shine. Comm. ACM 46:8, August 2003, 96-101. http://doi.acm.org/10.1145/859670.859676

Can distance be a blessing?

In the design, implementation and use of groupware the greatest challenge is often referred to be the absence of "group". The tools are considered gawky and inefficient, because asynchronous communication and virtual environments fail to create the sense and atmosphere of "real teamwork". Many of the latest tools aim in better engagement and interaction of users. I am asking, is unprofound communication necessarily a bad thing?

People are various, and so are teams. The process of teamwork is usually far from ideal. Work groups are not social groups in the same sense than families or lads. Relationships are superficial, motivation varies and different people may have different goals. Teamwork can be a wearing experience.

My writing has two different points: Firstly, could the use of groupware and separated spatiality work better in some situations just because it gives us more personal space? Secondly, is the research and development of groupware too biased towards "the ideal" group-work instead of "the real" group-work?

Fruits of the first lecture

When I came to this course my idea of groupware was that it was something that multiple persons could work on simultaneously. Usually the picture in my head was something like a table with a huge touch screen on it and group of people using it at the same time.

However, our first lecture introduced to me a much wider and specific definition. According to Ellis, Gibbs and Rein (1991), groupware are "Computer-based systems that support groups of people engaged in a common task (or goal) and that provide an interface to a shared
environment."

Another thing that our first lecture clarified to me was that groupware doesn't need to be simultaneous. Multiple people can work on something at different times. Or even at different places. (Ellis, Gibbs, Rein, 1991; originally, DeSanctis & Gallupe)

Nice observation was also that many of the programs and tools I use daily, are actually groupware. For example Dropbox - which Aleksi tells more about here - is an excellent tool. I don't actually use it as groupware, but rather as a small, free backup tool. Also Google Docs is quite handy at times. And of course, Wikipedia.

What is Groupware?

Groupware, collaborative computing, workgroup computing, multiuser applications, computer-supported cooperative work applications… A dear child has many names. I decided to create the first groupware blog entry simply defining what is meant by term groupware.

As mentioned at first lecture, groupware is software for groups that is designed to support group work and help groups of people to achieve their common goals by communication, collaboration and coordination [Ellis, Gibbs, Rein, 1991]. Examples of groupware include desktop- and videoconferencing, coauthoring features and applications, email, bulletin boards, meeting support systems, voice applications, workflow systems and group calendars, among others [Grudin, 1994].

In conclusion, according to Grudin when defining the meaning of groupware, it would be useful to consider questions “Was this software designed to support groups?” and “Is it being used to support groups?” [Grudin, 1994].

References:
[Ellis, Gibbs, Rein, 1991] Clarence A. Ellis, Simon J. Gibbs, Gail L. Rein, Groupware: some issues and experiences. Comm. ACM 34, 1 (Jan. 1991), 38-58.
[Grudin, 1994] Jonathan Grudin, Groupware and social dynamics: eight challenges for developers. Comm. ACM 37, 1 (Jan. 1994), 92-105.

- Minna