Timeliness and task specification in designing for human factors in railway operations

ARTICLE IN PRESS

0003-6870/$ - se

doi:10.1016/j.ap

�CorrespondE-mail addre

Ed.Marshall@s

Applied Ergonomics 36 (2005) 719–727

www.elsevier.com/locate/apergo

Timeliness and task specification in designing for humanfactors in railway operations

Andrew Shepherda,�, Edward Marshallb

aIndependent Consultant, 3 Outwoods Drive, Loughborough, Leics LE11 3LR, UKbSynergy Consultants Ltd., Chirnside, Low Road, Scrooby, Doncaster DN10 6AJ, UK

Received 6 August 2004; accepted 31 May 2005

Abstract

Human error is often related to flaws in system design which might have been avoided had greater attention been paid to human

factors knowledge and methods as the system was developed. The paper considers the role of human factors in system design and

argues that adopting an operational perspective in identifying human factors issues ensures that subsequent human factors advice is

focused upon real needs and is consistent with how managers and engineers choose to manage their systems. It also considers the

issue of timeliness of human factors input. Failure to consider human factors issues at a time when other design decisions are being

taken often means that it is less straightforward to accommodate changes. Thus, managers and engineers may resist dealing

effectively with potential human factors problems for reasons of cost and delay in meeting project milestones.

r 2005 Elsevier Ltd. All rights reserved.

Keywords: Human factors; Task analysis; Design processes; Project management

1. Introduction

Systems such as railways depend upon the synergybetween human beings and engineering assets to ensurethat the latter are used appropriately to meet customerrequirements, maintain safety of staff and the generalpublic, and meet the organization’s business goals.Thus, human beings must be employed, equipped andmanaged appropriately for railways to be safe andeffective. Railway companies demonstrate their commit-ment to human factors through corporate aims and inthe way that they employ safety specialists who useinspection and audit processes to investigate actualincidents, near misses and potential problems. More-over, they have a legal and business obligation tomaintain the well-being of staff, their customers and thegeneral public (e.g. HSE, 1999).

e front matter r 2005 Elsevier Ltd. All rights reserved.

ergo.2005.05.005

ing author. Tel.:+44 1509 215076.

sses: [email protected] (A. Shepherd),

ynergy-ergs.com (E. Marshall).

Despite this public commitment, the routine applica-tion of human factors is sometimes less effective than itcould be—in the railway industry and in otherindustries. Managers and engineers generally acceptthe relevance of human factors retrospectively when aproblem or potential problem arises following anincident, an accident investigation or an audit. Theymay be obliged to demonstrate their concerns byresponding to directives of inspection bodies such asthe Railway Inspectorate. However, in our experience,there is less inclination to consider human factorsprospectively in order to use it to contribute to anemerging design or manage a current operation. This isunderstandable when taken in the wider context ofmanagerial responsibilities, where remaining withinbudget and meeting development and operationaltargets may be paramount. Adopting human factorsmethods as an input to design or management canappear unduly costly and may be regarded as lessimportant than meeting other targets. The designer orengineer may take the view that these factors are

www.elsevier.com/locate/apergo

ARTICLE IN PRESSA. Shepherd, E. Marshall / Applied Ergonomics 36 (2005) 719–727720

common sense and will be taken into account anywaywithout needing to engage an additional discipline.There are notable exceptions in areas such as work-station and workplace ergonomics that are often appliedto inform the design of control rooms. However, eventhese can be misplaced if assumptions made about howwork will be done prove incorrect. Thus, workstationsmay comply with physical ergonomics principles butthey may still constrain how operating staff may interactwith a system. This can cause system control to be lesseffective than it might be.It is evident that many concerns about human factors

that could, in principle, be identified during systemdevelopment, will not result in system failure. Oftenconscientious and experienced staff will be able to avoidsevere problems or take them in their stride and resolvethem before serious consequences arise. This mayencourage the view that a system is basically safe, andmay reduce any inclination to address potential humanfactors problems systematically. Thus, managers andengineers may take the risk and rely on personnelselection, training and conscientious supervision andoperation in order to deal with problems that may arise.However, even good intent by operational staff can becompromised by the combination of design weaknessesand events, resulting in serious errors in superficiallysafe systems.These concerns cannot simply be laid at the door of

