Lesson Overview
This first lesson sets the foundation the whole of TRG 410 is built on: the idea that training is a system, not a pile of good lessons. By now you have learned to teach a lesson (TRG 301), to assess and supervise it (TRG 310), and to run it safely (TRG 320). This course asks a harder question. Given a real need in the Army, how do you design a whole course that meets it, prove it works, and keep it to standard as doctrine, kit, and law change? The answer begins with a way of thinking, and that way of thinking is what this lesson installs.
A course that is just a collection of favourite lessons, however well each one is taught, is a course built backwards. It starts from what the instructor enjoys teaching and hopes it adds up to something useful. A course built as a system starts from the other end: from a genuine need, from what a national must actually be able to do, and works back to the lessons that will get them there. Everything in between is connected, traceable, and checkable. That discipline is the systems approach to training, and it is the spine of the designer's craft.
Take this lesson as the knowledge layer of the course. It teaches you the mindset and the shape of the cycle; it does not yet make you a course designer. That skill is built by doing the work, by analysing a real need, drafting real objectives, designing a real programme, and having each step looked over by a qualified designer or standards owner. Where the College allows it, the practical design work and your first piloted course are reviewed and signed off in person under supervision. Reading is the start; the craft is in the practice.
By the end you will be able to explain why training is a system rather than a set of lessons thrown together, name and describe the five stages of the systems approach to training and the order they run in, explain how evaluation feeds back to improve the whole cycle, explain the principle that every course must be traceable to a real need, and describe the designer's mindset that this course will ask you to adopt.
Key Terms
- The systems approach to training (SAT): the disciplined way of building training as a connected system, from analysing the need to evaluating the result, with each stage feeding the next and the whole cycle improving over time.
- System: a set of parts that work together towards one purpose, where each part depends on the others, as against a heap of parts that merely sit side by side.
- The SAT cycle: the five stages Analyse, Design, Develop, Deliver, Evaluate, run in order, with evaluation feeding back to the start.
- Need: the real reason a course should exist; a genuine requirement in the Army for people who can do something they cannot do well enough now.
- Training gap: the difference between the performance the Army requires and the performance people can currently give, where that difference is a training problem and not a problem of kit, manning, or motivation.
- Training objective: a precise statement of what a national will be able to do after training, written as a performance (the task), its conditions (the circumstances), and its standard (how well).
- Course specification: the design document that captures what a course is, its objectives, lessons, sequence, methods, assessment, and programme.
- Traceability: the property of a course in which every lesson can be traced back to an objective, and every objective back to the need, so nothing is taught without a reason.
- Evaluation: the judging of how well a course worked, gathered from students, instructors, and the field, used to improve the course and close the loop back to analysis.
- Standards owner: the member who guards what a qualification certifies, so it means the same thing over time.
Why training is a system, not a heap
Begin with the failure this whole course is built to prevent. A subject is needed, so a capable member is asked to "put a course together". They are knowledgeable and willing, so they assemble the lessons they know well and care about, arrange them in the order that feels natural, and run them. The students sit through it, some of it is genuinely good, and at the end they are handed a certificate. It looks like a course. The trouble is that nobody can say what the certificate certifies, because nobody started from what the holder is supposed to be able to do. Some necessary things were never taught because the assembler did not happen to know them. Some lessons were taught at length because the assembler enjoyed them, not because they were needed. Nothing checks that the students can actually do the job the course was meant to prepare them for. The course is a heap of lessons that happen to be near each other, and a heap, however fine its individual parts, is not a system.
A system is different in kind, not just in tidiness. In a system the parts work together towards one purpose, and each part depends on the others. Pull out a lesson and you can say exactly what is lost, because that lesson was there to serve a named objective. Add a lesson and you must say which objective it serves, or it does not belong. The order is not a matter of taste but a designed build from known to unknown and simple to complex. The assessment is not a closing formality but the proof that the objectives were met. Because everything is connected, everything is traceable, and because everything is traceable, the whole thing can be checked, defended, and improved. That is what it means to say training is a system.
Hold the contrast plainly, because it is the heart of the lesson.
LESSONS THROWN TOGETHER A DESIGNED SYSTEM
[ lesson I like ] NEED
[ lesson I know ] |
[ lesson that's handy ] v
[ lesson someone gave me ] OBJECTIVES (perform / conditions / standard)
[ another good lesson ] |
| v
v LESSONS, in designed sequence,
??? a certificate ??? each one serving an objective
|
- starts from the teacher v
- no stated need ASSESSMENT proves the objectives met
- gaps and overlaps |
- nothing proves it worked v
- cannot be defended EVALUATION did it work? improve it.
= a HEAP: good parts, no purpose = a SYSTEM: every part traceable to the need
The point is not that the assembler was lazy or unskilled. Very often they are the most knowledgeable member available, which is exactly why they were asked. The point is that knowledge of a subject is not the same as the design of training in it, just as TRG 301 taught you that knowing a subject is not the same as being able to teach it. Course design is its own discipline, and the systems approach is how it is done.
The five stages of the SAT cycle
The systems approach to training runs in five stages: Analyse, Design, Develop, Deliver, Evaluate. Each stage feeds the next, and the last feeds back to the first. The rest of TRG 410 is, in effect, one lesson per stage, so treat the descriptions here as the map and the later lessons as the ground.
Analyse is where a course is born, and where most weak courses are quietly killed off before they waste anyone's time. You start from the need and find the training gap: the difference between the performance the Army requires and the performance people can give now. You confirm the gap is genuinely a training problem, because not every shortfall is. From the gap you write training objectives, each stating a performance, its conditions, and its standard. You decide what to train and, just as importantly, what not to. Lesson 02 takes this up in full. Get analysis wrong and every later stage is busy building the wrong thing well.
Design turns the objectives into a course. You choose the lessons, set their sequence from known to unknown and simple to complex, match a method to each objective (EDIP for skills, explanation and confirmation for knowledge, as TRG 301 taught), lay out the assessment plan to be valid, reliable, fair, and transparent (from TRG 310), and build the programme and timings. The product is a course specification: the design on paper before anything is written. Lesson 03 takes this up.
Develop builds the materials the design calls for: the lesson plans to the College's standard template, the instructor and student materials, and the assessment instruments. Then you pilot the course, run it once and watch it closely, and refine it before it runs for real. Lesson 04 takes this up. A design that is never developed and piloted is only a hope.
Deliver is the course running for real, taught by qualified instructors to the standard the College set. This is the stage your earlier TRG courses prepared you to do well, and it is where the design meets real students and real friction.
Evaluate judges how well it all worked, at several levels: the students' reaction, their learning, their later behaviour in the field, and the result for the Army. You gather feedback from students, instructors, and the field, and you use it to improve the course. Lessons 05 and 06 take up the keeping of standards and the work of evaluation. Crucially, evaluation does not end the cycle. It feeds back.
Here is the cycle as a whole.
+----------------------+
| ANALYSE |
+---->| find the need & gap |-----+
| | write objectives | |
| +----------------------+ v
| +----------------------+
| | DESIGN |
| | sequence, methods, |
feedback | | assessment plan, |
improves the | | course specification|
whole cycle | +----------------------+
| |
+----------------------+ v
| EVALUATE | +----------------------+
| reaction, learning, | | DEVELOP |
| behaviour, result | | lesson plans, |
| gather feedback | | materials, tests, |
+----------------------+ | pilot & refine |
^ +----------------------+
| |
| +----------------------+ v
+----------| DELIVER |<----+
| run the course to |
| standard, for real |
+----------------------+
Analyse -> Design -> Develop -> Deliver -> Evaluate -> (back to Analyse)
A word on how rigidly to read the order. The five stages are a discipline, not a one-way march that forbids looking back. In real design you loop within stages and revisit earlier ones as you learn: piloting in Develop may expose a weak objective from Analyse. The value of the cycle is not that you pass each gate exactly once; it is that you always know which stage you are in and that nothing is skipped. A designer who jumps from a vague need straight to writing lessons has not saved time. They have hidden the analysis they failed to do, and the cost arrives later, larger.
Evaluation feeds back: the loop that keeps the College good
Of the five stages, the one most easily neglected is Evaluate, and it is the one that turns a sequence of steps into a living system. It is tempting to treat evaluation as a closing ceremony: the course ran, the students passed, the box is ticked, on to the next thing. That is not evaluation. Evaluation asks whether the course actually worked, and it asks at more than one level: were the students well served on the day, did they truly reach the standard, do they do the thing in the field weeks later, and did any of it help the Army do its job? Those are different questions with different answers, and a course can pass the first and fail the last.
The reason evaluation matters so much is the arrow that runs from it back to Analyse. What you learn from a course that has run is the best evidence you will ever get about whether your analysis was right, your design sound, and your materials fit. If students reach the standard in the classroom but cannot do the task in the field, the gap you analysed may have been described wrong, or the conditions in your objectives may not have matched the real job. If instructors keep reporting that one lesson lands badly, your sequence or method may be off. Evaluation is how the system learns about itself, and feeding that learning back is how the next version of the course is better than the last. A course that is never evaluated cannot improve except by luck. A College that does not close this loop slowly drifts out of date while believing itself sound, because nothing is telling it otherwise.
So picture the SAT not as a line with a full stop but as a wheel that keeps turning. Continuous improvement is not a slogan bolted on at the end; it is the whole point of building training as a system in the first place. The loop is what lets a qualification mean the same thing this year as last, and mean something better next year. Lesson 10 makes this concrete.
Every course traceable to a real need
The single principle that holds the whole system together is traceability to a need. Every course the College runs should exist because the Army genuinely needs people who can do something, and you should be able to trace the line all the way down: from the need, to the objectives that name what people must be able to do, to the lessons that teach it, to the assessment that proves it. Pull any thread and it should lead somewhere. A lesson that traces to no objective should be cut. An objective that traces to no real need should never have been written. A need that the course never turns into objectives has been quietly dropped, and the course will not meet it.
This is the discipline that protects training from two opposite failures. The first is the course built from the teacher's preferences, the heap we began with, which teaches what someone likes rather than what the Army needs. The second, subtler, is the course that grows by accretion: a lesson added one year because of an incident, another because a keen instructor offered it, a third because "we have always done it", until the course is bloated with content nobody can quite justify and the truly necessary parts are crowded for time. Traceability is the test that prunes both. For every lesson you can ask, "which objective does this serve?", and for every objective, "which need does this meet?". If there is no clean answer, the content does not belong, however good it is in itself.
Traceability is also what lets a course be defended. When someone asks why the course is two weeks and not one, or why a particular skill is assessed so hard, or why a popular topic was left out, the designer who built a system can answer from the need down. The assembler of a heap can only say that it felt about right. In a small force where time is scarce and every hour of a national's training is paid for in time they are not doing something else, that ability to justify is not a bureaucratic nicety. It is good stewardship of a scarce thing.
The designer's mindset
This course will ask you to adopt a particular way of thinking, and it is worth naming it now so the later lessons land on prepared ground.
The first habit is to start from the need and the end state, not from the content. Before you think about lessons, you think about what a national must be able to do when they finish, and why the Army needs that. Content is the last thing you choose, not the first.
The second is to think in whole systems, not single lessons. You will still care about each lesson, but your unit of design is the course, and your test of any part is what it contributes to the whole. You ask not "is this a good lesson?" but "does this lesson earn its place in this course?".
The third is to decide what not to train. A designer's discipline shows as much in what they leave out as in what they put in. Time is finite; teaching everything teaches nothing well. Choosing the vital few objectives and protecting time for them is a core act of design, not a reluctant compromise.
The fourth is to build to be checked. You design so that someone can later prove the course worked: objectives written so an assessment can test them, a course documented so a validator can follow it. You are not the last word on your own course; you build it to be validated and evaluated by others, and you welcome that as the thing that keeps it honest.
The fifth is stewardship over ownership. The course is not yours; it is the College's, and through the College the Army's. You design it, but you hold it in trust, and you guard the standard it certifies so that the qualification means the same thing for the next national to earn it as for the last. That is the standards owner's frame of mind, and it runs through the whole speciality. ADM 220 records who is qualified to instruct precisely because the qualification is supposed to mean something fixed; your job as a designer is to make sure it does.
This is a more demanding posture than "put a course together", and that is the point. The College is only as good as the courses it designs and the standards it keeps, and those depend on members who think this way.
In Practice: Two Ways to Build the Map-Reading Course
A staff officer at the College is told the Army needs more members who can navigate confidently on foot at night, and is asked to build a short course. Two designers could take the task, and the difference between them is this whole lesson.
The first reaches for what she knows. She is good at map symbols and grid references, enjoys teaching them, and has a fine set of lessons on the subject ready to go. She arranges them in the order she likes, adds a lesson on compass theory because it is interesting, runs the students through a daytime classroom exercise, and certifies those who pass the written test. The course is well taught and the students enjoy it. Yet when these same members are out on a dark hillside weeks later, several of them are lost. The course taught map theory in a warm room and certified it with a paper test, but the need was night navigation on foot, and that performance, under those conditions, to that standard, was never analysed, never made into an objective, never taught, and never assessed. The course was a heap of good lessons aimed at the wrong target, and nobody could tell because nothing checked.
The second designer starts at the other end. She asks first what a national must actually be able to do: navigate a set route on foot, at night, in unfamiliar ground, within a time and without aids, to a stated accuracy. That is her objective, written as performance, conditions, and standard. From it she works back. Which lessons are genuinely needed to reach it, and in what order, from known to unknown? What must be taught as a skill by EDIP, practised on the ground in the dark, and what can be taught as knowledge in the classroom? What can be left out, because however interesting, it does not serve the objective? How will she assess it, validly and fairly, so passing the course really means a member can do the task? She drafts the course specification, develops the lesson plans and the night practical, and pilots it once with a small group, watching closely. The pilot shows that one lesson runs long and the night exercise needs a second safety officer, so she refines both before the course runs for real. Afterwards she gathers feedback from students, instructors, and the units the members return to, learns that the standard holds up in the field, and notes two small improvements for the next run. One designer built a heap and hoped. The other built a system and can prove it.
Check Your Understanding
- Explain the difference between a course that is "lessons thrown together" and a course built as a system. Why can knowledge of a subject not, by itself, produce a good course in it?
- Name the five stages of the systems approach to training in order, and explain in one or two sentences what each stage does. Why does it matter that evaluation feeds back to the start rather than ending the cycle?
- What does it mean to say every course should be traceable to a real need, and what two opposite failures does traceability protect a course against?
Reflection (write a short paragraph): Think of a course or lesson you have been taught, in the Army or elsewhere, that felt like a heap rather than a system: content that did not clearly add up to anything you could do afterwards. What was missing, in the terms of this lesson? Where would you have started if you had been asked to design it, and what would you have decided not to teach?
Summary
- Training is a system, not a set of lessons thrown together. In a system the parts work together towards one purpose and each is traceable to a need; a heap is good parts with no stated purpose, full of gaps and overlaps, and impossible to defend or improve.
- Knowing a subject is not the same as designing training in it, just as knowing a subject is not the same as teaching it. Course design is its own discipline, and the systems approach is how it is done.
- The SAT cycle runs in five stages: Analyse the need and gap and write objectives, Design the course and its specification, Develop the materials and pilot, Deliver to standard, and Evaluate. Each stage feeds the next, and the order is a discipline you may loop within, not a one-way march.
- Evaluation feeds back to Analyse, and that loop is what makes the system learn and improve. A course never evaluated cannot improve except by luck; a College that closes the loop keeps its qualifications meaning the same thing over time, and better.
- Every course is traceable to a real need: from need, to objectives of performance, conditions, and standard, to lessons, to assessment. Traceability prunes both the teacher's-favourites course and the bloated grown-by-accretion course, and it lets a course be defended.
- The designer's mindset: start from the need and end state, think in whole systems, decide what not to train, build to be checked, and hold the course in stewardship for the College and guard the standard it certifies.
- This lesson is the map. The rest of TRG 410 takes the stages one by one: Lesson 02 Analysing the Training Need, Lesson 03 Designing the Course, Lesson 04 Developing the Materials, Lesson 05 Maintaining Training Standards, Lesson 06 Writing Training Objectives and Outcomes, Lesson 07 Implementing and Running the Course, Lesson 08 Designing for a Small Force, Lesson 09 Governance, Standards Authority, and Accreditation, and Lesson 10 Evaluating and Improving. It builds on TRG 301 (methods of instruction and EDIP), TRG 310 (valid, reliable, fair, transparent assessment), and TRG 320 (training safety), and connects to ADM 220 (who is qualified to instruct), PME 210 (writing a course specification), and LDR 420 (the integrity of the standard).
Crown Copyright © 2026 | Published by Authority of H.R.H. The Prince of Kaharagia