Abstract
Socially oriented approaches to work systems design are increasingly important as new and disruptive technologies become more prevalent. Existing approaches used by organisations to integrate such technologies are often techno-centric and do not adequately consider human issues. Sociotechnical systems (STS) tools are intended to ensure that the technical and organisational aspects of a system are considered together, and given equal attention. However, they are predominately applied late in the design process, limiting their impact. In this article, we outline an STS approach to the early-phase development of a complex work system. The case study illuminates how an STS approach can facilitate the inclusion of socially oriented factors into the design process. We close with recommendations to guide the early-phase application of STS principles in other industries and contexts.
JEL Classification:
Keywords
1. Introduction
New digital technologies are radically transforming the nature of work and work systems themselves. These new technologies bring tremendous opportunities for work and society. In order to realise the benefits, it is likely that work systems will need to incorporate growing complexity. The degree of tight coupling between human and machines – and indeed between machines – will increase, resulting in highly interdependent and networked systems (Narula, 2014). The rapid pace of technological change also generates complexity and uncertainty (Cascio and Montealegre, 2016). To effectively integrate humans in these networked and complex work systems, organisations will need to proactively consider how people and technologies operate together, early in design, when the technologies are being designed and implemented. In this article, we detail a sociotechnical systems (STS) approach to integrate humans in increasingly complex technical systems.
The challenges faced by organisations seeking to adopt complex and advanced technologies are not new. Large-scale complex engineered systems (LSCES), such as aerospace, large maritime and major civil infrastructure (e.g. electrical power grids), have faced similar design challenges for decades. Just like the complex work systems of the future, LSCES push the performance envelope of existing systems and rely on advanced technologies, many of which may not be ‘commercial off the shelf’ (Bloebaum and McGowan, 2012). LSCES, similarly to future complex work systems (FCWS), are often bespoke. Exemplar work systems are few and far between, and the differences between existing and new systems are often radical (e.g. the development of military systems, such as submarines). In these cases, limited empirical data or ‘road maps’ exist to guide technological integration and system design. Most often, LSCES design and implementation involve systems engineering methods and frameworks, such as Model-Based Systems Engineering, a formalised application of modelling and simulation to support system requirements, design, analysis, verification and validation activities (Herzig et al., 2011; Lightsey, 2001). These approaches provide a structured yet flexible design process to reduce uncertainty and manage complexity (e.g. by breaking down the system design into manageable chunks).
Despite the incredible technological complexity of LSCES, they are – like FCWS – inherently sociotechnical in nature, because they are designed and operated by humans (Bloebaum and McGowan, 2012). And yet, likely due to the inherent technological complexity of these systems, their design is typically techno-centric in nature (Baxter and Sommerville, 2011), with little attention being given to how the technology should be designed to better meet human needs (Parker and Grote, in press). Analyses suggest that the failures of large complex systems to meet their deadlines, costs and stakeholder expectations are often due to inadequately considering human and organisational (i.e. ‘social’) elements in the design process (Baxter and Sommerville, 2011; Bloebaum and McGowan, 2012). As a result, scholars and practitioners have advocated for approaches that jointly consider social aspects, as well as technical aspects, in work system design (Bloebaum and McGowan, 2012).
There are many design approaches and frameworks which guide and support joint STS design (e.g. see Grote et al., 2000; Hughes et al., 2017; Nadin et al., 2001; Read et al., 2015). However, the uptake of STS approaches remains limited (Baxter and Sommerville, 2011; Clegg, 2000). A lack of widespread application has been partly attributed to issues with existing tools and approaches, such as their coverage, usability, lack of transferability or failure to suggest design solutions (Mumford, 2006; Waterson et al., 2015). A lack of awareness of the usefulness of these tools among systems engineers and technologists has also been suggested (Doherty, 2014). When these tools are employed, it is often at the late stages of design (Clegg, 2000), when many of the systems’ technologies have already been selected and developed (Majchrzak and Finley, 1995). At this point, the opportunity to adapt the work systems on the basis of socially oriented design criteria is constrained by the maturity of the development process – much of the design is already ‘set in stone’. We propose that STS analysis can more fully consider the potential human implications of these technologies if it occurs earlier in the process.
In particular, when applied at the early stages of design, STS principles can inform system definition, including how the systems’ technologies are designed and acquired. However, while the undefined nature of the system presents opportunity for impact, it also presents a challenge. To adopt STS methodologies from design outset, there is a need to consider the potential implications of the interaction between humans and technical systems which are yet-to-be in existence. This challenging application context may be why there are not many recorded examples of integrative tools and practices such as STS approaches being used for early-phase design, particularly for the first instance of a new type of system (Baxter and Sommerville, 2011).
In this article, we outline an approach developed to support the inclusion of STS principles in an early-phase complex system design, a military submarine. The objective was to inform the staffing requirements of the future system. This approach was designed to integrate with the formally defined system development process, to facilitate a higher degree of socially oriented design than would otherwise have occurred. We summarise key aspects that were instrumental to the success of the project, as well as our learnings on the application of a sociotechnical design process in a complex future work system development effort.
2. About the context
The approach outlined in this article was conducted as part of a large-scale research program 1 to inform the nature of crew endurance within potential future submarine designs. The objective of the overall design effort, embarked upon by the government, is to replace the existing fleet, which are approaching their decommissioning in approximately 20 years’ time.
At the time of the study, system design was in an early phase, with the first completed submarine expected in approximately 15 years’ time. As a result, many social and technical system elements, such as the technologies to be employed, functional allocations, automation capabilities and the likely human capital of the future workforce, were still unknown, or poorly defined. However, these STS elements are likely to have substantial implications for the design of the work and crew and need to be considered in early stages of the design process.
Determining staffing requirements early in the design has clear advantages. The physical specifications of the platform are defined early in the system’s design. Underestimating staffing requirements may result in a submarine which is too small and unable to sustain the crew numbers required to reach the expected level of capability without critical implications for work overload and fatigue (Moffitt, 2008). Therefore, considering staffing requirements early on in development ‘before the steel is cut’ was important to facilitate development of size and physical layout specifications which jointly considered social and technical system elements.
At the outset of this project, researchers were invited to assess major crew-endurance implications (e.g. sleep opportunities and workloads) of the staffing requirements proposed for the future submarine. Researchers introduced STS principles to evaluate staffing requirements. This process highlighted potential inadequacies in functional distributions and crewing numbers. As a result, the approach evolved from one of design evaluation to one of developing recommendations to facilitate design decisions and systems development. In this respect, the introduction of STS principles to the system design process was indirect. In what follows, we elaborate how we evaluated and informed the staffing requirements for a future submarine and encouraged broader consideration of work design and other socially oriented issues, through the application of STS principles.
3. A four-phase iterative approach to enable early-phase STS design
A four-phase iterative approach (depicted in Figure 1) was developed to support early-phase STS design. The objective of the first phase was to develop a contextualised understanding of the future work system. In the second phase, an appropriate scope for STS analysis was defined on the basis of the system development efforts. In the third phase, the analysis was conducted. Finally, the objective of the fourth phase was to define/refine ‘social’ elements of future work system (e.g. the need for certain personnel to be multi-skilled) and develop recommendations for technical system definition and design (e.g. messing requirements to accommodate the proposed watchkeeping approach).
The four phases of an iterative sociotechnical systems design approach to facilitate early-phase system development.
In each new iteration of the approach, the findings of the previous iteration and any new design decisions informed an updated future work system context. The approach was then re-applied to validate the Phase 4 outputs surfaced in the previous iteration, and to surface further social system definition and technical recommendations.
3.1. Phase 1: understand the system context
The purpose of Phase 1 was to understand the system context. This was accomplished by identifying the stakeholders involved (Phase 1, Step 1), and gathering data on the sociotechnical elements of the current (Phase 1, Step 2) and future work systems (Phase 1, Step 3). The nature of system design necessitates that design decisions and system specification is ongoing (Hirshorn, 2016). As such, although there was a defined ‘information gathering’ phase, ongoing efforts were made to seek and integrate new knowledge which would facilitate an up-to-date understanding of the future work system.
Phase 1 was based on steps outlined in the Systems Scenarios Tool (2017), developed by Hughes and colleagues. This tool highlights the need to involve key stakeholders, gather data on the current work system and consider alternate future work systems. Given the future submarine had already been broadly defined, considering the future system was largely a data-gathering activity, rather than scenario building, as is the case in the Systems Scenarios Tool.
Similar to other STS methods, information was acquired through a variety of channels – both formal and informal – such as discussions with stakeholders and end-users, workshops and structured interviews, empirical literatures, field studies and internal reports (e.g. Clegg et al., 1996; Hughes et al., 2017). To support a structured and systematic approach to knowledge gathering activities, the sociotechnical hexagon (Davis et al., 2014) was utilised to codify knowledge of the system context. The sociotechnical hexagon is a tool which can provide a simplified representation of the interrelated nature of the social and technical work system elements.
The framework depicts six interrelated elements, representing sociotechnical aspects of a work system, and the relationships between them: goals, procedures, culture, people, infrastructure and technology (see Figure 2).
The sociotechnical hexagon.
3.1.1. Phase 1, Step 1: identify and involve key stakeholders
Stakeholders include those involved in the current and future work systems (e.g. operational personnel), as well those concerned with future system design (e.g. the shipbuilders) (Sharp et al., 1999). Many projects fail where conflicting stakeholder needs and agendas are not managed (Bryde and Robinson, 2005; Taysom and Crilly, 2017). As such, researchers prioritised stakeholder engagement and sought to understand stakeholders’ perspectives and agendas.
The STS approach was not formally included in the system development process. Not being a mandated requirement, identifying and accessing relevant stakeholders proved challenging. In an effort to increase stakeholder reach and buy-in, researchers sought to support the goals of the stakeholder groups wherever possible (Lawrence, 2002), even when these were of limited direct relevance to the project. This entailed flexibility on the part of the researchers, and a willingness to try to understand both social and technical system elements.
Over the duration of the project, a focus on stakeholder needs was particularly important to form additional stakeholder connections. For example, in many cases, researchers were requested to attend meetings in order to share findings peripheral to the overall STS project objectives. It is primarily through attendance in meetings such as these that researchers were able to form connections with additional stakeholders, which was important for gaining commitment to a more STS-oriented design approach.
The system and design stakeholders
Points of contact included individuals within the military workforce planning team, the acquisition team, design contractors (e.g. shipbuilders, combat system designers), the research sponsor organisation, the military command unit and operational personnel.
In this system design effort – from these researchers’ perspective – it was often the case that the differing expectations of all stakeholders could not be simultaneously achieved. As such, to progress design decisions, trading-off the needs of one stakeholder against another was often required (Chinyio and Akintoye, 2008). Often these trade-offs were socially versus technically focused. For example, where the acquisition team emphasised manufacturing costs and space trade-offs and thus a reduction of crewing numbers, the operational personnel emphasised crew endurance and capability and thus advocated for an increase in number of crew. The research team focused on surfacing these trade-offs and making sure that they were explicitly addressed.
3.1.2. Phase 1, Step 2: collect existing work system data
Immersion into the organisation and existing work system (e.g. spending time on the submarines) facilitated contextual understanding (Ybema et al., 2009). In this project, a long-duration engagement and complimentary parallel activities undertaken by the research group (e.g. field studies which captured the effect of the operational environment on human endurance) were instrumental in building a rich contextualised understanding of the work system. Figure 3 shows examples of the STS elements of the current submarine, codified through the sociotechnical hexagon.
Examples of sociotechnical system factors considered to facilitate understanding of the current work system.
The military submarine work system is highly complex. As such, researchers did not hold any existing knowledge regarding the technologies or roles on board, the training and career pathways, or the organisational hierarchy and culture. The more a context deviates from one that researchers are familiar with; and the more difficult it is to acquire a contextualised understanding (e.g. a lack of empirical literature to facilitate an understanding of the submarine work context), the greater the degree of time investment necessary to facilitate this understanding. Considerable time was spent on this step, yet obtaining this information was essential for establishing the knowledge and credibility to encourage the inclusion of social factors in design.
3.1.3. Phase 1, Step 3: collect design and future work system data
The early-phase nature of the development efforts described here denoted a high degree of unknown and poorly defined future work system elements (Lightsey, 2001). Therefore, understanding the future work system was achieved through consideration of the following:
(a) The sociotechnical environment of the existing military vessels (identified in Phase 1, Step 2);
(b) Relevant systems design details, including ‘known’ or likely design decisions (e.g. the addition of console displays which will integrate data across technical systems);
(c) Likely alignment/dissimilarities between the existing work system and future work system (e.g. better platform endurance in the future submarine, suggesting crew may be required to sustain operations for longer durations).
The forecasted sociotechnical elements of the future work system were again codified through the sociotechnical hexagon (Davis et al., 2014). In addition, because sociotechnical system design practice is itself a sociotechnical system (Clegg, 2000), the design process and relevant factors were also captured, and coded through the sociotechnical hexagon. Figure 4 provides examples of STS factors considered to inform the future work system and development process.
Examples of sociotechnical system factors considered to facilitate understanding of the future work system (depicted by the solid-line borders) and work system design process (depicted by the dotted-line borders).
One particularly relevant sociotechnical element of the future work system was the first estimate of the staffing requirements proposed for the future system. This included recommendations for total personnel numbers, how these personnel should be divided between functions, and a proposed watchkeeping roster. Researchers adopted this first estimate as a basis to analyse and inform the staffing requirements of the future system (see Phase 3, Step 2 for analysis description).
3.2. Phase 2: outline the scope of analysis
The purpose of Phase 2 was to identify the scope of the STS analysis such that the STS analysis outputs (Phase 4) could support system development. In practice, this included ensuring the STS future system elements were selected appropriately (Phase 2, Step 1); explored at the right level (Phase 2, Step 2); and analysed in a way which was relevant and useful (Phase 2, Step 3).
3.2.1. Phase 2, Step 1: define system boundaries
To establish practical boundaries for project scope, only STS future system elements which were likely to be associated with staffing requirements were analysed. For example, technologies such as autonomous underwater vehicles will impact operator and maintenance requirements (Griffiths, 2002) and were included in the analysis. Conversely, whether the batteries employed on the future platform are lithium iron or lead acid was likely to have only a minimal effect on staffing requirements, so this element was not included. We refer to the STS elements contained in the boundaries of analysis as the ‘system of interest’.
System boundaries were also necessary to practically constrain the number of interdependencies between STS elements in later analyses (Phase 3). The rationale for defining a system of interest was derived from systems engineering frameworks, which partition the larger system into manageable components. These components are then designed, tested and validated before being reintegrated into larger wholes (Lightsey, 2001). In this project, the system of interest comprised the sociotechnical elements expected to impact, or be impacted by, the future submarine staffing requirements. The data gathered in Phase 1, Step 3 described above supported the definition of this system of interest.
In the early phases of system development, it is likely that many future system elements will be poorly defined, or even undefined. In the cases where these STS elements are necessary to inform the analysis, we suggest that these elements are included within the system of interest, and an explicit assumption is made that these elements will not differ between a reference system – in our case, the current submarine – and the future system. This ensures that if future design decisions contradict assumptions, these discrepancies can be easily identified, and corrected for, in new analyses. For example, at the time of the project, the future submarine maintenance philosophy had not been determined. This decision will have a significant impact on the maintenance function, including number of crew required. As such, it was assumed that the future submarine maintenance requirements would remain the same as the existing submarine, and current system maintenance requirements were included in the system boundaries. In these cases, the data gathered in Phase 1, Step 2 were utilised to ‘fill in the blanks’ within the system of interest.
3.2.2. Phase 2, Step 2: consider the level of abstraction
The depth of the analysis, or level of abstraction, will be dependent on the current phase of system development and the objective of the STS analysis (Rebitzer et al., 2004). In the current project, the need to consider a broad range of future work system elements, many of which were underdefined, resulted in a decision to conduct the analysis at high level of abstraction.
If abstraction is too high, important STS elements in the system of interest might be excluded from the analysis. This omission will increase the risk that STS analysis fails to predict the likely behaviours of the sociotechnical elements in the future work system (Johnson, 2006). For example, analysing staffing requirements of the future military submarine without consideration of the necessary domestic and ancillary tasks could result in inaccurate predictions of crewing numbers, and thus result in a future work system with too few crew to support the required work.
Conversely, an abstraction level which is lower than can be supported by the current system design phase increases the risk that the results of STS analysis are made on the basis of inaccurate predictions. For example, evaluating and informing the work design of a job role, before the technologies the operator will interact with are understood is unlikely to yield useable design recommendations. In these cases, we suggest that exploring STS implications that are highly contingent on future design decisions are delayed or ‘parked’ such that STS analysis informs the current or proximal – rather than distal – design-phase decisions.
Nevertheless, there will be cases where early-phase STS analysis at a low level of abstraction would benefit future design decisions or technological development. For example, designing a console interface is a detailed design decision and requires a low level of abstraction. However, informing how console design can support operator performance and situational awareness may require long analysis lead times (e.g. developing simulations, undertaking experiments). In cases that involve long lead times, we suggest early-phase STS analysis at a low level of abstraction is appropriate.
3.2.3. Phase 2, Step 3: identify objectives and evaluation criteria
To facilitate alignment of the STS approach with the existing design efforts, researchers considered both the work-system goals of the future submarine (e.g. enhanced endurance, range and capability) and those current design-phase goals which could be informed by STS analysis (Lightsey, 2001; Rebitzer et al., 2004). In this case, the design question addressed by researchers was the size of the vessel, as defined by the staffing requirements necessary to support increased submarine capability, endurance and range.
Researchers then developed STS analysis objectives in close collaboration with stakeholder groups (Grote et al., 2000; Hughes et al., 2017; Nadin et al., 2001). The objectives identified were operational functionality (i.e. are the crew numbers sufficient to undertake all the necessary work activities?) and crew endurance (i.e. is the rest and recovery afforded to the crew in the future submarine adequate in supporting them to meet the work system goals of increase capability, endurance and range).
Evaluation criteria were then generated based on these objectives. For operational functionality, criteria were generated in consultation with the operational personnel, who held the greatest level of knowledge regarding requirements to achieve individual and team work activities in the current submarine (Gasson, 2003). These criteria included the following:
Crewing numbers should allow for safe undertaking of all work activities (e.g. transiting/coming into harbour).
There must be a sustainable means to undertake high intensity operations without fatigue implications for the crew (e.g. no need to draft sleeping personnel to achieve the personnel numbers necessary).
When seeking to identify crew endurance criteria, it was evident that operational personnel lacked the necessary human sciences expertise and struggled to accept the need for socially oriented criteria. Consultation often surfaced an ‘if it ain’t broke don’t fix it’ attitude. Furthermore, when stakeholders involved in system design were engaged, they often questioned the benefits of socially oriented criteria, likening them to investment in activities of little perceived value such as ‘staff wellbeing’. As a result, researchers developed crew endurance-related criteria based on previous research and then endeavoured to socialise these criteria with the stakeholders.
Demonstrating expertise and using rational persuasion has been shown to enhance influence in project management (Lee and Sweeney, 2001; Thamhain and Gemmill, 1974). As such, in order to ‘sell’ the importance of these socially oriented endurance requirements to the stakeholders, researchers framed them in terms of their operational benefits (Aguinis et al., 1994; Lee and Sweeney, 2001). For example, the researchers presented research which demonstrated the cognitive decrements associated with lack of sleep (Killgore, 2010), or the risks of error when job roles comprise a high degree of passive monitoring (Young and Stanton, 2002). In the end, crew endurance requirements included the following:
The watchkeeping routine (i.e. the shift roster) supports good sleep hygiene practices.
Length of time-on-task does not elicit excessive cognitive demands and workloads.
Principles of good work design guide the allocation of functions/tasks where feasible.
Time off-watch is facilitative of recovery.
In iterative applications of this approach, researchers expanded the evaluation criteria. The generation of additional criteria was informed by relevant socially oriented criteria (e.g. training pipelines and career progression), as determined by the research team; the findings surfaced in Phase 3 in the previous iteration of the approach (e.g. a particular job function which required more operators at a particular operational condition); and additional concerns highlighted by the system designers (e.g. questioning how technological handover support may impact the operators). Importantly, as viable design recommendations were generated by the research team as a result of the STS approach, stakeholders became more open and supportive of socially oriented design criteria.
3.3. Phase 3: analyse the system of interest
The purpose of Phase 3 was to assess the system of interest: the sociotechnical future work system elements predicted to impact, or be impacted by, the future submarine staffing requirements (see Phase 1, Step 3 for a description of the proposed staffing requirements). Due to the early phase of system development, the future system technologies were not yet defined enough to facilitate high-fidelity system simulations or modelling activities (e.g. a simulation of the operations room). Therefore, conceptual walkthroughs of the work system across a variety of operational activities and scenarios were judged to be the most appropriate means of ‘simulating’ and testing the staffing requirements of the future submarine (Liu et al., 2009; Sweet et al., 2002). The walkthrough methodology was developed by adapting the commonly employed STS practice of using scenarios to explore potential configurations of future work systems (Clegg et al., 1996; Hughes et al., 2017), and a usability inspection method, the cognitive walkthrough (Spencer, 2000). The cognitive walkthrough describes user interfaces in order to walkthrough interface design, and as such can be applied early in the design process (Lewis and Rieman, 1994).
Careful consideration was taken to select participants who could best inform the workshop objectives, as well as provide information on the future submarine (Phase 3, Step 1). In the workshop, participants assessed the staffing requirements of the future submarine (Phase 3, Step 2). Phase 3 generated the data necessary to provide design recommendations (Phase 4).
3.3.1. Phase 3, Step 1: ‘Set the scene’ for analysis
Workshops were developed to provide a holistic view of the work context from different perspectives. The operational personnel (i.e. submariners) – who hold contextual knowledge regarding the operational and work system context (Abras et al., 2004; Gasson, 2003) – were identified as workshop participants. A diverse range of operational personnel spanning across levels (e.g. lieutenant through to trainees) and qualifications/jobs (e.g. technicians, communication operators, navigators) were selected.
It was crucial that participants understood and remained cognisant of the likely differences between the current submarine and the future work system of interest. Therefore, participants were provided with information on the social and technical elements of the system of interest, prior to conducting the STS analysis (e.g. detail on the proposed staffing requirements and new technologies; physically walking through a set-up of future operations room which demonstrated console placements).
Stakeholders with deep knowledge of the system of interest (i.e. an understanding of the development process and the likely constraints and capabilities of the future submarine and its technologies) were also present at the workshops to provide future-focused contextual information to the participants. The presence of these ‘future work system experts’ allowed participants to ‘prototype’ thoughts and ideas on the future work system and receive feedback on the viability of their suggestions. In addition, future work system experts were able to challenge participants who were considering their current practices, rather than the future system, in their analysis (Burke and Baldwin, 1999). For example, when a participant suggested that the ‘driving’ function would require a dedicated operator, they were reminded that new technologies would automate this task in the future system.
3.3.2. Phase 3, Step 2: analyse future system data
Analysing the system of interest was achieved through conceptual walkthroughs of work activities, of varying operational intensity, projected in the future system. Solving complex problems and generating enhanced design solutions are supported through simulations and visual prototyping (Goldschmidt and Smolkov, 2006). Therefore, the walkthroughs were supported by a physical representation of the future system (i.e. a visual A0 cross-section representation of the future submarine) and movable avatars representing job roles proposed in the first estimate of the staffing requirements (see Phase 1, Step 3). Exemplar work system activities – undertaken by the existing platform which would also need to be performed by the future platform – representing low, normal, moderate and high operational intensities, were selected for assessment (e.g. returning to periscope depth). This allowed the staffing requirements to be assessed and adapted based on the full range of operational intensities that may occur.
The system of interest was assessed against the assessment criteria established in Phase 2, Step 1 (i.e. the staffing requirements of the system of interest required to support operational functionality and crew endurance). For each scenario, participants placed the avatars that represented the job roles (and personnel numbers) required to perform the activity on the A0 cross section (e.g. 12 combat system operators spread across various functions, 3 technicians). Operational functionality for each operational intensity level was deemed ‘acceptable’ at the point where the minimum required personnel numbers to undertake a scenario safely had been allocated.
If the workshop participants could not achieve acceptable levels utilising the job roles suggested in the first estimate of staffing requirements, additional avatars (i.e. job roles) were added to the job functions where required (e.g. an additional combat system operator is required to staff a console for a particular work function), until minimum personnel levels were achieved (e.g. 13 combat system operators, 3 technicians). This process allowed the staffing requirements to be adapted such that they supported operational functionality. Following this, the crew endurance criteria were evaluated based on the adapted staffing requirements.
Assumptions, risks, caveats and any recommended solutions that surfaced during analysis were recorded. An example of this was the assumption that particular tasks would be fully automated. The results of the workshop process suggested that typical operations could not be sustained with the proposed first estimate staffing requirements (i.e. operational functionality category, criteria 2 could not be supported) and therefore the requirements required revision.
3.4. Phase 4: inform future system definition
The objective of Phase 4 was to derive concrete design recommendations to feed back into the development process and facilitate socially oriented design and planning decisions. This phase involved developing social system recommendations which addressed the caveats, risks, solutions and failures identified in the Phase 3 analysis. For example, participants concluded that there would be too few operators staffing the operations room if the proposed watchkeeping routine was adopted. As such, researchers developed and recommended an alternate watchkeeping approach (Phase 4, Step 1). In the case where socially oriented recommendations were unable to address caveats (e.g. the need for a task to be automated in order to allow an operator to achieve their goals), researchers reported these findings to the relevant stakeholders and provided technical recommendations (Phase 4, Step 2). Researchers first sought to provide ‘social’ solutions and recommendations, as ‘social systems’ design is less costly and does not require extensive and complex technological development efforts.
3.4.1. Phase 4, Step 1: generate ‘social system’ recommendations
The social elements within the system of interest were adapted based on the results of Phase 3, Step 2. Similar to other STS tools, the assessment criteria generated in Phase 2, Step 3 guided the process of developing recommendations (e.g. see Grote et al., 2000). For example, findings from the first application of the approach suggested that for staffing to be sufficient during typical operations, crew numbers on each watch would need to increase. To address this, researchers developed a recommendation to support increased on-watch crewing through an ‘on-call’ system, which theoretically supported all the operational functionality and crew endurance criteria.
The recommendations surfaced through the STS approach which were deemed ‘viable’ by stakeholders were then explored in the following iteration of the STS approach. For example, the ‘on-call’ approach we recommended was tested in the second iteration in order to determine whether this recommendation would indeed meet the assessment criteria when evaluated by the end-users. To increase the likelihood of uptake by systems design stakeholders, researchers advocated for the recommendations which showed promise following further STS analysis. Similar to ‘selling’ the socially oriented assessment criteria, researchers also emphasised the operational benefits of these recommendations to stakeholders (Lee and Sweeney, 2001).
3.4.2. Phase 4, Step 2: generate ‘technical system’ recommendations
When issues could not be addressed by adapting the ‘social system’, technical recommendations were developed. Drawing from the approach outlined by Grote et al. (2000), the goal of this step was not to produce a detailed technical solution, rather to develop design recommendations/requirements which would have to be explored in respect to their technical feasibility, and progressed by the engineers and technical specialists.
In the current project, for example, participants highlighted issues regarding handover requirements which could not be effectively solved through process-oriented recommendations. As such, a recommendation to consider technical solutions which could increase efficiency and situational awareness during handovers was provided to the acquisition team, who manage the requirement setting process and can request specific technological capabilities.
4. Outcomes of the STS process
In the research programme to date, three iterations of the STS approach have been performed. Based on what is currently understood about the future work system, the staffing requirements we have recommended support the criteria for operational functionality and crew endurance. The amended staffing requirements have since been adopted and progressed by the shipbuilders and other stakeholders involved in system development.
Major changes to the staffing requirements as a direct result of the STS approach include the definition of a watchkeeping approach, a system for supplementing on-watch crew to reach the required levels, a re-distribution of crew across job functions and an altered number of total crew. Although not all of these factors have physical design implications, the watchkeeping approach and total crew numbers are likely to affect physical layout specifications (e.g. where the bunks are located), and platform definition, such as number of bunks required, size of the messing spaces and hotel load (i.e. climate control, lighting, water desalination).
Importantly, the STS analysis represents an important first step in defining and validating the total number of crew required to sustain the desired level of submarine capability, without negative crew endurance implications. Historically, underestimating crew size in submarines has resulted in critical fatigue and long-term retention implications, as well as significant retrofitting costs (Moffitt, 2008). As such, we suggest that in a project such as this, early-phase STS application can have significant benefits to capability.
Finally, a further outcome of the process was stakeholder acceptance or ‘buy in’ to the importance of socially oriented criteria in systems development, which was not necessarily a priority for most stakeholders at the start of the project. As a result, researchers have been engaged to undertake an additional and expanding scope of work, with the potential for further inclusion of social considerations into the system design process.
5. Discussion
As the technological complexity inherent in work systems increases, organisations will more often need to adopt approaches to system design that match this complexity. Traditional change methodologies, such as process reengineering, are unlikely to fully support technological integration efforts (Bloebaum and McGowan, 2012). Faced with integrating new advanced technologies into work systems, organisations risk repeating the mistakes of previous complex system development efforts with their overly techno-centric design practices. Despite the espoused benefits of joint social and technical considerations guiding system development (Clegg, 2000), the uptake of sociotechnical principles and practices remains limited (Baxter and Sommerville, 2011).
The project we have described here indicates that even current large-scale complex design efforts do not formally incorporate socially oriented design criteria in the development process. In this case, only the clear link between submarine size and personnel requirements facilitated the bringing of human-related considerations, at least temporarily, to the forefront of design. This design challenge was the initial objective of our engagement, in which we were tasked with understanding how crew would respond to the design rather than inputting into the design itself. For us, however, advancing a sociotechnical design agenda was both critical and timely, given an ever-increasing degree of interconnectedness, interdependency and technological complexity in the submarine work system.
In this article, we aimed to describe the application of an STS approach to early-stage complex systems design, developed by integrating systems engineering and sociotechnical principles. We have provided an example of how to understand the system context (Phase 1) and select an appropriate scope of STS analysis (Phase 2), such that the analysis outputs can assist in design decisions and support the inclusion of socially oriented design criteria (Phase 4). We also outlined a methodology to assess a future system at an early phase of design, when many sociotechnical system elements are still unknown or underdefined (Phase 3).
We suggest that the objectives of Phases 1 (Understand the system context), 2 (Outline the scope of analysis) and 4 (Inform future system definition) do not address a specific stage of system design, rather these phases can be employed to support the selection and integration of socially oriented design criteria across the lifecycle of a complex system development process. However, the methodology outlined in Phase 3 (Analyse the system of interest) was developed to inform the systems’ staffing requirements, early in the design process. The methodology outlined in Phase 3 might inform high-level system requirements of other complex systems in early-phase development. In other stages, such as initial-stage (e.g. concept definition) or late-stage (e.g. sub-system or component design) design, we suggest that other socially oriented design tools – better suited to inform the design challenges of the current design phase – could replace Phase 3 of the approach outlined in this article.
5.1. Supporting the inclusion of socially oriented design criteria into complex systems design
Based on our learnings from the current project, we recommend the following steps to facilitate early-phase socially oriented design.
5.1.1. Align socially oriented analysis methods with formally defined system development phases
Aligning socially oriented tools and methods to the design phases of complex system development frameworks (i.e. systems engineering) can facilitate an integrative Sociotechnical Systems Engineering (STSE) design approach (Baxter and Sommerville, 2011). For example, in initial-phase design, a concept of operations is defined (Shamieh, 2011). Analysing the sociotechnical elements of the whole system at a high level of abstraction can support these activities. The organisational scenarios tool – proposed by Clegg et al. (1996) – for example, develops and evaluates a range of choices for how an organisation (or part of it) will work and could aid in concept definition. Following concept definition, broad-level work system requirements are set (Shamieh, 2011). We propose that Phase 3 of the STS approach outlined in this article can support system requirement definition. In later-phase design, when sub-systems and system components are being specified, STS tools which can assess these sub-systems/system components could be adopted to support design. For example, a tool such as KOMPASS – proposed by Grote et al. (2000) – assesses and informs functional allocations on the basis of sociotechnical principles and could support sub-system design (e.g. functional allocations within the control room).
We suggest that the design objectives – as outlined by the phases of the formally defined system development efforts – can be used to systematically select and successively apply a suite of socially oriented analysis methods. Such an approach allows socially oriented design criteria to complement the technical design efforts over the lifecycle of system development and helps to facilitate an STSE approach.
5.1.2. Demonstrate the benefits of including STS principles in design
In the design of large-scale systems with long lead times, there is a need to assess the effectiveness of the development effort before the work system is operational (Roedler et al., 2007). Performance metrics often consider factors such as budgets, project milestones and the degree of system definition (Roedler et al., 2007) but rarely include social considerations. At the same time, STS methods require a high upfront investment and may even prolong early-phase system development efforts (Baxter and Sommerville, 2011; McGowan et al., 2013). Therefore, traditional system development success metrics are unlikely to illuminate the benefits of an STS design approach, and they come too late in the process.
One suitable measure of impact and success, however, can be the uptake of STS-derived recommendations. Embedding socially oriented criteria into system development optimises the design and performance of new systems and reduces the risk of system failure (Doherty, 2014; Mumford, 2006). Therefore, increasing system designers’ focus on socially oriented design criteria can signify a positive application of STS principles. This increased social focus can be evidenced through factors such as expanded stakeholder connections and reach, renewed engagements, and human scientists being called upon to provide expertise.
Importantly, for system designers to recognise the value and benefits of socially oriented design, a solutions-focused approach is likely to be needed. In such an approach, the outputs of STS analysis directly address design challenges, provide tangible recommendations which are possible to implement, consider the contextual constraints and align with system design deliverables.
5.1.3. Support an integrative and multidisciplinary design approach
Human sciences have an important role to play in optimising the design of technologically complex systems. Nevertheless, decisions about the human and social factors in systems design are often made in the domain of engineering (Bloebaum and McGowan, 2012).
Many existing STS tools gather information from users of the work system to analyse a system of interest and propose solutions (Hughes et al., 2017; Nadin et al., 2001). Although users can generate useful design recommendations, they can also lack the technical and human-sciences expertise necessary to ensure design recommendations are viable. In the current project, the research teams’ ‘social system’ expertise was necessary to generate socially oriented design recommendations. However, providing viable design recommendations was only possible by integrating human-sciences expertise with both a contextual understanding of the work system and the technical design goals and limitations.
Consequently, we suggest that an optimised sociotechnical design process is facilitated by representation from three major groups: experts in the work system (e.g. end-users), experts in the technical systems design (e.g. technical designers), and experts in social systems design (e.g. organisational psychologists/human scientists). In addition, sufficient collaboration and shared system-understanding between these groups is important to ensure that design recommendations provided by one group consider and account for the needs of the others (Binder, 2016).
5.1.4. Develop the mind-set of system engineers
Organisations are often held morally and financially responsible for system failures that result from poorly designed or integrated technologies or technical system components (Oberg, 1999; Rogers et al., 1986). However, when poorly designed or integrated technologies contribute to ‘human’ failure, the system development process is rarely held accountable (Pidgeon and O’Leary, 2000; Vogelsmeier et al., 2008). As a result, socially oriented criteria are often underemphasised in complex systems design (Bloebaum and McGowan, 2012; Hirshorn, 2016). Other research similarly shows that professionals and managers outside social spheres often do not ‘naturally’ consider social issues, such as the value of designing work tasks that are engaging and manageable (Parker et al., 2019).
The engineering culture can be slow to change (Vincenti, 1990), and it is unlikely that formal inclusion of STS principles into system design can be achieved without bringing about some level of a change in the mind-set of systems engineers (Baxter and Sommerville, 2011). We suggest STS researchers and practitioners have a role to play in facilitating the inclusion of socially oriented design criteria into system engineers’ mind-sets. We identify three factors which can support this change.
First, it is important to emphasise the benefits of STS in the ‘language’ of system designers. In design processes which place a significant emphasis on models and simulations, STS analysis can be positioned as a cost-effective and relatively simple means to ‘simulate’ the future system in the early stages of design, and surface potential unanticipated interactions and interdependencies, which can then be accounted for (Bloebaum and McGowan, 2012).
Second, supporting socially oriented design considerations with a strong evidence base makes a difference to acceptance. For example, when ‘selling’ the need for protected sleep opportunities to design stakeholders, we used fatigue modelling, drew on empirical literature and conducted field trials to demonstrate the negative impacts on performance and operational capability if crew were fatigued. In other words, to be persuasive, human scientists can align data and evidence with the outcomes that are most important in the context.
Third, we recommend acknowledging the reservations engineers and end-users might have around the value of socially oriented design criteria. To address these reservations, we deliberately first and foremost emphasised the ability of the system to support operational functioning without significant crew endurance risks (e.g. sufficient sleep). Only once STS analysis outputs supported operational functioning did the research team advocate for the value of considering additional socially oriented factors in early-stage design, such as career progressions, training needs and organisational change management.
Integrating socially oriented design considerations from the outset of complex work system design has historically been, and continues to be, a challenge. In this article, we have described an STS approach which facilitated the development and inclusion of socially oriented design recommendations in the early phases of a complex system development effort, the design of a military submarine. We close with practical and research implications which we suggest are key in advancing an STSE design agenda.
Key practical and research implications
Advancing STS theory, and making STS design more accessible, is timely. Organisations stand to gain a significant competitive advantage by adopting novel and complex technologies. Adopting these advanced technologies will likely require a considered design approach. Faced with significant technological complexity in work system design, there is a risk that organisations will continue to adopt techno-centric approaches. Sociotechnical tools and methods can support organisations in integrating humans effectively in the design of FCWS (McGowan et al., 2013).
There are few examples of the successful application of STS principles in a prospective manner, particularly for a new type of system (Baxter and Sommerville, 2011). Too often, STS methods are employed late in the design process, when many of the systems’ technologies have already been selected and developed (Majchrzak and Finley, 1995). We advocate a proactive integration of socially oriented methods and tools from early in systems development. Early integration can allow socially oriented design criteria to shape system definition and the requirement setting process from the outset of design. A major challenge of early-phase STS future system analysis is the need to consider the potential implications of the interaction between humans and technical systems which are yet-to-be in existence. In this article, we have provided an example of an early-phase STS analysis of a future system, when many elements of the system are still unknown or underdefined.
To facilitate the inclusion of socially oriented design criteria over the design lifecycle, we propose that socially oriented design tools and methods align with the formalised design phases. Multiple STS tools can be applied over the lifecycle of a system development effort in order to embed socially oriented design criteria across the process. These tools can be systematically selected on the basis of the level at which they analyse the system (e.g. whole-of-system vs component-level), and/or aspects of system development they can inform (e.g. work design interventions, functional allocations or interface design).
Providing suggested solutions that demonstrate consideration of the technical and organisational context (i.e. appeared ‘feasible’ to both the end-users and engineers) were key to our success in informing the design effort. We suggest that to advance an STSE agenda and embed social criteria into the design process, STS analysis must allow for the generation of viable and actionable recommendations that address the challenges and goals of the current design phase and corresponding stakeholder needs.
Footnotes
Acknowledgements
The authors would like to thank all the design stakeholders and operational personnel that contributed to this project. In particular, we would like to thank the Human Systems and Information Integration Team (Defence Science Technology Group), the Royal Australian Navy and their affiliated contractor organisations and the broader Work System Design Team at the Future of Work Institute (Curtin University). Sharon K Parker acknowledges funding support from the Australian Research Council, FL160100033.
Final transcript accepted 22 March 2020 by Catherine Collins (Editor, Special Issue).
Funding
The author(s) disclosed receipt of the following financial support for the research, authorship, and/or publication of this article: This work was supported by research grants RES61297-1 and RES59831, MyIP 9079 and MyIP8341 from the Defence Science Technology Group (Australia).
