Royal Army College

Lesson Overview

The whole systems approach to training turns on one thing, and that thing is the training objective. Lesson 02 found the need and turned it into objectives, and Lesson 03 designed a course around them; this lesson goes deep into the objective itself, because it is the linchpin from which the entire system hangs. Design builds toward the objective, materials teach toward it, assessment tests it, validation checks against it, and evaluation asks whether it was met. Get the objective right and everything downstream has a clear, fixed target to serve; get it wrong, vague, untestable, or aimed at the wrong thing, and the whole course is built on sand, however well the later stages are done. A course designer who can write a sound objective has the single most important skill in course design.

The heart of the craft is that an objective must be precise enough to build on, teach to, and test against, which means it must state, in plain and observable terms, what the learner will be able to do. This is where most weak objectives fail: they say the learner will "know", "understand", or "appreciate" something, which sounds like learning but cannot be designed for or tested, because you cannot see inside a head. A sound objective names an observable performance, the conditions under which it is done, and the standard to which it must be done, so that an instructor knows exactly what to teach, an assessor knows exactly what to test, and everyone knows exactly what "passed" means. The discipline of writing objectives is the discipline of turning a vague wish about what students should learn into a precise, testable statement of what they will be able to do.

This is the knowledge layer. It teaches you the parts of a sound training objective, how to write performance, conditions, and standard, the difference between terminal and enabling objectives, and how objectives drive the whole system, so that you can write objectives a course can be built on. The judgement of pitching an objective at the right level for a real need, and writing a whole linked set for a course, is built by designing real courses under a qualified course designer and signed off. Read this to know how an objective is written; learn to write them by designing courses.

By the end you will be able to explain why the objective is the linchpin of the systems approach, write a training objective with its performance, conditions, and standard, choose observable verbs and reject untestable ones, distinguish terminal from enabling objectives and link them, and recognise the common faults that make an objective useless.

Key Terms

Training objective: a precise statement of what a learner will be able to do after the training, stated in observable terms with conditions and a standard.
Performance: the part of an objective that names the observable action the learner will do, expressed with a verb that can be seen and measured.
Conditions: the part of an objective that states the circumstances, equipment, aids, or limits under which the performance is to be done.
Standard: the part of an objective that states how well the performance must be done to pass, the criterion against which it is assessed.
Observable verb: an action verb naming something that can be seen or measured (apply, assemble, calculate, identify), as opposed to vague internal verbs (know, understand, appreciate).
Terminal objective: the objective expressing what the whole course or major part certifies the learner can do; the destination the course exists to reach.
Enabling objective: a smaller objective expressing a step the learner must master on the way to a terminal objective; the building blocks of a course.
Pitch: the level of difficulty and cognitive demand at which an objective is set, matched to the real need and the learner.
Testable: the quality of an objective that allows it to be assessed, because it names an observable performance and a standard; the test of a sound objective.
Alignment: the matching of teaching and assessment to the objective, so that what is taught and what is tested are both exactly what the objective states.

Why the objective is the linchpin

In the systems approach, every stage refers back to the objective, which is why an error in the objective propagates through the entire system. The design of the course is the arrangement of teaching to reach the objectives; the materials are built to teach toward them; the assessment is built to test whether they were met; validation asks whether the training meets them; evaluation asks whether meeting them solved the need. Pull the objective out and none of these has a target; get the objective wrong and all of them faithfully serve the wrong target. The objective is the single point through which the need is translated into everything the course does, which is exactly why it is worth the care this lesson gives it.

This also means the objective is where the most expensive errors are made, because they are made earliest and corrected latest. A vague objective lets the designer build a plausible-looking course that teaches and tests something, but not reliably the thing the need required, and the gap may not show until the course is validated or, worse, until its graduates fail in the field. By contrast, a precise objective makes every later stage easier and self-checking: the designer knows what to include, the assessor knows what to test, and a lesson or a test that does not serve an objective stands out as obviously off-target. Time spent getting the objective right is repaid many times over downstream, which is why experienced designers spend a disproportionate share of their effort here.

