U.S. Army Research Institute

for the Behavioral and Social Sciences

Research Report 1718

Staff Group Trainer: Development of a ComputerDriven, Structured, Staff Training Environment

Milton E. Koger

Human Resources Research Organization

Susan L. Quensel and Alicia R. Sawyer

BDM Federal, Inc.

John J. Sanders, Kimberly A. Crumley, and James D. Brewer

PRC, Inc.

Bruce S. Sterling

ARI

19980622 133

March 1998

Approved for public release; distribution is unlimited.

UTIC QUALITY INSPECTED 1
U.S. Army Research Institute

for the Behavioral and Social Sciences

A Directorate of the U.S. Total Army Personnel Command

EDGAR M. JOHNSON

Director

Research accomplished under contract

for the Department of the Army

BDM International, Inc.

Technical Review by

James W. Lussier, ARI Ft. Leavenworth

NOTICES

FINAL DISPOSITION: This Research Product may be destroyed when it is no longer

needed. Please do not return it to the U.S. Army Research Institute for the Behavioral

and Social Sciences.

NOTE: This Research Product is not to be construed as an official Department of the

Army position, unless so designated by other authorized documents.
REPORT DOCUMENTATION PAGE

1. REPORT DATE (dd-mm-yy)

March 1998 .

2. REPORT TYPE

Final

4. TITLE AND SUBTITLE

Staff Group Trainer: Development of a Computer-Driven, Structured,

StaffTraining Environment

6. AUTHOR(S)

Milton E. Koger (HumRRO); Susan L. Quensel and Alicia R. Sawyer

(BDM); John J. Sanders, Kimberly A. Crumley, and James D. Brewer

(PRC) and Bruce S. Sterling (ART)

7. PERFORMING ORGANIZATION NAME(S) AND ADDRESS(ES)

BDM International, Inc. (Prime)

1801 Randolph St. NE

Albuquerque, NM 87106

PRC Inc.

1500 PRC Drive

McLean, VA 22102

Human Resources Research

Organization (HumRRO)

66 Canal Center Plaza,

Suite 400

Alexandria, VA 22314

Army Research Institute

ATTN: TAPC-ARI-IK

2423 Morande Street

Fort Knox,KY 40121

9. SPONSORING/MONITORING AGENCY NAME(S) AND ADDRESS(ES)

U.S. Army Research Institute for the Behavioral and Social Sciences

ATTN: TAPC-ARI-IK

5001 Eisenhower Avenue

Alexandria, VA 22333-5600

3. DATES COVERED (from. .. to)

September 1995 -November 1997

5a. CONTRACT OR GRANT NUMBER

MDA 903-92-D-0075

5b. PROGRAM ELEMENT NUMBER

0602785A

5c. PROJECT NUMBER

A791

5d. TASK NUMBER

2228

5e. WORK UNIT NUMBER

R03

8. PERFORMING ORGANIZATION REPORT NUMBER

10. MONITOR ACRONYM

ARI

11. MONITOR REPORT NUMBER

Research Report 1718

12. DISTRIBUTION/AVAILABILITY STATEMENT

Approved for public release; distribution is unlimited.

13. SUPPLEMENTARY NOTES

14. ABSTRACT (Maximum 200 words):

The Staff Group Trainer Project was a research and development effort sponsored by the U.S. Army Research Institute for the

Behavioral and Social Sciences in coordination with the Force XXI Program. The project produced two training support packages

(TSP)--battalion and brigade-designed to train these staffs to more effectively and efficiently communicate within and between

staffsections, command post, and the unit commander. Based on tactical scenarios developed for the Virtual Training Program,

both TSPs focused on staff functions that support the military decision-making process within the execution phase ofthe movement

to contact, deliberate attack, battalion defense in sector and brigade area defense missions. The TSP design and development were

based on lessons learned from previous Virtual Training Program efforts, structured design methodology, and adult learning

principles. This report provides details on the Staff Group Trainer Project's history, methodology, and lessons learned.

15. SUBJECT TERMS

Battalion StaffTraining

Structured Training

Brigade StaffTraining

Simulation-Based Training

Training Development Methodology

Force XXI

SECURITY CLASSIFICATION OF

16. REPORT

Unclassified

17. ABSTRACT

Unclassified

18. THIS PAGE

Unclassified

19. LIMITATION OF

ABSTRACT

Unlimited

20. NUMBER

OF PAGES

-22

21. RESPONSIBLE PERSON

(Name and Telephone Number)

Kathleen A. Quinkert, Contracting

Officer's Representative

Standard Form 298
Research Report 1718

Staff Group Trainer: Development of a ComputerDriven, Structured, Staff Training Environment

Milton E. Koger

Human Resources Research Organization

Susan L. Quensel and Alicia R. Sawyer

BDM Federal, Inc.

John J. Sanders, Kimberly A. Crumley, and James D. Brewer

PRC, Inc.

Bruce S. Sterling

ARI

Armored Forces Research Unit

Barbara A. Black, Chief

U.S. Army Research Institute for the Behavioral and Social Sciences

5001 Eisenhower Avenue, Alexandria, Virginia 22333-5600

March 1998

Army Project Number Education and Training Technology

20262785A791

Approved for public release; distribution is unlimited.

iii Preceding PageBlank
FOREWORD

The Innovative Tools and Techniques for Brigade and Below Staff Training (ITTBBST)

program is part ofthe U.S. Army Research Institute for the Behavioral and Social Sciences (ARI)

ongoing research to establish innovative methods for training combined arms forces. The

ITTBBST program has three major parts: Battlefield Functions (BFs), Battle StaffTraining

System (BSTS), and the Staff Group Trainer (SGT). The BFs are defined as processes or

activities occurring over time that must be performed to accomplish a mission or supporting

critical tasks. A BF provides task integration, combined arms interaction, and inter-Battlefield

Operating System (BOS) linkages. The BSTS is a research program using paper and multimedia

products to train brigade and battalion staff officers in basic skills necessary to perform theirjobs.

The SGT is a research and development (R&D) effort designed to train small staffgroups in basic

information management skills.

The current turbulence, staff experience levels and lack of effective training opportunities

in battalion and brigade staffs combine to create a training challenge for commanders. The SGT

R&D effort is designed to provide the commander a tool he can use to meet this challenge. The

purpose ofthe SGT R&D effort is to conduct research on training basic information management

skills needed during mission execution by a new or inexperienced staff. The SGT assumes that

individual staffmembers are knowledgeable in their individual areas. The SGT R& D program is

designed to bridge the training gap between individual skills and integrated staffskills, preparing a

stafffor mission exercises in constructive simulations or field exercises.

The training objectives ofthe SGT are ten staff processes involved in the staff decision

making cycle ofsee, assess, decide and act. The SGT R&D effort uses the structured training

method. This involves developing detailed training support packages (TSPs) containing events (in

this case, message traffic) causing the staff processes to be performed. Information is collected to

provide feedback to the training audience concerning how well these processes were performed...

This information is presented to the training audience in After Action Reviews (AARs). Training

progresses in difficulty using a crawl, walk, run sequence.

The SGT R&D effort consists oftwo TSPs, one for brigade and one for battalion. Each

ofthese TSPs contain tables training staffprocesses associated with staffsection, command post

and command and control levels. The TSPs use computers to emulate communications systems in

delivering a stream ofscripted messages from higher, lower and adjacent headquarters.

Information on performance ofstaff processes is recorded by both computers and a minimum

number of observer controllers using checklists describing staff actions expected based on the

message stream (or cues) received by the staff. The turnkey features, train the trainer materials,

and TSPs are aimed at making this an easy to use program that requires minimum preparation

time on the part ofthe commander and his staffto train staff processes in the execution phase of a

unit mission

This report documents the methodology and lessons learned in the SGT project. The

report describes the rationale on which the R&D program is based, overall design of SGT,

software, exercise and TSP development, the formative evaluation, lessons learned and overall
conclusions. The report provides researchers and decision makers an overall understanding ofthe

SGT R&D effort.

The SGT has been used by the 149th Armored Brigade ofthe Kentucky National Guard,

and is slated for use by a brigade ofthe Texas National Guard. Upon completion ofthe R&D

effort, it will be delivered to the Directorate ofTraining and Doctrinal Development (DTDD) of

the U. S. Army Armor School and Center at Fort Knox, KY. The DTDD will make decisions

concerning future refinement, use, and prospective fielding ofthe SGT R&D effort and its

products.

ZITAM. SMUTIS

Technical Director

VI
STAFF GROUP TRAINER: DEVELOPMENT OF A COMPUTER-DRIVEN,

STRUCTURED, STAFF TRAINING ENVIRONMENT

EXECUTIVE SUMMARY

Research Requirement:

Maneuver staffs needed a tool to bridge the training gap between the skills achieved

through individual training and the collective skills required of an entire battalion or brigade staff.

The contemporary battlefield inundates a staffwith information. Battalion and brigade staffs must

possess strong information management skills ifthey are to perform their mission successfully.

Staffmembers must attend to more information while responding with greater detail and speed

than ever before.

At the same time, factors such as downsizing, decreasing defense budgets, and the

emergence of advanced battlefield weaponry are impacting training requirements. These factors

create a need for less resource intensive training. An outcome ofthis evolution is an Army need

to develop innovative programs aimed at training soldiers to function effectively as battalion and

brigade staffs on the modern battlefield.

The goal ofthis research and development effort was to develop computer-driven,

structured stafftraining focused on the military decision-making process. The program was to

develop innovative tools and techniques to bridge the training gap between individual skills

training and the collective level ofinteraction and tactical decision-making provided by the

constructive simulation stafftraining environment.

Procedure: -......,.. ..-,.,-..-,-.,,- —,,,„.,.,~»,..„«,-».,^,.-.-..--~ -- . .

The development team analyzed the gap in stafftraining between individual training and

collective training on the Janus or Brigade/Battalion Battle Simulation (BBS) simulations and

designed two training programs-battalion and brigade-to bridge that gap. Each training program

was composed of progressive tables advancing from individual staffsection to command post

(CP) and then to command and control (C2) tables. A C

2

table involved multiple CPs. Each table

was divided into modules-section specific modules for the staffsection table, CP modules (e.g.,

tactical, main, and rear CP modules for the brigade program) for the CP table, and mission

(movement to contact, defense [battalion defense in sector and brigade area defense], and

deliberate attack) modules for the C

2

table. Within each module, the team developed 2-4

exercises with support materials, organized into a training support package (TSP) for each

program-battalion and brigade. After internal testing ofthe exercises, the exercises and training

system were pilot tested with soldiers. After making suggested modifications in the exercises and

TSPs, the training programs were tested with surrogate staffs and a training team. Suggestions

from these tests were incorporated into the final TSPs.

At the start ofthe project, the Staff Group Trainer hardware suite consisted ofsix Sun

SPARC workstations linked by a local area network (LAN). Two workstations were added later

in the project. Each workstation consisted oftwo 19-inch color monitors, a keyboard, a

vii
processor, and a mouse. A military tactical map was displayed on the left-hand monitor. A

message display was on the right monitor. One workstation was used to control the exercise.

This workstation sent pre-scripted messages to the other workstations.

Findings:

The concept ofusing a computer-driven, structured training environment to train new or

inexperienced staffs was found to be viable. The computer system delivered scripted message lists

that reduced training overhead. Approaches for unit training preparation and methods for

structuring the after action review (AAR) were observed to benefit the trainers and staff.

The training system needs further development for staffuse. Staff personnel cannot afford

to invest time in learning how to use a training system that differs from their operational systems.

The training program must either emulate or run on actual equipment or require minimal training

time.

The multimedia general situation previews were very effective in preparing the stafffor the

exercise. A similar presentation in the form ofspecific section previews should be developed for

each staffsection. Staffs must be brought into both the general situation and the specific situation

for their section. The multimedia presentation has the potential ofrapidly meeting this challenge.

A staff process model (graphic) proved to be an effective means offocusing the staff on task

performance. This graphic presentation ofstaff actions was effective in AARs. The multimediaassisted, end-of-module AAR aided the commander and training team in presenting a focused

AAR.

Utilization ofFindings:

The StaffGroup Trainer developed two stafftraining support packages-battalion and

brigade. More work is required to refine these programs and the delivery system into a useable

tool for the commander in the field. Ultimately, battalion and brigade staffs will be able to use

these training programs to develop staff proficiency and enhance combat readiness. Follow-on

research can build on the foundation established by this project to improve both the delivery

system and the training programs. Future sponsors, designers, developers, and trainers can

benefit by applying the lessons learned.

vui
STAFF GROUP TRAINER: DEVELOPMENT OF A COMPUTER-DRIVEN,

STRUCTURED, STAFF TRAINING ENVIRONMENT

CONTENTS

Page

INTRODUCTION .' 1

Background 1

Review OfPreceding Projects 4

Problem Statement 5

Technical Objective 5

Scope ofthe Project 5

Organization ofthe Report 6

DESIGN 6

Design Principles 6

Training Concept 8

Training Audience 12

Training System 14

Training Objective Development .14

Training Matrix Evolution 15

Training Team 21

Exercise Phases 23

SOFTWARE DEVELOPMENT 30

Methodology 30

Formative Evaluation ofthe Software 31

Key Software Enhancements 33

EXERCISE DEVELOPMENT 34

Mission Development 35

Exercise Definition 35

Exercise Materials Development 38

Development ofFeedback Materials : 40

TRAINING SUPPORT PACKAGE DEVELOPMENT 43

Structured Writing 43

Battalion Prototype Exercise Development and Delivery 44

Brigade Prototype Exercise Development and Delivery 44

Battalion Draft Training Support Package Development 44

IX
CONTENTS (continued)

Page

Brigade Draft Training Support Package Development 44

Final Training Support Package Delivery 45

FORMATIVE EVALUATION 45

Prototype Reviews 45

Pilot Tests 47

Battalion Implementation Trial 49

Brigade Implementation Trial 50

LESSONS LEARNED 52

Analysis 52

Design 55

Development 58

Implementation 62

Evaluation 63

CONCLUSIONS 64

Staff Group Trainer Project 64

Training Program Potential 65

Recommendations for Further Research , ,...;........, , 65

REFERENCES ...67

ACRONYMS and ABBREVIATIONS 71

LIST OF TABLES

Table 1. Battalion Training Audience 12

Table 2. Brigade Training Audience 13

Table 3. Training Objectives for Battalion and Brigade Training Programs 17

Table 4. Battalion Program - Training Objectives for Each Exercise 20

Table 5. Brigade Program - Training Objectives for Each Exercise 20

Table 6. Battalion Training Team 21
CONTENTS (continued)

Page

Table 7. Brigade Training Team 22

Table 8. Staff Group Trainer Project Software Modifications 32

Table 9. Module Duration 53

LIST OF FIGURES

Figure 1. StaffGroup Trainer Project training progression 3

Figure 2. The relationship between challenge and ability: The "flow" experience 7

Figure 3. Battalion training program 10

Figure 4. Brigade training program 11

Figure 5. Evolution ofthe staffsupport cycle 16

Figure 6. Training matrix 19

Figure 7. Intelligence section end-of-exercise action plan worksheet - Brigade Exercise 34 27

Figure 8. Commander's observations worksheet - Brigade Exercise 34 and 35 29

Figure 9. Exercise development flowchart.'........?.....;.......' 7..."..'....'„.'.".'.." 7.......... :.:........36

Figure 10. Staffsupport process model-Brigade Exercise 3 4 39

Figure 11. Intelligence section observer's checklist - Brigade Exercise 34 41

Figure 12. Exercise director's checklist - Brigade Exercise 34 42

xi
STAFF GROUP TRAINER: DEVELOPMENT OF A COMPUTER-DRIVEN, STRUCTURED

STAFF TRAINING ENVIRONMENT

INTRODUCTION

The Staff Group Trainer1Project was a research and development program to develop

computer-aided, structured stafftraining using the execution phase ofthree combat missions:

movement to contact, defense, and deliberate attack-to focus on the military decision-making

process. The Staff Group Trainer Project produced two separate training support packages

(TSP)-one for a heavy maneuver battalion/task force, and one for a heavy maneuver brigade.

Within both TSPs, the exercises were designed to be progressively more difficult (crawl, walk,

run). Both programs contained three components-staffsection exercises (training within the

section, or "intra-staff'), Command Post (CP) exercises (training within the whole CP, i.e.,

between sections or "inter-staff'), and Command and Control (C2) exercises (training between

CPs, e.g., main and rear CPs).

Background

Current evolution ofthe U.S. Army requires innovation in manning, training, and

equipping the force. Factors such as downsizing, decreasing defense budgets, and the emergence

of advanced battlefield weaponry are creating new training requirements. These factors clearly

create a need for less resource intensive training. Not only must a soldier ofthe 21st century

possess new skills; he/she faces the challenges ofincreased staffturnover currently facing the

Army. Additionally, data collected from the Combat Training Centers have identified deficiencies

in training staffsynchronization (Thompson, Pleban, & Valentine, 1994; Department ofthe Army,

1996). One outcome is an identified Army need to develop innovative programs aimed at training

soldiers to function effectively as battalion and brigade staffs on the modern battlefield. The Staff

Group Trainer Project addressed this need. This project was developed under the Force XXI

Training Program (FXXITP), a program to carry the Army's training capabilities into the 21st