people responsible for system development and manage-ment. Human factors professionals must continue toaddress the question of how best to support organiza-tions so that significant human factors issues can betaken into account during system development in timefor problems to be identified and solved with minimumexpense and inconvenience. In part, this is a matter ofdemonstrating the benefits that will be obtained byadopting human factors at an appropriate time and theconsequences of not doing so. Making best use ofhuman factors advice during system development will berepaid by reducing the costs and consequences ofsubsequent incidents and improved productivity result-ing from improved working arrangements and re-sources. Adopting human factors need not incursignificant additional cost.As important as setting out the consequences of

ignoring human factors is the demonstration that thehuman factors community can provide sensitive andcost-effective methods that are consistent with thepracticalities of managing a system. Human factorsshould be embraced as an input to the design process,to be taken into account when design decisions aremade and not merely regarded as an afterthoughtwhen basic design has been completed and constru-ction has commenced. To serve this purpose, weargue that human factors should be undertaken froman operational perspective so that managers and

engineers appreciate how such issues relate to theoperational goals for which they are responsible andhuman factors professionals properly understand theinfluence of the context and concerns to which they arecontributing.

2. The case for human factors

The reliability of people employed to work in a systemdirectly affects system performance. Human factors isconcerned with the health, safety and well-being ofworkers for which managers have a duty of care.Human beings are important components of complexsystems because, within limits, they are physically andmentally versatile, so engineering does not need to solveall functional problems. People are physically skilledand can do difficult physical tasks where automation hasnot been devised or is uneconomical. They can alsocarry out tasks entailing judgment and decision-making,often with greater flexibility than machines, althoughthis may be accompanied by concerns about reliability.Their flexibility can enable people to overcome flaws insystem design and deal with unforeseen circumstances.Thus, in the railway industry people are employed todeal with unforeseen and unscheduled events, as well touse tools and equipment to carry out tasks in locationswhere automated solutions are too costly or incon-venient. In the case of signalling operations, forexample, rules and procedures may apply across thesystem, but it requires signalers to apply judgment andskill to identify the contexts where these rules andprocedures apply and to interpret them according to thelocal configuration of services, infrastructure and risk.Equally, in the case of maintenance tasks, while muchmay be prescribed because much equipment is ubiqui-tous, there is still a need for maintenance staff to adaptto conditions through flexible physical, perceptual andcognitive skill in order to service the real requirements ofthe railway.It is common in engineering cultures for managers

and engineers to be dogmatic about what operatingstaff are required to do. Although compliance with the‘rule-book’ is often the adopted official stance, manypeople in management and supervisory positions regardsome degree of operational flexibility as necessary ifbusiness goals are to be met. Such instances are,technically, violations, but may be assumed to bejustified if expedited carefully with operating stafffully aware of the risks they are taking in order toensure that optimal service is maintained. Even so,compliance with the rule-book should apply, but therule-book should be written to reflect the realities ofoperating a complex system according to business aswell as safety requirements, because business goalsoften compromise safety goals. There is a problem

ARTICLE IN PRESSA. Shepherd, E. Marshall / Applied Ergonomics 36 (2005) 719–727 721

because judgment and cognitive skills cannot bedescribed categorically to satisfy the explicit require-ments of a rule-book in the way that physical actionscan be prescribed and observed. Accommodatingjudgment and cognition within a rule-book wouldrequire an extension to merely recording requiredactions in response to events. It should include state-ments regarding the information that needs exhaustivelyto be taken into account in reaching decisions andevidence that staff have been trained and assessed to anappropriate level of skill and versatility to makedecisions. This is an area where human factors expertiseneeds to be engaged.In requiring people to do jobs, attention should be

paid to how they work, what they can do well and wherethey will be ineffective. It is here that human factorsknowledge plays an important role. People havelimitations in the manner in which they processinformation about the system and make controldecisions. They are limited in the actions they can carryout by their anatomy, physiology and psychology. Thedesign of work resources will affect efficiency andreliability of human performance. The efficiency andeffectiveness with which workers are able to use theseresources is influenced by their competency, how theycooperate with one another and their working environ-ment.Basic human factors knowledge has been established

