A methodology for situated analysis and design

We have explained how restructuring the environment and providing situated information to actors can increase efficiency and effectiveness by enabling routine conduct of actions. Now we show how these insights can be combined to produce a new kind of information system analysis and design methodology. This methodology aims to increase efficiency and effectiveness through supporting routine action; in particular, by reducing wasted human effort in search of information.

The domain of the situated analysis and design methodology

What actions can be routinised?

Not all actions systems can be routinised in order to improve efficiency and effectiveness. It is a separate project to define exactly what the necessary conditions are, but basically we need to be able to describe the action dependencies. For example, it would not be possible to design a system of routinised actions to cure patients of cancer. This is because we do not know what set of actions will reliably cure patients of cancer. In other words, we cannot describe the action dependencies that will lead to a patient being cured of cancer.

What actions should be routinised?

Whether or not an action should be routinised is not evident from the description of the action, any more than whether or not an action is useful is evident from the description of the action. For example, even as apparently creative an activity as writing a song can be routinised through use of a template and formulas; indeed, many popular ‘hits’ have been written this way. Similarly, lecture preparation can be approached either as a routine or as a creative activity.

While the purpose of routinising an action is to increase efficiency or effectiveness or both, a good system takes account of more than this. The ISO standard criteria for usability of products (ISO 9241-11) are the effectiveness, efficiency and satisfaction with which users can achieve their goals. We will apply these criteria to the quality of systems, replacing the notion of ‘user’ of a system with that of ‘actor’ in the system. This means that, although the purpose of routinising an action is to increase efficiency or effectiveness, this needs to be weighed up against the effects on actor satisfaction. Returning to the previous examples, there are writers who do not want to approach song writing in a formulaic way. Similarly, there are lecturers who prefer to have complete discretion over how they prepare and present a lecture, perhaps even eschewing established conventions.

In any organisation, choosing which actions are to be routinised is a matter of negotiation between stakeholders, rather than being evident a priori. The issues at stake in deciding whether to routinise something are efficiency, effectiveness and actor satisfaction. Actors who gain satisfaction from relying on their professional skill and judgement to carry out particular actions may not wish to see these actions routinised. Which actions should be routinised also depends upon the specifics of the workplace. If routinisation does not significantly improve the efficiency or effectiveness of the action, then there is no reason to introduce a routine system simply for the sake of it. On the other hand, routinisation has the potential to greatly improve efficiency and effectiveness, particularly through reducing actions such as unnecessary searches for information.

Applying the situated analysis and design methodology

Figure 4: Applying the situated analysis and design methodology.
Figure 4: Applying the situated analysis and design methodology.

In this section, the principles of the methodology are outlined and illustrated using examples from the case study. Figure 4 is a conceptual depiction of the situated analysis and design methodology. As before, conceptually, each triangle represents a particular system of actions designed to achieve the goal(s) near the apex. The three stages in the methodology (represented as the triangles in Figure 4) are elaborated in the following sections.

Analysing the existing system of actions

Analysis involves both description and evaluation. The existing system of actions is described in order to identify what is currently being achieved; at the same time, the efficiency and effectiveness of the existing system of actions is evaluated. There are three conceptually distinct aspects to the analysis of the existing system of actions: analysis of existing work practices, analysis of information actors’ needs, and analysis of existing environmental support. In practice, these analyses may occur concurrently.

Analysing existing work practices

In principle, and as discussed above, each action could be specified with more and more precision as we move down the action hierarchy. In actual analysis we need only go down to the level of detail that is natural and makes sense to actors when describing what they do. Of course, the situated information system is only concerned with providing information about non-discretionary action. Those actions that are not to be routinised (because, for example, they depend on an individual’s judgement and skill) are treated as black boxes in the analysis.

A variety of tools to describe action systems already exist (e.g. Peterson, 1981) and the choice of tool is not important to the methodology. Our emphasis is not on modelling tools but on conceptualising the processes of changing the existing system.

The basic principle is that existing work practices need to be analysed in terms of actions and their context; that is, what happens, when and where, who does it, and with what (see, for example, Table 1). These actions also need to be described in terms of their action dependencies (see, for example, Figure 3) and the purpose of each action needs to be established (see, for example, Figure 2). This last aspect goes beyond simple notions of modelling processes. It involves ascending the action abstraction hierarchy (asking ‘why’ questions) in order to understand, in increasingly general terms, the purpose of each documented action. At the same time, the particulars of the action context are also increasingly generalised.

Describing the action system in this way makes it possible to identify whether the sequence of actions (what), and the division of labour, use of resources, timing, and location (how) is efficient in terms of human effort and time. The analysis assists in identifying whether any actions are redundant and whether there is a need for better coordination (i.e. coordination of actions by particular people or things) as well as making explicit exactly where any delays are occurring.