Century (Department ofthe Army, 1994).

The contemporary battlefield inundates a staffwith information. It is vital that battalion

and brigade staffs possess strong information management skills ifthey are to successfully

perform their mission. Staffmembers must attend to more information while responding with

greater detail and speed than ever before. This challenges staff personnel and their capacity to

process, analyze, coordinate and integrate information, and make recommendations.

The predecessor Commander/Staff Trainer (C/ST) was developed under the Simulationbased Multiechelon Training Program for Armor Units (SIMUTA) program. It consisted of a

computer networked system with six workstations supporting a battalion staff exercise aimed at

training information processing for principal staff officers in the main CP and combat trains CP

1 Staff Group Trainer was originally called Commander/StaffTrainer (C/ST). The name was changed in summer

1996.
processing for conventional forces, with staff officers directing disposition ofincoming messages

and creating minimal message traffic within a movement to contact scenario. Textual feedback

modules linked to individual performance during the mission, focusing strictly on message

handling and overlay maintenance, were present on individual workstations. The SIMUTA C/ST

Project did not train staffinteraction.

The SIMUTA Program was part ofthe Reserve Component Virtual Training Program

(RCVTP). The RCVTP was established at Fort Knox, Kentucky to develop innovative structured

training for the total armor force so that networked simulation technologies could be fully

exploited. The RCVTP was redesignated the Virtual Training Program (VTP) to more accurately

reflect a total force program.

The U.S. Army Research Institute for the Behavioral and Social Sciences' (ARI's)

statement ofwork for a follow-on to the SIMUTA C/ST Project was included in the "Innovative

Tools and Techniques for Brigade and Below Staff Training (ITTBBST)" Program. This

program called for enhancements to the SIMUTA C/ST software and exercises and specified

adding battalion-level defense in sector and deliberate attack missions and retrofitting the

movement to contact mission developed for the SIMUTA C/ST Project. It also required

development of brigade exercises for the area defense, deliberate attack, and movement to contact

missions. Under the ITTBBST Program, the Staff Group Trainer Project became part of an

integrated training strategy including the Battle Staff Training System (BSTS) based on

Battlefield Functions (BFs)2. More information on BFs, particularly those related to command

and control ofthe armored brigade, can be found in Ford, Mullen and Keesling (1997).

The BSTS Project developed computer-assisted instruction on individual staffskills for

commanders and staff officers in armored and mechanized infantry battalions and brigades. The

BF Project analyzed processes or activities performed to accomplish a mission or support critical

tasks! The BFs provided developers in the BSTS and Staff Group Trainer Projects with detailed '

descriptions ofC

2

functions emphasizing linkages and dependencies among maneuver, combat

support, and combat service support elements. The BFs established a common framework for

designing and implementing performance measurement and after action reviews (AARs).

The Staff Group Trainer Project's training exercises were designed to serve as the "bridge"

between individual staff officer skills training provided by the BSTS and the structured unit

training provided by simulation-driven exercises developed in ARI's SIMUTA Simulation-based

Mounted Brigade Training (SIMBART) and Combined-arms Operations at Brigade Level,

Realistically Achieved through Simulation (COBRAS) Programs (Figure 1). At a macro level, the

BFs provided a task-based strategy for stafftraining and provided objective performance

measures for the Staff Group Trainer Project. Thus, the BFs provided the structure to span the

training gap from BSTS to Janus-driven exercises with the VTP or FXXITP.

2 The term "Battlefield Function (BF)" was designated by the U.S. Army Training and Doctrine Command

(TRADOC) in September 1996 to replace "Critical Combat Function (CCF)."
In the ITTBBST Program, the ideal training progression begins with BSTS training to

develop the individual's understanding ofhis staffresponsibilities. Staffmembers then participate

in a series of Staff Group Trainer exercises. These dynamic small group training experiences

focus on staff processes needed to support the commander's battlefield awareness, recommend

courses of action, and support the commander's decisions. The structured messages sets and

short situational exercises focus the staffs on intra- and inter-staffprocesses. Participation in Staff

Group Trainer exercises helps prepare staffmembers for an increased level ofinteraction and

tactical decision-making provided by the Janus or Brigade/Battalion Battle Simulation (BBS)

collective training environment.

Command & Control

Tables

Command Post

Tables

Staff Section

Tables

söSSsÜBsääi

liOTP^

Figure 1. Staff Group Trainer Project training progression.
Review OfPreceding Projects

The Staff Group Trainer Project had its roots in two related areas. The first was the ARI

Armored Forces Research Unit (AFRU) research on future battlefield conditions. The second

was ARI AFRU research on structured, simulation-based training for mounted forces.

Starting in the late 1980s, the ARI AFRU conducted a series of experiments to evaluate