through psychological and biological research. Suchresearch is often based on experimental studies, carriedout under controlled conditions enabling researchers toattribute experimental effects to psychological orbiological causes. This approach enables hypothesesabout behaviour to be formally tested, but it is limited inaccounting for the complexity that invariably ariseswhen dealing with real tasks. A more applied strand ofhuman factors research has focused on the investigationof real tasks in different occupational contexts, forexample radar watch-keeping, air traffic control, processcontrol and human computer interaction, usually byexamining performance in the real work situation orthrough simulation. Such research often relies onmaking inferences from observation, analyzing verbalutterances, collecting questionnaire data, carrying outtask analysis, or analyzing response patterns to differenttypes of event. These methods can be open to a chargeof being less than scientific in comparison with therigour that can be applied in laboratory work, since realevents are difficult to control or standardize and taskbehaviour is more complex. Moreover, observations andfindings may be subject to researcher bias. Despite this,such studies substantially add to how we understandapplied situations and provide greater context validitythan formal experimental research. They are, therefore,most useful in conducting research that can be appliedto the occupational context.

3. Human factors in management and design

Human factors can be treated as part of the broaderdisciplines of management and design. People arerecruited, trained, equipped and managed in order tocomplement engineering assets. Recruitment and train-ing are generally the concern of Human ResourceManagement. Equipping people is an engineeringresponsibility in terms of designing the means by whichthe worker is able to control equipment and providingtools to enable the worker to be more effective byamplifying power, assisting decision making, providingprotection for inhospitable environments and enablingremote operation. Management involves providingadequate resources to: operate and maintain systems—including specifying the size and roles of work teams tomatch system demands; setting goals, targets andoperating standards; organizing work; and supervisingwork to ensure it is carried out appropriately. Manage-ment responsibility for these aspects of design is not indispute, but it should be emphasized that all of theseshould take human factors knowledge into account.Management is also responsible for specifying the set

of demands with which a system may be required tocope. Different demands placed on a system placedifferent requirements on what workers have to do.Increasing the productivity of a railway by increasingtraffic, for example, has an obvious consequence forworkload unless steps are taken to match the capabil-ities of staffing to the new demands. This may causehuman error through excessive workload, boredomthrough under utilization, inadequate information andfacilities, and task difficulty. Managers and designersmust balance their aspirations for system performancewith reality concerning human capability. Better still,they should take responsibility for better management ofhuman factors in order to limit the extent to whichsystem aspirations are compromised by human limita-tions.Railway systems provide serious challenges to man-

agers who must ensure sufficient human resource—interms of appropriate numbers and appropriate skills—to cope with the contingencies that can arise throughoutthe day. Traffic patterns vary as the day progresses andunscheduled events place extra demand on an operatingteam’s capabilities. Such pressures may result in errorsof decision-making through excessive workload orerrors of judgment concerning the allocation of prio-rities.Human factors, is not an optional extra in system

development. It does not add extra features to a systemwhich one could, arguably, do without, like a fresh coatof paint. The concerns of human factors exist whether ornot human factors specialists are consulted. In theabsence of expert human factors guidance in the railwayindustry, for example, there will still be controls in trains


and signal boxes; information will still be providedthrough windows, instruments and via communicationsdevices; there will still be a thermal, visual andmechanical environment in which people must work.Engineers will have explicitly or implicitly specified thesein systems they have designed and they may regard thesedecisions to be a matter of commonsense. In reality, thefailure to recruit a specialist human factors perspectivecan add to the risk and can contribute to manyoperating errors and accidents.

4. The need to understand tasks

Systems designers and developers work in stages byspecifying how materials or components can be used tofulfill a functional part of the design—then develop thefull design until the system is ready for commissioning.In the process of specifying and configuring componentsit is necessary to observe: functional requirements;constraints on costs; constraints on materials, in orderto withstand thermal and mechanical stresses; compli-ance with various regulations, such as those governingacceptable practice or the use of resources. Each elementof design must be compatible with the other elementsbeing designed for the overall system. A feature that isoften missing during stages in design is a properspecification of how people are supposed to use theequipment being designed. Without this, designers areill-informed about this aspect of design. As a result, thefinished system may not provide enough space orsuitable equipment to carry out the necessary operatingand maintenance tasks; or enough information to enabledecisions to be taken properly; or the working environ-ment may be, ill-suited to human beings carrying outthese tasks.It is rare to find system designers being provided,

