The aim of this book has been to assess a digital Mission Planning/Battle Management (MP/BM) system in an operational field trial, and where possible to compare it with the analogue process that came before it. Significant shortcomings in the system’s performance were identified which arise not necessarily because the system is technically ineffective (although this is sometimes the case) but principally because it is not well matched to its human users. In other words, the interface between the capabilities provided by the system and the ability for human users to access them, and harness their benefits, is in some cases critically hampered. The findings of the book, therefore, provide a salutary lesson in the dis-benefits that arise from not integrating Human Factors (under the rubric of Human Factors Integration) right at the beginning, and then throughout, the complete design life cycle (as advocated in chapter two). What might at first appear to be an ostensibly technical system is in fact a ‘socio-technical system’. Human Factors provides the tools and techniques to optimise both.
On a more practical level, what the findings of this book reveal is that the introduction of a simple and naturalistic facility such as encrypted radio has yielded a significantly positive effect on the complex tasks involved in tactical command and control. Analysis within this book finds that the radio is the main conduit for this improvement over the analogue process. Simple ‘Chat’ and ‘Free Text’ tools appeared to offer benefits far beyond those anticipated, and were preferred to the more ‘formal’ tools that had required significant design and development effort. Whilst the highly complex digital MP/BM system improved activity in some areas, it significantly hampered it in others. Numerous shortcomings in nearly all aspects of what Human Factors is normally considered to be about, that is, the Human Computer Interface, were encountered. These include:
• the keyboard and thumb cursor (which were both difficult to use so external keyboards and mice were used instead);
• screen (one screen was not enough – users would need two as a minimum to do their work);
• interface design (the interface was not intuitive and did not conform to the generally held software conventions);
• processing power (there is a mismatch between the available processing power and the requirements of the software);
• logging on (logging on to the system is unnecessarily complex);
• contact reports (locations of enemy engagements) and friendly forces position reporting lag far behind the true situation.
An analysis of the planning process found that workstations really only supported two parts effectively, namely the editing of the Warning Order (WO) (after a paper printout had been reviewed and relevant sections highlighted) and writing up of the Requests For Information (RFI) for higher command (after the Mission Analysis had been committed to a whiteboard). In both of these instances, the digital MP/BM system was used after the conventional media had been used to extract meaning. Thus digital MP/BM was being used as a conduit for passing requests and information on to others, rather than as a tool to aid the intellectual activity and creativity inherent in the planning process which was observed when looking at the pre-digitised system (chapter three). The key finding here is that the ‘process’ of planning is as important, if not more so, than the eventual ‘products’ of planning.
Based upon the evidence collected it is not possible to make a judgement about the robustness of the data and voice services. The analysts did however observe numerous system crashes and extremely slow data transfer times. There is little evidence to suggest that the new system supported the staff process or increased tempo. On the contrary, subjective opinion (see chapter four) as well as operation timings indicates that the digital MP/BM system has had a negative impact on tempo and offers little above the analogue process. The results of the survey discussed in the constraints analysis (chapter four) revealed that whilst the system was rated positively for its ability to support battlefield management, it scored poorly for its ability to support planning, with none of the respondents offering a positive opinion. More specifically the summary of opinion shows that the new system was scored as worse for: tempo, flexibility, efficiency, effectiveness and fidelity as well as the time taken to produce plans. The introduction of the encrypted radio is clearly a very positive and welcome addition, and examination shows this attribute for the majority of the positive opinion of battlefield management in the digital system. Examination of the staff officers’ ratings of aspects of the workstations, however, reveals the software and digital planning tools are incompatible with the planning activity. In some cases, the digital MP/BM software could be improved through redesigning the user interface and interaction experience, however, in many cases the planning activity should not be attempted in this digital system.
The analysis of digital MP/BM using Hierarchical Task Analysis (HTA) and Systematic Human Error Reduction and Prediction Approach (SHERPA) (chapter five) showed significant shortcomings in the structure of tasks and that the system had many opportunities for users to commit errors. The most significant shortcomings of the system were summarised in the following points:
• lack of standard conventions (such as the copy and paste process where there is already an industry standard approach);
• overly complex processes (such as marking up the maps and development of the overlays);
• complex menus (with structures that are too wide and deep);
• unintuitive drawing tools;
• lack of consistency in the user interface;
• general poor interface design.
Some of these points were picked up by other analyses, such as observation, the usability questionnaire and the Engineering Equipment & Materials Users Association (EEMUA) survey, which indicated that they were of major concern.
Analysis of the Distributed Situation Awareness during the planning phases (chapter six) revealed questions about the timeliness and accuracy of information, the tempo of planning in digital MP/ BM, the accuracy of information from digital MP/BM (as staff had to engage in additional checking activities) and the poor support for the different Situation Awareness (SA) requirements in the different planning cells. Analysis of the operational execution tasks revealed that the Local Operational Picture (LOP) was often out-of-date or spurious (clarification of Own Situation Position Report (OSPR) data was required, placing more load on the secure voice channel for updates of the blue force positions) and a low level of LOP and OSPRs (requiring the operations cell to compensate for digital MP/BM’s shortcomings by drawing blue force positions directly on to the Smartboard – but these were wiped off every time digital MP/BM updated or was changed). In summary, it was found that Distributed Situation Awareness was not well supported by the digital MP/BM system, as people have different (SA) requirements, which are subject to change, depending upon their tasks and goals at any moment in time.
The Social Network Analysis (SNA) (chapter seven) provided a unique insight into the real-life challenges of introducing net-centric platforms in service. Emergent behaviours arose in which ‘something stupid’, in this case a highly simplistic Free Text facility, ‘bought something smart’. Whether this was an attempt by users to restore the mismatch between their net-centric approach and their corresponding cold-war style problem is debatable, but in either case it tells systems designers that users favoured a ‘simple system that enabled them to do complex things’ rather than a ‘complex system that only enabled them to do simple things’. Another interesting issue was that the presence of data, or even the network to carry it, was not enough on its own to increase operational effectiveness. The ability to turn that data into information or knowledge through human actors ostensibly ‘doing something with it’ is key. The results of the present analysis suggest that not enough of this is occurring in the present system and that greater attention toward the user/ technology interface, and perhaps even the entire philosophy behind digitisation, requires further evolution aided by the body of knowledge contained in Human Factors.
Another finding that goes to the heart of the NATO model of command and control (also chapter seven) is where the live organisation actually positioned itself in practice. Its static characterisation clearly bore the hallmarks of a distinctly net-enabled centre of gravity, as defined by procedures and doctrine, but it was the users, in attempting to meet the challenges created by their ‘problem’, that pulled this organisation into virtually all areas of the approach space. By and large it was down to them and their interpretation of the system, the way they massaged it and made such adjustments as they saw fit, that gave the system its resultant levels of agility and tempo. The fact that the system, in the end, was able to provide such a level of agility and tempo is encouraging. But as mentioned above, there was a fundamental mismatch between approach and problem which seemed very hard to overcome. Indeed, success in the mission required arduous efforts on the part of those involved and to some extent occurred despite the presence of the MP/BP system rather than because of it.
From the 35 EEMUA 201 principles against which digital MP/BM system was evaluated (chapter eight), only eight were met (where no improvements were required, that is, window resizing, single and multiple windows, snap shot capture, power back-up, pictorial displays, cool background and foreground colours, no use of animation). A further 12 principles were partially met (where some improvements to the current system are recommended, that is, permanently viewable overview display, capability to expand screens, provision of start-up, state monitoring and shut-down screens, ease of navigation through hierarchy, simple hierarchical structure, ease of navigation across levels, user-defined default configurations, user-defined favourites and quick access buttons, electronic shift handover notes, quick and unambiguous item selection, different interaction methods, sparing use of colour coding), whilst eight principles failed to be met (where significant shortcomings in design were identified, that is, access to necessary information, maximum number of windows on display, important windows on permanent display, hotlinks to databases, quick and consistent feedback, quick access to details, uncluttered displays and single task-based windows). A further seven of the EEMUA 201 principles were deemed not applicable to digital MP/BM.
Further usability assessment was undertaken with a Human Computer Interaction (HCI) questionnaire (chapter nine) which supports the observational studies and EEMUA 201. It too shows many shortcomings in the interface design, as rated by those who were charged with using it. It is interesting to note that overall ratings were generally lower at Battle Group (BG) level (where the system is being used very much ‘in the field’), but even at Brigade (Bde) (where the environment within which the system is being used is a little more benign) the overall ratings failed to go beyond neutral. The system was rated particularly low on ‘explicitness’ and ‘error prevention and correction’. Generally speaking, the people using the system did not find it intuitive and many found that they lost work due to inadvertent errors.
On the topic of the environment within which the MP/BM system is designed to be used, for the sake of completeness it too was assessed (in chapter ten). This was not intended to inform the design of the digital MP/BM per se, rather it was to consider if the surrounding environment met with current standards for control centres (that is, BS/EN/ISO 11064-6:2005 Environmental Requirements for Control Centres). Seven main environmental criteria were evaluated: ambient temperature, humidity, air quality, lighting, acoustics, vibration and aesthetics. Some points of concern were highlighted. Although it should be noted that these criteria were developed for civilian rather than military control centres, environmental stressors are not trivial. Coupled with the fact that staff can work for shifts of 12 hours or more, it places even greater emphasis on the design of interfaces to match expectations, enhance ease of use and be error tolerant.
The extensive analyses undertaken in the course of this book has led to the identification of many potential improvements to digital MP/BM systems. Generally, the system is too slow, cumbersome, overly complex and does not use accepted conventions in the user interface. The main recommendations vary between short- and medium-term improvements. The improvements are divided into five sections: general design, user interface, hardware, infrastructure and support. General design improvements:
• Only digitise what needs to be transferred to other parties. The analogue system already works well for most of the planning process.
• Adopt a multimedia approach, such as the use of digital capture of images and text. Products that can be produced quickly using the analogue media may then be transferred into the digital medium.
• Take care to ensure that the digitised processes are as least as quick and convenient as the analogue processes, and that progress is not hindered by using the digital medium. For example, the digital Combat Estimate seven questions planning process might have to be undertaken quickly, for example, allowing only 17 minutes or less per question.
• The start-up processes need to be automated.
User interface design improvements:
• The Graphical User Interface (GUI) needs to adopt accepted conventions, such as those used by Microsoft, IBM and Apple, which are in the open literature. These conventions are familiar to the Headquarters (HQ) staff.
• The menu and menu navigation structure needs to be simplified.
• Provide a ‘See All’ button to allow a HQ to see everything within its boundaries.
• Excessive and additional functionality needs to be hidden from the user.
• Standard drawing tools need to be provided.
• Icons need to be grouped by function, to prevent accidental activation (for example, sending a contact report, rather than publishing a document).
• Consistency is needed in the interaction, dialogue and actions required by the user.
• Printing needs to be simplified, by the provision of a printing wizard, a print preview and a general reduction in the number of steps.
• Printing time needs to be reduced considerably.
• The interface needs to be customised to the role of the staff, for example, different interfaces are required for plans, operations, intelligence, fire support, engineering, I-Hub, logistics, watch keeper, air/aviation, administration and communications.
• Improve the refresh rates for pan and zoom (with mapping on) as these are far too slow.
• Limit the maximum number of windows that can be displayed at any one time.
• Reduce the requirement for users to have multiple windows open to perform a task, by designing task-based windows that contain all the necessary information to perform that task.
• Allow users to save ‘favourites’, for example, a palette of tools.
• Provide hyperlinks to electronic Standard Operating Procedures (SOPs).
• Provide immediate and relevant feedback on user actions.
• Reduce the amount of clutter on screens.
• Clear all forms as a default option.
• Provide meaningful error messages with suggested user actions.
Hardware improvements:
• The User Terminals are far too slow and faster processors are clearly required to support the current level of functionality. Consider the option of TEMPEST protection for the whole HQ tent, therefore allowing staff to use Commercial-off-the-Shelf (COTS) technology such as ‘Tough-books’ (for example), which have a more acceptable processing speed and considerably reduced cost.
• Increase the size and resolution of the screens, so that mapping visualisation will match HQ requirements.
• Most users need two screens, one for the current LOP and one for the work they are undertaking. The Ops cell needs three screens, one for the LOP, one for the staff work and one for the flash messages.
• Overlays need to be printed on A0 plotters. At present BG was required to print off the overlay on an A4 paper printer and redraw on to a map overlay.
Infrastructure improvements:
• Updating of the blue and red picture needs to be in real-time. Because of delays in the LOP update, the staff rely even more heavily on voice for updates thus exacerbating the delays for data. Greater bandwidth (or optimisation) is required to support both the levels of secure voice transmission observed in the exercise and rapid transmission of positional report data. Otherwise considerable reductions in secure voice transmission will be required.
Support improvements:
• Provide a simple user manual, with a ‘Getting Started’ section covering the basics for each cell. Examples of ‘Getting Started’ sections can be found in many COTS software manuals.
• Provide a help section that provides instructions on how to use an item as well as a description of the item (currently only a description is provided). For example, the current help section describes how to open a new user-defined overlay but it doesn’t instruct the user on how to draw on the overlay.
The analysis presented here identified a series of problems associated with the design of the digital MP/BM system; the aim of this section is to introduce some approaches that can be used to aid system design. Of course, we readily acknowledge that many of the topics to be discussed may be uneconomical to implement into the current version, however, they should be of benefit for future programmes.
As alluded to already, the digital MP/BM programme has served to illustrate the implications of failing to consider and act upon basic Human Factors and interaction design principles in the early stages of, and throughout, the design process. In the early stages, input can be included at minimal cost resulting in massive cost saving and enhanced capabilities in the latter stages of the programme. These cost savings can be realised in the areas of reduced training cost and reduction in design changes.
Figure 11.1 shows the four key factors that can be manipulated to affect system performance. It is possible to map these four overlapping factors on to a set of four themes that emerged throughout the analysis.
Many requirements-led procurement processes, ironically, lack the agility, tempo and self-synchronisation of the system trying to be procured. Changes are difficult to incorporate as requirements become fixed to contracted deliverables. Equipment specification is likewise fixed for long periods of time while technology continues to progress, thus bespoke systems with closed architectures tend to be the norm rather than COTS systems with more open architectures. The type of equipment best able to meet the aims and aspirations of NEC is likely to be an open, flexible sort of technology. This philosophy enables users to readily adapt it to suit their needs and preferences, and to genuinely support through-life capability as users evolve the technology, and technology is evolved to users.
In the introduction to the text titled ‘The design of future things’, Norman (2007a) is keen to defend the users of systems. Norman makes the following comment, which seems pertinent to this case:
‘The ‘blame-and-train’ philosophy always makes the blamer … feel good: if people make errors, punish them. But it doesn’t solve the underlying problem. Poor design and often poor procedures, poor infrastructure, and poor operating practice, are the true culprits: people are simply the last step in this complex process… We must design our technologies for the way people actually behave, not the way we would like them to behave.’
(Norman, 2007a)
Figure 11.1 Key enablers to enhance performance (adapted from Macey 2007b)
Perhaps the most commonly adopted approach to system improvement within the UK Army is training, and the culprit when things do not work as planned is a lack thereof. There is undoubtedly benefit to system performance on more intensive and expensive training programmes, and it is to the credit of military personnel that in most cases they can (often with significant effort) overcome such challenges through training alone. Training is, however, no substitute for effective systems design. It is impossible to completely train for error prevention. Skill fade in unintuitive complex systems is a significant concern. Under times of duress and stress, it is highly likely errors will be made as people revert to stereotypical conventions and expectations when interacting with systems (Reason, 1997). In other words, it is not possible to completely ‘train out’ problems.
Training is one method to increase staff competency. The other approach is to recruit staff with a different, more compatible, skill and ability set. The problem, of course, is that the specific skill set required to operate an overly complex MP/BM system is not (or should not) be the focus of otherwise skilled and adept military personnel. In other words, they know perfectly well already how to enact command planning tasks and any system aimed at improving that should not require much, if anything, beyond which personnel bring to the task already. In summary, it seems wholly inappropriate to change the staff to fit the competencies required by the digital MP/BM system. Rather, the system should be engineered so that the tool set supports the current operators in the tasks that they are already considerably skilled at.
Changes to the current SOPs are expected; with new capabilities come new opportunities and new working processes. The development of the SOPs should be a symbiotic relationship with system development. As it is, the system under investigation is a peculiar hybrid, with the step-change represented by the digital system appended to a set of evolved SOPs. The high-speed hierarchy that results from this mix highlights that the ‘Net’ in NEC does not just refer to Networked technology, but also the type of organisation in which it is embedded.
The proximal issue in terms of designing digital MP/BM for human use centres on the information presented by the system to its range of users. In every analysis performed on the system it is this issue that recurred; the design of the interface stunts human adaptability, represents a handicapping bottleneck for operational effectiveness, decreases tempo and increases complexity.
Firstly, it is clear that designers need to have a deep understanding of the process that they are designing to support; they need to understand the system at a number of levels of abstraction, its functional purpose, how this can be measured, the functions required and processes that need to take place. Further, they need to understand the relationships between these levels, particularly the second-order effects of changes to particular process. Designers also need to understand what the SA requirements of the various different end users are and design the system accordingly. In collaborative systems SA is an individual, team and systemic phenomenon and systems should support this by presenting global and specific user SA information. Collaborative systems should contain tools and interfaces tailored to the different SA requirements of its users. Schneiderman (1998) points out that, ‘successful designers go beyond the vague notion of “user friendliness” probing deeper than simply making a checklist of subjective guidelines. They have a thorough understanding of the diverse community of users and the tasks that must be accomplished’ (p. 10).
Secondly, as obvious as it sounds, the information presented by the system should be accurate at all times. It is surprising to observe, in the military domain of all domains, a system that does not present completely accurate information. Thirdly, timeliness of information presentation is key; the information presented by the system should be as up-to-date as is possible; delayed information diminishes user SA considerably.
The following guidance emerges from the Distributed Situation Awareness analysis performed:
1. Clear definition and specification of SA (or information) requirements. The findings suggest that the collaborative system design process should begin with a clear definition and specification of the SA requirements of the different users of the system in question. This should include a description of the process involved, the different roles and tasks involved in the process and a description of who needs to know what and when in the process they need to know it. Clearly, the designers of the system in this case did not fully appreciate the distinct roles and SA requirements of the different end users. Although this principle sounds somewhat obvious, unfortunately it is not always adhered to. Matthews et al. (2004) point out that knowing what the SA requirements are for a given domain provides engineers and technology developers a basis to develop optimal system designs to maximise human performance rather than overloading workers and degrading their performance. Matthews et al. (2004) suggest that ‘it is important, therefore, to know the SA requirements for various jobs to design systems that optimally present information, to evaluate the impact of new technology, and to develop effective training procedures to prepare workers to interact with advanced information systems’ (p. 160). Matthews et al. also suggest that ‘systematically identifying what it is the worker needs to know to accomplish key goals is a fundamental step in designing technological systems that optimise work performance’ (p. 161) and that SA requirements analyses findings can be used to develop appropriate measures of SA for assessing the final system in terms of its support for SA requirements.
2. Design system to support compatible SA requirements. The findings suggest collaborative systems should be designed to cater for the compatible SA requirements of its end users. Within collaborative systems, users more often than not have distinct SA requirements and so the system should be designed so that users are not presented with information, tools and functionality that they do not explicitly require. The system should therefore be designed to support the roles, goals and SA requirements of each of the different users involved in the process. This might involve the provision of different displays, tools and functions for the varying roles and tasks involved. This removes the problem of high workload and getting bogged down in too much data and also reduces the requirement to send large products and data sets to every agent working within the system. In the same way that everyday PCs can be adapted by users so that the user interface and its functionality suit their own needs, it may also be more appropriate to allow the system and interface to be customisable based on the user’s role (for example, G2) or on the job that the user is working on at a particular time (for example, synchronisation matrix) which will remove the vast number of redundant components of the system that get in the way when the user is doing their specific job. Gorman et al. (2006) advocate adaptive and timely information sharing, which they stress does not mean that everybody has access to the same information at the same time, but rather implies communicating the appropriate information (and importantly no more than this) to the right person at the right time. In this case the analysis indicated that the distinct SA requirements of the different end users were not supported in any way; rather the system remained the same in terms of information presentation, interfaces, tools available and functionality regardless of who was using it. The principle of providing system elements only with the information that they require becomes even more critical with the advent of NEC systems, where the great increases in information communicated around the system mean there is great potential for informational or data overload.
3. Use multiple interlinked systems for multiple roles and goals. When a team is divided into distinct roles and team members have very different goals and informational requirements it may be pertinent to offer separate (but linked) systems. In the same way that Microsoft Office provides separate word processing (for example, Word), drawing (for example, Visio) and spreadsheet (for example, Excel) tools, distributed team working support systems should provide a suite of mission support tools catering for the different users and roles involved; each tool should have the functionality and information required for the role it is designed to support whilst also containing the ability to see global information. As described previously the digital MP/BM system focussed on in the current study remained the same regardless of who was using it.
4. Customisable/tailored interfaces. As articulated previously, the nature of collaborative systems is such that there are specific roles and SA requirements. Subsequently, the information and the tools that one agent needs to use may be very different to that that another agent needs. Collaborative systems should therefore be customisable, allowing users to customise (either by them or intelligently by the system based on usage) the interface so that the information and tools that they specifically require are present. This increases the usability and ease of use of the system and also reduces interaction time (that is, having to mine through menus to find information and tools required).
5. Consider technological capability and impact on Distributed Situation Awareness. Again perhaps an obvious, but nevertheless critical, recommendation is that system designers need to carefully consider the constraints imposed on them by technological capability and design the system accordingly. Distributed Situation Awareness in this analysis was adversely impacted by both the capability of the displays and mapping used and also by bandwidth limitations. It is therefore recommended that systems be designed within the constraints of the technology available.
6. Ensure the accuracy of information presentation. It goes without saying that the information presented by any command and control system should be highly accurate. System designers need to ensure that the information presented by all aspects of the system is accurate at all times. The present study revealed that the mission support system under analysis did not always present accurate SA-related information, such as contact and positional reports and enemy and friendly movements on the battlefield; further this information was often not presented in a timely manner.
7. Provide filtering functions. When systems have displays containing movement and location information relating to distinct entities (for example, enemy, friendly, neutral and so on) on a map, it is important that the system allows the users to filter the display so that different classes of information only are displayed.
8. Clear communications links. Throughout our research the importance of communications links for DSA acquisition and maintenance has consistently been highlighted; additionally a number of other researchers have identified communication links as key to team SA (for example, Gorman et al., 2006; Stanton et al., 2006; Walker et al., 2006) It is therefore critical that collaborative systems possess the appropriate communications links and that the users working with the system understand which communications channels are and are not open to them and also understand when and to whom what information should be communicated. This follows on from Stanton et al.’s (2006) conclusion that the links between agents in a network are at least as important as the agents themselves in maintaining DSA.
9. Test DSA throughout the design lifecycle. It is clear that DSA should be considered and tested where possible throughout the design life cycle. DSA requirements should be used to drive the design of concepts, and concepts should be evaluated based on their ability to meet the DSA requirements of the end users.
In conclusion, a clear paradox has emerged. At a more conceptual level the interface that has been designed is one that is extremely complex, one that forces users to perform a large number of relatively arbitrary, simplistic tasks. The paradox is that this is the polar opposite of the capability that it should afford. As highlighted within the analysis, digitisation is more than networked computers, it is about endowing command and control with synergistic, open-systems behaviour like ‘self-synchronisation’. For this, a flexible, adaptable, simple system (from the user’s perspective) is the sort of system that will allow humans to perform the complex military tasks for which they are selected, recruited and well able to perform.
Moves have been made to develop digital systems to support distributed team working and planning processes (see Riley et al., 2006 and Roth et al., 2006) with the system that forms the topic of this book being the latest in a long line. The current system, like many of the previous, shares a focus on the products of the planning process for distribution between the planning team and to other people in the network. The challenge to system designers has been to preserve the collaborative, public and creative parts of the planning process as well as supporting different levels of plan fidelity (which will depend on the time available to develop the plan). Perhaps the biggest challenge is to decide what needs to be digitised and what form this digitisation should take. Given that military planning teams have invested considerable effort in developing and refining their planning skills using the traditional media, it would seem appropriate to try and support these activities, where appropriate, rather than requiring them to develop a new set of skills. Hybrid systems, therefore, may prove to be a viable point on the developmental timeline.
The planning process has evolved over centuries of refinement and improvement (Clausewitz, 1832). Roth et al. argue that much insight may be gleaned from studying the work-arounds and home-grown cognitive artefacts that are being used by command and control teams (such as the so-called ‘cheat-sheets’ and sticky notes). The traditional analogue planning process (as described earlier) is certainly abundant with potential metaphors, such as overlays, stickies, routes, Course of Actions (CoAs) and so on. It is worth considering if the conventional media could be captured digitally (by camera, scanner or other means) if they need to be transmitted as electronic documents with orders or reports, or for wider distribution. As a general design principle, the production of electronic documents should be at least as easy as the production of their analogue equivalents. Baxter (2005) is wary of the inexorable trend to digitise and concerned by the history of technology failing to deliver expected benefits, this is not just linked to military experience (Stanton & Marsden, 1996; Sinclair, 2007). Baxter argues that very few people understand the interrelated issues for technology, operations and Human Factors (being conversant in just one of these topics is not sufficient).
Transformational approaches of the ‘step-change’ nature seen throughout this book are likely to cause more problems than they solve. There are concerns that digitisation will lead to additional ‘emergent’ work (Kuper & Giurelli, 2007), both in terms of increasing the amount of ‘direct’ work required as well as the work associated with operation of the digital tools. The emergent nature of the task-artefact cycle has been described by Carroll (2000). Certainly it will not be possible to predict all the ways in which any future system would be used, so it is important to make the system as flexible as possible so that users may adapt and evolve it to suit their purposes (Roth et al., 2006).
Kiewiet et al. (2005) noticed that there are marked differences in the planners’ domain knowledge, pointing out that group planning ensures an integrated approach rather than an overemphasis on one planner’s area of strength. The social aspect of planning has not been lost on other researchers (Houghton et al., 2006; Stanton et al., 2006; Walker et al. 2006; Jenkins et al., 2008a). The collaborative aspects of planning seem to be a key to successful mission planning. As in the observational case study reported in this book, Riley et al. (2006) identified how different cells contributed to the planning process, such as intelligence, operations, logistics, fire support, engineering and air defence. Kuper & Giurelli (2007) argue that design of collaborative tools to support command and control teams is one of the keys to effective team work.
The case study presented by Riley et al. (2006) shows how Human Factors can contribute to the design of a mission planning system which is based on a thorough understanding of the planning process, the demands and constraints. In the design of their prototype tools they stress the need to provide a quick visualisation of the plan and the current situation. This enables the current operational picture to be compared with the plans, which may require changes to the plan as the situation changes (Stanton et al., 2008a; Stanton et al., 2008b). The Human Factors and Ergonomics methods introduced at the beginning of this book will help the individual to understand the demands and constraints placed on the people and technology in pursuit of their work, and therefore help design systems that are more appropriate. As a finale to the book we have imagined two futures for digital command and control, one pessimistic and one optimistic, which are presented as fictional ‘thought experiments’ based on the scenario described in chapter three (the mission planning process at BG).
In the first thought experiment, a pessimistic vision of technology is imagined. The WO has arrived from Bde, but this is a lengthy textual document that cannot be read easily off the small laptop screens. Printing off this large document is far from easy as it has a number of unintuitive steps. It is easy to forget to print off the attachments, and this process usually takes several attempts to complete. In addition, the printing is slow and at least 10 copies have to be printed so that all the staff officers have a copy. Once the WO is printed, the Chief of Staff (CoS) can go about the business of preparing the WOs for each company they are controlling. The CoS uses a different marker pen for each company and another to identify generic features in the orders. They then pass the order to a clerk who retypes the relevant material for each company into a word processor. The attachments are sorted from the Bde WO into a file on the main hard drive. As the file names are abstract, a separate list is kept on paper with a description of what is in each file. Sometimes this list is lost, so the files are required to be checked again and another paper log created. Occasionally the wrong attachment is sent to a company with their WOs. When the main orders arrive, the printing procedure is entered into again with similar frustrations, then a BG orders preparation timeline is created in the software. Unfortunately, the timeline is often longer than the screen, so the user has to keep scrolling left and right to see all of the deadlines for each of the Combat Estimate questions. The attachments cannot be used in their digital form, (for example, digital overlays for preparation of orders) partly because of incompatibilities in the graphics software (that is, there are problems with scaling of images as they appear in the wrong places) and partly because of the level of detail is not appropriate. Rather they have to print them off and then re-enter the information for themselves when recreating their own overlays. The planning timeline demands that the orders are produced within 2 hours, to allow the lower echelons time for their own planning. This means that there is 17 minutes per question in the Combat Estimates seven questions planning process. The drawing tools in the bespoke software do not conform to the normal industry standards (the ones that everyone is familiar with) and so the staff have to re-learn the functions of the tools every time they use them. In addition the user input devices are not as simple as a mouse (being a very stiff joystick that is ‘soldier-proof’), which requires considerable force to move and the on-screen pointer moves jerkily. The staff officers complain that it is hard to find objects in the interface, and files are easily erased if the correct key combinations are not used when saving a file. This sometimes means that the same work is undertaken two or three times. The consequence of which is that it takes a considerable amount of time to produce the outputs for each part of the planning process. This is very frustrating for all involved. The software experts find they are being continually called to help with what they consider trivial aspects of the user interface, finding tools and icons, showing people how to print documents and attachments and reminding users how to save files. They do notice themselves, that after any time away from the software, they cannot remember how to perform some very basic functions, but they put this down to training fade and resolve to go on the next refresher course. The most frustrating aspect of the digital way of working for most users are all the additional tasks they have to do and that somehow an intuitive planning process has been turned into an unintuitive one in the name of ‘progress’. Most frustrating of all is the fact that the planning process has been lengthened considerably. The 2-hour timeline to answer the seven questions now looks wildly optimistic, as they only got half way through by that time. But as one of the staff commented, that would have been plenty of time for the old analogue process, when paper maps, overlays, flip charts and pens were used for planning.
In the second thought experiment, an optimistic vision of technology is imagined. Again, the WO has arrived from Bde, this time the order is broken into chunks that can easily be read on the large, high definition, screens. To call it a document is a hang-up from the old world of paper. In fact it is a hypermedia webpage, with more in common with an Internet page. Clicking on links takes the reader to different parts of the orders, from the mission, to the maps, to the boundaries, to the assets, to the enemy. It is easy to forward on the relevant parts of the order, by a simple checking and highlighting process. Editing with notes and amendments to make the material relevant at company level is as simple as would have been with paper and pen for both the text and graphics pages. These pages are then ‘posted’ to each company by dragging and dropping into a mailbox and clicking on a send button. When the main orders arrive, everyone can see the orders webpage and click on the links relevant to their specialism. The large, high definition, screens make it easy to see the terrain in great amount of detail. As the screen can be laid flat or upright at the press of a button, it is easy for everyone to gather around and see the lay of the land. The relevant overlays from Bde can be edited by adding or removing symbols before they are overlaid on to the terrain maps. As it is a large touch screen, grabbing a symbol and positioning it is reminiscent of the old days of ‘stickies’ and ‘acetates’ – but these days the ground coordinates and details can appear automatically. Digital pens and rubbers mean that phase lines and boundaries are easy to add and remove, with all the data being stored automatically. As before, a timeline is created when the orders arrive, but the large screens mean that the timeline can be displayed in full. The drawing tools behave just like the tools in all other software so there is nothing new to learn. In fact, it is such an intuitive interface that most people don’t comment on it as it’s just a natural way of undertaking the work. Occasionally someone will notice that it is exceptionally easy to use (normally a visitor to the HQ) which will elicit a comment about how it is easier than the paper-based equivalent. The consequence of all this is that the timeline to produce the products is easily achieved with time to spare. The trainers of the system remark that there is no real training to be done, it’s just plug-and-play command and control. Occasionally the old-timers will remark that the younger staff have it easy, as they had to learn the planning process the hard way with paper maps, overlays, flip charts and pens. Then, if you wanted multiple copies you had to redraw everything by hand, now you just press a button marked ‘copy’. It’s as simple as that.
It is worth pointing out that both of these thought experiments are entirely a figment of our collective imaginations, but it is our contention that Human Factors and Ergonomics can prevent the pessimistic outcome and assist in the optimistic one. It has been the aim of this book to show that Human Factors and Ergonomics has a considerable part to play in designing and evaluating command and control systems, be they digital or analogue.