The following example from the case study demonstrates an inefficient division of labour that resulted in a bottleneck.

Case study example 1: inefficient division of labour

Before the pharmacy could prepare the treatment for a patient (individualised dosage of a drug), the patient’s blood results needed to be checked and marked as OK on the chemotherapy orders. The liaison nurse had the job of checking the blood results and obtaining the chemotherapy orders for all patients to be treated for that day. However, the nature of the liaison nurse’s job (liaising with doctors, nurses, patients, their carers, the pharmacist and other hospital staff) meant that she was constantly interrupted. This, in combination with the sheer numbers of patients to be checked meant that the liaison nurse tended to be a bottleneck in the process of chemotherapy preparation.

Analysing information actors’ needs

In a system of actions, in order to act at the right time, actors need to know that the prior actions on which their action is dependent have been successfully completed. Analysis of the action dependencies reveals what information actors need in order to act. Both the human and temporal efficiency of actions can be improved by minimising the effort spent by actors looking for information; either information that required actions have been completed or information regarding which action is next. We return to the case study for an example where the existing system did not provide actors (nurses) with the information they needed at the time and place where they needed it.

Case study example 2: information nurses need in order to administer chemotherapy to a patient

In order to administer chemotherapy to a particular patient, nurses needed to know whether the patient had arrived, whether a treatment couch was available, whether the chemotherapy treatment had been prepared, and whether the patient was well enough for chemotherapy treatment. However, nurses were required to be physically by the side of the patients they were currently treating. While it was immediately (visually) obvious to a nurse when a treatment couch became available, information about whether the other conditions were met could only be obtained by leaving the side of the patient. A disproportionate amount of time was spent seeking this information, at the expense of attending to patient needs. The information sources that nurses used to find this information included the hospital mainframe computer system, inspection of the treatment table (where the chemotherapy treatments were brought after being made up in the pharmacy), visiting the waiting room and talking to the ward clerk. This meant that, while treating patients, nurses had to regularly walk into the treatment preparation room to check the treatment tables, walk to a computer to check the hospital computer system, or walk to the reception area to ask about particular patients, or to page a doctor.

A further difficulty was that a patient might arrive just after a nurse had looked up the mainframe computer system, the treatment might arrive just after a nurse checked which treatments were in the treatment preparation room, or the blood results might become available just after a nurse had looked up the relevant computer system. Each of these time lags between the condition being satisfied and the nurse knowing that the condition was satisfied, contributed to an avoidable delay in administering the treatment and placed severe limits on the quality of patient care delivered. That is, it hampered effectiveness. As well as being spatially remote, the necessary information was not accessed in a timely way.

Analysing existing environmental support

In analysing the action context, to what extent existing environmental structures (physical, organisational and temporal) support action becomes evident. Paying attention to the affordances offered by existing environmental structures makes apparent whether efficiency could be improved through, say, altering existing roles or changing the spatial layout of the workplace or the temporal structure of the day. What follows is an example of how the physical location of a resource (the chemotherapy order) was not supporting routine action.

Case study example 3: missing chemotherapy orders

A patient’s treatment and dosage was hand-written on a paper form called the ‘chemotherapy order’. These chemotherapy orders were essential as an authorisation for treatment. They were kept in a sleeve inside the patient’s paper history file, which frequently ran to several volumes. In theory, these histories for chemotherapy patients were meant to be brought up to the Chemotherapy Unit at least a day before the patients’ chemotherapy treatments. In practice, some of these histories could not be located. If a patient had a downstairs clinic appointment before their chemotherapy appointment, the history (containing the chemotherapy orders) would be downstairs in the clinic and the patient would be expected to carry their history up to the Chemotherapy Unit after their clinic. On almost every day of the field research, there was at least one history that could not be located or chemotherapy orders were otherwise missing. Finding missing chemotherapy orders was a frustrating task involving much running around by clerks and nurses.

Negotiations regarding the new system of actions

In traditional information systems analysis and design, a requirements analysis is conducted to determine client needs in situated analysis and design, a negotiation phase occurs based around aspects of action; broadly, what is to be done and how it is to be done.

Negotiation of the action context and action dependencies

Organisational constraints are those constraints to do with the specification of the action context and action dependencies; specifically, what is allowed and what is required by the organisation. Note that the constraints we refer to here are not the same as the structures in the environment that constrain or enable particular actions. Here we are referring to what is allowed and what is required by the organisation. What is allowed by the organisation is basically the set of actors, locations, times and resources that can be associated with action. A subset of these is what is required by the organisation. What is required by the organisation may be a reflection of the organisation’s preferred way of operating or may be a response to outside pressures such as legislation. The organisation may have requirements regarding the action context. For example, the organisation may require that certain actions be conducted by a particular type of actor (e.g. a doctor), a particular instance of a type of actor (e.g. Doctor Jones), in a particular type of location (e.g. a hospital ward), a particular instance of a type of location (e.g. the chemotherapy ward), using a particular type of resource (e.g. expandable patient record), or a particular resource (e.g. written patient record), or any combination of these. The time may also be constrained. For example, chemotherapy treatments that take more than four hours to administer may have to be begun in the morning.