early on, with task descriptions or task specifications insufficient detail to enable them properly to take intoaccount what workers must do to fulfill their roles.Many designers work with system specifications andrely on a stereotypical notion of the sorts of thingsthat workers are likely to do in similar contexts. Thereare many good reasons why a project must makeprogress, but when this is done at the expense ofobtaining appropriate design information at a timewhen the information can be used effectively andeconomically, inappropriate design decisions may betaken. Often task analysis is left until it is required toinform training design or, at least, interface design. Thenit may be too late to contribute effectively. The taskanalysis is now limited to addressing how best to fithuman capability to the equipment that has alreadybeen installed. But if the basic design is flawed, thehuman operator can only be trained to make best use ofa flawed system.

Sometimes, ergonomics knowledge is applied piece-meal and this can cause its own problems. For example,software engineers may take into account human–com-puter interface design guidelines to create screens thatconform to standards of character height, colourconsistency, glare and screen flicker rate. However,their failure to understand, in sufficient detail, the tasksthat have to be carried out can mean that they do notproperly understand what information is required forstaff to make operating decisions. Hence, they useergonomics guidelines to display inappropriate informa-tion, resulting in errors of judgement and risk-taking byoperating staff.The sole focus on functional requirements rather than

operating requirements can result in problems that onlyemerge later as a result of a safety review, an operatingproblem or an accident. Problems may never becomemanifest if operating staff find ways of coping, but theymay result in accidents if staff become overloaded andare unable to attend to the difficulties that emerge. Evenwhere the engineer is aware of the potential problemsfor human operation, lack of familiarity with humanfactors knowledge or methods can compromise design.In order to make judgements about all of these

features it is necessary first to understand the tasks thatworkers and operating teams must undertake. Taskanalysis must be suited to examining these issues, but itmust also enable those people responsible for thesuccessful operation of the system to be fully confidentthat their operational requirements are being addressed.

5. The operational perspective for understanding tasks

An operational perspective focuses on what manage-ment requires operating staff to do with the equipmentand resources at their disposal in order to meet thesystem’s operating goals in accordance with anyconstraints they must observe in doing this. Thus, theoperational perspective requires that the human factorspractitioner understands the purpose of the work, theenvironment in which people work and the timepressures they experience. It takes account of widersystem goals and activities and the other duties that aworker must fulfill. It takes account of the system’svalues, including the business requirements, costs andconsequences of error. It takes into account constraintson how things are done, including economic constraintsthat place a limit on the resources used, legislation thatmay govern the employment of staff and safetyconsiderations. Adopting an operational perspectiveensures that the human factors input satisfies therequirements of operational management. It avoids thedanger of human factors specialists placing their owninterpretation on what should be done and deviatingfrom the manager’s perspective.


An operational perspective is a functional perspective,but the word ‘operational’ is preferred here in order toemphasize what has to be done to make a system meetits functional requirements. If a task entails dealing withfaults or incidents, for example, this might be achievedby: (i) referring the problem to highly experienced andqualified team members; (ii) training all staff inproblem-solving skills; (iii) developing decision aids;(iv) specifying case-by-case procedures; (v) addressingthe cause of faults and reengineering the system in someway; (vi) providing better information and access forrepair; (vii) using a combination of these things. Each ofthese would have different human factors implications,but each would serve the same operational end.Identifying and representing difficulties or dangers ofinadequate design to management is often a key role forhuman factors specialists within system development. Itis unlikely that a human factors input will alter thefunctions that management ultimately want a system tofulfill but early referral to human factors will enablemany human factors problems to be addressed, thenremoved or minimized.

Fig. 1. Illustration of a task redescription.

6. Task analysis from an operational perspective