new tools and equipment (position navigation system, command and control display, and

commander's independent thermal viewer), which the Army was planning to bring to the armored

forces. Much ofthis research effort fell under the Combat Vehicle Command and Control

(CVCC) Program. It began by evaluating each piece of equipment at crew and tank platoon

levels (Du Bois & Smith, 1989, 1991; Quinkert, 1990). From crew and platoon levels, the

research progressed to evaluating the integrated impacts of all tools and equipment at company

level (Leibrecht, Kerins, Ainslie, Sawyer, Childs & Doherty, 1992) and then at battalion level

(O'Brien, Wigginton, Morey, Leibrecht, Ainslie, & Sawyer, 1992; Leibrecht, Meade, Schmidt,

Doherty,' & Lickteig, 1994; Meade, Lozicki, Leibrecht, Smith, & Myers, 1994; Atwood, Winsch,

Sawyer, Ford, & Quinkert, 1994). A limited part ofthe research effort at battalion level focused

on the role ofthe battalion tactical operations center (TOC) equipped with automated

workstations (O'Brien et al. 1992). This initial research with automated workstations provided the

equipment and impetus to continue investigating an approach for training effective and efficient

staff processes.

The second origin ofthe StaffGroup Trainer Project came from research in structured

training conducted under SIMUTA starting in 1993 (R. G. Hoffman et al. 1995). The intent of

SIMUTA was to provide compressed, turnkey training to units in a simulation environment

focusing on the mission execution phase. Unit collective training was developed for tank,

mechanized infantry, and scout platoons; tank companies and tank-heavy company/teams; tank

battalions and tank-heavy task forces; and tank or tank-heavy battalion/task force staffs. Training

materials were developed and packaged as a library ofstructured simulation-based training

exercises which a unit commander could use to meet unit training needs. These exercises came

with a complete TSP including a multimedia program orientation and planning materials with

complete operation orders (OPORDs) for the units; and job aids, exercise checklists and feedback

guidelines for observers to use during preparation, execution, and AARs. The TSP also included

guidelines for preparing take home packages (THPs) for units after they complete their training.

The SIMUTA program (C. H. Campbell, R. C. Campbell, Sanders, Flynn, & Myers, 1995; R. G.

Hoffman et al. 1995) provided a basis for the orders, TSPs, THPs, and structured simulationbased training development methodology ofseveral follow-on programs including the Staff Group

Trainer Project.

The C/ST project was part ofthe SIMUTA program and used CVCC technology as a

base. The CVCC TOC workstations were used as exercise drivers and part-task trainers for

primary battalion staff. Simulation Networking (SIMNET) acted as a driver for the CVCC

soldier-in-the-loop simulations for mission rehearsals, war gaming, execution, and AARs. The

C/ST workstations were different from the CVCC TOC workstations in their purpose-training

versus research. Since the ARI AFRU wanted training to focus on information processing, the
ARI research team developed four exercises based on the SIMUTA movement to contact

scenario. The SIMUTA C/ST hardware/software package established the baseline from which the

Staff Group Trainer Project's hardware/software package evolved.

Three preceding projects-SIMUTA, SEMBART, and SIMUTA - Battalion Exercise

Expansion (SIMUTA-B)-provided baseline OPORDs and the framework for the tactical

structure ofthe StaffGroup Trainer Project's scenarios. They also provided the initial

methodology for design and development oftraining exercises and TSPs.

Problem Statement

As represented in Figure 1, maneuver staffs needed a tool to bridge the training gap

between the skills achieved by a primary staff officer who had participated in BSTS training and

the collective skills required of an entire battalion or brigade staffusing SIMUTA SEMBART or

COBRAS training exercises. The Staff Group Trainer Project development team's front-end

analysis indicated this gap should be spanned by a stepped training package. This translated into

staff cell training (small groups ofindividuals from a staffsection operating within a CP), CP

training, and training ofthe collective staff operating in multiple CPs. The development team

found a need for training emphasis on the staffs synthesis ofinformation and the communication

ofthat information to the commander so that he could use it in his decision-making process.

Technical Objective

The primary objective was to develop and formatively evaluate primary staff and

staff/group training modules using the Staff Group Trainer technology at battalion and

brigade levels for movement to contact, deliberate attack, and defense missions.

Scope ofthe Project

The StaffGroup Trainer Project developed a battalion and a brigade stafftraining

program. The training programs used a modified SIMUTA C/ST hardware/software package to

support delivery ofthe training. The training approach focused on the performance ofindividual

staffmembers, staffgroups (e.g., Intelligence Officer [S2] and Operations Officer [S3]), and the

integration/synchronization ofthe primary battle staff during the execution phase ofthe scenarios.

Each scenario used the SIMBART and SIMUTA-B orders developed for the VTP. These

scenarios were based on at least one battalion operating east to west in the central corridor ofthe

National Training Center at Fort Irwin, California. The enemy forces were the same as those in

the SIMBART and SIMUTA-B scenarios and were based on the heavy opposing force units at

the Combat Training Centers and in the U.S. Army Training and Doctrine Command (TRADOC)

(Department ofthe Army, 1993b, 1993c). Each exercise took less than an hour of actual

execution time. Each was preceded by a preview and preparation phase that did not exceed an

hour and was followed by a structured AAR ofless than an hour. The training programs included

train-the-trainer components, TSPs, and preview and AAR support materials.
Organization ofthe Report

The remainder ofthis report contains the following sections:

Design - A description ofthe training program design including decisions that were made

and rationales for those decisions.

Software Development - The methodology and decisions involved in modifying the system

software.

Exercise Development - A description of how the exercises were developed, decisions

made during the development, and the internal formative evaluation.

Training Support Package Development - A discussion ofthe process for developing the

TSPs, including decisions made and results ofreviews ofthe initial products.

Formative Evaluation - A description ofthe formative evaluation process followed in the

project and a summary of key findings during external tests ofthe training program.

Lessons Learned - A summary ofthe most important lessons learned during the project.

Conclusions - The findings and suggestions for continued research.

DESIGN

Design Principles

The StaffGroup Trainer Project development team designed the TSPs for the staffto have

a high likelihood ofsuccess in each exercise. Research in adult learning and stafftraining support

this design objective. Olmstead (1992) pointed out that other researchers (Mills, 1967; Gill,

1977) found that nothing contributed more to greater cohesiveness than a successful action.

Thus, the team developed the training programs so that for each exercise, the staffwould be

challenged but should successfully achieve the exercise's training objectives. Druckman and

Bjork (1994) wrote that "self-confidence is a potent predictor of an individual's performance" (p.

202) and that the role of an instructor is "to develop and sustain a learner's high level ofselfconfidence by ensuring performance success" (p. 202). Jourdan, Bandura, and Banfield (1991)

suggest that when first teaching a complex task, a learner's self-confidence beliefs and perception

ofsuccess are enhanced by emphasizing process-related (learning) goals over outcome-related

(performance) goals. Success is redefined to include effort, form, and strategy, rather than

winning or losing or number oftasks completed (Jourdan et al. 1991).

Designing exercises that are both challenging and provide a high likelihood ofsuccess is a

formidable task. The task is to design exercises where the challenge of a task matches the ability

ofthe participants, so that they become absorbed "in the game." This is referred to as "flow"

(Martens, 1990). On one side ofthe "flow" state is frustration because a task is too challenging;

on the other side is boredom when the task is too easy (see Figure 2). Within the "flow" state, the

training challenges the participant but he experiences success. Martens stated that the participant

becomes caught up in or "immersed" in the activity when the "flow" state is achieved. This could
be similar to Brown's (1992) concept ofimmersion. While designers, developers, and trainers

strive to achieve this "flow" state in training, it is complicated because staffs and staffsections are

often not at the same level oftraining. Providing "flow" exercises for all requires a robust training

environment. The training matrix conceptualized at the beginning ofthis project to provide this

robustness is discussed later.

High

CHALLENGE

Low

Anxiety

Low

ABILITY

Figure 2. The relationship between challenge and ability: The "flow" experience

(This figure is from Martens, 1990, p. 45.).

The development team designed the AARs and trainer instructions so that feedback to the

stafffocused on performance ofstaff actions and was provided positively-praising good

performance and avoiding harsh criticism of poor performance. During feedback sessions,

Johnson and Johnson (1994) emphasized that team members must process how they are

functioning as a team, examine what actions were helpful and not helpful, and make decisions

about what they want to continue or change.

The development team designed the training to foster team cohesiveness. Training a staff

requires staffmembers to be able to: (a) individually make decisions by processing systemspecific knowledge and (b) function as members of a team sharing individual knowledge and

conclusions, then processing pooled information into system-wide decisions (Druckman & Bjork,

1994). According to Mclntyre and Salas (1995), "tactical teams within the military exist (1) to

help a leader assess a given scenario involving imminent danger or threat, (2) to provide

information to the leader in a form that he or she can use in making a decision, and (3) to

implement the action implied by the decision that the leader comes to" (p. 9). Orasanu and Salas

(1993) discussed a concept of "shared mental models." A shared mental model is organized

knowledge shared by team members who work together over relatively long periods oftime.

According to Orasanu and Salas (1993, p. 7), "such knowledge enables each person to carry out

his or her role in a timely and coordinated fashion, helping the team to function as a single unit

with little negotiation ofwhat to do and when to do it." U.S. Army doctrine establishes a basis

for a staffs "shared mental model" (Department ofthe Army, 1988a; 1988b; 1988c; 1988d; 1992;

1993d). The StaffGroup Trainer Project development team designed the TSPs so that leaders

would reinforce this model. Orasanu (1990) found that leaders of high-performing teams stated
more plans, considered more options, provided more explanations, and sounded more warnings or

predictions. The TSP design concept was built on this research background and Army doctrine,

and it formulated conditions to guide the staffto develop a "shared mental model." The

development team also established training objectives that emphasized process-related goals

(Jourdan et al. 1991).

To embed these design concepts in the TSPs, the development team designed the TSP to

allow leaders to communicate expectations for what was required from the staff/sections prior to

the start of an exercise. Thus, at the start of an exercise, leaders communicated plans, options,

explanations, warnings, and predictions for the exercise. Because ofleader involvement in the

training, leaders could reinforce or expand upon what they wanted to see during exercise

execution. Because training exercises portrayed a unit successfully conducting its mission, the

development team provided message traffic to the staffthat showed subordinate units were

successful. During each exercise, the training staff had a high likelihood of achieving the training

objectives. To further encourage this, the basic message list from the subordinate and higher units

or staffs provided an accurate and timely picture ofthe battlefield. Messages were regulated so

that the staff had adequate time to perform required tasks.

The development team designed the AAR to focus on processes and what did and did not

work. As suggested by Johnson and Johnson (1994), observers facilitated the staffformulation of

what to continue (sustain) or change (improve).

Training Concept

The Staff Group Trainer Project plan was based on an analysis ofthe training gap between

BSTS and collective Janus or BBS exercises. The development team examined results ofthe

SIMBART trials (a structured Janus brigade staff exercise), the. SIMUTA Janus.trials (structured

Janus battalion staff exercises), BSTS courses, and the SIMUTA C/ST exercises. They

determined that SIMUTA C/ST exercises would not provide the staffsections and CPs the

interactive train-up they would need prior to a Janus or BBS exercise.

As a result ofthis analysis, a new concept emerged, involving more than the primary staff

officers. The training became oriented toward the staffsection, the CP, and the unit staff as a

synergistic team. For this effort, the development team adopted the definition of "team" used by

Morgan, Glickman, Woodard, Blaiwes, and Salas (1986, p. 4), "...a distinguishable set oftwo or

more individuals who interact interdependently and adaptively to achieve specified, shared, and

valued objectives." This shift in focus was the impetus to change the project name from C/ST to

StaffGroup Trainer.3The revised StaffGroup Trainer concept highlighted how staff officers

would evaluate the information and make decisions on mission impact, and then take action on

their analysis. The new concept expanded the training audience to include at least two additional

members per section. These individuals assisted and freed that section's officer to perform the

3 Although not actually adopted until this project was underway, the term Staff Group Trainer will be used for the

project from this point forward. This highlights the change in focus from the SIMUTA C/ST project.
higher order stafftasks and interact with other sections as the training expanded into a decisionmaking exercise.

The TSP structure was organized in tables. Tables consisted ofseveral modules, each

containing several exercises. Figure 3 illustrates the battalion TSP, while Figure 4 illustrates the

brigade training program. The entry point for all staffsections was their first exercise in the staff

section table. Each section had its own module consisting oftwo exercises. In the battalion

program, the section modules were conducted concurrently. In the brigade program, the main CP

and tactical command post (TAC CP) section modules were conducted concurrently. The rear

CP modules were conducted at a different time because there were not enough workstations to

conduct all sections concurrently. For both the battalion and brigade TSPs, each CP had its own

training module. Both the brigade and battalion TSPs contained three exercises per CP module.

The C

2

tables in both programs consisted ofthree modules-movement to contact, deliberate

attack, and defense (battalion defense in sector and brigade area defense) missions. In the

battalion TSP both CPs participated in each module. Each module in the battalion TSP consisted

offour exercises. In the brigade TSP only two ofthe three CPs could participate in each module.

The command group and TAC CP participated in the movement to contact module. The main

and rear CPs participated in the deliberate attack module. The TAC and Main CPs participated in

the area defense module. Each module in the brigade program consisted oftwo exercises.

The remainder ofthis chapter discusses the program design in terms ofthe training

audience, the training system (hardware and software), training objectives, evolution ofthe

training matrix, the training team, and phases of an exercise.
Io

a, 2

•aic

.2

13S
sa.

•a

•3\-< +-»

13

•c«u

.1
Training Audience

The development team designed each TSP for a staffinitially at a "crawl" level oftraining.

Such a staffwould be inexperienced in working with one another or be having difficulty working

together. This does not imply that individual staff members would be untrained but that, as a

collective section, the staffis at the "crawl" level oftheir training. In fact, each staffmember was

assumed to be knowledgeable of his job. The development team profiled the training audience as

members of an active or reserve conventional heavy maneuver battalion or brigade staff. A

conventional unit was one equipped with fielded digital equipment (i.e., current maneuver control,

field artillery, intelligence, and combat service support systems) but no experimental digital

equipment. The training audience was defined as individual staffmembers, staffgroups (e.g.,

members ofthe S2 and S3 sections), and primary battle staff. The training audience includes

those staffmembers who routinely work in one ofthe unit's CPs—see Table 1 and Table 2. The

commander and the S3 are not included in this training audience. The commander and the S3, but

especially the commander, are involved in the TSPs as trainers and unit standard setters.

Table 1

Battalion Training Audience

Command Post Section Training Personnel

Operations Section

Main Intelligence Section

Command Post

Fire Support Element

Engineer Section

Logistics Section

Combat Trains Personnel Section

Command Post

Battalion Maintenance Section

Medical Platoon

Executive Officer (XO)/Battle Captain (BC)

Assistant S3

Operations Non-Commissioned Officer

(NCO)

Operations Assistant - -

S2

Intelligence NCO

Intelligence Specialist

Fire Support Officer

Fire Support NCO

Fire Support Specialist

Engineer Officer

Engineer NCO

Engineer Specialist

Logistics Officer (S4)

Supply NCO

Personnel Officer (SI)

Assistant Personnel StaffNonCommissioned Officer (PSNCO)

Maintenance Officer/NCO

Maintenance Administration Specialist

Medical Officer/NCO

Medical Administration Specialist

12
Table 2

Brigade Training Audience

Command Post Section Training Personnel

Tactical Command Post

Main Command Post

Rear Command Post

Operations Section

Intelligence Section

Fire Support Element

Operations Section

Intelligence Section

Fire Support Element

Engineer Section

Logistics Section

Personnel Section

Support Operations Section

S3 (Officer in Charge [OIC])

53 Air

Assistant Operations NCO

Operations Assistant (optional)

Tactical Intelligence Officer

Senior Intelligence NCO

Assistant Fire Support Officer [FSO]

Fires Support Specialist

XO or Battle Captain

Assistant S3

Operations NCO

Operations Assistant

54 Representative

S2

Intelligence Sergeant

Assistant S2

Fire Support Officer

Fire Support NCO

Fire Support Assistant

Engineer Officer

Engineer NCO

S4

Senior Supply NCO

SI

Medical NCO

PSNCO

Forward Support Battalion (FSB)

Operations Officer

Assistant FSB Operation Officer

13
Training System

Initially the Staff Group Trainer hardware suite consisted ofsix Sun SPARC workstations

linked by a local area network (LAN). Two workstations were added later in the project. Each

workstation consisted oftwo 19-inch color monitors, a keyboard, a processor, and a mouse. A

military tactical map was displayed on the left-hand monitor. A message display was on the right

monitor. One workstation was used to control the exercise. When an exercise was executed, this

workstation sent pre-scripted messages from the exercise message database over the LAN to the

other workstations. One or two workstations were allocated for support personnel role-playing

subordinate units or staffs and higher headquarters. The remaining workstations were allocated

across the staffpositions. The system also had a large screen monitor that was used to display the

main CP's situation map. Each staffsection in the main CP could update information to this

situation map.

The allocation ofworkstations varied depending upon what staff positions were trained in

a given exercise. These workstations emulated the staffsection's mapboard, staffjournal, files,

and all forms of communication devices the staffsection might have (i.e., radios, faxes,

telephones, fielded digital systems, etc.). The messages from the control station were addressed

to specific stations (i.e., S2, commander, etc.). Each workstation displayed only the messages (a)

addressed to the staffsection using the workstation or (b) available via network distribution. The

LAN permitted staffmembers at the different workstations to exchange information. Additional

reports could be created and received.

The two main components of each workstation were the tactical map display and the

message display. The map display gave each staffsection the ability to tailor the map's scale and

features to meet their needs. The section could create, display, and edit various operational

overlays on the map display; This enabled the staffsection to maintain the same type ofmap- -

based information as they would in a CP. The message display indicated incoming reports and

allowed the section to open a message to read its contents. Messages were displayed in standard

message formats. The staffsection could also store, recall, compose, transmit, forward, and

annotate messages on the workstation.

The team developed software modifications to enhance some ofthe functional features

and to make the system more reliable and easier to use. These modifications are discussed in

more detail in the software development section.

Training Objective Development

The training objectives for the Staff Group Trainer represented an evolution from the

work completed within the SIMBART program and incorporation ofthe BF analyses.

The SIMBART development team devised a means offocusing on staff activities that

supported the commander's decision points (Koger, Long, Britt, Sanders, Broadwater & Brewer,

1996). The team drew heavily on Olmstead's (1992) adaptation of Schein's (1965) adaptivecoping cycle which looked at organizational process. Schein (1965) suggested this cycle as a

sequence of activities used by organizations in adapting to changes in their environments.

14
Olmstead (1992) adapted this cycle to identify, isolate, and evaluate staff processes. Olmstead's

adaptation is shown as the inner cycle in Figure 5. The SIMBART cycle is the second ring in

Figure 5. The SIMBART team referred to this as "greening" or changing the terminology to

Army terms rather than academic terms. The SIMBART development team established an

observation and feedback system that focused on these staff processes, and although some

difficulties arose with the implementation during the pilots and trial, the design was an effective

way to quantify staff performance.

The Staff Group Trainer Project development team focused on training the staffto meet

the commander's needs on staff processes and products. The development team also examined

the BFs. The BF analyses fit well into the staffprocess model developed in SIMBART. With a

few changes and adjustments, the development team modified the SIMBART cycle into the cycle

shown as the outer ring in Figure 5. This cycle defined the training objectives for the exercises.

The training objectives evolved as the project matured. Initially, only five training

objectives—process, analyze, coordinate, integrate, and recommend—were listed in the training

program. By the end ofthe project design phase, all ten training objectives were included in the

program. Table 3 shows the training objectives as they appeared in the final TSPs.

Training Matrix Evolution

The concept for the project's training matrix originated with Lieutenant General Frederic

Brown (Retired) at the SIMUTA proof-of-concept test when he referred to C/ST as the "staff

conduct-of-fire trainer (COFT)" . The development team conceptualized a matrix that progressed

from the staffsection to CP and then to the staffin multiple CPs. This sequence enabled

individual staff officers to progress from individual tasks to full staff exercises. This conceptual

matrix became the foundation for the design and development of each training program. Each

block m the matrix represented a single exercise. The version, shown in Figure 6, bears a

similarity to the unit COFT training matrix (General Electric, 1985). There were three

dimensions-training complexity (X-axis), mission complexity (Y-axis), and simulation intensity

(Z-axis).

Training objectives became more complex from the staffsection table to the C table along

the X-axis (from left to right in Figure 6). In Tables 4 and 5, the training objectives are ordered in

the left column. These tables illustrate the progression within the battalion and the brigade

programs, respectively. Note that early exercises focused on first training objectives—monitor,

process, and analyze-while the C

2

table focused on later training objectives of direct,

synchronize, and disseminate.

15
I

o

OH

3

1

+-•

O

e

o

'Io

2

VO
VO

o

(X

J5

+-»

O

c

o

I

3»
Table 3

Training Objectives for Battalion and Brigade Training Programs

Training Objective Description

Monitor unit operations

Process information and

messages

Analyze/evaluate

information

Communicate mission

critical information

Coordinate information

and intelligence

Integrate staffinput

Recommend a course

of action

Disseminate

commander's decision

Synchronize activities of

subordinate and

supporting units.

Direct BOS assets to

support commander's

intent

Each section actively seeks information about

• higher,

• adjacent,

• support and

• subordinate units.

Each section acquires information by

listening to reports and

asking for needed information.

Each section

• collates,

• transforms, and

• organizes information.

Each section stores information on

• maps,

• situation boards,

• journals, and

• files.

All information can be retrieved and used.

Each section attaches meaning, either speculative or confirmed, to information that

has been acquired.

Each section transmits information or intelligence to those who must make

decisions about or act on it. This includes initial transmittal ofsensed information;

relaying; and disseminating throughout the

• staff,

• command posts, ' *"'

• subordinate units,

• supporting units, and

• higher headquarters.

Each section exchanges and discusses information and intelligence with others

outside the section to clarify meaning and determine implications.

The XO/BC aids the commander's battlefield awareness by:

combining information and intelligence from all staffsections,

putting information and intelligence into a useable format, and

passing information and intelligence to the commander.

The XO/BC identifies areas requiring staffsections to combine efforts to support

the commander's intent.

XO/BC and staff sections develop and analyze courses of action.

XO/BC recommends a course of action to the commander.

The staff prepares and issues orders or fragmentary orders (FRAGOs) to inform

units and staff of commander's decision.

The XO/BC and each section monitor unit and Battlefield Operating Systems

(BOS) assets to ensure their efforts are aligned to execute the commander's intent

or direction.

The XO/BC and each section

track activities ofBOS assets and

intervene, ifrequired, to ensure their activities support the commander's intent.

17
The Y-axis ofthe matrix (the vertical axis in Figure 6) represented the complexity ofthe

program's three missions. When the development team analyzed these missions for complexity of

staff actions, they ranked the three missions from simplest to most complex as follows:

movement to contact, deliberate attack, and defense.

The Z-axis (the front-to-back axis in Figure 6) represented simulation intensity. The

original idea was to vary not only the number ofmessages but also the type ofinformation and

accuracy. There would be three different message lists-one with only critical messages, one with

critical messages and other messages that were not critical for the section, and one with critical

messages, non-critical messages, and inaccurate messages. Progressing along the Z-axis would

have meant that the staffwould have to deal with increasing numbers ofmessages, as well as an

increase in complexity of analysis because of changes in the message value and accuracy. In the

delivered exercises, only accurate messages were included although the list did contain both

critical and non-critical messages. Only accurate messages were included because the

development team was concerned with the workload at each workstation.

For this project, the team did not develop TSPs for the entire matrix. The unshaded

blocks in Figure 6 indicated exercises the development team proposed to complete in this project.

The unshaded blocks represented a possible progression a unit would take through the matrix to

complete the training. Figures 3 and 4 (presented earlier) showed the delivered programs. The

exercises in these programs corresponded to the unshaded blocks. Although the conceptual

matrix indicated multiple entry points, the delivered training programs had one entry point. The

staff's progress through the matrix would be determined by its performance in an exercise.

Exceptional performance would take the staffinto more challenging exercises. Poor performance

would result in a remedial exercise. The staffwould progress to the next table only after

successful completion ofthe gate exercise. Since the entire matrix was not developed and the

development team was concerned with the workload at each workstation, the developed exercises

contained only accurate messages.

18
«ONÜs

•

"-Ö

*j£

c•

- UJ E£oON•o

*—•Ü

ok-

-» BOU

««

•oEO

ft.

•oe«EEoO

OS

O

£

a»

•a

'3
Table 4

Battalion Program - Training Objectives for Each Exercise

Section Table Command Poslt Table Command anc Contro Table

Training

Objective

First

Exercise

Second

Exercise

First

Exercise

Second

Exercise

Third

Exercise

First

Exercise

Second

Exercise

Third

Exercise

Fourth

Exercise

Direct ; F

Synchronize F

Disseminate - F F

Recommend F - F . F - 0

Integrate F ■■■■■■■-t's\ F '.-.Ft*- ' F- o

Coordinate . F F F -

F~

F •

Ö 0

0

Communicate F 0 0

Analyze F F F 0 F 0 0 0

Process F O 0 0 O 0 0 o 0

Monitor F O 0 0 U O 0 o 1 o 1

F - Focus ofthis exercise

O - Training objective previously focused upon, now observed only

Table 5

Brigade Program - Training Objectives for Each Exercise

Section Table Command Post Table Command and

Control Table

Training

Objective

First

Exercise

Second

Exercise

First

Exercise

Second

Exercise

Third

Exercise

First

Exercise

Second

Exercise

Direct b

Synchronize F

Disseminate F

Recommend F F"- " F

Integrate F F

ii iy . ,III

F.-:- V,-/p . •: -.

Coordinate F F F ' 0

Communicate F F F 0

Analyze F F 0 0 Ü -r O ^-:

Process F ^v'0'y;

; 0 0 0 0 0

Monitor %:;F»,v. 0 0 0 0 0 0

F - Focus ofthis exercise

O - Training objective previously focused upon, now observed only

20
Training Team

The framework for the TSP design was not tied to the organization and functions of a

specific training team.4The development team configured a training team composed of 12

trainers for the battalion program (Table 6) and 15 trainers for the brigade program (Table 7).

The following paragraphs summarize the role of each training team member.

Table 6

Battalion Training Team

Title Quantity

Exercise Director

Senior Observer (Main Command Post)

Intelligence Section Observer

Operations Section Observer

Fire Support Element Observer

Engineer Section Observer

CTCP Observer /Logistics Section Observer

Personnel/Medical Section Observer

Maintenance Section Observer

Interactor 2

System Administrator 1

„ . Exercise Director ...............

The exercise director worked with the unit commander before, during, and after the

exercise. The director assisted the commander by helping him focus on important issues that

occurred and ensuring that the training team brought important information on staff performance

to the commander's attention during execution. The TSPs contained materials that the exercise

director used to assist the commander.

System Administrator

The system administrator initialized the training system and loaded the exercises. During

the exercise, he ensured that the messages were properly sent to the workstations and took

immediate action should any problems occur. After the exercise, the system administrator sent

the end-of-exercise (ENDEX) materials to all the workstations and prepared the system for the

AAR process.

4 The training team has been referred to as an observer/controller (O/C) or observer/controller/interactor (O/C/I)

team in other programs. This project used the term "training team" to reflect the team's training focus.

21
Table 7

Brigade Training Team

Title Quantity

Exercise Director

Senior Observer/Main CP Observer

Intelligence Section Observer (Main CP)

Operations Section Observer (Main CP)

Fire Support Element Observer (Main CP)

Engineer Section Observer (Main CP)

TAC CP Observer/Operations Section Observer (TAC CP)

Intelligence Section Observer (TAC CP)

Fire Support Element Observer (TAC CP)

Rear CP Observer/Logistics Section Observer (Rear CP)

Personnel Section Observer (Rear CP)

FSB Support Operations Section Observer (Rear CP)

Interactor 2

System Administrator 1^

Interactors

.. Interactors role-played as higher, lower, and adjacent staffs communicating with the

training audience. During the exercise, the interactors responded to message traffic not addressed

to the training audience. They kept the exercise director and commander apprised of how the

staffwas keeping higher and lower headquarters informed ofthe battle.

Command Post Observers

One person served as the observer in the Main CP. In the TAC CP, Rear CP, and CTCP,

the CP observer also observed one ofthe sections. The CP observer monitored the interaction

between the sections within the CP. After each exercise, he discussed his observations with the

officer charged with the CP's operation. The CP observer in collaboration with the exercise

director facilitated the end-of-module AAR.

Staff Section Observers

The training team included a dedicated observer for every section in each CP. This

arrangement ensured that each section was observed and given feedback at the end of every

exercise. Individual section observers were most important during the initial tables where the

focus was on the staffsection's performance ofthe initial training objectives.

22
Exercise Phases

The project design organized the exercises into phases to facilitate exercise development

and administrative control during execution. These phases began when a unit was at the site and

had made its preparations for conducting the training. Each exercise was broken into four phases:

• Exercise preview,

• Exercise preparation,

• Exercise execution, and

• AAR.

The following sections discuss each phase and its design basis. The methods for

developing the indicated materials are discussed in the exercise development section.

Exercise Preview

Brown (1992) wrote that setting the context for a battle command stafftraining exercise

would be a significant implementation challenge. His goal was to have the staffimmersed in the

battle context in 30 minutes or less. He suggested that a unit staffwould have to be

knowledgeable about both the general situation and the specifics necessary for "each individual

staff officer and small staffteam to fit in to a fast moving situation" (Brown, 1992, p. 3-8).

Brown envisioned the general situation summary to be far easier than the specific situation to

present to a staff. He anticipated the specifics to be the most challenging to present, but to have

the "highest potential for training applications" (p. 3-9).

The project development team's analysis aligned closely with Brown's (1992). They

envisioned the general situation summary to be a short battle summary to the entire staff,

consisting of:

• what had led up to this point in the battle,

• what to expect in the exercise, and

• the exercise training objectives.

The developers designed the general situation summary to be conducted by the exercise

director or senior observer using a map with appropriate overlays. The commander could tell his

staffwhat he expected from them during the exercise. The commander's expectations consisted

ofthe critical pieces ofinformation he needed from the staff or the fact that he wanted the staffto

make a recommendation based on their analysis ofthe situation when a decision point was

reached. This approach was based on Orasanu's (1990) findings on leaders of high-performing

teams and reinforced the "shared mental model" concept discussed by Druckman and Bjork

(1994). The developers allotted 10 minutes for the general situation summary and the

commander's instructions. The developers also prepared a multimedia presentation ofthe general

23
summary for several modules to demonstrate an alternative approach to delivering this portion of

the preview.

The specific situation was more challenging to prepare and present to the unit. The design

was structured so each section observer could present a separate section preview including

updated information or charts, overlays, journals, etc. and a verbal section-specific situation

update. The section observer was required to highlight the portion ofthe decision support

template (DST) and execution matrix specific for the section and any other section specific

requirements. The section leader was allowed time to highlight his needs, other staffsection

needs, and his commander's needs. These needs were derived from the section leaders' analysis

ofthe DST, execution matrix, and guidance provided by the XO/BC. This highlighting ofneeds

further supported the "shared mental model" concept. The exercise TSP provided each section

observer with his briefing and all exercise material for his section. The section observer was

allotted about 10 minutes for his preview. The delivery ofthe preview was vital for the unit to

achieve maximum training benefit.

Preparation

After the staffwas immersed in the situation, they were given time to prepare for the

exercise. This included posting maps, updating charts, and coordinating on anticipated actions for

the exercise. During this phase, the staff and staffsections had to converge their action plans with

the specific situations presented in the previews. R. G. Hoffman et al. (1995) found that units

participating in the SIMUTA structured training exercises took more time than had been allocated

for the preparation phase. In this program, the developers allotted approximately 10 minutes for

the unit to complete their preparation. Although this was an important phase, the development

team recognized more time could be used than was allotted. Therefore, they instructed the

training team to push the staffto complete preparations within the allotted time.

Execution

The structured training design required that a staffbe provided with cues during

execution. The quality oftraining was directly related to the number, timing, and fidelity ofthese

cues. During execution of an exercise, there were three sources of cues: the system (or

interactor), the training team, or the staff. Two ofthe three were controlled by the system or the

training team. For the staff created cues, the TSPs provided instruction to the training team to

control those cues that detracted from the training.

System or Interactor Created Cues

Messages from the message database were the primary means of providing cues to a staff.

These messages provided all the critical information coming from outside the staff. The number,

timing and fidelity ofmessages were critical. Fidelity required doctrinally accurate and

situationally correct message traffic. Messages were presented in an expected format, i.e.,

according to established Army procedures. Enough messages were presented to the staffto

ensure that they could achieve the exercise training objectives. The messages were delivered so

that staffmembers were not overwhelmed. Inherent in the message delivery rate was the time

24
required for the staffto accomplish the training objectives. For example, when the staffsection

received key messages, it must have sufficient time to analyze and communicate its analysis with

other staffsections. The development team designed the system so that: message formats

replicated standard formats, the number ofmessages was sufficient to provide the necessary detail

but not overwhelm the staff, and the exercise director could change the delivery rates based on the

staffs performance.

Coaching

In the SIMUTA and SIMBART programs, observers did not follow the instructions

concerning coaching the training unit (R. G. Hoffman et al. 1995; Koger et al. 1996). Shlechter,

Bessemer, Nesselroade, and Anthony (1995) found that observers coached more during a unit's

early SIMNET training than in later training exercises. However, coaching incidents were below

the developer's expectations (R. G. Hoffman et al. 1995). Hoffman attributed part ofthe problem

to the need for systematic guidelines for each observer. The StaffGroup Trainer Project

development team incorporated such guidelines in observer checklists. For each exercise, the

development team inserted coaching questions for each key event.

Within a given training exercise, the development team identified one or more "teachable

moments" (i.e., specific, sometimes intense, points within a given scenario that offered particularly

valuable opportunities for learning to take place). As a unit conducted an exercise, each staff

section responded to message cues that replicated the traffic precipitated by the flow ofbattle.

Processing those messages amounted to the mission-specific action that was required ofthe staff

member (e.g., update the enemy situation based on a report of enemy vehicular movement). The

outcome that the observer was prompted to look for was grounded in the BFs that were aligned

with a given staff cell or section. As appropriate, the senior observer could pause the exercise

momentarily, without any staffmember leaving his position at a workstation, and use the directed

questioning approach to cause the staffto think about actions previously taken, or impending

actions. Each observer also could use this directed questioning approach to cause his section to

think about its actions. The exercise did not have to be paused to use the directed questioning

approach.

This technique of presenting one or two focused, reflective questions at set points in an

exercise encouraged staffsections and individuals to think about critical aspects oftheir

performance. No answer was necessary, and the exercise continued. Coaching occurred at the

workstation, limited distractions, sped the exercise, and challenged staffmembers to consider

information referenced during the end-of-exercise AAR.

Each observer's coaching questions focused his attention during the exercise and in

structuring the AAR. During the AAR, he obtained comments from the section that promoted

self-discovery learning. By preparing expected responses to each rhetorical coaching question,

the development team created an "a-way" (Brown, 1991) for comparison to the unit's

performance. Brown's "a-way" is not a "school solution." It is a way that a successful staff

performed in the same situation. In this program, this was the way the development team thought

a successful staffmay have performed.

25
After Action Review

One level of AAR for all tables and an additional level for CP and C

2

tables was designed.

The first was the section end-of-exercise AAR that provided each section immediate feedback on

its performance. The staffsection observer conducted these at the section's workstation after the

exercise. The second was the end-of-module AAR. The senior observer or exercise director

conducted this at the end ofCP and C

2

table modules. The end-of-module AAR focused on CP

or staff processes and interactions. Both AARs were structured to facilitate observer objectivity.

Section End-of-Exercise After Action Review

The section end-of-exercise AAR was divided into several components: staffsection selfassessment, previous action plan review, message handling review, overlay comparison, execution

discussion, battle tracking discussion, staffsupport process model (this model is described later in

this section) discussion, section action plan preparation, and coordination with other staff

sections. Observers completed the end-of-exercise AAR within 30 to 60 minutes, depending on

the complexity ofthe exercise and the needs ofthe staffsection. To start the AAR, the observer

reviewed the purpose ofthe exercise and the staffsection's action plan from the previous

exercise, helped the staffsection focus on the key performance issues from this exercise, and then

helped the staffsection determine areas needing improvement. This design had each observer

facilitate the staffsection's decisions on what to continue (sustain) or change (improve) as

suggested by Johnson and Johnson (1994). The observers emphasized process-related training

objectives as recommended by Jourdan et al. (1991). The emphasis was not on what decisions or

actions the staffmade but rather on how decisions were reached or how the actions were taken.

Self assessment. At the end of an exercise, the observer gave the staffsection an end-ofexercise action plan worksheet (Figure 7) listing objectives specific to the section. The section as

a group rated itself on each objective and explained why they rated themselves as they did. Each

training objective listed expected activities for the staffsection that were keyed to the exercise.

Training objectives, tasks for the exercise, and action plan review. The observer reviewed

the training objectives, exercise tasks, and section's last action plan. The purpose ofthis review

was to clarify the focus during the AAR.

Review ofmessage handling. A message summary review and staffjournal review were

designed to give a quick synopsis ofwhat the section did with all messages that came through the

workstation during the exercise. The focus was not on message content but whether the staff

opened and read the message and then took action.

26
42E

«ao

•e

cs

"3

C/3

09B£EeURating

ObjectivesExpected Activities

Integrate

• Time/distance approach of

enemy w/ Bde plan

Recommend• Course of action re

counterattack (CATK) plan

DERBY

Disseminate

• Cdr's decision re CATK

plan DERBY

61) B«M