The practical upshot is a discipline: nothing in a course should exist that does not serve an objective, and no objective should exist that the course does not teach and assess. This two-way alignment, every lesson and test tracing to an objective, every objective traced to teaching and assessment, is the structural integrity of a course, and it is only possible when the objectives are precise enough to align to. The rest of this lesson is how to write them that precisely.

The three parts: performance, conditions, standard

A sound training objective has three parts, and naming them is the core technique of this lesson: performance, conditions, and standard. Together they turn a vague aim into a precise, testable statement.

Performance is the observable action the learner will do, and it is the heart of the objective. It is expressed with a verb that names something you can see or measure: apply, assemble, calculate, identify, fire, plot, treat, brief. The performance answers "what will the learner actually do?", and because it must be observable, it forces the designer to decide what the learning looks like in action rather than leaving it as a fog of "understanding". This is the part that most often goes wrong, and its own section follows.

Conditions state the circumstances under which the performance is done: with what equipment or aids, in what setting, with what help or what limits. "Given a casualty and a first-aid kit", "without reference to notes", "under simulated battle conditions", "using the issued map and compass". The conditions matter because the same performance is a different objective under different conditions, doing a calculation with a calculator is not the same skill as doing it in the head, and treating a casualty in a calm classroom is not the same as treating one in the field. Stating the conditions fixes which version of the performance is meant.

Standard states how well the performance must be done to pass, the criterion the assessment will apply: how accurately, how quickly, to what tolerance, against what checklist. "Correctly within two minutes", "to the standard in the drill book", "with no critical-point failure", "to within five metres". The standard is what makes the objective assessable as pass or fail, and it ties directly to the criterion-referenced marking of TRG 310: the standard in the objective is the standard the assessor holds. An objective without a standard cannot be assessed consistently, because no one knows how good is good enough.

   THE THREE PARTS OF A TRAINING OBJECTIVE

   PERFORMANCE   the observable action the learner will DO
                 ......... an action verb you can SEE/MEASURE
                           (apply, assemble, plot, treat, fire)

   CONDITIONS    the circumstances it is done under: equipment,
                 aids, setting, help, limits
                 ......... "given X", "without notes", "in the field"

   STANDARD      how well it must be done to pass: accuracy, time,
                 tolerance, checklist
                 ......... "correctly within 2 min", "no critical-point
                           failure", "to within 5 m"

   Example: "GIVEN a casualty and a first-aid kit (conditions), APPLY a
   pressure dressing to a limb wound (performance) correctly within two
   minutes (standard)."
   ......... testable, teachable, and unambiguous about what "pass" means.

The verb: observable, not vague

The single most common and most damaging fault in writing objectives is the vague verb, and it deserves its own treatment because avoiding it is most of the battle. Objectives that say the learner will "know", "understand", "appreciate", "be aware of", or "be familiar with" something feel like statements of learning, but they are useless as objectives, because they name an internal state no one can see, and so they cannot be taught toward precisely or tested at all. How would you assess whether someone "understands" leadership? You cannot, directly; you can only assess something they do that demonstrates it. So the vague verb either gets quietly replaced by an observable one at assessment time, meaning the real objective was never written down, or it gets "assessed" by impression, which fails reliability.

The cure is to write the performance with an observable verb, one that names something you can see the learner do or produce: identify, list, describe (in writing or speech, which are observable), demonstrate, apply, assemble, calculate, plot, operate, treat, brief, plan. If you cannot see or measure the learner doing the verb, it is not yet an objective. The useful test is to ask: what would I watch the learner do to know they have met this? If the answer is clear, the verb is observable; if the answer is "I'd just somehow be able to tell", the verb is vague and must be replaced. Often the fix is to ask what "understanding" the thing would let the learner do, and make that the objective: not "understand the orders process" but "produce a set of orders to the standard format from a given situation".