Adopting an operational perspective is a long-stand-ing approach in the application of human factors. It hasbeen used to develop task analysis methods that focuson the real and agreed requirements of an organizationwithout imposing inappropriate solutions. Hierarchicaltask analysis (HTA) (Annett et al., 1971; Duncan, 1972,1974) is an important example of this. Furthermore, it isa valuable starting point for using other approaches totask analysis. It is often important to obtain informationabout cognition, physiology or error types but unlessreal requirements and constraints are first establishedthrough an operational specification of the task, there isa danger that the human factors contribution may driftfrom the real requirements of management and thesystem. HTA fulfils this requirement of situating thetask firmly within a perspective agreed with manage-ment. Moreover, HTA often provides sufficient infor-mation to identify and deal with problems or humanfactors design issues without recourse to a specialistpsychological or physiological form of analysis. Tounderstand the cognitive processes involved in trainingtrain-operator skills, for example, it is important first tounderstand the range of tasks that the system requires ofthe train-operator and, thus, the context in whichcognitive performance must be considered. The systemmay require that the operator initiates actions, monitorsprogress, diagnoses problems, and plans and carries outresponses to contingencies. Each of these may or maynot warrant a specialist examination of the constituentpsychological, physiological or anatomical processes.

But if further examination is required, it can beundertaken with a proper appreciation of the bound-aries of the sub-task in question and the task context inwhich it is carried out.HTA examines tasks by considering the broad

operational goal that the client—the person responsiblefor the system—judges to be appropriate. In the railwaycontext, this could be concerned with track mainte-nance, signalling, train operation or station supervision,for example. Usually, an analyst works with the client,or a task expert responsible to the client, to agree anappropriate operational description of the task at thisbroad level. This general task description is the startingpoint for HTA and is expressed as an imperative orinstruction—in the form of verb–object. For example,tasks could be expressed as ‘maintain track’, ‘carry outsignalling duties’, ‘supervise station’. At this point, noneof these three examples implies any detail concerninghow these tasks will be performed.HTA then progresses by examining the overall goal

through a process of redescription. Redescription setsout subordinate goals and a plan. The plan describes theconditions under which each subordinate goal is carriedout in order to achieve the overall goal. Fig. 1 shows aredescription of the operational goal of ‘parking’ apassenger train in a depot—this is actually part of amuch broader analysis concerned with signalling andcontrol duties in a train depot. All of the goal statementsin boxes are expressed in the verb–object form. The planrefers to each of the subordinates, indicating when it isappropriate to carry them out. Shepherd (2001) givesextensive examples of HTA from a number of industries,demonstrating how hierarchies of plans can helpaccount for task complexity.Each subordinate goal is considered in turn to decide

whether it warrants further attention. This judgment ismade by considering the probability and costs ofinadequate performance. Together, these estimatesindicate the risk attached to carrying out the goal. Ifthe risk is judged unacceptable then either a solution issought to overcome the problem, or further redescrip-tion of the subordinate goal in question is carried out.This process continues until the task is sufficiently wellunderstood to satisfy the analyst and the informant that


all of the risks in the task have been considered and thatsolutions have been proposed to deal with issues ofconcern. This systematic process results in a hierarchicaldescription of the task in terms of goals, subordinategoals and plans.

Fig. 2. Some functions associated with trackside maintenance in HTA

format.

7. Using several experts

It is often important to obtain information for a taskanalysis from a range of people. ‘Maintain track-sideequipment’ is a complex task, where many differentfacets must be taken into account, especially because itintrudes on service delivery and has safety implications.The concerns of operations management include judgingurgency, setting priorities and specifying when it is mostconvenient to carry out maintenance in order tominimize disruption to timetabled services. Engineeringmanagement concerns include ensuring that mainte-nance teams are organized most appropriately, theyrespond quickly and they are properly equipped andsupported with tools and spare parts. Safety concernsinclude providing appropriate isolation of the track,issuing permits to work, guarding the track and super-vising the system to ensure continued protection.Operational and signalling concerns take account ofthe consequences of the maintenance on the widersystem. There are technical aspects concerned withdealing most efficiently with the diagnosis, repair orreplacement of equipment. Communications are con-cerned with providing information on system status tovarious other parties whose own work will be affected.This is a common feature of most railway tasks whereactivities that appear simple become complex by needingto consider the interactions between customer service,line control, signalling, engineering and safety.In many respects, this complexity characterizes the

railway industry more than almost any other industrygiven its geographical spread, range of engineeringdisciplines, customer service and safety concerns.Appreciating this complexity requires that the appro-priate range of expertise is recruited during task analysisand making sure all responsible parties are able toexpress their concerns.In examining the tasks involved in a particular

