On the Design of Flight-Deck Procedures - Intelligent Systems ...

6.1.7 Computerwork and ProceduresProcedures dictate tasks, and often these tasks involve some form of transformation (e.g., convertingaltitude reported in meters to setting the altimeter in feet). A complex transformation between input andoutput may increase workload, create possible confusion, require procedural aiding, and worst of all,invite error. The following example illustrates the effect of a complicated transformation.The crew of a B-757, preparing to fly from Miami to Washington National, was dispatched with a computergeneratedflight plan with the following route: “radar vectors, AR-1 CLB ILM J-40 RIC...” When the crewattempted to enter the flight plan into the Route page of the CDU, they got no further than CLB, whichcontinually resulted in an error message of “not in database.” They repeatedly tried to enter the flight plan andcontinued to receive the same message after entering CLB. What was the problem? CLB (Carolina Beach) is anon-directional beacon, not a VOR as the three-letter designator on the flight plan implied. The flight plan, tobe correct and compatible with the “expectations” of the CDU should have read “CLBNB.” It was not until thecrew took out their paper charts and traced the route that the error in the flight plan was apparent (Wiener, 1989).If the same computer-generated flight plan had been issued to a non-FMS aircraft, there would be nosuch incompatibility. But that is exactly the point -- documents must be compatible with the equipmentthey support. If an efficient operation is desired, the transformation between the input task and theoutput task should be kept simple. In this case, there should have been a direct mapping between thedata entry task (CLB from the flight plan) and the output (entering the NDB into the CDU).Guideline #12: Paperwork should be designed carefully to be compatible with the device forwhich it is intended. Particular care should be exercised in preparing materials for computerbasedsystems. It may be necessary to provide differently formatted documents for differentcockpit configurations.6.2 CRM AND PROCEDURESEffective execution of procedures in a multi-person crew depends on effective crew coordination andresource management (Wiener, Kanki, and Helmreich, 1993). Although the term CRM is widely usedto describe many aspects of human-human interactions, including team-building, social interaction,leadership, etc., the discussion here is limited only to the crew coordination aspects of performing aspecified task.6.2.1 Crew CoordinationOne of the objectives of any procedure is to promote better coordination among crews. The term crew isexpanded here to include all agents that are involved in performing a task (e.g., the push-back of anaircraft from the gate requires that the ground crew and the pilots work together). For that duration, allof the agents involved in performing a task (e.g., ground crew, ground controller, cockpit crew, gateagent) are considered here as a crew. These system procedures, accordingly, are shared and conductedby all the agents involved.There are several attributes of a procedure that can be utilized by the designer in order to promote crewcoordination:Reduced variance. Procedures trigger a predetermined and expected set of actions. There areseveral benefits resulting from this:1. SOPs allow “freshly formed” crews, often comprised of individuals who have never previouslymet, to effectively and efficiently discharge important operational tasks with minimal need forformal co-coordination and superfluous communication” (Johnston, 1991; Hackman, 1993).2. Clear expectations of the in-process or in-coming tasks allow for easier monitoring on part of theother agent(s) in the crew.35