3.4 Organisational memory systems continued
3.4.1 Integrating memory systems into the flow of work
There has been a substantial amount of research interest over the last decade in group/organisational memory systems. For example, software researchers have investigated the possibility of capturing design rationale, the key reasoning that underpins design decisions (Moran and Carroll, 1996). However, time and again projects have failed. A given information codification scheme encourages particular ways of thinking about information and the problem at hand: typically, information must be categorised, labelled and perhaps linked to other entries. If this way of thinking does not help the designers in their ongoing work, which is of course their first priority, then the memory system will be rejected. For example, Buckingham Shum et al. (in press) review lessons learned from over 15 years’ field deployment of a particular approach, concluding that there is a fine balance to be achieved between the tool's usability, staff skill and computational services.
Technology vendors would convince us that we need simply install their software and the foundation for organisational memory capture is laid. This completely ignores the whole spectrum of rather more complex human issues concerning how this technology will integrate into the ongoing flow of work in a particular context. It is invariably harder to change work practices than software. Understanding how a memory system will integrate into workflow is critical, as is illustrated by the following two case studies (Boxes 3.2 and 3.3).
Box 3.2 The day-to-day reality of maintaining a team memory
In 1992 Hewlett-Packard researchers developed and tested TeamInfo, a prototype group memory system. They used it for about six months to store information relevant to their project. TeamInfo classified email messages, creating a searchable archive.
Berlin et al. (1993) describe the practical challenges facing this project team. They document the challenge of ‘forced cognitive cohabitation’, in which different team members had to reconcile their idiosyncratic habits and preferences in the way they filed and searched for information. Agreeing on a set of indexing categories was the first step, but it was not enough. People varied widely on at least five key dimensions:
Should items be located in one or many places?
Should ongoing issues be classified under headings reflecting where/when they were discussed, or their meaning/theme, or both?
How fine-grained should subcategories be?
What should be the scope of the repository?
What is the relevant category for an individual item of information? This is determined by the anticipated users of the information and their purposes (different people have different priorities).
Box 3.3 From folklore to living design memory
The Designer Assistant system at AT&T Bell Labs sought to capture the ‘community-specific folklore’ within software development projects in order to assist reuse (Terveen et al., 1993). Previously, such informally maintained knowledge was ineffective (not everyone learned what they needed), inefficient (communication was taking more and more time) and fragile (loss of key personnel meant loss of knowledge).
The solution developed was as follows:
The Designer Assistant provided a user interface to a design knowledge base containing information about an important but complex piece of software which other systems had to call on.
The knowledge base was accessed by designers answering Y/N questions about the design of their systems; experts’ solutions at different points in the hierarchy were stored as textual ‘advice items’.
A record of Designer Assistant use and knowledge base advice was annotated to relevant design documents to allow changes to be traced.
Reports of software bugs and their solutions were encoded in the knowledge base.
Knowledge base maintenance was made part of the development process, and any knowledge base advice which was used was made part of the formal software review process.
Key factors in the Designer Assistant's success were its integration with a widely used information system, the fact that it had enough useful content not to be trivial, and efforts to merge it with organisational procedures to prevent it from becoming out of date or being ignored.
This approach will only be directly applicable to well-defined and understood domains for which a knowledge base can be developed to guide users through the repository's structure. However, ill-structured domains could still benefit from the Designer Assistant's other features if alternative ways can be found to help users submit and index new material.