function it is often helpful first to treat the function asa task carried out by a single—all-powerful—individualwho is able to multi-task and be in several places atonce. By considering the function in this way it becomespossible to anticipate the range of concerns to beaccommodated. Fig. 2 illustrates how functions asso-ciated with trackside maintenance may be related toeach other. ‘Maintaining trackside equipment’ is clearlynot a task for one person. To complete these activitiessuccessfully will involve line-control and signalling staff,maintenance staff, safety marshals, engineering depots

and supervision. To conduct the analysis requires thecollaboration of managers, engineers, supervisory andsafety specialists. Their concern will be to identify whatneeds to be done for safe and comprehensive main-tenance in the context of the wider railway operation,then construct a system comprising people and equip-ment that will deliver these functions.

8. Task analysis through a workshop

In modelling a multi-facetted task or system, such asrepresented in Fig. 2, it is useful to convene a jointactivity to enable concerned parties to collaborate. Thisis an uncommon way to conduct task analysis, but canbe very effective. The analyst operates as a facilitator,often focusing attention on one workshop member at atime, whilst taking account of comments made byothers. The analyst uses a white board, flip-chart or alaptop computer with projection facilities so that every-one can share the information and the emerging taskdescription. In this way contributing parties can bothrepresent their discipline and appreciate why operatingdecisions are taken. It is noticeable in such workshopshow different people, with their different perspectivesgain from this contact as they often start to understandaspects of the system they were unfamiliar with, andappreciate where compromise is necessary.One such exercise was undertaken in the analysis of a

system control task for London Underground. Thecomputer control of the line offered novel opportunitiesfor system control staff, since many signalling and line-control functions were to be automated. Managementwanted to take advantage of the flexibility offered bythis new technology and were confronted with theproblem of how to construct jobs, job descriptions,training specifications and team organization in wayswhich integrated signalling and line control duties totake account of the automation provided by the newsystem.


A number of task analysis sessions were held,attended by line controllers, signalling staff, managers,personnel staff and supervisors. Initially the linecontrollers and signalling staff tried to ‘shoe-horn’ thenew task into a form with which they were familiar—assuming that some people on the proposed operatingteam would be line-controllers, while others would besignalers. However, management and personnel staffwere at pains to resist this in order to take advantage ofthe investment in the technology. The people attendingthese sessions contributed in different ways. Thesignallers and line controllers provided expertise at aprocedural level, while managers and engineers providedexpertise at a broader operational level that reflected therequirements of the organization in operating this newsystem. The sessions were used to shape and reshapedrafts of the tasks. Eventually, different perspectiveswere understood and a composite activity emerged withindividual roles for control-team members to act flexiblywhilst observing proper arrangements for safe andeffective signalling and line control. The task analysisalso specified how the operating team should deal withsystem problems—diagnosing the problem, providingcompensation while the problem was dealt with, andsystem recovery. This task design allowed for the size ofthe operating team to be varied throughout the workingday in accordance with changes in traffic as indicated bythe timetable and the supervisor’s judgment of work-load. Indeed, the final task resembled that of air trafficcontrol (ATC), where ATC officers are responsible forthe safe and expeditious management of aircraftthrough a specific airspace sector. Just as ATC officersmay be directed to supervise larger or smaller air sectorsaccording to traffic requirements, so too could thestaffing of the system control centre be varied to copewith the changing demands of the timetable.An important point to emphasize in both Figs. 1 and

2 is that task representation focuses upon goals to beachieved by the railway system and not on humanfactors, despite the fact that human factors considera-tions are identified during the analysis. As these areneutral operational statements, it means that differentsolutions can be offered to deal with identified problems.This is another benefit of using a team of informantsfrom different domains; not only do they bring togethernecessary considerations in defining the task, they canalso trade ideas concerning overcoming problems.

9. Timeliness in task design

A major responsibility of project management in thedesign of complex systems is the timely integration ofthe different contributing disciplines. Timeliness isparticularly crucial for human factors to be mosteffective. Applying human factors does not imply a

single intervention, but several—for example, workplacelayout, human–machine interface design, training andhuman error analysis. Each of these entails engagingwith the wider design and development process atdifferent stages. Timeliness is important because if someof these things are done too early or too late theresultant design will be inadequate. In some cases designwill be based on incomplete information; in other casesit will be constrained by other aspects which are nowfixed. The result is that the human factors benefits arelimited and may appear inconsequential. The humanfactors specialist will be frustrated by being preventedfrom making an effective contribution and the client willbe unimpressed because little value has been added.Timeliness requires that any human factors input ordecision is made at an appropriate time in the designprocess.It is impractical here to cover in any detail how