'53 H

»H *s <*>

cfl 2u

*o

Co

00

•cffluU

CO

•ao

'S. BOIU6

«AoiauBo

ts

vi

<u1

T3Bs
Review of battle tracking. On the workstation, the observer brought up the ENDEX

overlay and the section's overlays, and provided the ENDEX charts from the TSP. These charts

contained information the staffsection should have tracked during the battle (i.e., unit strengths

and locations, enemy strengths and locations). The observer provided the staffsection with the

starting information at the beginning ofthe exercise. He and section members then compared the

overlays and charts for agreements and differences and determined causes and ways to correct any

differences.

Observer checklist discussion and staffsupport process model review. Each observer's

checklist was designed for his section and exercise observed. This checklist had key messages the

section received, expected staff actions on these messages, and coaching questions for each

expected staff action. The observer used the coaching questions to facilitate staffsection

discussion. The staffsupport process model was a graphic depicting the relationship of a key

event to all expected staff actions during the exercise. This was used during the discussion on

expected staff actions. The discussion assisted the staffsection to decide how to sustain or

improve its performance during the next exercise.

Action plan development. Observers reviewed the previous action plan with the staff

section. The section evaluated how it did on that plan. The observer facilitated the section's

preparation of an action plan for the next exercise.

Coordination with other staffsections. Staffsection members communicated with other

staffsections to work out areas of needed coordination discussed during the AAR.

StaffLeader Discussion

While staffsections conducted their end-of-exercise AARs, the commander, exercise

director, senior observer, and XO/BC discussed how the commander's information requirements

were met during the execution. This discussion's purpose was for the commander to assist the

XO/BC in understanding the commander's, higher headquarters', and subordinates' information

requirements, and for the commander and senior observer to provide feedback on how well the

XO/BC were filling those needs. (Figure 8 is an example ofthe commander'sjob aid supporting

the discussion.)

28
<DOco

(0£0

0)

.Qo

<DÖC

