A Cautious View of Collaborative Tools

How NOAA might use Collaborative Technology

• To assist in management of field projects
• scheduling resources
• managing dispersed data sets
• maintaining "corporate memory"
• To facilitate dispersed meetings
• synchronous audio/video technology
• provide virtual meeting places

More uses

• To facilitate multiple authorship
• sharing of text and graphics
• intelligent version control
• annotation and review
  
• To provide ongoing feedback to authors
• make readers' comments available to authors and other readers
• maintain forward references

My background

• Artificial Intelligence
• Metalog
• An interest in computers and sociology

Artificial Intelligence

• Software introduction into the workplace
• AI based coordination tools
• Automatic classification and routing of email messages

Metalog

• an electronic notebook
• can classify and link entries
• used in several field projects
• used to develop a "corporate memory" about the COADS database

Lessons learned from Metalog

• a modern mail system (like Eudora) can do most of the useful things that Metalog could do
• Scientist/developers shouldn't compete with general purpose software.

An interest in computers and sociology

• Have recently taught university courses on this subject
• LOTS of work is out there
• Several whole fields exist, notably CSCW (Computer-Supported Cooperative Work)

The CSCW experience:

• Initial enthusiasm (1988)
• The discovery that workplace sociology nearly always wins over technology
• Dawning realism (1990)

The New Columbus Phenomenon:

• Developers believe they are the first discovers of a "new use" of a technology
• The technology is seductive
• Developers ignore past history in related fields
• Costly mistakes are repeated

A lesson learned:

• To see this, you need to look for silence. People don't often write papers about failure.
• Jonathan Grudin has studied this in detail and discovered that groupware is very different from
• single-user systems
• organization-wide shared databases

Grudin's reasons for failure of collaborative software:

from his paper: Groupware and Social Dynamics: Eight Challenges for Developers

• A disparity between who does the work and who gets the benefit
• for example: scheduling software
• Critical mass and the Prisoner's Dilemma ("lurking")
• for example: The NOAA Java HyperNews Discussion page
• Disruption of social processes
• lack of awareness about unequal relationships
• example: project tracking software, and "The Coordinator"

More reasons for failure

• Exception handling in work groups
• Standard procedure is often a myth
• Designing for infrequently-used features
• Few evaluations to rely on
• Developers' intuition often breaks down
• Groupware introduction into the workplace is difficult
• the "1 out of 5 problem"

Some Successes

• Email
• Balance of effort for sender and recipient
• Multiple kinds of software hardly matter
• Critical mass problem has largely passed in NOAA
• Lotus Notes
• Used with great success by Price Waterhouse (in fact they now vend Notes consulting services)
• Successful introduction may require a major corporate push
• A search on "Lotus Notes" and "evaluation" yields nothing useful
• But, Notes is a very successful product

Questions we should ask about collaborative tools:

• Who does the work and who gets the benefits?
• Is it consistent with the real group culture
• Can people be encouraged (or coerced) to use it?
• Is it easy to sabatoge (either intentionally or unintentionally)?

More questions

• Does it facilitate
• what is supposed to be done, OR
• what is actually done?
• Have we avoided the New Columbus Phenomenon?