This does not mean knowledge does not matter, or that everything is a physical skill. Knowledge objectives are perfectly proper; they are simply written with observable verbs too, identify, describe, explain (aloud or in writing), distinguish, which name observable evidence of the knowledge, rather than the unobservable "knowing" itself. The point is not to banish knowledge but to make the objective name the evidence by which the knowledge will be recognised, because that evidence is what can be taught toward and tested.

Terminal and enabling objectives

Objectives come at two levels, and distinguishing them organises a whole course. The terminal objective expresses what the course, or a major part of it, finally certifies the learner can do: the destination, the reason the course exists, usually a real, job-level performance ("plan and brief a section patrol to standard", "treat the common battlefield casualties under field conditions"). The terminal objective comes straight from the training need of Lesson 02; it is the need restated as a performance.

The enabling objectives are the smaller steps the learner must master on the way to the terminal objective: the building blocks. Reaching a terminal objective usually requires several enabling objectives in sequence, each a performance the learner must be able to do before the next makes sense, and together they map the route from the learner's starting point to the terminal performance. Designing a course is, in large part, identifying the enabling objectives that lead to each terminal objective and sequencing them, which is the architecture Lesson 03 builds. Each enabling objective is itself written with performance, conditions, and standard, just pitched at the step rather than the destination.

The two levels lock the course together. The terminal objectives tie the course to the need (Lesson 02); the enabling objectives tie the individual lessons to the terminal objectives; and assessment tests at both levels, confirming the enabling steps along the way and the terminal performance at the end. A course whose terminal and enabling objectives are clearly written and linked has a skeleton that holds; one with a fog of vague aims and no clear terminal-to-enabling structure has nothing for the design, teaching, and assessment to hang on.

   TERMINAL AND ENABLING OBJECTIVES

   TRAINING NEED (Lesson 02)
        |  restated as a performance
        v
   TERMINAL OBJECTIVE   what the course finally certifies (job-level)
        |  "plan and brief a section patrol to standard"
        |  reached by mastering, in sequence:
        +---> ENABLING OBJ 1  (a step, with its own P-C-S)
        +---> ENABLING OBJ 2
        +---> ENABLING OBJ 3  ...
   ---------------------------------------------------------------------
   Enabling objs -> the LESSONS teach them; assessment confirms them
   Terminal obj  -> the COURSE certifies it; the final assessment tests it
   Everything traces need -> terminal -> enabling -> lesson + test.

Common faults and the test of a good objective

A few faults recur, and a designer who knows them can self-check. The vague verb (know, understand, appreciate) is the chief one, treated above. The missing standard is next: an objective that names a performance and conditions but no criterion ("apply a dressing") leaves the assessor to invent the standard, breaking consistency. The untestable objective is the general case: any objective you cannot picture assessing is not finished. The wrong pitch sets an objective above or below the real need, certifying more or less than the job requires, a waste either way. The bundled objective crams several distinct performances into one, so it cannot be cleanly taught or assessed as a unit, and should be split. And the orphan, an objective the course does not actually teach or assess, or a lesson or test that serves no objective, breaks alignment and should be reconciled.

Against all of these stands one simple test that catches most faults: can you state exactly how you would assess it? If you can describe the assessment, what the learner would do, under what conditions, judged to what standard, the objective is sound, because that describability is precisely what makes it teachable and testable. If you cannot, the objective is not yet written, whatever words are on the page. This test is the designer's habitual check, applied to every objective before building anything on it, because an objective that cannot be assessed cannot anchor a course, and an hour spent fixing the objective saves a course built on a vague one. Write the objective so you could hand it to an assessor and they would know exactly what to do, and you have written it well.

In Practice: Turning a Need into Objectives