different human factors interventions relate to otheraspects of the design/development process, but there aremany examples such as:

�
Equipment may need to be installed early, but ifimplications for maintenance are only consideredlater on then the requirements of maintenance staffwill not have been taken into account, resulting ininsufficient space for movement, poor layout andunsatisfactory facilities. This can result in mainte-nance delays or risks.
�
Task simulators intended for training are specifiedand procured without understanding the tasks to betrained, who is to be trained or how training shouldbe carried out.
�
Control rooms and control workstations are specifiedand designed without a proper understanding of thetasks to be carried out and, therefore, without aproper understanding of what team members will berequired to do or the information and controlfacilities they will need to do these things.
This last item can be illustrated by reference to therailway system control task discussed earlier. Throughexamining the tasks, it emerged that team members hadto communicate with each other during the course oftheir work. The task analysis had identified roles fordifferent team members where they concentrated theirefforts on a designated sector of line. However, aproblem in any sector had implications for activity inother sectors; different team members needed to knowhow colleagues would be dealing with various issuesbefore they could resolve their own problems in anoptimal fashion. Communication between team mem-bers was, therefore, essential. Unfortunately, thedetailed analysis of how the task was to be carriedout was done later on in system development, withmany control-room layout decisions already taken and


implemented. The desk positions in the control roomwere already specified and the electrical installations hadalready been completed. Revising this would have beencostly and time-consuming and was, therefore, under-standably resisted.Some simulation exercises were carried out to observe

this mode of operation and it demonstrated thenoisiness of the task environment and the potential fordistractions or stress for team members. One member ofa prototype team being observed was seen to duck belowhis desk to avoid the gaze of people trying to attract hisattention so that he could concentrate on what he had todo. Consequently, he ignored key information fromcolleagues. As an experiment, we changed the controlroom layout so that all controllers were sitting around atable in ‘conference’ style. The noise levels droppedalmost immediately. Now all members of the team werein line of sight of each other, so each team membercould see how busy colleagues were. Because they wereworking closer together they better understood whatcolleagues were trying to do at any point in time andappreciated how their own information related to thesedecisions. They could refrain from interrupting unne-cessarily but recognized that an interruption from acolleague was likely to be relevant and should be listenedto. What emerged, therefore, was genuine teamwork anda potentially less stressful environment.This was not a comprehensive study and did not cause

the company to review the engineering decisions thathad been taken. Nor did the observations categoricallydemonstrate that the conference style arrangement wassuperior—it was quite likely that team members wouldadapt, with experience, to the control-room layoutadopted. But the example is still worth describing. Onlyby trying to understand how people will work is itpossible to provide facilities that will best suit theirrequirements. In this example, the basic control roomdesign that engineers had specified had not been basedon any precise idea of tasks or how teams would beorganized, but had been motivated more by how suchthings were usually done in signalling centres. Had tasksand team roles been considered earlier—a humanfactors issue—then different room layouts could havebeen considered on their merits and could have resultedin more satisfactory working arrangements. Architec-tural features and hard-wiring would not have beencompleted thus leaving greater freedom for innovativedesign to match the requirements of the team.Many examples can be given and all human factors

specialists will have their own stories to tell. Suffice tosay, every engineering judgment has the potential toconstrain the degrees of freedom available for humanfactors design, including: allocation of function; situat-ing equipment; designing equipment, designing inter-faces and the working environment. These are alsoinextricably connected with specifying teams and jobs,

training and personnel support. To incorporate humanfactors properly, human factors interventions should betimely. By considering human factors issues alongsideengineering decisions, it is easier to make engineeringchoices that place least constraint on how jobs will becarried out.As a post-script to this issue of timeliness, it is worth