The organisation may also have some requirements regarding action dependencies; in other words, regarding the order of actions. For example, the organisation may require that treatment that has a short expiry is not prepared until chemotherapy orders are approved.

Nevertheless, some of what the organisation allows or requires will be negotiable, especially as some of the perceived requirements will simply be the way things have always been done. It is only in the negotiation phase that the analyst can identify which constraints are ‘hard’ (Johnston et al., 2005); that is, those that the organisation cannot or is unwilling to see changed. These ‘hard’ constraints are those constraints that necessarily govern aspects of any redesigned system; they are not negotiable with the client.

Negotiation of client goals

The client’s goals for the system can be viewed as another type of ‘hard’ organisational constraint. Describing the existing system of actions included establishing the purpose of existing work practices. In other words, in terms of Figure 4, it involved moving up the action abstraction hierarchy. We make a pragmatic decision to move up the action abstraction hierarchy until we reach those actions the client considers are the goals. As well as describing the purpose of what is done, these higher-order actions become constraints on what is done.

For example, through analysing the system of actions in the chemotherapy ward we identified four main goals in its day to day work. These are delivering chemotherapy treatment, providing a high level of patient-centred care, participating in clinical trials and nursing research and fulfilling the organisational administrative requirements. Each of these is a higher-order action performed by the client’s organisation and is recognised by them as a goal. However, these are not necessarily the highest (most abstract) actions. We could use ‘why’ questions to move even further up the abstraction hierarchy. For example, chemotherapy is administered in order to treat a patient’s cancer, in order to improve their health and so on. However, administering chemotherapy was a hard constraint in how the organisation treated a patient’s cancer. This meant that there was no scope for us as analysts to consider other treatments such as, for example, alternative therapies.

As Figure 4 indicates, in the design phase, all organisational constraints that have been identified through negotiations as ‘hard’ are taken as given aspects of the new system of actions.

Designing a new system of actions

Designing a new system of actions involves taking account of hard constraints and making use of the action possibilities of the mix of possible actors, locations, resources and temporal ordering. In terms of Figure 4 this means moving down from the agreed goals, through the fixed context and dependency constraints and designing a new set of actions, dependencies and contexts that satisfy the agreed goals. The action possibility space is also deliberately manipulated to constrain and enable particular actions. The purpose is to increase efficiency and effectiveness through routinisation of action. Working within the hard constraints, use may be made of the affordances offered by existing environmental structures or the existing environmental structure may be changed in order to routinise the action.

Providing information to support routine action is also of key importance. Information is conveyed through representation of the possibility for action. This information assists actors not only to know what to do next but also gives them the information they need that allows them to do the next thing. In designing a new system, the action system need only be specified with enough precision so that actors know what they have to do.

The following example from the case study describes how a change in organisational structure and representation of the possibility for action supported routinisation of action.

Case study example 4: redesigning a new system of actions

The proposed new system of actions included the following three solutions to problems identified in the analysis stage.

Change in organisational structure

As described earlier, analysis of existing work practices revealed that the liaison nurse tended to be a bottleneck in the process of chemotherapy preparation. A change in the organisational structure (division of labour) was recommended. Rather than having the liaison nurse check the blood results and obtain the chemotherapy orders for all patients, each treatment nurse was to check blood results and obtain chemotherapy orders for their own patients. This patient information was then in manageable parcels for each treatment nurse and it made sense that the treatment nurses obtain the information given that they were the ones who needed to use it. The shifting of more responsibility for patients to the treatment nurses was also welcomed by both the liaison nurse and the treatment nurses.

Representation of the possibility for action

Earlier in this section we described the wasted effort and delays caused by nurses having to seek out the information about whether the prerequisites for treating another patient were satisfied. The proposed solution was that Nurses carry devices to alert them in real time about the satisfaction of the prerequisites for patient treatment; that is when their patients arrive, when their patient’s blood results arrive, and when the chemotherapy treatment is ready. In other words, the devices represented the possibility for action (the action of administering chemotherapy to a patient). Providing this information to nurses in the time and place in which they needed it, increased temporal and human efficiency.

Stabilisation of the physical environment (Hammond et al., 1995)

Again, earlier in this section, we described the wasted time and effort involved as clerks and nurses ran around trying to find missing chemotherapy orders. The proposed solution was that chemotherapy orders be taken out of the history files and stationed in DayWard. This greatly reduced the time spent searching for them.