DSAT Explained: What JSP 822 Actually Asks of You
The Defence Systems Approach to Training, without the acronym overload — what it actually requires, and why it gets blamed for problems it didn't cause.
What DSAT actually is
DSAT — the Defence Systems Approach to Training — is the methodology set out in JSP 822 for designing, delivering and assuring training across Defence. Strip away the acronym and it's a structured way of answering five questions: what capability is required, how will training be designed to build it, how will it be developed, how will it be delivered, and how will you know it worked.
It exists for a reasonable purpose: training that isn't systematically designed against a real requirement tends to drift — delivering what's easy to teach rather than what the mission actually needs.
Why DSAT gets a bad reputation
Almost every complaint about DSAT is really a complaint about how it's been implemented locally, not about the framework itself. Treated as a checklist to complete before training can be signed off, it becomes exactly the slow, bureaucratic process people assume it is.
Treated as a decision-support framework — a structured way of testing whether a proposed intervention actually addresses the capability requirement — it does the opposite: it stops organisations wasting time and money on training that was never going to work.
The phases, in plain English
DSAT runs through Analysis (what's the capability requirement, and what's the gap), Design (what should the training look like to close it), Development (building the actual content and materials), Delivery (running it), and Evaluation (did it work, and what does that tell you for next time).
The phases aren't meant to be a one-way waterfall. The most effective DSAT implementations treat Analysis and Evaluation as a loop — using what you learn from delivery to sharpen the next round of analysis, rather than starting from zero each time.
Where organisations go wrong
The most common failure is skipping straight to Design and Development because someone has already decided training is the answer — which defeats the purpose of the Analysis phase, whose actual job is to test that assumption.
The second most common failure is treating Evaluation as a satisfaction survey rather than a test of whether the capability gap actually closed. A course that everyone enjoyed but that didn't move the underlying metric hasn't been evaluated properly — it's been rated.
Using DSAT to move faster, not slower
The Senior Information Officer Rapid TNA case study is a direct example: a team that assumed speed and DSAT compliance were in conflict discovered that used properly, as a decision framework rather than a process to endure, DSAT accelerated good decisions rather than delaying them.
The real constraint in that engagement wasn't the methodology — it was unclear current requirements and undefined future role needs. Once those were resolved, DSAT-defensible answers came quickly.
Common questions on this topic.
DSAT and JSP 822 are Defence-specific, but the underlying discipline — define the capability requirement, test whether training is the right intervention, evaluate against the outcome, not just satisfaction — applies to any regulated or high-stakes training environment.
Not when it's applied as intended. Speed problems usually come from unclear requirements or treating DSAT as sequential paperwork, not from the framework itself — see the Rapid TNA case study for a direct example.
They share the same broad shape — analysis through evaluation — but DSAT is specifically aligned to Defence governance, assurance and audit requirements under JSP 822, with defensibility built into every phase.
Want this thinking applied to your organisation?
Insight is useful. Applied insight changes outcomes. Let's talk about yours.