HFI seeks to separate the roles of customer and solution provider from the beginning in order to minimise the potential for conflict.. Customer. Solution Provider.
3rd South East Asian Network of Ergonomics SocietiesInternational Conference 2014, Singapore
Human Factors Integration in the Systems Lifecycle RS Bridger a
Institute of Naval Medicine
ABSTRACT It has long been recognised that there is a lack of fit between Human Factors and Ergonomics (HF&E) and the rest of the systems design lifecycle. Key components of a framework for Human Factors Integration are reviewed following a brief historical introduction and a discussion of systems theoretical concepts. Systems design starts when a capability need is identified and ends when the system is decommissioned. Early identification and analysis of requirements is a critical entry point for scientific knowledge of HF&E. The presentation will end with a short case study to contrast ‘HFI thinking’ with traditional ergonomics thinking. The former focusses on technology management and the processes for optimal exploitation of resources, including human resources, whereas the latter is an extension of basic science to risk assessment. The former is an essential part of systems requirements specification and the latter features strongly in acceptance testing. KEYWORDS Systems Design;Requirements Specification; Acceptance Testing. INTRODUCTION It has long been argued that the lack of a framework for Human Factors Integration (HFI) has acted as a braking factor on the inclusion of Human Factors and Ergonomics (HF&E) in design. DeGreene, (1980, 1986) argued that despite the perceived usefulness of ergonomics amongst its practitioners and researchers, ergonomics has not clearly interfaced itself with other, more established disciplines and that it lacks frameworks and models capable of expressing its benefits in terms relevant to the function of wider sociotechnical macrosystems. To think about anything requires a concept or model, not just of the thing itself but also of the context in which it is being observed (Gharajedaghi J.1985). When complex systems are designed, the context is one of systems engineering embedded in a systems lifecycle, often referred to as the CADMID cycle. In this paper, a framework for putting HF&E in context, a framework for HFI, is described, together with some of the thinking behind it. It of some importance (although rarely discussed in academic literature) that systems design takes place in contractual environment between a customer and a solution provider. Both have the same objectives (to design a successful system) but different interests and there is always potential for conflicts of interest. HFI seeks to separate the roles of customer and solution provider from the beginning in order to minimise the potential for conflict.. Customer
Solution Provider
Specifies Requirements Determines acceptance tests Tests solution Identifies missing requirements Accepts solution
Designs solution Builds prototype Supplies system for testing Modifies solution Delivers system
HFI is known as 'Human Systems Integration' (HSI) in some countries. This terminology is rejected because systems are built to benefit humans and humans are already part of systems. When designing complex systems, qualified HF&E specialists are needed by both parties.
Origins of HFI HFI has its origins in systems theory, which was a product of industrialisation and a response to the challenges of building and operating increasingly complex systems. Rapid technical advances required systems to be designed using compatible components, including human ones, without prior knowledge, custom or practice. The Larkin Building (1908), designed by the architect Frank Lloyd-Wright was an early example of a head office building incorporating many new technologies at the time. The demand for office and administrative services was increasing and a 'total system concept' was constructed to meet the demand using steel frame construction, air conditioning, mechanical ventilation, electrical and natural lighting and some 'open plan features to support a system of work organization based on the writings of FW Taylor. Metaphorically, it was an example of 'new wine in new bottles'
RS Bridger
Systems - A definition A system consists of a set of elements, the relations between the elements and the boundary around them. Inputs cross the boundary from the environment or from other systems and enter the system. The elements interact to execute functions (activities necessary to achieve a common purpose - the system goal). One or more outputs leave the system, enter the environment or become the inputs to other systems (Figure 1). In practice, the output of the system is the same as its purpose and the range of output it can produce is its capability. In the past, the unintended or unwanted outputs of systems (such as waste products in Figure 1) were often been ignored, but this is an area that is receiving more attention in HFI in relation to macro-system sustainability (Haslam and Waterson, 2013). The key considerations in the design of any system are capability it must deliver; the inputs needed to achieve the purpose; the functions applied to the inputs and the choice of elements and their interaction when executing the functions. Singleton argued that the proper focus of HF&E was on understanding 'what needed to be done' and not on how to do it and the that what needed to be done was best achieved by focussing on functions first of all. Functional thinking fosters creativity by keeping the design space open to a range of technical solutions for as long as possible The system user (or 'customer') must first specify the requirements of the system (what it must deliver). The user's requirements are then specified in greater detail as the system concept develops. Systems theorists in human factors and in other disciplines often state that systems have emergent properties (de Greene, 1978). In the present discussion, we might put this differently by saying that systems integration presents designers with emergent problems. As elements are bought together, problems of integration arise that are not always apparent at the level of the elements or subsystems themselves. HFI is therefore a tool that can be used to overcome problems of integrating people with technology in increasingly complex systems. Leveson (2011) points out that in complex systems, most accidents happen at the boundaries between systems components rather than failure of the components themselves. HFI focuses on one of the major boundaries in any system - the human- technology interface, wherein integration is achieved, not only by 'fitting the technology to the user' but by implementing appropriate constraints on the interaction. Standard Operating Procedures are an example of such constraints. Failure to properly understand what constraints are needed is one reason many systems fail.
Figure 1. Example of a System (from Bridger, 2009)
Systems HF&E and Traditional HF&E Early ergonomics textbooks contained a great deal of information about people, gleaned from applied research in anatomy, physiology and psychology (e.g. McCormick, 1957) but little advice about how to use the information (i.e. missing context). The book by Singleton (1974) is an exception. This book contains very little information about the core sciences of ergonomics. Singleton's focus was on the 'systems approach' and the activities needed to design systems, recognising that HF&E had to be integrated into the systems design processes in order to succeed. In HFI, this means that HF requirements are included at the very earliest stages. For example, many furniture companies offer excellent chairs which embed the knowledge obtained from over fifty years of research into seating. For HF&E, a reasonable question to ask is 'Is this an ergonomic chair?'. For HFI, in contrast, the question might be 'Is there a requirement for sedentary work?'
GENERIC REQUIREMENTS FOR SUCCESSFUL SYSTEMS All systems must be designed with the following Generic Requirements: inertia (resistance to change); resilience (the ability to recover from perturbations caused by change; and succession (planned obsolescence and replacement of components). Resilience has two components - amplitude, the degree to which system functioning can be perturbed without damage, and elasticity, the speed at which it returns to a stable state when external conditions normalize. Similarly, there are also Generic HF&E Requirements (Table 1) and mandatory 2
RS Bridger
requirements varying in strength and derived from the law, standards, guidelines and custom and practice. MoD (2012) states that all more detailed and system specific HF&E requirements will be derived from the generic requirements in Table 1 as the system concept develops. It is in the generation of increasingly detailed and system-specific requirements that subject matter expertise in HF&E is required and this is a critical role for the HF&E specialist on the design team. For each of these requirements, acceptance criteria have to be generated to determine whether the requirement has been met in the solution. Acceptance criteria might be derived from standards or guidelines or they may depend on user-trials or even experiments (Table 1). This is another task where formal knowledge of HF&E is required, particularly if trials or experiments are needed. Ergonomist have long held the view that ergonomics works best when it is considered at the earliest stages of design. In terms of the present discussion, specification of requirements is key because if HF requirements are not specified, they are not implemented
Table 1. Generic Human Requirements* and One Level of Decomposition
Level 1 Employ the right people for the job Provide a suitable work environment Support work and non work human functions Satisfy User Organization Constraints
Level 2 Descriptions of jobs and users Equipment usable and safe; Environment meets legal requirements and standards; environment is compatible with tasks Tasks compatible with user-expectations and skill; Optimal work loading; Adequate rest, recovery and nutrition Clear work role; Consult users; Appropriate work patterns; Support from management and colleagues
Writing Requirements Requirements specification should not be left to system designers. Subject matter experts and user representatives should be included. In designing a new airport, for example, the capability need is to provide landing and take-off facilities for a defined number of aircraft: services to process passengers and accommodate staff: and links with the surrounding transport infrastructure. The requirements include the routes to be serviced, staffing levels, whether international or national flights or both can use the airport and the rates at which aircraft can arrive and depart and passengers can flow through the terminal. Whether the airport buildings are built of wood, steel, concrete or plastic is part of the solution, not part of the requirement. In HFI, generic HF requirements are stated at the outset, then they are decomposed into increasingly specific requirements as the system concept develops. A proper audit trail of decisions is kept such that detailed requirements can be traced back to generic requirements. Requirements must be objective and amenable to acceptance testing. Traditional ergonomics is vital for decomposing generic requirements into specific requirements both with respect to detail and objectivity and, more importantly, for understanding the need for such requirements. MoD requires all solution providers to include an HFI plan in tender documents and that all HF work must be overseen or conducted by a member of the IEHF. However, even when these conditions are met, there are major conceptual and practical problems in ensuring that the right knowledge is applied, in the right way at the right time when writing requirements: •
Systems design teams: Are multidisciplinary but does not always see themselves as such
•
Knowledge management: Knowledge tends to be 'stove-piped' in different domains and is not always visible to project teams when it is needed. This often applies to socio-technical knowledge needed to decompose generic HF&E requirements into system-specific requirements. Some technically advanced systems are primitive socio-technically with jobs that are mere relics of an earlier industrial age. (fatigue was common in Victorian sweat shops and is still common in modern ships bridges). Allocation of function between operators and machines is a critical phase in systems design but is often conducted with little thought being given to the design of the resulting jobs.
•
Research literature: is not always usable because the findings of research are either inconclusive or effect sizes are not reported or cannot be reported due to deficiencies in research design . Human performance was not investigated at a hierarchical level applicable to the system being designed.
•
Textbooks: describe useful technical information but not the tools to use it.
•
Project teams: lose sight of the 'big picture' and see the system design process and the CADMID cycle as a self-contained processes, losing sight of the bigger picture ('CADMID tunnel vision'))
3
RS Bridger
•
Over-reliance on human operators to provide the resistance and resilience to ensure system stability, while forgetting that people go home at weekends, get bored, find better jobs and can't be in two places at the same time.
•
Over-reliance on standard operating procedures to ensure safety and efficiently without considering the usability of the procedures, the costs and benefits to the user or the system of not following them.
•
Inappropriate assumptions about people: the persistence of Tayloristic work practices such as automation which impoverishes human work roles and management practices that de-skill and overregulate highly skilled people (some aspects of 'clinical governance' in health care).
•
Requirements specification is hierarchical in terms of the level of detail and in terms of force. There is a hierarchy of forcefulness ranging from legal requirements: standards; guidelines; custom and practice and learning from legacy data.
NEW SYSTEMS AND 'GOOD IDEAS': WHY DO SOME SUCCEED AND OTHERS FAIL? Many new systems succeed because they are not really new at all. A 'Freedom Ship' has been proposed. At 1.3 km long, 100 metres high and 225 metres wide it would be a floating city for 50,000 people, circumnavigating the globe every year. Is the proposal feasible? Technically, it is and it could be argued that it is not really a new idea at all, merely 'old wine in a big bottle' since the requirements for successful town planning and the requirements for building cruise shops are already well understood. It is likely though, that some of the challenges would occur at the interface between these two domains. 'Solutioneering' is a term used when technical solutions to problems are proposed before the requirements have been specified and is the opposite of functional thinking. Apart from constraining the design space too early, solutioneering can lead to solutions that aren't needed (there is no requirement for them even though the design concept is good and rationale sound) and to poor solutions that nobody wants. Many, apparently new ideas, work because the system architecture into which they are embedded is already stable. Electrically powered cars for personal transport have been feasible for many years but have been held back primarily by limitations in battery technology, particularly recharging . As these limitations are overcome, a 'tipping point' may be reached where rapid adoption of these technologies will occur, the stable architecture having removed much of the uncertainty. From the present perspective, a transport system dominated by electrically powered cars for personal transport and buses is not a new system, rather 'it is new wine in old bottles' - a new subsystem within an existing system., illustrating the principle of succession. The fundamental characteristics of the road transport system, including most of the arrangements for safety (the 'rules of the road') remaining unchanged.
HFI IN SYSTEMS DESIGN HFI activities should take place throughout the lifecycle of the system. In the United Kingdom, the acronym CADMID (Concept, Assessment, Design, Manufacture, In-Use, Disposal) is in common use (e.g. Ministry of Defence, 2012). The main steps are as follows: Establish project concept and objectives: At the earliest stages, the focus is purely functional - on what is needed not how it is to be achieved. Typically, requirements are identified and defined as succinctly as possible. The choice of techniques to elicit the information (e.g. focus groups, interviews with subject matter experts, userpanels etc.) is itself a key part of the HFI process. The role of operators is determined early in the design process when functions are allocated either to automation or to operators, or flexibly to both. According to Deardon (2000), in those cases where functions can be performed by humans or by automation, the function should only be automated if it is separable from the operator's role and does not interact with it. Establish Human Factors Integration Strategy: The HFI strategy is essentially the work programme for HF over the project timeline, Identifying the main HF activities, the resources to conduct the activities and the timelines for completion. Produce Human Factors Integration Plan (HFIP). The HFI Strategy should be included within the HFIP together with details of those responsible for the plan, the main activities of the plan and the methods used to conduct the activities. Inter-relationships with the wider project and any constraints and dependencies should also be made explicit. Establish Context of Use. The context of use for the solution is established for the use by the solution provider and other stakeholders. The context of use details how the system is going to be used; where and under what conditions; and how in relation to other systems. Analyse Legacy System Data and Feedback: If an existing system is to be upgraded, requirements specification may be fairly straightforward - a matter of changing the parameter values. If a new system is being developed, information about the operational requirements of the process and the role of human operators may be needed. In both cases, the goal should be to use legacy information to identify and solve any existing ergonomics problems and avoid generating any new ones. Genuinely new systems ('new wine in new bottles') are rare, but are
4
RS Bridger
conceivable (e.g. a manned mission to Mars) and present real challenges, not least because there is so little legacy data available. Establish User Population and Characteristics; The physical, psychological and social characteristics of the intended User population are identified, described and documented and communicated to Solution Providers in the form of a Target Audience Description (TAD). Conduct Early Human Factors Analysis (EHFA). A high-level, comprehensive and balanced analysis of the People-Related aspects of the project, including: Concepts and Doctrine; Equipment; Information; Infrastructure; Logistics; Organisation; Personnel; Training. The output from the EHFA should include a list of key PeopleRelated Considerations including risks, issues, constraints, assumptions, supported by evidence and expert judgement. EHFA occurs as soon as detailed project objectives and constraints are sufficiently mature. Develop ITEAP - Integrated Testing and Evaluation Plan: Low-level requirements should be explicit, unambiguous and testable and the tests should be quantifiable in some way against a criterion of acceptance. To make requirements explicit, quantified and testable: • Use explicit single-sentence requirement statements. Don’t use narrative descriptive paragraphs other than for contextual and supporting information. •
Define for each individual user requirement: who the owner is, what is the need, how much, in what circumstances and how satisfaction is to be proved.
•
Define for each system requirement: how much of what 'service' is to be delivered, to which user, in what circumstances and how satisfaction is to be proved.
The outputs from this activity are either the making of an acceptance argument to put forward to the appropriate Acceptance Authority or a return to the test/trial activity to collect further evidence. System Operation and Safety Leveson (2011) has argued that accidents often occur because the requirements for safety were missing or were poorly drafted, resulting in inadequate safety constraints when the system was accepted. In such circumstances, human operators are, to use Singleton's (1974) metaphor, are the 'elastic glue that held the system together. Over-reliance on human operators for safety introduces risks when job demands exceed the boundary conditions for human reliability, due for example, to fatigue or overload. Psycho-social conditions may create peverse incentives for rule breaking, for example, when Standard Operating Procedures are not followed because the costs of following them are perceived to outweigh the benefits in relation to the perceived level of risk (See Wilde, 1974) for further discussion of safety behaviour in the context of Risk Homeostasis Theory). Decommissioning Many systems are built to last 40 years or more and attention has to be paid, at the design stage, to the requirements for safe de-commissioning including the handling of hazardous materials and the dismantling of structures that were modified during the life of the system. Attention should also be paid to the treatment of human operators, some of whom may be facing redundancy, early retirement or may need re-training.
Case Study: HFI Thinking in Action The author was asked to visit a secure facility wherein the guards were complaining of ill-health due to the heavy burden of personal protective equipment (PPE) they were required to wear on duty. It became clear that procurement had taken place in a piecemeal fashion: there was a wide variety of workplaces and operator roles and hazards were highly distributed and variable. PPE was not regarded as a 'system' itself, or as part of a larger system, and there was an absence of control and feedback at different hierarchical levels. This meant that the conventional approach of traditional ergonomics, based on risk assessment, would be unwieldy and only effective at the time it was applied. A more process-orientated approach focused on HFI and management was taken, resulting in the observations listed below: 1. Numerous PPE assemblies were in use for different operational roles. Several of these exceeded the mass limit set in the appropriate standard (Ministry of Defence, 2008) for a maximum one third of lean body mass. No assembly had been validated against an operational requirement to ensure that degree of protection met the requirement. The assemblies did not offer 'scale able' protection (adaptability to different security requirements). 2. Officers worked a 12-hour shift with one hour for lunch after 6-hours on duty. This does not accord with the basic principles of work physiology - when physically arduous work is carried out, short periods of work should be interspersed with short rest periods to prevent the accumulation of fatigue. 3. There was no system of health surveillance in operation: absenteeism due to musculoskeletal ill-health was not monitored; high risk areas had not been identified and the efficacy of any improvements could not be monitored. 5
RS Bridger
4. Human Factors Integration was not apparent in the procurement process. There was a lack of user-consultation and user-involvement. 5. The arrangements in place were characterised by low-level complexity that was unlikely to be manageable by a strict top-down policy framework. Rather, the policy should direct those responsible for health and safety to seek local solutions at individual workstations to comply with health and safety legislation. All of the above can be traced back to either an absence of requirement(s) or violation of a generic HF requirement (Table 1). The solution is not to change the equipment or train the guards, but to improve the control processes that govern how the work is planned, conducted and reported.
CONCLUDING REMARKS: HFI AND THE ROLE OF HF&E Large organisations often lack processes for integrating specialist knowledge into their operations and planning. HFI is a management process for exploiting HF&E knowledge and skill in the systems lifecycle. Functional HF&E plays the major role in requirements specification, early task analysis and the analysis of legacy data. Traditional HF&E is essential for drafting the ITEAP and for designing, conducting and reporting the findings of acceptance testing. Both are needed for successful integration of HF&E and the employment of properly trained HF&E specialists should always be a contractual requirement in all large scale projects. Project teams are usually better at writing technical requirements than requirements for HF&E because they lack the expertise and understanding of what needs to be done. 'If it's not a requirement, it doesn't get done' The greater the uncertainty about what we are making, the newer the wine and the newer the bottles, the greater the need for HFI: All things connect All things are bound together What happens to the Earth Happens to the Children of the Earth Man has now woven the web of life He is but one thread Whatever he does to the web He does to himself How can one sell the air? Funerary Oration of the Native American Chief Seattle.
REFERENCES Bridger, RS. 2009. Introduction to Ergonomics. CRC Press, Boca Raton, Fl. DeGreene, K.B. 1978. Force fields and emergent phenomona in sociotechnical macrosystems: theories and models. Behavioural Science, 23:1-14. DeGreene KB ( 1980). Major conceptual problems in the systems management of humanfactors/ergonomics research. Ergonomics, 23, 3-11. DeGreene KB. 1986. Systems theory, macroergonomics and the design of adaptive organisations. In: Human Factors in Organisational Design and Management: II, edited by O Brown Jr and H Hendrick, North Holland, New York. Gharajedaghi J.1985. Towards a Systems Theory of Organisation. Seaside, California Intersystems Publications. Haslam, R., Waterson, P. 2013. Editorial. Special issue on Ergonomics ans sustainability.Ergonomics,56:343347. Leveson, N. 2011. Engineering a Safer World: system thinking applied to safety. MIT Press Wilde, GS 1994. Target Risk. PDE publications, Toronto, Canada.
6