A course designer of the Royal Army College is given a real need: the Army requires its members to be able to do a particular job-task to a defined standard, and a course must be built to produce that capability. A weak designer would write an aim like "students will understand and be familiar with the task" and start building lessons. The College's designer writes objectives first, and writes them precisely.

She begins with the terminal objective, taking the need and restating it as an observable, job-level performance with its conditions and standard: given the real conditions of the task, the learner will do the task, to the defined standard, expressed so that she could hand it to an assessor and they would know exactly what to test. She rejects every vague verb: not "understand the task" but "perform the task"; not "be aware of the safety rules" but "apply the safety rules" in a way that can be seen. Then she works out the enabling objectives, the steps a learner must master to reach the terminal performance, each written with its own performance, conditions, and standard, and sequenced so each is the foundation of the next. For every one she applies the test: can I state exactly how I would assess it? Where she cannot, she rewrites until she can, because that is the proof the objective is real.

With the objectives written, the rest of the design almost falls out: each enabling objective tells her what a lesson must teach and what a test must check; the terminal objective tells her what the final assessment must demand; and alignment is built in, because everything traces to an objective and every objective is taught and tested. When the course is later validated and evaluated, it will be measured against exactly these objectives, so the precision she spent here pays off all the way down the system. She has done the most important thing in course design: turned a vague need into precise, testable objectives that the whole course can be built on, which is the linchpin this lesson is about.

Check Your Understanding

Explain why the training objective is the linchpin of the systems approach, and how an error in the objective propagates through design, materials, assessment, validation, and evaluation. What is "alignment," and why is it only possible with precise objectives?
Set out the three parts of a sound objective (performance, conditions, standard) with an example, and explain what each contributes. Why is a missing standard a serious fault?
Explain why vague verbs (know, understand, appreciate) make an objective useless and how to replace them with observable ones, including the "what would I watch them do?" test. Then distinguish terminal from enabling objectives and explain how they link a course together.

Reflection (write a short paragraph): Take something you can do well and try to write a proper training objective for it, with an observable performance, conditions, and a standard, and then apply the test: could you hand it to an assessor who would know exactly what to do? Notice how much harder it is to write than a vague "the student will understand it", and why that difficulty is the point. Then think about a course or class you have taken whose aims were vague: how did that vagueness show up later, in teaching that wandered, or assessment that seemed to test something other than what was taught?

Summary

The training objective is the linchpin of the systems approach: design, materials, assessment, validation, and evaluation all refer to it, so an error in the objective propagates through everything. The most expensive errors are made here, and precision here is repaid all the way down. Alignment, every lesson and test tracing to an objective and every objective taught and tested, is the structural integrity of a course.
A sound objective has three parts: performance (the observable action, with a verb you can see or measure), conditions (the circumstances, equipment, aids, or limits), and standard (how well, the criterion the assessment applies). A missing standard leaves the assessor to invent one and breaks consistency.
The chief fault is the vague verb (know, understand, appreciate), which names an unobservable internal state and cannot be taught toward precisely or tested. Replace it with an observable verb (identify, apply, demonstrate, calculate, treat) by asking "what would I watch the learner do to know they have met this?" Knowledge objectives are written the same way, naming the observable evidence of the knowledge.
Terminal objectives state what the course finally certifies (the need restated as a job-level performance); enabling objectives are the sequenced steps that lead to them and that the lessons teach. Everything traces need → terminal → enabling → lesson and test.
Guard against the common faults (vague verb, missing standard, untestable, wrong pitch, bundled, orphan) with one test: can you state exactly how you would assess it? If yes, it is sound; if no, it is not yet written.
This is the knowledge layer; pitching objectives to a real need and writing a whole linked set are mastered by designing real courses under a qualified course designer and signed off. This lesson deepens the analysis of Lesson 02 and the design of Lesson 03, ties directly to the criterion-referenced assessment of TRG 310, and underpins the implementation, validation, and evaluation of the lessons that follow and Lesson 10.

Writing Training Objectives and Outcomes