People often ask me about Human–Systems Integration (HSI). So, I put together this high-level primer, along with a corresponding infographic, describing HSI and why it’s important to use in all complex, socio-technical system design projects.
What’s HSI, by definition?
HSI is a philosophy and set of processes that focus on systems-level human performance concerns throughout a system’s entire life-cycle. Its purpose is to mitigate the risk of downstream system failure. More formally, the Department of Defense (DoD) Handbook on human engineering process offers this definition:
HSI is a comprehensive management and technical strategy to ensure that human performance, the burden design imposes on manpower, personnel, and training (MPT), and safety and health aspects are considered throughout system design and development. HSI assists with the total system approach by focusing attention on the human part of the total system equation and by ensuring that human-related considerations are integrated into the system acquisition process (MIL-HDBK-46855A, Section 5.1.2, 1999, p. 19).
Like other systems-level engineering approaches, HSI is a high-level, multi-disciplinary design process in which each subsystem, and its interactions with other subsystems, are carefully crafted so as to maximize overall system performance. In other words, designing with the sum of the parts in mind, rather than simply maximizing the performance of each, individual component. However, unlike traditional systems engineering, HSI also emphasizes human performance throughout.
Good HSI practice promotes several core principles:
- Emphasize human performance issues early in the design process
- Emphasize system-level outcomes (across the HSI domains)
- Focus on life-cycle (not just immediate) costs/benefits
- Realistically facilitate multidisciplinary design processes
First, HSI continuously emphasizes human performance during the research, design, and development stages of the system acquisition process. In other words, HSI ensures “the human in acquisition programs is given equal treatment to hardware and software” (FY09 DoD HSI Management Plan, p. 3). To be clear, HSI practitioners consider all potential human interactions with a system across its full life-cycle, but their work primarily occurs during earliest stages of the life-cycle, as they help design the future system.
Second, HSI attempts to optimize overall system-level performance. This means that researchers and developers evaluate outcomes, such as costs and benefits, at the comprehensive system level and not simply at the individual component levels. That is, HSI practitioners strive to achieve the greatest total efficiency and effectiveness for a whole system, within given resources; this may mean that individual components, by themselves, aren’t perfect. In addition to considering traditional hardware, software, and administrative components of a system, HSI practitioners recognize several human-centric domains of interest, including manpower, personnel, training, safety and occupational health, human factors engineering, habitability, and survivability.
|Manpower||People necessary to operate, maintain, and support a system|
|Personnel||Knowledge, skills, and attitudes the system’s operators, maintainers, and support personnel must possess|
|Training||Training required to support a system’s operators, maintainers, and other support personnel|
|Safety/Health||Considerations for acute or chronic illnesses, disabilities, or death for system operators, maintainers, and other support personnel|
|Human Factors||Considerations for potential injury, errors, or inefficiencies caused by the physical, cognitive, or affective aspects of human–machine interfaces|
|Habitability||Physical conditions, living conditions, and, if appropriate, personnel services (e.g., mess hall) affecting system performance|
|Survivability||For systems that might encounter threats, the potential harm to systems’ operators, maintainers, and support personnel as well as ability to mitigate this damage|
Third, HSI practitioners take a long view of their systems’ performance, attempting to maximize benefits—while controlling costs and mitigating risks—across a system’s entire life-cycle. Many different life-cycle models exist, but in general, they all include initial development phases, followed by implementation, operation, and eventual retirement stages. For example, Bahill and Dean (2009) surveyed a variety of systems engineers who, by consensus, offer these seven typical system life-cycle phases: (1) Discovering system requirements; (2) Investigating alternatives; (3) Full-scale engineering design; (4) Implementation; (5) Integration and testing; (6) Operation, maintenance and evaluation; (7) Retirement, disposal and replacement.
Finally, in order to achieve the goals just described, HSI practitioners must facilitate a multidisciplinary design process. This often entails “translation” between specialists in different disciplines (e.g., between sociologists and computer scientists) and the negotiation of requirements among interested parties (e.g., brokering compromises between training specialists, manpower analysts, and operational stakeholders). In practice, this means that HSI practitioners spend time eliciting inputs from various stakeholders, documenting assumptions, clarifying friction points, and developing various communication devices that transform these requirements and analyses into meaningful, unambiguous formats (e.g., personas, scenarios, various diagrams, storyboards, concept maps, interface mock-ups, and other prototypes).
HSI Risk Mitigation
The ultimate purpose of HSI is to mitigate the risk of system failure. Systems can fail for a wide variety of reasons. Heuristically, these reasons fall into two large categories: technological issues (e.g., flaws in the system design) and logistical issues (e.g., budgetary and schedule issues). Failure may occur during any phase of the system life-cycle. For example, a project may be cancelled during the engineering design phase because of cost and schedule overruns. Or a system may be terminated before the end of its planned life-cycle because it suffers from high operating costs and becomes too expensive to maintain. According Pew, Mavor, et al. (2007), three of the most common causes of system failure include:
- Underutilization or disuse due to difficult, inefficient, or dangerous design
- Serious compromises in system performance from human error
- High operations and maintenance costs and challenges
Why use HSI?
Technically, HSI is part of a good Systems Engineering approach. Too often, however, organizations neglect to include human performance considerations in their SE processes. Over time, this has led the US Department of Defense and other federal agencies to develop guidelines mandating or instructing the use of HSI (e.g., Office of the Secretary of Defense, 2011; Defense Acquisition University). For example, the DoD “5000 Series” formally directs the use of HSI in all DoD system acquisitions processes. However, compliance isn’t the only reason to use HSI—it makes good business sense, too!
HSI has a high Return on Investment (ROI)
Published case studies repeatedly show high ROI from HSI efforts. For instance, a review by Harold Booher lists an Air Force program that had a 50:1 ROI (i.e., a savings of $50 for every $1 initially spent on HSI) as well as two different Army helicopter programs that had 44:1 and 22:1 ROIs, respectively. The Commonwealth of Australia also commissioned a literature review of HSI ROI, which includes several dozen quantitative accounts. The coy title of their review is Human Systems Integration is worth the money and effort!—so you can guess what they found. :-)
Why does HSI have such great ROI? Because it addresses some of the major reasons why systems fail. As the Pew, Mavor, et al. textbook explains: Many systems failure because human performance considerations weren’t sufficiently incorporated into their requirements. And we’re talking about a lot of failure, here. For technology projects in the United States, only 34% of are successful; 15% completely fail, and 51% are partially successful. These projects most frequently fail because “(1) an inadequate understanding of the intended users and the context of use, and (2) vague usability requirements, such as ‘the system must be intuitive to use’” (p. 191). HSI helps mitigate these major risks, and when early in the system design process, it ultimately helps reduce the chances of system underuse, reduced operational performance from human errors, and other common causes of system failure.
What do HSI practitioners actually do?
At a high level, HSI tasks seem similar to Systems Engineering tasks, but HSI practitioners emphasize the human element in these activities. Some common categories of HSI tasks include the following:
- Identify goals and write requirements for socio-technical systems
- Help design solutions to meet the requirements
- Perform system scoping to maximize total life-cycle ROI
- Identify and mitigate life-cycle risks with test,evaluation, and evidence-based design
- Actively facilitate multidisciplinary design
HSI vs. Similar Disciplines
HSI is related to several other disciplines. Most notably, HSI closely resembles Systems Engineering, and formally, an effective SE process should already include HSI processes. In real-world practice, however, system engineers often inadvertently neglect human concerns. That is, “there has been a continuing concern that, in each phase of development, the human element is not sufficiently considered along with hardware and software elements” (Pew, Mavor, et al. (2007), p. 9). It was for this reason that HSI developed into a unique specialty area.
Similarly, from a definitional perspective, “HSI is synonymous with the traditional definition of human factors in its broadest sense” (Malone, Savage-Knepshield, and Avery, 2007). Again, in real-world practice, researchers tend to conceptualize Human Factors and Ergonomics (HF/E) from a more limited perspective, emphasizing immediate operator issues and neglecting broader life-cycle considerations, the range of applicable domains, and system-level emergent properties. Even Macroergonomics, a subspecialty of HF/E that incorporates more strategic and systems-level perspectives, still lacks HSI’s emphasis on optimizing (trading off) among the components of a system, seeking to maximize ROI across a system’s total life-cycle, and actively facilitating multidisciplinary system design.
Ultimately, HSI fills practical gaps in both Systems Engineering and HF/E. It draws upon systems engineering perspectives to underscore broad-spectrum system concerns and life-cycle management issues, and it pulls methodologies and best practices from HF/E, in order to give emphasis to the human in complex system.
In sum, HSI is an applied, practical discipline intended to spotlight human performance concerns (broadly defined) during the early design and development phases of a system. HSI practitioners take a broad, long-term view of a system’s performance, and they try to minimize (human-centric) cost, schedule, and performance risks across the system’s life-cycle while working within programmatic limits (i.e., cost and schedule requirements). Many agencies mandate the use of HSI, and when applied effectively—and early enough in the system design process—it yields massive ROI. So, what are you waiting for!? Go get some good HSI right now! :-)