In my recent post, Automation Infatuation, I identified Work-Focused Analysis and Design as a process that would avoid the problems associated with clumsy automation. In this post I explain what Work-Focused Analysis and Design is and why it is important.
What is it?
Work is directed at accomplishing something useful. In other words, it has a purpose. Furthermore, it has associated values and it has criteria. To be characterized as work-focused, the process of analysis and design must first identify what is to be accomplished and then identify associated values and criteria. The next step is to focus on how the work could be done and finally, how it might be supported and coordinated.
There is nothing in this definition that privileges either humans or technology. The goal of Work-Focused Analysis and Design is to identify what must be done, how it might be done and what might be the challenges. That knowledge should then be represented in a way that helps us design a fully integrated and coordinated work system.
In my own design work, I use the framework of Cognitive Work Analysis as outlined by Rasmussen, Pejtersen and Goodstein (1994) and Vicente (1999), and Functional Workspace Design as I outline in a recent book. I do not want to claim that these two approaches, when combined, offer the only strategy for Work-Focused Analysis and Design, but they do offer a systems approach that addresses the full range of issues.
Illustration; why it matters
It is not always obvious what people are doing when they engage in work. There is a tendency for those in the technical disciplines to believe that work processes are obvious and rational. Thus, we can simulate them with automatons.
This sort of thinking can get you into trouble. To illustrate, I draw on an analysis by Richard Cook and his colleagues of an automated scheduling system for patient evacuation, proposed for the U.S. military.
The new system relieved operators of the task of scheduling and, for large-scale problems at least, produced better schedules.
However, situations arose for which there was no entirely satisfactory schedule. In such cases, operators were called on to justify the proposed schedule and possibly repair it to ensure that urgent requests for patient evacuation were satisfied. This sort of thing had always been a challenge but, in the process of manual scheduling, operators had implicitly developed a good level of situation awareness about available resources and potential conflicts. They could use that situation awareness to repair a schedule in response to urgent or emerging demands. In their use of the new automated scheduling system, operators were unable to build that situation awareness and were ill-prepared to repair schedules when needed.
Clearly, none of this is necessary. The developers of the automated scheduling system were entirely unaware of the need for operators to build this sort of situation awareness. After all, if the scheduling system does its job, those operators are unnecessary. Or, at least, that is the way the argument goes.
A comprehensive Work-Focused Analysis could have uncovered this requirement for operators to build situation awareness and would have guided development of a support tool to assist scheduling as it helped operators build crucial situation awareness.
Illustration; Work-Focused Analysis
A planning director within a nuclear power facility was concerned that his emergency response team was not performing well during certification exercises. In particular, it seemed that everyone was overloaded.
Senior management expressed the view that it was not possible to increase staffing because space was already limited. What was needed was labor-saving technology to ease the workload.
A cognitive design group observed an exercise in progress and, following the exercise, interviewed a number of the staff. They identified a high number of hand-offs and a number of information bottlenecks. The flow of information to key deciders was inefficient. A number of the staff were unclear about their own role, about who made key decisions, and about how information passed through the team.
One recommendation made by the cognitive design group was to consolidate staff positions. This resulted in reduction in staff numbers from 80 plus to 35. The workload problem was resolved not by adding staff or inserting special technologies but by reallocating the work into more efficient work packages.
The cognitive design group made a number of other recommendations; reorganize room layout to put people who interacted with each other near each other, have team leaders clarify team member roles and explicitly identify the key deciders, and employ after-action reviews.
All recommendations were implemented. The next exercise ran more smoothly with less noise and confusion. Staff asked fewer questions because their situation awareness had improved. Key deciders were able to expand their time horizons and found themselves thinking ahead instead of reacting to problems. Paradoxically, work load decreased despite the reduction in staff.
This rather straightforward Work-Focused Analysis led to a dramatic improvement in the performance of an overworked team without the additional expense of more staff or new technology?
To finish up
I would love to go on but this is sufficient for a blog post. I hope it illustrates with sufficient clarity the problem you can get into if you neglect subtle but crucial work processes as you design work support systems, and how you can use Work-Focused Analysis and Design to develop effective and efficient work support systems.
Cook, R.I., Woods, D.D., Walters M. & Christoffersen K. (1996). The Cognitive Systems Engineering of Automated Medical Evacuation Scheduling. Proceedings of Human Interaction with Complex Systems, IEEE Computer Society Press, Los Alamitos, CA.
Klinger, D. W. & Klein, G. (1999). Emergency response organizations: An accident waiting to happen. Ergonomics in Design, 7(3), 20-25.
The particular fact that team size was reduced from 80 to 35 is reported in Militello, Laura G., Dominguez, Cynthia O., Lintern, Gavan & Klein, Gary (2010). The Role of Cognitive Systems Engineering in the Systems Engineering Design Process. Systems Engineering, 13 (3), 261-273.