stressing that different human factors decisions takenwithin the design of a particular system will benefit fromthe same task analysis. People responsible for systemdevelopment often fail to consider the human dimensionin any detail until confronted with the need to providestaffing. It is then that they must examine tasks in detailin order to design training, write operating proceduresand develop personnel specifications. Sometimes theirfirst detailed understanding of what people have to docomes with the process of carrying out a human erroranalysis prior to commissioning with a view todemonstrating that the system is safe. Having examinedthe task for either of these reasons, it often becomesclear that other aspects of the system should have beendesigned differently. Neglecting task analysis early indesign can be an extravagant oversight.

10. Concluding remarks—organizing for human factors

Resolving the problems of human factors integrationis an organizational issue. The range of human factorsinputs and their timeliness needs to be appreciated.Expertise to provide these inputs needs to obtained andsupported. There is an organizational developmentrequirement to promote the integration of humanfactors and to prepare members of design and operatingteams to accommodate this sort of input.The potential for contributing human factors meth-

ods to enhance system design and operation includes thefollowing:

(1)
Modelling or synthesizing tasks: using task analysis,and using this information to develop aspects ofdesign. This includes assisting management withunderstanding the essential nature of cognitive tasksin supporting railway operations and has implica-tions for operating philosophies and the specificationof performance criteria in the ‘rule-book’, forexample.
(2)
Supporting the design of human factors artefacts and
processes including:� task allocation–allocation of function, work-load-ing, job- and team-design;

� work design–information, workplace layout,equipment and interfaces;

� competency–personnel selection, training, tasksupport, team development, performance assess-ment;


� the working environment.Design should be based on an approved taskanalysis.

(3)
Evaluating stages of design in order to identify
potential human factors problems sooner rather than

later in the lifetime of design and development.
(4) Auditing how the overall system will work or fail and
supporting improvements.

Of these areas the retrospective assessment of designdecisions is most widely addressed—i.e. aspects of 3 and4. Often this is done through the application of humanerror methodologies, but there are other methods thatcomplement these approaches. In particular, it is oftenparticularly beneficial to seek empirical evidence that asystem design can be used effectively by operating staffusing simulation studies or studies that monitor andevaluate performance of the real task.Employing human factors input in areas 1 and 2 is less

evident and this is often a lost opportunity. Area 1 isimportant for establishing a proper operational focusfor subsequent work and also provides information tosupport the design activities in area 2. If these stages aredealt with conscientiously, they will serve to avoid manyof the problems identified in 3 and 4. This will providegreater confidence for the operation of the system andminimize errors of design, so reducing costs and systemdown-time, including delays due to re-work. A coherentapproach to human factors would treat each of theseaspects in turn to contribute to efficiencies and promotegreater consistency between different aspects of design.Thus, human factors expertise will provide advice on

when and what inputs are beneficial with regard to:

�
priming designers to take account of human factors; � providing standards and design advice; � carrying out, teaching, supporting or evaluating taskanalysis;
�
evaluating design stages and system performance,including contributing to safety audits and humanerror analysis.Timeliness of human factors interventions needs to be
understood when managers are planning projects. Arelevant human factors input should be a component ofall projects, especially in the development of safetycritical systems. Early negotiation with a human factorsspecialist will assist in judging the timeliness of involve-ment.Organizations may employ and support their own in-

house human factors expertise. In engineering develop-ment projects, it may be appropriate to ‘buy in’ expertisefor the duration of the project given the limitations onthe life of the project. Nevertheless, even here, it shouldbe acknowledged that there is a need for all members ofa development team to appreciate the role of humanfactors in contributing to system development.

Acknowledgements

We greatfully acknowledge the numerous personnel inboth London Underground and Network Rail who haveprovided time, information and insights into railwaysystems.

References

Annett, J., Duncan, K.D., Stammers, R.B., Gray, M.J., 1971. Task

Analysis. H.M.S.O, London.

Duncan, K.D., 1972. Strategies for the Analysis of the Task. In:

Hartley, J. (Ed.), Programmed Instruction: An Education Tech-

nology. Butterworth, London.

Duncan, K.D., 1974. Analytical Techniques in Training Design. In:

Edwards, E., Leeds, F.P. (Eds.), The Human Operator and Process

Control. Taylor and Francis, London.

HSE, 1999. Reducing Error and Influencing Behaviour. HSE Books.

Shepherd, A., 2001. Hierarchical Task Analysis. Taylor and Francis,

London.

Documents

Timeliness and task specification in designing for human factors in railway operations