(0EEoü©3

"ÖOQ<

3EEJo

Ml EEooB

ts

<Uwu«

00• • *

IX,
End-of-Module After Action Review

An End-of-Module AAR was designed to end each CP and C

2

training module. This AAR

was conducted after the section AARs and was limited to 30 to 60 minutes. The exercise director

conducted this AAR. As with other AARs, the focus ofthis AAR was improving staff

performance. The staffleft this AAR with a plan to improve its performance (sustain its strengths

and improve where weaknesses were identified).

The commander was integral to the structured end-of-module AAR. The exercise director

provided the commander a guide before each exercise to focus him on key activities. These

guides also focused commander's comments during the AAR. The exercise director, assisted by

the interactors, provided the commander an assessment of how well the staff kept higher and

lower elements informed. After the exercise director reviewed the training objectives and tasks,

the commander explained how the staff portrayed the tactical situation and how the staff

helped/hindered his vision ofthe battlefield, situational assessment, and actions. The

commander's comments complemented his after-exercise discussions with the XO/BC. The

commander focused on improvements the staffmade during the training. Prepared slides focused

on activities that occurred during the module and assisted the commander in keeping his

comments focused on staff performance.

The design called for the commander and staffto complete the end-of-module AAR by

assessing their own performance. A slide (multimedia for some exercises) for each facet of

performance was provided to assist the commander and staffin this assessment. After completing

the assessment, the staff prepared an action plan to sustain and improve performance during

follow-on modules or unit home-station training.

SOFTWARE DEVELOPMENT

The project team organized the software development process into phases or lots. Lot 1

allowed testing for the basics ofbattalion exercises. Lot 2 included modifications to support

testing ofbrigade exercises. Lot 3 modifications enabled the development team to test the

battalion and brigade TSPs using actual units.

Methodology

The software development planning built on the legacy code from the CVCC and

SIMUTA C/ST projects. Therefore, only modifications and enhancements were considered.

Initially, a list of desired software modifications (Table 8) was developed. The modifications were

based on: (a) identified shortcomings in the legacy system which emerged during the SIMUTA

C/ST formative evaluation and (b) the project team's experiences with the software. The basis for

prioritization was contribution to the training objectives articulated in the program design. The

software modification's final status is shown in the third column of Table 8 labeled "Delivered."

Ofthe items shown in Table 8, the three most critical changes needed to improve system

capability were the abilities to: (1) use expanded radio nets, (2) change platform names from

30
battalion stations to brigade stations, and (3) display messages on the screen in a format consistent

with tactical standing operating procedures (TSOP).

When the code was examined closely, a determination was made that it would not be cost

effective to attempt only to enhance the legacy software. The legacy software had been designed

to protect the integrity ofthe system. The players and radio nets were set by the programmer and

could not be modified by the user. Although message contents could be altered using the text

editor on the Sun workstations, the message formats were custom designed in C code. That

meant that even a small change (e.g., have item X appear as line 2 instead ofline 1) to a

previously coded message or any new message would require expensive programmer code

changes. The development team needed to be able to change messages and redefine nets and

platforms as the exercises were developed. In order to change, the software approach was

restructured to a data base methodology.

Formative Evaluation ofthe Software

As each software lot was delivered, the software was installed on a stand-alone Sun

system. There, tests were run to see if expected performance standards were met. If no problems

were encountered during this stand-alone trial, the software was loaded and tested on the

network. When the pilots and the trials were conducted, the development team asked individual

workstation operators to identify problems they encountered while using the equipment.

31
Table 8

Staff Group Trainer Project Software Modifications

Lot# Description

1 Adjusted message formats so that more than 1024 bytes could be sent in a

single message.

1 Reformatted staffjournal to resemble the standard Army form.

1 Updated report formats and included Army standard message priorities.

1 Provide capability to adjust exercise execution speed. (Not delivered as

desired but allowed the development team to change exercise speed.)

1 Developed capability for a workstation to annotate reports.

2 Modified station role assignments.

2 Reduced size ofminefield symbol.

2 Modified radio net structures to handle various echelons and locations.

2 Increased color palette so that colors on the map display corresponded to

military map colors.

3 Provided ability to pause and restart the exercise.

3 Provided ability to recover individual workstations.

3 Created capability to send overlays from workstations.

3 Replaced text-based exercise summary with graphic ofmessage handling.

3 Provided menu driven controls to systems administrator.

3 Improved workstation recovery capability.

3 Provided capability to build database of each session that is keyed to staff

position.

3 Developed automated Take Home Package (on a stand-alone personal

computer platform).

NA Added a 100 x 100 km map grid (not on the original list).

3 Simplified the required inputs for graphics.

3 Made "map edit" default mode to make use easier.

3 Made "highlight top" the default status of any overlay posted on top ofthe

map display.

3 Added range fan symbols.

Delivered

Yes/No

Yes

Yes

Yes

Yes/No

Yes

Yes

No

Yes

Yes

Yes

No

No

No

NoYes

Yes

Yes

Yes

No

No

No

No

32
Key Software Enhancements

This section discusses the major software accomplishments achieved during this project.

These mainly reflected the basic restructuring ofthe operational context ofthe software. These

enhancements provided the most useful improvements to the system's training capabilities.

Changes to Message Formats and Editing Procedures.

The system was upgraded to a more flexible message input design. This was part ofthe

development of new message formats. It provided the training developers with a message viewer

similar to what might appear in custom data base forms. With this user-friendly Graphic User

Interface (GUI) message editor, which consisted oftext boxes and pop-up lists, the training

developer could rapidly and accurately input pre-scripted messages needed to drive the structured

training. This was a significant enhancement.

Impacts ofChange

The impacts ofthe change were:

• Decreased operational costs iffielded. This modification decreased the man-hour

requirements for exercise message construction by a factor ofmore than 40-to-l.

• Decreased errors in the message input to the point that messages could be created

over a lunch hour and the exercise could be run when the staffreturned.

• Eliminated likelihood of a system crash due to an improper message format.

Recommended Improvements --.„,.<.,-.

Capabilities ofthe message editor should be expanded to include generating the exercise

message stream without having to enter the text editor on the Sun platform. This would further

decrease man-hour requirements and potential for error, while maintaining flexibility.

Station Roles and Radio Nets

The delivered software no longer required new code and programmer assistance to modify

station roles and radio nets. This enabled training developers to easily reconfigure the

workstations to support various configurations necessary for the battalion and brigade TSPs.

Impacts ofChange

The workstations could be reconfigured to accommodate multiple CP configurations. In

the legacy system only one configuration was possible without a programmer changing the code.

In the new system, the system manager could easily change the role of any workstation. This

allowed the developers to modify the configuration for the various levels (brigade and battalion)

and CPs (TAC, main, and rear CPs for the brigade, and main CP and CTCP for the battalion).

33
Recommended Improvements

It is still not possible to change the radio nets a workstation receives as the exercise is

running. This means that a workstation can not switch from one radio net to another during an

exercise. This capability should be examined if exercises are to contain training activities such as

displacement ofthe main CP in which responsibility for the execution ofbattle must be transferred

to the rear CP and sections must change the nets they monitor.

After Action Review Graphics

The design concept for AARs revolved around the actions taken by the staffwith regard

to "Key Teaching Point" messages and staff actions needed to provide commanders with orders

and information to correctly implement the commander's intent. The SIMUTA C/ST AAR

provided the training staffwith feedback on what actions were considered to be doctrinally

correct with respect to actions taken on incoming messages. All feedback was presented to the

student in textual format. No use was made ofthe data collected in the instrumentation packages.

In this project, an AAR plot was developed to graphically display the measurements collected.

This plot showed various parameters on message actions (e.g., messages annotated, posting of

messages to situation displays, etc.) across time.

Impacts ofChange

The impacts ofthe change were:

• Graphic display of performance trends. This allowed the staffsection to do

performance self-assessment during the exercise.

• A more appropriate means of evaluating-adult learning.

• Direct application of performance instrumentation in a form which was immediately

usable by staffsections and developers/researchers.

Recommended Improvements

The AAR presentation capability should be modified to tie it directly to the training

objectives-particularly monitor, process, analyze, and communicate. This would minimize an

observer's subjective assessment and foster self evaluation. The AAR plot should contain links

with message traffic processed on that station, so a message may be brought up and viewed while

the plot is displayed. The plot could be expanded to incorporate performance during training

"windows of opportunity" and include a solution overlay as part ofthe AAR.

EXERCISE DEVELOPMENT

The development team tailored the structured, simulation-based training methodology

(Campbell et al. 1995). The methodology was used as a start, but it was found that the

methodology did not fit a research and development project with undefined technology or a

training device without documented task analysis and measures ofperformance. The

34
methodology was modified to that shown in the flowchart in Figure 9. One change was to split

Phase 4 (Training Support Package Development) into Feedback Materials Development and

Exercise Materials Development phases. In previous projects (SEMUTA, SIMUTA-B, and

SIMBART), exercise material development was not required to the extent it was in the Staff

Group Trainer Project. For these projects, the unit and interactors created the message traffic

from what was unfolding during the simulation. For the Staff Group Trainer Project, the project

development team had to create and then load into the computer system all messages that would

be received by the unit staff.

Mission Development

Develop Tactical Scenario

The SIMBART brigade and higher orders and the SIMUTA-B battalion orders were used.

Both ofthese projects had developed complete orders and graphics packages. The SIMUTA-B

battalion was one ofthe battalions in the SIMBART brigade. These two sets of orders and an

actual execution on Janus provided the training program tactical scenario and scenario events.

Determine Tactical Scenario Events

At the start ofthe project, the development team executed each SIMBART brigade

mission on Janus and recorded the screen views on videotape. The exercise was recorded in two

versions: one focusing on the battalion sector ofthe battle, the other showing activities in the

brigade sector. These became the battles used for the Staff Group Trainer Project. The events to

occur during tactical scenarios were determined by reviewing the events that occurred during

these Janus executions.

Exercise Definition '

Determine Exercise Training Objectives

During the project design phase, the team selected a logical progression in the training:

staffsections, individual CPs, and multiple CPs. This progression was designed to prepare an

inexperienced or poorly trained staffto conduct collective staff exercises in Janus or BBS. Within

each training program table and module, there was a deliberate progression from exercise to

exercise. Each exercise provided the staff an opportunity to practice and improve on skills from

the previous exercise and added at least one additional training objective.

35
Mission

Development

Develop

Tactical Scenario

Determine

Tactical Scenario Events

Exercise

Definition

Determine Exercise

Training Objectives

Select Mission

Segment for

Exercise

i

Develop

Mind Maps

Feedback

Materials

Development

Exercise

Materials

Development

Develop

Observer Checklists

Develop

Message Traffic

Develop AAR

Materials

Develop

Information

Charts

X

Develop

STARTEX & ENDEX

Graphics

Figure 9. Exercise development flowchart.

36
Since the training objectives were centered on the staffsupport cycle (see Figure 5), early

exercises started at the beginning ofthe cycle. Succeeding exercises continued along this cycle.

The first three training objectives in the cycle-monitor, process, and analyze—did not depend on

interaction with other staffsections. The staffsection tables focused on developing the ability to

perform these objectives within the staffsection. This allowed staffsections to be trained

independently but concurrently using the same message list.

Each CP module consisted ofthree exercises (see Figures 3 and 4). Because of equipment

limitations, only one CP was trained at a time. The team designed the first CP exercise to train

the first three training objectives, the same objectives trained in the last staffsection exercise. The

middle exercise focused on communicating analyzed information within the CP, and to the

commander and higher and lower elements. The last exercise in each module was designed to end

with the staffmaking a recommendation to the commander concerning a decision point.

The C

2 modules varied between the battalion and brigade TSPs. For the brigade, each

module consisted oftwo exercises. The first exercise progressed to the recommendation at a

decision point. The second exercise started with the commander making the decision and

directing the staffto disseminate that decision. Finally, the staffwas to aid the commander in

synchronizing and directing the actions ofthe brigade units.

For the battalion, each C

2 module consisted offour exercises. The first two exercises

progressed to a decision point. The last two exercises started with the commander having already

made the decision and the staffgoing through the last three training objectives.

Select Mission Segment for Exercise

.. . Exercise authors examined the tactical scenario and determined the specific time periods in

the scenario when the training objectives could be met for each exercise. They kept the battle

flow continuous for each module if possible. This meant that each exercise in a module would

flow directly into the next exercise. This was accomplished for all but one module—battalion

defense in sector. For this module, there was a 20-minute gap between two exercises coinciding

with a break between echelons ofthe advancing enemy.

Since the development team designed the staffsection tables to advance through only the

first three training objectives, they restricted these exercises to periods in the tactical scenario

without enemy contact-generally the early movement ofthe brigade or battalion in the movement

to contact mission. They kept the first exercise relatively short and simple so the staff could

master the initial objectives and get accustomed to the training system. The second exercise

began from the end ofthe first exercise and continued to just before initial contact with the

enemy.

For the brigade CP and C

2 modules, the exercise authors selected a decision point for each

module and went backward or forward in time from that decision point to meet the designated

training objectives. For battalion C

2 modules, the exercise authors used doctrinal phases as

described in FM 71-2 (Department ofthe Army, 1988d) to determine the content ofthe exercises.

37
Once each exercise author defined the time period and key events within that time period, he

completed the exercise outlines.

Staff Support Process Model

The staffsupport process model was a pictorial showing an exercise key event and

associated message traffic plus the minimum expected staffbehaviors (a sample is at Figure 10).

The pictorials became training aids to help the staff understand how key messages prompt staff

actions and how sections combine pieces ofinformation. It also helped observers facilitate

discussion with staffsection members on key events and actions.

Exercise Materials Development

Once the exercise outlines were finished, authors developed exercise materials. The

following sections describe the methods and resulting products.

Develop Message Traffic

The team conducted a map exercise, augmented by the Janus videotape, DST and

synchronization matrix, to determine the type ofmessage traffic that should be received by the

training stafffrom subordinate, adjacent, and higher units or staffs for each scenario. They put

this information into a message summary database. This database included time, report type,

whether the message was a key message, originator, addressee, radio net, message summary, and

a training outcome for each message. After the map exercise, the team developed message

summaries for each mission. Based on the message summary database, the team constructed the

message traffic database. Using Janus videotapes as a reference, the development team verified

activities, times, locations, and strengths ofboth enemy and friendly units against the estimates

made by exercise authors.

Develop Information Charts

To begin this development, the team initially used the set of charts in Field Circular (FC)

71-6 (Department ofthe Army, 1985) as a baseline to determine what information charts each

staffsection would maintain. Examples ofthese charts are: enemy strength and location, friendly

strength and location, and completion of elements ofthe reconnaissance plan. Once the message

traffic for each exercise was developed, exercise authors prepared information charts for each

staffsection. Authors prepared these charts for the beginning and end of each exercise. They

obtained the beginning information by reviewing the Janus videotape and the message database up

to the start ofthe exercise. The ENDEX charts were prepared by adjusting the charts based on

message traffic during the exercise. The development team found that information needed to

keep the charts accurate was not always in the message database. Each exercise author went back

to the Janus videotapes to verify the required information. This led to more messages being

added to the tactical scenario and exercise message databases.

38
CO

3

(50

c

PQ

o

C/S

<Do

o(-1&

tio

4-»

00

2

ON
Develop Exercise Graphics

The same procedure used to develop information charts was used to develop exercise

graphics. The exercise authors determined the location of all friendly and enemy units at the start

of each exercise and created the overlay for the workstation map display. Then, based on

message traffic and the Janus exercise, the location of all units at the end ofthe exercise was

determined. Often the message traffic did not support the ending location offriendly and enemy

units. Additional messages to support the end-of-exercise graphics were created as needed.

Development ofFeedback Materials

Feedback materials focused on key events in each exercise. Each exercise was designed to

have only two or three key events. This allowed the observers to concentrate on observing and

providing feedback on those key events.

Observer Checklists

The observer checklists were designed to be easy to use, focus only on key events, and

allow the observer to concentrate on staff performance. For every exercise, authors developed a

checklist for each observer and the exercise director. Each section observer checklist contained

key messages for the section, expected section activities, coaching cues, and a place for observer

comments (Figure 11). The exercise director's checklist (Figure 12) focused on the information

needs ofthe commander. This was linked to the commander's C

2

cycle (see, assess, decide, act)

(Department ofthe Army, 1995).

After Action Review Materials

The section observer's AAR material consisted of: end-of-exercise action plan

worksheets, observer checklists, a staffsupport process model, and ENDEX charts and overlays.

All ofthis material was discussed in previous sections.

The training objectives were synchronized with evaluation and feedback material during a

map exercise. During this exercise, team members assessed ifmessage traffic, DST,

synchronization matrix, staffsupport process models, and observer checklists were in agreement.

As a result, some message traffic and checklists were revised.

40
CO

(U

'S

•n

ffl

o

S

4>

O

c

o

o

e

u

öO

• *9>*
Ieo

aW

o

•a

J3a§SoU

•cv**

•cuH

Vi Qa

s

SÄ

VI

u

«8S

w

SU

I

•8

i8

a,

1/3

<

ts

V

CO

•»*as

«SO

•c

pa2

'Su

1—( s
TRAINING SUPPORT PACKAGE DEVELOPMENT

The TSPs consisted of paper-based instructions and other non-traditional components (the

computer program on the training system, message databases, preview and AAR materials on

computer system). This section focuses on the paper-based instructions.

Development ofbattalion and brigade TSPs evolved from lessons learned in previous

projects-SIMUTA and SIMBART. The original Staff Group Trainer Project's TSP design was

based on the SIMBART TSP. However, the mission volumes were modified because ofthe

difference in the program structure. The following organization was used:

• Volume I: Training Guide,

• Volume II: Unit Preparation Materials,

• Volume III: StaffSection Table,

• Volume TV: CP Table, and

• Volume V: C

2

Table.

Several packages supplemented these volumes. These materials included:

• Tactical Materials: This volume contained all orders and the TSOP used in the

program. The brigade TacticalMaterials contained the division and brigade orders

and the brigade TSOP. The battalion Tactical Materials contained the brigade and

battalion orders and the battalion TSOP.

• Workstation Operator's Guide: This guide was the same for both TSPs.

• System Administrator's Guide: This guide was the same for both TSPs.

• Train-the-Trainer Guide: This guide instructed a training team how to administer and

conduct the battalion and brigade training programs. Because of differences between

the two programs, the Train-the-Trainer Guide supplement differed between the two

TSPs.

• Program Highlights: Because ofthe differences between the battalion and brigade

programs, a separate program summary was prepared for each.

The following sections highlight the TSP development process.

Structured Writing

The structured writing methodology was used in preparing the TSPs. Structured writing

emphasizes (a) separating information into small units by purpose and function so it can be easily

read and understood, (b) sequencing information based on its use and need, (c) labeling topics for

43
easy scanning, and (d) presenting information in modular units so it can be easily modified (Horn,

1995). Users ofthe SMUTA-B and SMBART products reported that the structured writing

presentation made the packages easier to use than the more traditional, prose-style approach

(Graves & Myers, 1997; Koger et al. 1996).

Battalion Prototype Exercise Development and Delivery

The exercise outlines were used to develop a battalion prototype TSP. The battalion

prototype package contained support material for 4 ofthe 32 exercises in the battalion training

program. The prototype package included the movement to contact module from the C table.

These exercises allowed a comparison ofthe new exercises to the SIMUTA C/ST exercises. The

prototype provided sample materials for external review. Comments from the prototype reviews

are discussed in the formative evaluation section.

Brigade Prototype Exercise Development and Delivery

The brigade prototype package included exercises 14 through 16 (the main CP module of

the CP table). The prototype contained all the exercise support materials for these three

exercises. Comments from the prototype reviews are discussed in the formative evaluation

section.

Battalion Draft Training Support Package Development

The draft TSP was used and reviewed during the pilot and implementation trial and then

refined based on user and customer comments.

The battalion draft TSP contained Volumes /-Fand the TacticalMaterials. Some ofthe

. CTCP exercise materials in Volume TV and all of Volume V were still being developed. The

Workstation Operator's Guide, System Administrator's Guide, and Train-the-Trainer Guide

were also delivered in the draft TSP, although some oftheir components were still being

developed.

A new document, StaffGroup Trainer Program Highlights, was added to the package.

The Highlights summarized the battalion training program. It became "tool" the VTP

Observer/Controller (O/C) team had requested during the prototype review.

Brigade Draft Training Support Package Development

The brigade draft TSP was structured similarly to the battalion draft. However, the

development team did not prepare a brigade Workstation Operator's Guide and System

Administrator's Guide because the functions were the same regardless of echelon. As with the

battalion draft TSP, the development team prepared a Highlights document that summarized the

brigade training.

44
Final Training Support Package Delivery

The final versions ofthe battalion and brigade TSPs were delivered after the revisions

resulting from the implementation trials were completed. Final development included adjusting

messages and overlays to better support the exercises, finalizing TSP contents, and finalizing the

Staff Group Trainer Project electronic files.

FORMATIVE EVALUATION

Two levels offormative evaluation were conducted throughout the project-internal and

external. The external evaluations consisted of prototype exercise reviews, pilots, and

implementation trials. Previous sections described the internal reviews. The following sections

describe the results ofthe battalion and brigade prototype exercise reviews, pilot tests and

implementation trials.

During the external evaluations, team members collected feedback using a variety of

methods. For the pilots and implementation trials, team members observed specific aspects ofthe

training implementation techniques and exercise design. Immediately after each pilot and trial,

they compiled their observations. During the pilots, the team questioned the participants after

each exercise. At the conclusion of each pilot, they interviewed all participants as a group.

During the trials, all training team members completed questionnaires and participated in "hot

washes" at specific points in the training. Participants completed questionnaires at the conclusion

of each module and participated in a group interview after the trial. Post-trial group interviews

with the training team during the week following each trial were conducted. The comments in

this section were obtained from combining the information gathered from all these methods.

Prototype Reviews

Participants in the battalion prototype review were representatives ofthe battalion VTP

O/C team. Participants in the brigade prototype review were representatives from the Combined

Arms and Logistics Centers, Intelligence School, and the brigade and battalion VTP O/C teams.

The comments on the exercises were compiled by members ofthe development team. The

following discussion lists significant points made during the prototype review concerning exercise

development.

The purpose ofthe prototype reviews was to have potential users review the training

program and materials. The reviews focused on what the development team could do to make the

training programs more effective and the TSPs more useful. Selected reviewer comments are

discussed in the following paragraphs.

The reviewers were concerned about the highly structured AARs. The development team

maintained that more structured and prescriptive AAR instructions and materials enabled a less

experienced observer to provide valuable feedback to the staffsection he was observing. Final

testing during the trials and subsequent field interviews with commanders for the follow-on Staff

Group Trainer Project confirmed the need for the more structured AAR method.

45
Reviewers questioned whether internal CP communication and coordination would be

conducted face-to-face or through the workstations. The team modified instructions and

expanded the train-the-trainer program and staff orientation to ensure the staffsections

understood that internal CP communication and coordination should be conducted face-to-face.

Reviewers were concerned about exercise speed and the use of pauses. Allowing the

exercise to be slowed to less-than-real-time execution, or paused, were features not available in

real-life situations. The reviewers questioned whether the pause feature would ease the stress of

battle and dilute the training value ofthe exercise. However, the "crawl" nature ofthe Staff

Group Trainer Project's methodology argued that slowing exercise speed or pausing the exercise

allowed staffsections more time to learn the basics ofstaff coordination and synergy before

progressing to a real-time, more realistic exercise, such as Janus or BBS missions.

In the training program design at the time ofthe battalion review, a battalion staff

progressed through the training program using the movement to contact scenario for the staff

section table, the main CP used the deliberate attack for its CP module, the CTCP used the

defense in sector scenario for its CP module, and the battalion staff chose any ofthe three

scenarios for the C

2

table. The reviewers believed it was difficult for a unit to study and be

prepared to execute all three missions. The team changed the CP table so that each CP would use

the deliberate attack scenario for its CP modules.

Workstation availability was addressed during the reviews. At the time ofthe reviews,

there were only six workstations available. As a result, some staffsections shared workstations

during the C

2

exercise. This was seen as potentially a serious training problem. More

workstations were obtained before the end ofthe project.

The reviewers suggested improvements in the message traffic. These suggestions were

incorporated into subsequent TSPs. The reviewers recommended that some information on the

message list be eliminated. The message list included items that cued staff actions, actions that

staffmembers were expected to perform when they received messages, and the BF tasks on which

their actions were based. All this information, though useful, made the message list lengthy and

difficult to use. The list was modified to include only basic message information-time, whether

or not the message was a key message, report type, originator, addressee, net on which the

message was sent, and message summary. The other elements (expected staff actions and BF

references) became part ofthe observer checklists and staffsupport process models.

The reviewers indicated there were redundant instructions in the TSP chapters for

different training team members. They suggested eliminating that redundancy by moving

instructions and materials pertinent to all trainer positions into a single section at the beginning.

The development team used these suggestions in developing the brigade prototype exercise

packages.

Reviewer comments on the brigade prototype led to major revision ofthe Training Guide

(Volume I) and Unit Preparation Materials (Volume II) for the draft TSPs. Additionally, the

reviewers suggested that both volumes could be presented in a multimedia format (e.g.,

videotape, CD ROM). They felt the user would prefer the multimedia format over reading the

46
material. Reviewers were enthusiastic about observer checklists and staffsupport process

models. They stated both should be helpful in providing performance feedback to training staffs.

They also discussed the need for a tool to capture the staffsection and CP's action plans so that

the results could be easily incorporated into the final THP.

Pilot Tests

The development team scheduled each pilot test-battalion and brigade--for a three-week

period. A training team was required for the entire three weeks, while the staffwas required for

only the second ofthe three weeks. When the software and exercises were not ready for the

battalion pilot, the team restructured the pilots. This restructuring still allowed the team to test

the exercises prior to the implementation trials. Each pilot was reduced to a single week.

Because ofscheduling constraints with the VTP O/C team, the brigade pilot was conducted one

week followed by the battalion pilot the next week.

The purpose ofthe pilots evolved into preparation for the implementation trials. The

development team crafted the following objectives for the restructured pilot tests:

• Train the VTP O/C team to operate the training system,

• Familiarize the VTP O/C team with the training programs, and

• Evaluate all exercises and materials scheduled for the trial.

For the brigade pilot, the VTP O/C team served in a variety ofroles to experience the

training from different perspectives. To start, the development team delivered the workstation

operator training to the VTP O/C team. Following this, the development team gave the VTP O/C

' team a short orders briefing on each mission, then asked them to review the orders package. The

O/C team performed as workstation operators during the section table, while the development

team performed as staff officers. For the CP table, the development team performed as

workstation operators while the O/C team performed as staff officers. Finally, for the C

2

table

exercises, the O/C team acted as observers and the development team role-played as the unit staff-

-both workstation operators and staff officers. This allowed the O/C team members to gain

experience in all the roles required for the training, and participate in all the exercises scheduled

for the trials.

Because oflessons learned during the brigade pilot, the development team made some

changes to the battalion pilot. The brigade O/C team had not achieved a full conceptual grasp of

the training until the last day, when the development team functioned as the entire staff and the

O/C team functioned as observers. The development team conducted a demonstration at the

beginning ofthe battalion pilot for the O/C team participants. The demonstration appeared to

help the participants grasp the concept. This demonstration was added to the train-the-trainer

program and to the unit orientation.

47
Brigade Pilot Results

The brigade pilot was the first opportunity to test the train-the-trainer materials. Though

limited in scope, the executed portion included providing an introduction to the training program,

workstation operator and system administrator training, and a review oftactical materials. The

workstation operator training was well received, with the following suggestions: (a) add practice

exercises to link the individual workstation operator tasks with the workstation operator practical

exercise, (b) include staffsection officers in some parts ofthe workstation operator training so

they have prior knowledge ofworkstation capabilities and limitations before executing the staff

section table, and (c) emphasize creation of new reports with consolidated information rather than

routine forwarding ofreceived reports.

The VTP O/C team requested more combat service support traffic and overlays, engineer

traffic, and intelligence traffic. Inconsistencies between the message traffic and overlays were

identified and marked for correction. The O/C team indicated that the exercises might have too

much happening in too little time and thus be unrealistic. However, the development team

explained that the times were based on the same missions executed on Janus.

During the pilot, the training system only had a 50K x 50K map grid that could be used by

the brigade staff. The brigade Janus exercises used a 100K x 100K terrain database for the

simulation. This terrain database extended approximately 50K further west and south than the

50K x 50K battalion terrain database. In the brigade Janus exercises, the staffs used paper maps

for their work and had no interaction with the simulation's terrain database. Some ofthe brigade

area defense- and movement to contact-based exercises were conducted off StaffGroup Trainer's

50K x 50K map grid. To compound this, the intelligence message traffic for the brigade Janus

exercises extended beyond the simulation's brigade 100K x 100K terrain database. Since the

brigade staffs in the Janus exercises used paper maps this did not present a problem for them. In

the Staff Group Trainer exercises, the staffused the system's map to track all friendly and enemy

units. As a result, approximately 60% ofthe enemy graphics and some friendly units were offthe

system's map. This made it difficult for the brigade staffto execute the exercises.

Revisions were made to the exercises and TSPs to respond to these comments. The 100K

x 100K map capability was delivered prior to the brigade implementation trial. The larger map

was not required for the battalion exercises.

Battalion Pilot Results

The following key issues resulted from the battalion pilot:

• The system administrator needed to be proficient to execute exercises.

• The demonstration helped the participants to grasp the training concept.

• The staffsection table needed to be more challenging.

• The message traffic and overlays had to be checked for accuracy and consistency with

OPORDs.

48
Where possible, modifications were made to the TSPs and exercises to address these

issues.

Battalion Implementation Trial

The StaffGroup Trainer Project's hardware suite was moved to the Mounted Warfare

Test Bed, a new software drop was put on the system, and two workstations were added to the

system between the pilots and the battalion trial. The train-the-trainer phase (including

workstation operator training) was conducted for the VTP O/C team during the first week ofthe

trial. The O/C team conducted the training for a surrogate battalion staff during the second week

ofthe trial. During the trial, the staff executed all staffsection table exercises, the main CP

module, and the C

2

table movement to contact module.

There were software/hardware problems resulting from moving the system, adding two

workstations, and installing a new software change. The development team was not able to

resolve these problems until the last day ofthe trial. Because ofthese problems, the training

schedule was adjusted. The schedule changes and delays caused by the system problems

contributed to negative comments from some staffmembers. In their after-trial responses, staff

members reported that the training system's hardware/software interfered with training, the

training program was not responsive to staff actions, the training program was too complex and

too long, and the message traffic did not contain enough messages and contained too many

mistakes. The battalion O/C team echoed many ofthese comments. Development team members

observed many ofthe same problems and sought solutions.

The development team realized a number ofpositive results from the trial. Based on

observations and feedback from the participants, the following findings emerged:

• Individual section"performance and main CP ihteractioris improved.

• The staff progressed through the staffsupport cycle.

• The observer checklists were relatively easy to use and helped the observers keep

section AARs focused on training objectives.

The staffsupport process model proved to be a useful tool.

• The discussions between the XO/BC, commander, exercise director, and CP observer

were important in training the XO/BC.

• The importance ofseveral key players—commander, exercise director, and

interactors~was highlighted. The commander must be involved in the training. He

must set the tone and inform the staff ofhis information needs. The exercise director

must assist the commander throughout the training. The interactor cell must be staffed

by at least two people in the CP and C

2 modules. These two individuals must be

knowledgeable about staff activities and familiar with the exercises.

49
• The end-of-module AAR needed to be more structured with additional training aids to

assist the exercise director and commander.

Brigade Implementation Trial

The development team implemented some ofthe lessons learned during the battalion trial

in time for the brigade trial. Added emphasis during the train-the-trainer program was placed on

areas where the training program was not implemented as designed during the battalion trial. This

emphasis proved beneficial as training team members followed the instructions presented in the

training. The team created a multimedia end-of-module AAR presentation to help the commander

and exercise director focus on the training objectives. A fire support expert was also added to

review all the exercises, add fire support traffic, and correct faulty message traffic and overlays.

The workbooks and training team materials were also streamlined.

The VTP O/C team served as the training team for the brigade implementation trial. They

went through the train-the-trainer phase (including workstation operator training) during the first

week ofthe trial. The O/C team then conducted the brigade training program the following week.

The brigade staffwas an ad hoc staff assembled from units at Fort Knox, Kentucky and

elsewhere.

At the conclusion ofthe train-the-trainer phase, which lasted less than three days, the

development team obtained the VTP O/C team members' opinions about the program and

materials. The O/C team indicated that more time was required for them to prepare to conduct

the training. Their estimate was a minimum offive days with additional time required for the

interactors. They stated that the training program was overly complex.

Members ofthe ad hoc staff and O/C team were concerned that the workstation operator

training program was not ensuring the operators would be proficient for exercise execution. The

development team observed that a few workstation operators fell behind in processing messages

during the exercises. The team noted that there were too many messages being forwarded on the

same net (repeating the same message on the same net), use ofthe system to do internal CP

coordination when face-to-face communication was expected, and forwarding ofindividual

messages rather than creating new, consolidated messages or providing the analysis of a group of

messages. These practices all increased the workload for each workstation operator and were

contrary to workstation operator training. Members ofboth the ad hoc staff and O/C team

recommended that training audience members be briefed on the workstation capabilities.

For the brigade trial, the software/hardware problems that had been encountered during

the battalion trial were remedied. There were no software/hardware problems to interfere with

training. In their after-trial responses, the brigade staffmembers and O/C team members reported

that the training system (hardware/software) got in the way oftraining, the training program was

not responsive to staff actions, the training package was too complex, and the message traffic was

not adequate and contained mistakes. The brigade staffmembers and the O/C team members

reported the training system got in the way oftraining because the system was new and the CP

environment was different because all means of external communication were replaced with the

50
system. The staffmembers wanted the CP environment to mirror the field CP to include

configuration and equipment.

The project development team observed many positive aspects ofthe program. Despite

comments by the participants, staffperformance did improve. The developers noted that the staff

did improve in monitoring unit activities and asking for more information from the units

concerning their activities. Information was processed more rapidly and efficiently, and more

analysis ofthe information was accomplished. During early exercises, more messages were

forwarded without analysis to sections that had already received them.

51
LESSONS LEARNED

This section reports the major lessons learned by the development team during this

project. The intended audience consists of: (a) training developers, (b) program sponsors who

allocate funding or training programs and establish program goals and objectives, and (c) training

implementers. These lessons describe problem areas encountered, suggestions on how to avoid or

cope with these problems and areas the development team felt were informative.

This section is organized based on the phases-analysis, design, development,

implementation, and evaluation-in the Army's Systems Approach to Training (Department ofthe

Army, 1988e).

Analysis

There were four major lessons learned during the analysis phase ofthis project. These

lessons learned dealt with training audience characteristics, training program goals, training

resources, and training objectives. This section discusses each ofthose lessons.

Training Audience Characteristics

During the pilots and implementation trials, branch school representatives and VTP O/C

team members challenged the training design audience characteristics. The development team

used the training audience characteristics identified in the statement ofwork (SOW) at the

beginning ofthis project. As a result ofthese challenges, the development team interviewed

several brigade commanders. These interviews validated the training audience characteristics

used in the project. The lesson learned is that future projects should include an analysis of

training audience characteristics and needs at the beginning ofthe project.

Training Program Goals

The team established goals early in the program to guide the design, development,

implementation and evaluation ofthe training. Using these goals, the development team created a

training program to bridge a training gap between individual skills and collective staffskills;

however, they discovered the training gap to be greater than originally thought. The resulting

discussion between the sponsor and the development team produced a shared understanding of

the training gap and a refinement ofthe training goals--an understanding that, unfortunately, was

not shared by all trainers and participants. Consequently, the development team learned the

importance ofselecting trainers and participants for the formative evaluation phase who

understand, or "buy into," the goals and purpose ofthe program. This convergence of

understanding is particularly important when pilot and trial trainers and participants are not part of

the intended audience, e.g., an actual unit staff, but are emulating that audience in the evaluation

exercises.

52
Training Resources

During pilots and trials the development team uncovered insights about module duration

and the training team. Interviews with the brigade commanders, verified these insights. Ifthese

areas had been uncovered in the analysis phase ofthis project they would have resulted in major

modifications to the project design.

Module Duration

Comments received during pilots and trials questioned the length ofthe program and

modules. In interviews with brigade commanders, commanders indicated that they could

accommodate a four-hour block oftraining for their staff as often as once a week or as

infrequently as once a quarter. Commanders suggested that blocks oftraining be designed not to

exceed four hours. No time restrictions were considered in the analysis and design phases ofthe

project. The development team focused on meeting the training objectives. As a result, modules

consisted oftwo to four exercises based on the development team's estimates ofwhat was

required to achieve the training objectives (see Table 9).

Table 9

Module Duration

Expected Length per

Number ofExercises Module (Hours)

Battalion Training Support Package

Section module 2 4

CP module 3 8

C

2 module 4 12

Brigade Training Support Package

Section module 2 4

CP module 3 6

C

2 module 2 6

As a result ofthe pilots and trials, the development team determined that adjustments

could be made to reduce each module to four hours or less. In most cases this could be

accomplished by reducing the number of exercises in a module. Each module would typically

consist oftwo exercises. The second exercise would reinforce what the training audience learned

during the first exercise and its AAR. These adjustments were not made in this project's training

program but were suggested for follow-on work.

The lesson learned was that the duration oftraining must fit into the target audiences'

anticipated time allocation for the training. Developers can never ignore or discount available

training time. During the analysis phase oftraining program development, the training developer,

sponsor, and potential user must determine anticipated training time restrictions.

53
Training Team

The training team is a training resource that influences the design of a training program.

In interviews with brigade commanders, the commanders indicated that resources for a training

team are very limited and that any training team for stafftraining would probably come

predominantly from inside the unit headquarters (battalion or brigade). Training teams such as the

VTP O/C team are typically not available for a local commander's stafftraining program and

funding for travel to a stafftraining site is generally not available. Thus, structured, computerdriven stafftraining should be available at the brigade's home station and require a minimal

training team.

Reducing the personnel overhead requirements for stafftraining represents a significant

cost saving to the military. In this project, only support personnel-system administrator and

interactors~did not actively observe and provide feedback to the training staff. This contrasts

with a Janus exercise where support personnel can easily consist of 20 to 30 people in addition to

the observer team. However, even the requirements for 9 to 12 observers plus the support staff

would still exceed the personnel immediately available to the brigade commander. Future efforts

must strive to reduce the training team to numbers the brigade commander can support. The

training benefits or losses associated with various training team structures should be explored.

Training Objectives

Integration ofthe Staff Support Cycle into the Training Program

In the SIMBART program (Koger et al. 1996), the SIMBART Team had difficulty in

getting the O/C team to focus the AARs on staffprocesses. The SIMBART Team had not

integrated the SIMBART staffsupport cycle (see Figure 5 earlier in this document) into the

training objectives and observer checklists. As a result, the O/Cs were able to circumvent the

staff cycle. During the AAR process they did not focus on the brigade staff's actions. In the Staff

Group Trainer Project, the development team further evolved and integrated the staffsupport

cycle into the instruction design. They adjusted the SIMBART concept and developed the staff

support cycle to include BF analyses tying training objectives with specific tasks and performance.

The cycle defined the training objectives for the training programs. These objectives in turn were

used to structure the observer checklists and AARs. Because ofthis integration, the training team

accepted the staffsupport cycle and used it in conducting all AARs. The lesson learned is that by

tightly structuring the training objectives into the trainer support materials, resistance to

implementation as designed is decreased.

54
Measuring Performance ofTraining Objectives

In this project, the development team did not quantitatively analyze the training objectives.

They did refine the training objectives and tie them more closely to stafftasks and BFs.

The first several ofthese training objectives-monitor, process, analyze and communicatecan be measured by instrumentation on the computer system. However, ifthe Staff Group

Trainer's computer-driven, structured training environment is fielded, it must not just claim to

train performance, it must have developed and evaluated measures ofperformance for all tasks to

ensure that commanders can determine that training does take place.

Design

It is difficult to design exercises that train processes, and provide a high likelihood of

success, while providing a challenging training progression. This section discusses major lessons

learned in the development team's attempts to design a program that would meet this goal.

Additionally, this section discusses the team's use of a shared mental model to enhance team

training.

Separating Process from Outcomes

The AARs in previous SIMUTA and SIMBART stafftraining exercises were long and

focused on battle outcomes rather than staff processes (R. G. Hoflman et al. 1995; Koger et al.

1996; Graves & Myers, 1997). This is typical ofAARs for most battle exercises and simulations

where winning is the objective not how you play the game. The StaffGroup Trainer is not a

tactical trainer. The exercise is information-based. Battle scenarios serve only as the means to

drive staff actions. They are designed to elicit individual and team behaviors. To train the staffit

is necessary to focus on staff processes. The information provided to the staffis selected to paint

a picture which will cue specific staffbehaviors. This information is highly structured. Observers

know when staffbehaviors should occur and they can focus on the staffs reactions to these cues.

The development team intentionally designed the exercises to be short to separate staff

processes and actions from battle outcomes. The staff acts and produces specific staff products.

But, the exercise is stopped before the staffs recommendations or products have an opportunity

to influence the battle outcome. While some participants were disappointed because their actions

and products had no impact on the battle, the structure helped the training team remain focused

on process during the AARs because there were no outcomes to discuss. The development team

learned that short, structured exercises improved the acceptance ofthe training focus on staff

processes.

Training Progression

StaffGroup Trainer training began with a section table, proceeded to the CP table and

then the C

2

table. The team believed that this organization would provide a logical progression

for staff development. As discussed previously, they designed the exercises in the tables to

provide a high likelihood ofsuccess for the participants. Thus, early exercises and tables would

55
be easier than later exercises and tables. During the trials, the development team observed a

significant gap between performance requirements for staffsection table modules and the CP

modules.

From their observations during the trials, the team determined that staffsection exercises

had not prepared the sections to continue to the CP table. This meant that either the objectives of

the staffsection table were not achieved or that there was not a smooth progression between the

last staffsection exercise and the first CP exercise. Feedback from users and the development

team indicated that the staffsection table exercises needed to be more challenging. These

exercises as implemented were too easy even for a staffsection at the crawl level oftraining.

From the trials, the development team determined that they had not provided a smooth

progression from the section table to the CP table. The team looked at making the staffsection

exercises more challenging

Since this training focused on a staffin its early stages oftraining, process-related goals

were appropriate especially in the early exercises. Upon review, the development team conceded

that the training program did not adequately assist the staffsection in achieving the table training

objectives. The exercises were too easy and failed to focus the observers adequately on the

processes needed for a staffsection to meet the commander's informational needs. Correctly

designed these exercises should focus the staffsection on what it must look for, where to find it,

and what to do with it once found.

Whether or not the training program requires a C

2

table deserves further investigation.

While the Staff Group Trainer program has C

2

tables, the developmental complexities-increased

number ofworkstations, increased number observers, increased workload on the interactor cell,

ability ofthe system to handle communication between CPs-associated with design ofsuch tables

proved to be extensive. Because ofthese complexities and additional resources required, the

usefulness ofthe C

2

exercises on the StaffGroup Trainer system was questioned. Further

research is required to determine ifthe training without the C

2

exercises would be sufficient to

prepare the stafffor Janus or BBS exercises.

The lesson learned in developing progressive tables is that the development team must

look carefully at the objectives at each level. Because ofthe progressive nature ofthe structured

training program, the staffmust be successful at the section level before continuing to the next

level. The training audience must achieve the training objectives at each level ifthey are to be

successful in later stages ofthe training. A possible solution would be to make the staffsection

modules more challenging and have the section focus on staff processes; however, this would only

partly smooth the progression between the section table and the CP table. The development team

thought the staff also might require an additional level of exercise before the CP exercises. This

level would be composed ofspecific staffgroup modules. These modules would focus on

selected parts of a staffthat must work together in specific instances (e.g., targeting cell

composed offire support and intelligence section personnel). Training a specific staffgrouping

would better prepare them to work together within the CP environment ofsubsequent modules.

56
Staff Success in a Challenging Environment

The training matrix conceptualized at the beginning ofthis project (Figure 6) provided for

multiple entry points and different paths through the program based upon proficiency. These

entry points and proficiency-based paths would help to provide the flexibility necessary for

"flow." These were not developed. While additional entry points and paths must be developed

for robustness these may create conditions that may disrupt the performance cues designed in the

base exercise. It will be necessary to test thoroughly the exercises to prevent introducing

confounding factors.

The automated assessment software should be designed to recognize less than optimum

performance and suggest alternative methods to provide coaching modes depending on the

performance level and desires ofparticipants. For example, some participants may want coaching

suggestions automatically provided, others may want suggestions only when they request them,

and others may want no coaching or suggestions at all.

Shared Mental Models

As explained earlier, this shared mental model concept has the team sharing a common

vision ofthe game and each person's role in that game. Klein and Thordsen (1989) described this

as a "team mind." Coaches have explained this as teammates having played together enough so

that they anticipate each other's moves. The development team saw the application ofthis

concept as a staffsupport process model (see Figure 10) which graphically depicted the staff

actions surrounding each exercise's key events.

The training design reinforced this concept. It provided time for the commander to share

his model (vision) ofthe upcoming exercise and his expectations for the staffbefore each exercise.

The commander used the DST to focus the staff on what he anticipated would be the staffs -

actions/interactions during the exercise. At the beginning ofthe module AAR, the commander

repeated his expectations and provided the staffinformation on what he received. Finally, the

staff and commander determined the actions they needed to improve during the next exercise to

ensure the commander had the information needed to conduct the battle.

The team saw great potential in the strategies they used to integrate the shared mental

model concept in strengthening staffteam work. The approaches may be useful to other

developers ofteam training programs. However, the methods used still needed to be refined.

Additionally, there are many additional training ideas that could be implemented that would

further enhance this training. Several ideas for enhancing mental models in teams are presented in

Stout, Cannon-Bowers, and Salas (1996/1997) and Cannon-Bowers, Tannenbaum, Salas, and

Volpe (1995).

The effectiveness ofthe shared mental model depends on the commander. The team

observed two different types of commanders. One commander provided little feedback or

direction to the staff, while the other commander was active and provided the staffspecific

feedback and direction on what he wanted. The difference in the learning environment created for

the staffwas apparent. The team learned that staff efficiency can only be optimized ifthe staffis

57
made aware ofthe commander's information requirements. Commanders must become involved

ifstaffs are to maximize performance.

Development

Lessons learned regarding development are divided into three groups: exercise

development, training system (software) development, and TSP development. There was an

additional lesson learned that overlapped two ofthese groups-simultaneous exercise and

software development. This lesson is discussed at the end ofthe development section.

Exercise Development

Message Traffic Development

Being totally computer driven, these TSPs provided an opportunity for the development

team to structure exercises more tightly than any previous structured training program. The

message traffic had to replicate all ofthe information coming into the staffyet not overwhelm the

staffwith messages. Developers learned that it is extremely time consuming to develop and

thoroughly test the message database for structured computer-driven exercises.

Subject Matter Experts

During this project, the team discovered that there was a higher specificity of knowledge

required than in previous projects. In earlier projects, the team was not required to develop the

specific message traffic. These teams only had to develop the general flow ofthe battle. In the

StaffGroup Trainer exercises, the development team had to create highly detailed messages

coming into the stafffrom every echelon and every supporting unit. To obtain this high level of

detail, individuals involved in creating the messages had to be highly competent. As this type of...

structured stafftraining matures, the message traffic will need to be refined for the staffto receive

correct, timely, detailed messages over the correct device. This type of detail can only be

provided by individuals with current and specific knowledge of all aspects ofthe BOS. Future

computer-driven exercises need to allocate ample funds to ensure that the technical subject matter

expertise is made available.

Training System Development

All developers need a clear picture ofthe desired training environment. However, it is

especially critical for software developers. If possible, they should also be provided information

on potential expansions ofthe system. This information helps them design flexible, scaleable code

which will make future development efforts less expensive. Given no direction, coders take lowrisk coding approaches to ensure code meets delivery requirements. This code will have high

reliability at an earlier development stage, but may lack the flexibility needed for expansion. To

facilitate this, managers supervising this code development should be aware of potentials in the

field (e.g., GUI features, such as "enable" and "disable" button selections; and options in system

design, such as client server versus peer-to-peer design).

58
User-Friendly Interfaces

Although the system was drastically improved, it still needs an improved GUI to reach the

ease of operation required for a fielded system. At the beginning ofthis project, the legacy system

interfaces were difficult and time consuming for the developer team to use. The data input system

developed in this project greatly simplified the developer input requirements. This was important

because it allowed more exercise variations to be tested. The lesson learned is that developer

tools must be considered in software development, not just software for end users.

Emulate Fielded Systems

The brigade commanders interviewed do not want valuable stafftraining time spent

learning a computer system that only drives the exercise. They want staffmembers to practice on

their own Army Tactical Command and Control System (ATCCS) systems; for example, the S3

section wanted to use their Maneuver Control System. To do this the ultimate training system

could be embedded in the various ATCCS systems, emulate the user-interface characteristics of

the actual tactical equipment, or be very easy to learn (less than one hour for proficiency).

IfATCCS equipment was emulated both operators and staff could be trained. The staff

would focus on training the staffsection in how best to use the system's capabilities.

Training Support Package Development

As discussed previously, the TSP includes both the paper-based instructions and more

non-traditional items such as the system software, multimedia presentations (previews, and

AARs), and the message database. The TSP also contains a "how to" conduct the training (trainthe-trainer) program. The following sections discuss some ofthe lessons learned about both the

paper-based portions and the non-traditional components. .-..,-. ,. -

Training Support Package Organization

During previous VTP structured training projects (SIMUTA, SEMUTA-B, and

SIMBART), the development teams tried various ways to organize the paper-based TSPs to

make them easier for a training team to use (R. G. Hoffman et al. 1995; Graves & Myers, 1997;

Koger et al. 1996). In these projects, the training teams prepared execution preview materials,

job aids, checklists, and starting and ending exercise materials. This project organized the paperbased TSPs into the five-volume sets described earlier. The O/C team felt this configuration was

difficult to use. It required them to extract and copy TSP materials to make team member

workbooks. Based on feedback from the O/Cs, the developers created workbooks that were

approximately ten pages per exercise. These workbooks provided the O/Cs the material they

needed and were evaluated as "user friendly."

The development team has learned that to be useful to the training team, the mandatory

information—execution procedures and design philosophy-must be presented in a quickly

digestible, user-friendly format. The paper-based TSP may not be the best means to provide

materials. Potential ways to replace traditional paper may be formats such as videotape or

computer-assisted instruction. Perhaps preview and AAR materials could be embedded on the

59
training system and some form of electronic clipboard or hand-held computer may offer relief

from paper training packages for the training team. Various options need to be explored to

provide job-aids and checklists to the training team. Future efforts should consider non-paperbased TSPs.

Structured Information Presentation

Structuring took place on several levels to include structured writing, message previews,

and AARs. The following sections discuss the lessons learned in structuring at these levels.

Structured writing. Structured writing has been shown to be beneficial in previous VTP

projects (Koger et al. 1996; Graves & Myers, 1997). In this project, the training team found that

structured writing helped them understand the written material in the TSPs more quickly. In the

prototype exercise reviews, the participants requested that even more use be made ofsome ofthe

structured writing presentation techniques. Specifically, the participants wanted information in a

short, to-the-point presentation. The short "bullets" rather than prose decreased the amount of

time required to digest the materials. The team maximized structured writing principles (Horn,

1995) in the TSPs. In the future, paper-based TSPs should use structured writing.

Message formats. The original SIMUTA C/ST messages did not use standardized

formats. The development team converted all messages to the formats in Field Manual 71-3

(Department ofthe Army, 1988a). The staffread messages in these formats and also used them

to compose their own messages. Familiarity with the formats permitted participants to more

rapidly parse information. Future projects should implement ATCCS formats where possible.

Previews. Multimedia previews were not part ofthe design. They were developed and

implemented for some modules and exercises to examine their potential. The general situation

multimedia previews were enthusiastically feceive'd by the staff and training team. Multimedia

previews must continue to be developed ifsuch training programs are to be exportable.

The development team discovered that high-quality previews are costly to develop. A

dedicated, knowledgeable graphic artist with sophisticated software and hardware is necessary to

keep costs at a reasonable level. While development team members became more proficient in

scripting and composing the previews, thus decreasing the cost per preview, full implementation

of dynamic/interactive links to training performance measures will increase costs.

Staffsection-specific multimedia previews were not developed. Brown (1992) has

suggested that while the staffsection-specific previews are probably the most difficult to deliver,

they offer the most training benefit. Part ofthis premise was qualitatively evaluated during this

project. The development team provided detailed preview exercise materials to the training team

for most ofthe exercises. When the material was used staff performance was positively impacted.

Additional work is required to develop detailed material for each staffsection for each exercise.

After the material is developed and tested for effectiveness, resources should be devoted to

prepare multimedia material for all staffsections. The development team has learned that

maximum structuring ofmaterials is necessary to ensure consistent, repeatable training.

60
After Action Reviews. The automated delivery ofscripted message traffic in the Staff

Group Trainer Project provided more structure to the training program than in previous

programs. The impact ofthis structure was most evident in the AAR. The structured message

traffic and events for an exercise provided the framework necessary to focus the AAR on specific

training objectives that were cued by message traffic. The team designed a structured, multimedia

AAR that kept the training team more closely aligned with the design and made AARs easier for

the O/Cs to conduct. Since future computer-driven stafftraining programs need to be designed as

exportable, easy-to-use packages, the structured, multimedia AAR will help a less experienced

training team better achieve the training objectives. The computer-driven AAR also needs to be

extended to the staffsection level.

Observer Checklists. Observer materials must be explicit and not require extensive

familiarity with the scenario. Instead of vague guidance, staff actions should specify behaviors for

observers to look for.

Train-the-Trainer Requirements

The train-the-trainer program as designed required approximately three days. It was to be

presented by an individual very knowledgeable ofthe program and its underlying concepts. After

the brigade commander interviews, it became obvious that any exportable, useable train-thetrainer program must be significantly shorter and easier to implement in the field. The lesson

learned is for the training developer to ensure that the train-the-trainer program is also designed

and developed to meet the needs ofthe audience.

Simultaneous Exercise and Training System Development

Simultaneous training and software development led to scheduling difficulties. Software

deliveries were not well aligned with the training development schedule. Training developers

were not able to test the training exercises on the system until the pilots. Ifsimultaneous training

and software development is planned, schedules must be aligned to allow adequate internal testing

prior to external testing. This may require more flexibility in test schedules or additional time

allotted to compensate for unexpected problems.

The software lot development must be integrated in the program development ofthe noncomputer components. This requires delivery of capabilities based on an analysis ofhow the code

must be developed. For example, item 1 on the user's priority list might require that items 15 and

16 would need to be developed first. The coding requirements must be linked with the

capabilities required to test the system during development.

Demonstrations

During the brigade pilot, there was a sensing that the training team had not been provided

with a clear concept ofthe TSPs. At the start ofthe last day ofthe brigade pilot, the development

team played the role of a brigade staff and executed one ofthe C

2

exercises. This demonstration

allowed the training team to see how a staffwas expected to execute the exercise on the training

system. This demonstration appeared to clear up a number of questions the training team had

61
about how the training should be executed. Based on this response, the development team

concluded that a demonstration would help both the training teams and the staffs understand how

the training program was executed. The development team added a live demonstration to the

start ofthe Train-the-Trainer Program and the staff orientation.

This demonstration was labor intensive. It required the training team to role-play as an

entire staff. There are more efficient/effective ways to conduct this demonstration, e.g.,

videotape. A videotape could be used to highlight specifics ofthe training program. More work

is required to develop the demonstration for this training program. When it is fully developed it

should be placed on suitable media.

Implementation

There were two lessons learned in implementing this program, relating to the role and

structure ofthe training team and the physical environment for the training.

Training Team

This project and previous VTP programs (R. G. Hoffman et al. 1995; Koger et al. 1996;

Graves & Myers, 1997) have faced problems with acceptance ofthe training program design.

This report discussed means of providing the training team with information and rationales for the

training program using TSPs and the Train-the-Trainer Program. Cognizance ofthe design does

not ensure acceptance. The training team must be convinced that the training program is effective

given the time and fiscal restraints oftactical units. Achieving acceptance is difficult when the

approaches are different than what they are convinced works.

Since this and the previous VTP programs were research projects, at least part ofthe

explanation should include the fact that this is research and that the training design needs to be

followed to determine its effectiveness. Only by being tested can the design be fully evaluated.

The development team must take the time and effort to ensure:

• The training team leadership understands that this is a research project.

• In research projects some concepts are tested that do not work.

• In research projects the training team members must implement the training program's

design to the best oftheir abilities so that the design can be evaluated.

The development team must involve the training team and participant staffleadership early

in the program.

Physical Features

The participants commented that the staffsections should be laid out the same as in a CP.

That means that the physical relationship between sections should be consistent with the actual

unit operating environment. When it is not cost prohibitive, face validity should be implemented.

62
The participants also wanted the tasks performed similarly to the way they would be

performed using their regular equipment. The most commonly made comment concerned posting

the map. In the pilots and trials, there were no paper maps and associated overlays available to

the staff. All ofthe work with maps was required to be done on the workstations. The

participants wanted the ability to post maps in the same manner as in the field CP to allow transfer

oftraining. In future training programs, the task ofposting a map could be performed on either

paper maps or on system maps, at the option ofthe participants (see equipment emulation

discussed earlier). Paper maps, interestingly, were not of concern to the brigade commanders

interviewed.

Evaluation

Several major lessons were learned in the evaluation phase. First, the formative evaluation

model used in this program is a valid model. However, adjustments can be made in execution to

improve results. Second, participants—as per the design plan-are key to a valid evaluation of a

research training project.

Formative Evaluation Methods

During the project, the development team did not conduct the formative evaluation as they

had planned. Certain portions were delayed or moved into later phases of development. As

Tessmer (1993) pointed out, the resistance to revision increases as the project gets closer to

completion. M. Hoffman (1986) indicated that every project has a pre-emption point. According

to Hoffman, a pre-emption point is a point where changes can no longer occur because financial

or emotional investment is too great to make the change. Since portions ofthe evaluation were

moved closer to the project completion, the implementation of changes became increasing more

difficult to make and still meet the contract delivery schedule. In effect, some ofthe evaluations

were conducted either very near or beyond the pre-emption point.

The lesson learned is that each phase of a formative evaluation is important. Phases of

evaluation should be conducted and revision recommendations provided early enough in the

development cycle so that they can be used. Certain aspects ofthe formative evaluation, such as

an expert review or one-to-one evaluation, should be done as early as possible in a project.

Ample time needs to be scheduled into the development cycle to allow for revisions based on the

formative evaluation. Without ample time for revisions, the evaluation's usefulness for that

project may not be realized. Future projects, however, may be able to benefit from the

evaluation.

Participants

Although many ofthe participants did an outstanding job of playing their roles, the staffs

for the trials were not an actual battalion or brigade staff. These individuals assembled to form a

surrogate staff only for the trial. They were usually the appropriate rank and branch or specialty.

However, since this training program design was focused on training a staffto respond to the

information needs ofthe commander, the ad hoc staff had serious short falls. These participants

lacked the synergy and motivation of a regular staffworking with their commander in a training

63
environment. The lesson learned in this project is that the target audience should be used in all

trials.

CONCLUSIONS

Staff Group Trainer Project

The StaffGroup Trainer Project developed TSPs bridging the gap between individual and

integrated stafftraining. The training focused on preparing the staffto meet the commander's

information needs. The progressive exercises trained the staffin their procedures and prepared

them for their next level oftraining. The decision-making exercises led a staffthrough the

complete staffsupport cycle.

Field commanders continue to express a need for battalion and brigade structured staff

training. The StaffGroup Trainer Project established a solid base for future design, refinement,

and implementation. With downsizing, decreased opportunities for field training, and rapid staff

turnover, the StaffGroup Trainer technology provides a high-payofftraining option.

The overhead for stafftraining cannot be labor intensive and should be largely invisible to

the staff being trained. Today, staff personnel cannot afford to invest substantial time in learning

how to use a training system. The support system must either emulate or run on actual

equipment, or require a short training time. Further development ofthe Staff Group Trainer

technology should explore these requirements.

A follow-on to the Staff Group Trainer Project to design and develop a program that can

be implemented without a significant support staffshould be considered. Commanders indicated

that obtaining a large support staff or traveling to a training site for this type oftraining is not

feasible. Any stafftraining program must be easy for the commander to use within his assets or

with minimal augmentation and available at the commander's home station. Future developments

ofstructured, computer-driven stafftraining systems must take into consideration field training

needs and start with a front-end analysis. Program designs must then be generated in light of

these needs.

64
Training Program Potential

The Army has a need for training tools to enable staff groups to become proficient at

critical functions. Unit commanders want a program to train stafffundamentals prior to

conducting more elaborate and costly training exercises. Such a program must:

• be turnkey,

• have low overhead requirements (training personnel),

• be easy to use, and involve short train-up requirements (administrators and trainees),

• consist ofshort, intense vignettes, and

• contain modules that take no more than half a day to complete.

A training team in which the commander is the senior trainer, even though team members

may not be permanently assigned, remains a key component of a stafftraining program. The

training program is his tool to train his staff. The training team must work for him and support his

informational or situational requirements. To optimize training, the training team must have

available a train-the-trainer program and TSPs which are concise, efficient, and easy to use.

Recommendations for Further Research

The following list is based on this project's lessons learned and summarizes areas for

further research and development to meet unit commander's needs.

1. Further work is desirable to merge the BFs into new and existing structured training

programs. Since the BF and the StaffGroup Trainer Project were conducted concurrently

many ofthe products developed in the BF project were not totally integrated into the training

programs.

2. The training team availability for structured, computer-driven stafftraining programs will

remain a problem within the Army. Further research should be conducted to determine

minimum staffing requirements and trade-offs associated with various training team

configurations.

3. Further work is needed to enhance the configuration and presentation ofTSPs. Possibilities

include:

• Putting the TSP in an electronic medium.

• Presenting some ofthe material in the TSP via multimedia techniques.

• Using an electronic clipboard-type device for observer checklists.

65
4. Further improvements can be made to the train-the-trainer program. The program needs to be

exportable, concise, and easy to use. Some form ofmultimedia or computerassisted/managed training may be suitable. This program must be tied to the training team

availability, number oftrainers required, and the time constraints these individuals are under.

5. Further investigation into the utility and means ofproviding the staffpre-exercise materials is

required. This project used multimedia for the general preview with very positive results.

Effective means of presenting staffsection-specific previews still need to be determined.

6. Investigation on whether the C

2

exercises are required to prepare a stafffor Janus or BBS

should be conducted.

The Staff Group Trainer Project advanced the development process of providing battalion

and brigade stafftraining programs to the commander as a tool to train his staff. More work is

required to refine these programs and the delivery system into a useable tool for the commander

in the field. This project provided direction for future developments in this area.

66
REFERENCES

Atwood, N. K., Winsch, B. J., Sawyer, A. R., Ford, L. A., & Quinkert, K. A (1994). Training and

soldier-machine interface for the combat vehicle command and control system (ART

Technical Report 1007). Alexandria, VA: U.S. Army Research Institute for the Behavioral

and Social Sciences.

Brown, F. J. (1991). A simulation-based intensified training readiness strategy for the reserve

component (IDA Paper P-2611). Alexandria, VA: Institute for Defense Analyses.

Brown, F. J. (1992). Battle command stafftraining (EDA Paper P-2785). Alexandria, VA: Institute

for Defense Analyses.

Campbell, C. H., Campbell, R. C, Sanders, J. J., Flynn, M. R., & Myers, W. E. (1995).

Methodology for the development ofstructured simulation-based training (ARI Research

Product 95-08). Alexandria, VA: U.S. Army Research Institute for the Behavioral and

Social Sciences.

Cannon-Bowers, J. A., Tannenbaum, S. I., Salas, E., & Volpe, C. E. (1995). Defining

competencies and establishing team training requirements. In R. A Guzzo & E. Salas

(Eds.), Team effectiveness and decision making in organizations. San Francisco, CA:

Jossey-Bass.

Department ofthe Army. (1985). Battalion and brigade command and control (FC 71-6). Fort

Knox, KY: Headquarters, U.S. Army Armor Center.

Department ofthe Army. (1988a). Armored and mechanized infantry brigade (FM 71-3).

Washington, DC: Headquarters, Department ofthe Army.

Department ofthe Army. (1988b). Mission training plan for the heavy brigade command group and

staff(ARTEP 71-3-MTP). Washington, DC: Headquarters, Department ofthe Army.

Department ofthe Army. (1988c). Mission training plan for the tank and mechanized infantry

battalion task force (ARTEP 71-2-MTP). Washington, DC: Headquarters, Department of

the Army.

Department ofthe Army. (1988d). Tank and mechanized infantry battalion task force (FM 71-2).

Washington, DC: Headquarters, Department ofthe Army.

Department ofthe Army. (1992). Tactics and techniques for combined arms heavy forces:

Armored brigade, battalion/task force, and company/team (FM 71-123). Washington, DC:

Headquarters, Department ofthe Army.

Department ofthe Army. (1993b). Heavy opposing force (OPFOR) organizational guide

(TRADOC Pamphlet 350-1). Fort Monroe, VA: U.S. Army Training and Doctrine

Command.

67
Department ofthe Army. (1993c). Heavy opposing force (OPFOR) operational art handbook

(TRADOC Pamphlet 350-14). Fort Monroe, VA: U.S. Army Training and Doctrine

Command.

Department ofthe Army. (1993d). Staff organization and operations (FM 101-5). Washington,

DC: Headquarters, Department ofthe Army.

Department ofthe Army. (1994). Force XXI operations: A concept for the evolution offulldimensional operations for the strategic Army ofthe early twenty-first century (TRADOC

Pamphlet 525-5). Fort Monroe, VA: U.S. Army Training and Doctrine Command.

Department ofthe Army. (1995). Joint planning (Command and General StaffOfficer Course

Lesson Number MS 511/6). Fort Leavenworth, KS: Combined Arms College.

Department ofthe Army (1996). National Training Center priority trends: 4QFY94 through

2QFY96. Fort Leavenworth, KS: Center for Army Lessons Learned.

Druckman, D. & Bjork, R. A. (Eds.). (1994). Learning, remembering, believing: Enhancing

human performance. Washington, DC: National Academy Press.

Du Bois, R. S., & Smith, P. G. (1989). A simulation-based evaluation of a position navigation

system for armor: Soldier performance, training, and functional requirements (ARI

Technical Report 834). Alexandria, VA: U.S. Army Research Institute for the Behavioral

and Social Sciences. (AD A210 696)

Du Bois, R. S., & Smith,. P. G. (1991). Simulation-based assessment of automated command.

control, and communications for armor crews and platoons: The intervehicular information

system (TVIS) (ARI Technical Report 918). Alexandria, VA: U.S. Army Research Institute

for the Behavioral and Social Sciences. (AD A233 509)

Ford, J. P., Mullen, W. J., & Keesling, J. W. (1997). Analysis ofCommand and Control Battlefield

Functions as Performed in the Armored Brigade (ARI Research Report 1711). Alexandria,

VA: U.S. Army Research Institute for the Behavioral and Social Sciences.

General Electric. (1985). Unit-conduct offire trainer instructor's utilization handbook. Daytona

Beach, FL: Author.

Gill, D. L. (1977). Influence of group success-failure and relative ability ofintrapersonal variables.

Research Quarterly. 48. 685-694.

Graves, C. R. & Myers, W. E. (1997). An expansion ofthe Virtual Training Program: History and

lessons learned (ARI Research Report 1703). Alexandria, VA: U.S. Army Research

Institute for the Behavioral and Social Sciences.

Hoffman, M. (1986). Commentary: Good news and bad news. In M. Smith (Ed.), Introduction to

performance technology (pp. 145-152). Washington, DC: National Society for

Performance and Instruction.

68
Hoffman, R. G, Graves, C. R, Koger, M. E., Flynn, M. R, & Sever, R. S. (1995). Developing the

reserve component virtual training program: History and lessons learned (ARI Research

Report 1675). Alexandria, VA: U.S. Army Research Institute for the Behavioral and Social

Sciences.

Horn, R. E. (1995). Participant's manual for developing procedure, policies. & documentation.

Waltham, MA: Information Mapping, Inc.

Johnson, D. W. & Johnson, F. (1994). Joining together: Group theory and group skill (5th ed.).

Englewood Cliffs, NJ: Prentice-Hall.

Jourdan, F. J., Bandura, A., & Banfield, J. T. (1991). The impact of conceptions of ability on selfregulatory factors and motor skills acquisition. Journal of Sport and Exercise Psychology.

8, 213-226.

Klein, G. & Thordsen, M. (1989). Cognitive processes ofthe team mind. Final Report to NASAAmes Research Center. Yellow Springs, OH: Klein Associates.

Koger, M. E., Long, D. B., Britt, D. B., Sanders, J J., Broadwater, T. W., & Brewer, J. B.

(1996). Simulation-based mounted brigade training program: History and lessons learned

(ARI Research Report 1689). Alexandria, VA: U.S. Army Research Institute for the

Behavioral and Social Sciences.

Leibrecht, B. C, Kerins, J. W., Ainslie, F. M., Sawyer, A. R, Childs, J. .M., & Doherty, W. J.

(1992). Combat vehicle command and control systems: I. Simulation-based company-level

evaluation (ARI Technical Report 950). Alexandria, VA: U.S. Army Research Institute for

the Behavioral and Social Sciences.

Leibrecht, B. C, Meade, G. A., Schmidt, J. H, Doherty, W. J., & Lickteig, C. W. (1994).

Evaluation ofthe combat vehicle command and control system: Operational effectiveness

of an armor battalion (ARI Technical Report 998). Alexandria, VA: U.S. Army Research

Institute for the Behavioral and Social Sciences.

Martens, R. (1990). Successful Coaching (2d Ed). Champaign, IL: Human Kinetics, Inc.

Mclntyre, R. M. & Salas, E. (1995). Measuring and managing for team performance: Emerging

principles from complex environments. In R. A. Guzzo, E. Salas, & Associates (Eds.).

Team effectiveness and decision making in organizations. San Francisco: Jossey-Bass Inc.

Meade, G. A., Lozicki, R. J., Leibrecht, B. C, Smith, P. G, & Myers, W. (1994). The combat

vehicle command and control system: Combat performance of armor battalions using

interactive simulation (ARI Research Report 1661). Alexandria, VA: U.S. Army Research

Institute for the Behavioral and Social Sciences.

Mills, T. M. (1967). The sociology ofsmall groups. Englewood Cliffs, NJ: Prentice-Hall.

69
Morgan, B. B, Jr., Glickman, A. S., Woodard, E. A., Blaiwes, A, & Salas, E. (1986).

Measurement ofteam behaviors in a Navy environment (NTSC Report, No. 86-014).

Orlando, FL: Naval Training Systems Center.

O'Brien, L. H., Wigginton, D, Morey, J. C, Leibrecht, B. C, Ainslie, F. M., & Sawyer, A. R.

(1992). Combat vehicle command and control battalion-level preliminary evaluation (ARI

Research Report 1627). Alexandria, VA: U.S. Army Research Institute for the Behavioral

and Social Sciences. (AD A257 467)

Olmstead, J. A. (1992). Battle staffintegration (IDA Paper P-2560). Alexandria, VA: Institute for

Defense Analyses.

Orasanu, J. (1990). Shared mental models and crew performance (Laboratory, Cognitive Science

Technical Report 46). Princeton, NJ: Princeton University.

Orasanu, J. & Salas, E. (1993). Team decision making in complex environments. In G. Klein, J.

Orasanu, and R. Calderwoods, (Eds.), Decision making in action: Models and methods.

Norwood, NJ: Ablex.

Quinkert, K. A. (1990). Crew performance associated with the simulation ofthe commander's

independent thermal viewer (CITV) (ARI Technical Report 900). Alexandria, VA: U.S.

Army Research Institute for the Behavioral and Social Sciences. (AD A226 890)

Schein, E. H. (1965). Organizational psychology. Englewood Cliffs, NJ: Prentice-Hall.

Shlechter, T. M., Bessemer, D. W., Nesselroade, P. Jr., & Anthony, J. (1995). An initial evaluation

of a simulation-based training program for Army National Guard units (ARI Research

Report 1679). Alexandria, VA: U.S. Army Research Institute for the Behavioral and Social

Sciences. (AD A297 271)

Stout, R. J., Cannon-Bowers, J. A., & Salas, E. (1996/1997). The role ofshared mental models in

developing team situational awareness: Implications for training. Training Research

Journal. 2.85-116.

Tessmer, M. (1993). Planning and conducting formative evaluations. London: Kogan Page

Limited.

Thompson, T. J., Pleban, R. J., & Valentine, P. J. (1994). Battle stafftraining and

synchronization: The integration offunctions critical to combat operations. In R. F. Holz,

J. H. Hiller, & H. H. McFann (Eds.), Determinants of effective unit performance.

Alexandria, VA: U.S. Army Research Institute for the Behavioral and Social Sciences (pp.

179-230).

70
ACRONYMS and ABBREVIATIONS

AAR After action review

AFRU Armored Forces Research Unit

ARI U.S. Army Research Institute for the Behavioral and Social Sciences

ATCCS Army Tactical Command and Control System

BBS Brigade/Battalion Battle Simulation

BC Battle Captain

BF Battlefield Function (formerly Critical Combat Function - CCF)

BOS Battlefield Operating System

BSTS Battle StaffTraining System

C/ST Commander/stafftrainer (currently called StaffGroup Trainer)

C

2 Command and Control

CATK Counterattack

CCF Critical Combat Function

COBRAS Combined-arms Operations at Brigade Level, Realistically achieved

through Simulation

COFT Conduct-of-Fire Trainer

CP Command post

CTCP Combat trains command post

CVCC Combat Vehicle Command and Control

DST Decision Support Template

ENDEX End of exercise

FC Field Circular

FRAGO Fragmentary order

FSB Forward Support Battalion

FSO Fire Support Officer

FXXITP Force XXI Training Program

GUI Graphic User Interface

ITTBBST Innovative Tools and Techniques for Brigade and Below StaffTraining

LAN Local Area Net

NCO Non-Commissioned Officer

O/C Observer/controller

O/C/I Observer/controller/interactor

OIC Officer in Charge

OPORD Operation Order

PSNCO Personnel StaffNon-Commissioned Officer

R&D Research and Development

RCVTP Reserve Component Virtual Training Program

SI Personnel Officer

S2 Intelligence Officer

S3 Operations Officer

S4 Logistics Officer

SGT Staff Group Trainer

71
SIMBART

SIMNET

SIMUTA

SIMUTA-B

SOW

TACCP

THP

TOC

TRADOC

TSOP

TSP

VTP

XO

Simulation-based Mounted Brigade Training

Simulation Networking

Simulation-based Multiechelon Training Program for Armor Units

Simulation-based Multiechelon Training Program for Armor Units

Battalion Exercise Expansion

Statement ofwork

Tactical Command Post

Take-home package

Tactical operations center

U.S. Army Training and Doctrine Command

Tactical standing operating procedures

Training Support Packages

Virtual Training Program

Executive Officer

72