The preceding chapters have introduced the empirical design background for this thesis, and have presented and developed activity theoretical concepts for understanding collaborative activities and collaboration artifacts. A logical question to ask then is; how were (or can) such theoretical concepts be used in design of computer technology? Or, in the words introduced when discussing the role of ‘theory’ in design (chapter 1); how can the practices concerning the design of computer support for cooperative work be informed by the
presented activity theoretical framework? This question is addressed in this section by giving examples of how activity theory has been applied in the enclosed papers [3, 4, 6] to inform analysis and design in the SAIK project.
According to the framework, a collaboration artifact should mediate a co-operating ensemble’s collaborative work, while supporting the activity-based coordination of this work. Let us consider this in greater detail.
5.1.1 Supporting Collaborative Work
One of the central issues of the presented framework, is the 3-level analysis of a collaborative activity. Let us consider how this insight from activity theory informed changes to the design of thePatient Scheduler. At the surgical department (called “U”) involved in the SAIK project, thePatient Scheduler was designed to supports the activity of creating an operation plan. At U, the creation of the schedule is done by the “operation planner”
(a secretary), who schedule the operations based on a referral letter from the general practitioner and a “dispersal note” from the surgeon in charge of the admission of patients. Normally, planning of operations takes place as co-ordinated work where both the means for work and the object of work are stable. In these routine cases, the operation planner can do most of the plan-ning herself. Not infrequently, however, the operation planner cannot create an operation plan for a patient that meets all the constraints – often there is simply not enough resources available at U or at the radiology department within the time frames set up by the surgeon. Therefore the planner needs to engage in a co-operative effort with the surgeon in order to find another acceptable plan based on his knowledge about the operation and her knowl-edge of the resource constraints within the hospital. This analysis of the activity of operation scheduling helped re-design the Patient Scheduler to support such cooperation between the operation planner and the surgeon (and others at U). In this case, the ideas of notes and shared folders emerged, enabling asynchronous cooperation between the operation planner and the surgeon. In subsequent prototyping sessions, these ideas were found useful and further developed.
Hence, a collaboration artifact should be designed to mediate the three levels of a collaborative activity, and the transitions between them. Other
exam-ples of how the Patient Scheduler supports the transition between the three levels of a collaborative activity are provided in Bardram (1998). Be-cause contemporary organization of work in a post-industrial era is charac-terized as non-routine, as cooperation, and as constant transformation and re-conceptualization of the work, I find that this conclusion is an important result of my work. The computer system needs to be able to adopt to this constant flux in collaborative work activity, and thus be able to support work, which has to shift from routine to co-construction and back again. It is important to support the upward transition from co-ordinated work to cooperation and co-construction through re-conceptualizing the means and objects of work, if not the work is to be frozen in rigid routine. Support-ing the downward transition by implementSupport-ing and routinizSupport-ing new ways of organizing work is however equally important.
These general recommendations for adaptability of a collaboration artifact for re-construction of the means and objects of work might sound like in-corporating generic tailoring functionality into the computer system. This is however not the case. The support for implementing and routinizing new work practices might be created for modest but important aspects of a com-puter tool. The important point, however, is to identify in what way the means and object of the collaborative activity are being changed and/or co-constructed on a regular basis, and hence support these aspects of the activity in the future system as well. For example, looking at the task of re-questing a radiology examination, it often fluctuated between being achieved as ordinated work (through paper-based forms) to being achieved as co-operation (through negotiating timeslot over the telephone) [3]. This was a recurrent theme within all the hospitals visited. Therefore, a core design idea in the Patient Scheduler was the design of shared resources, which were to support such closer cooperation. Another recurrent change to the means of work, was re-allocation of radiology resources at different meetings between radiology and the clinical departments. Therefore, the Patient Scheduler supports allocating resources to different department, accord-ing to such changes [6].
5.1.2 Supporting Coordination of Distributed Activi-ties
Another central notion of the presented framework, is the conceptualization of coordination. Thus, important information concerning the design of a collaboration artifact comes out of asking: in what way does a collaboration artifact mediates the coordination of a collaborative activity? Such analyses of the way coordination of collaborative work is mediated by different arti-facts, have been a recurrent theme in the SAIK project. Examples of differ-ent coordination artifact analyzed includes: unraveling programs, protocols of treatments, and care plans [3]; order forms, booking calendars, and plan-ning boards [4]; operation schedules, operation books, and the timeframes used at psychological artifacts at the surgical department [6]; and of course the Green System [4]. All of these analyses of different artifacts mediating coordination at the different hospitals, have been used to inform the design of the Patient Scheduler[3, 6].
[3] discusses the role of plans as mediators for coordination, and demonstrates how activity theory can inform the design of workflow systems. A workflow system typically supports the creating a model of the task sequence, i.e. the
‘workflow’, and then support the management of the flow of information and responsibility as an ‘enactment’ of this workflow (Georgakopoulos, et al., 1995; Grudin & Poltrock, 1997). Workflow systems are often divided into a ‘workflow modeling module’, for creating the models of work, and a
‘workflow enactment module’, creating plans for work (Sch¨al, 1996). This creates a separation between planning and executing work in terms of time, space, and actors. The paper shows that such a separation is not evident in hospitals; rather the plans used there are created as “situated planning”.
The paper discusses the drawbacks of such a separation, and argues that this separation mightprevent learning. The models guiding the distribution of the work need to correspond with the conditions of the work itself and these models hence need to be constantly enhanced and changed to reflect the actual work. But, the only point in time you can detect whether a model corresponds to the work is when the model does not, i.e. during the enactment, when the plan based on the model breaks down. And if you have separated this enactment phase, which is the basis for learning about the applicability of the models, and the modeling phase, you have prevented the work practice from learning, and from embedding the results from this
learning in models for later use. Therefore, it should be possible to change the workflow models (i.e. plans) in the course of the activity.
Hence, a collaboration artifact’s support for planning – i.e. creating plans for coordination of work – should be an integral part of support for work.
This conclusion is supported by reports of successful use of workflow tech-nologies, which exactly is characterized by a close connection between the workflow capabilities and the object of work. Such successful stories include, for example, the use of LinkWorks in the PoliTEAM project at GMD, which incorporate workflow support together with support for object sharing and communication (Prinz & Kolvenbach, 1996), and Configuration Management Systems, where workflow support is closely connected to the source code (Grinter, 1997). The same principle is used in the design of the Patient Scheduler, as discussed in [3].
5.1.3 Supporting Activity-based Coordination
The activity theoretical framework emphasized that coordination of work is basically activity-based interaction, and thereby reflects the object of work.
Therefore, if a collaboration artifact’s coordination aspects should support activity-based coordination, these coordination aspects need to reflect the object of work. The activity theoretical framework identified three coordi-nation aspects of a collaboration artifact; shared object, shared tool, and shared communication. Let us consider these in turn.
Shared object(s) should reflect the object of work. If the object of work only exists within a collaboration artifact, then sharing this object will certainly always reflect the object of work. For example, the operation schedule made in the Patient Scheduler is an object of work (for the people in charge of creating it) and by sharing it, they can coordinated their work around it. However, if the object of work exists outside the collaboration artifact, the collaboration artifact, can only contain a representation of this object of work. In order for this representation of the object of work to support coordination, it needs to reflect relevant aspects of this object of work – relevant according to the activity that is to be coordinated. For example, within hospitals the patient is a central object of work, and the medical record contains representations of the patient. But, in order for the record
to help coordinate work, it needs to reflect relevant part of the work of the different doctors, and others involved in the treatment. What is relevant in this case, can only be established by looking at the activities of the involved actors. The checklist, used in aviation for example, is another prototypical example of such a shared object representation, reflecting certain relevant aspects of the object of work (Hutchins, 1997).
Shared communication should reflect the object of work. This means that the communicative coordination aspect of a collaboration artifact should be designed to reflect what the communication is about, i.e. the object of work.
Hence, communicative coordination is achieved more efficiently when the communication reflects the work. This is equivalent with the notion of semi-structured messages. In thePatient Scheduler, for instance, the requisi-tion form used to request an examinarequisi-tion of a patient is designed to reflect this purpose. Similar, a note in the Patient Scheduler can be attached to an object (e.g. an appointment), which reflects that it is communica-tion concerning this object. Communicacommunica-tion in general can be supported by electronic mail and conference systems. However, these general communica-tion tools are not always well-suited for communicative coordinacommunica-tion, because they do not reflect what the communication is about. It is perfectly possible to use an ordinary email system for requesting radiology examinations (this was actually done in the SAIK project). It is however rather cumbersome to write in free text all the information needed for this request. This can be done more efficiently by filling in a requisition form with check-boxes.
A shared tool should reflect the object of work. This means that a shared tool must be used as a tool for work. For example, if the radiology schedule, as a representation of the work at radiology, is not used to guide the work at radiology and thereby reflects the ‘real-world’ work, it is completely useless as a shared tool, mediating coordination. Therefore, a fundamental criterion for the success of shared resource schedules in the Patient Scheduler to support coordination across departments is, that they are valid and trust-worthy, i.e. that they reflect the way in which the work actually is done. And the primary way to ensure this, is to have these schedules used as guiding tools in the daily work (see [6] for further details). [4] discusses an example of such an examination schedule maintained in the Green System, which was not used to guide the flow of examinations, but was kept for administrative purposes. This schedule therefore did not reflect the work, but merely some
administrative aspects of this work (accounting for examinations performed), and was thus useless as a coordination mechanism for other departments.