ADDIE Model: Five Phases, a Template, and an Example
The five ADDIE phases for teams with no training department, plus a worked example, a five-phase worksheet, and the version that runs in an afternoon.
The ADDIE Model
What each of the five phases actually produces, where the model came from and why its original fifth phase was Control rather than Evaluate, a worked example carried end to end, a worksheet that holds the whole process on one screen, and the version that runs in an afternoon when nobody on the payroll designs training for a living
The first training module I built took three weeks and taught the wrong thing. I knew exactly what I wanted people to know, so I wrote it all down, recorded it, assigned it, and then watched the same mistakes keep happening. What I had skipped was the part where you find out what the gap actually is before you start producing content.
ADDIE is the correction for that mistake, and its entire contribution is the running order. Analyze, Design, Develop, Implement, and Evaluate. Content production sits fourth. By the time you open a recording tool, the problem has a number attached to it and every module has an objective you could watch someone perform.
This guide covers what each phase produces, where the model came from and why its original fifth phase was not Evaluate, a worked example carried end to end, a worksheet that holds the whole process on one screen, and the version that runs in an afternoon. That last part is the gap in every other explanation: they assume an instructional designer, a project timeline, and a review committee. I build the people tooling for businesses that have none of those at FirstHR.
What the ADDIE Model Is
The ADDIE model is a five-phase process for building training, run in order: Analyze, Design, Develop, Implement, and Evaluate. Each phase produces one artifact that the next phase needs, which is what makes it a process rather than a list of good intentions.
The sequence is the whole idea. Almost every failed training project I have seen started at phase three, because producing content feels like progress and asking what the problem is feels like a delay. The result is a module that is well made and aimed at nothing in particular.
What ADDIE buys you is three decisions made in the right order: what problem you are solving, what a trained person can do that an untrained one cannot, and only then what the material looks like. Get those in the wrong order and the third decision quietly determines the first two.
Where ADDIE Came From
ADDIE came out of a 1975 US military project, and the acronym arrived later than the model it describes. The Interservice Procedures for Instructional Systems Development, published in August 1975 by the Center for Educational Technology at Florida State University and credited to Robert K. Branson, set out a five-phase method for building military training that could also be applied to any interservice curriculum development activity (ERIC record ED122022). The work was sponsored by the Naval Education and Training Command.
The detail worth knowing is that the original five phases were Analyze, Design, Develop, Implement, and Control. Not Evaluate. Control is a broader idea: it covers the ongoing management of a training system, of which measuring the last course you ran is only one part.
So where did the acronym come from? Michael Molenda went looking and could not find a single author or founding document. Writing in Performance Improvement in 2003, he concluded that the term came into use by word of mouth, as a label for the whole family of systematic instructional development models rather than as one person's invention (ERIC record EJ676523).
That history has a practical consequence. There is no canonical ADDIE specification you can be wrong about, which means the arguments over whether a given approach is really ADDIE are not worth having. The five phases are a checklist of decisions in a sensible order. Treat them that way and the model behaves.
An acronym assembled after the fact is also the simplest explanation for the swapped fifth phase. Nothing bound the label to the document that came first, and Evaluate describes the narrower thing most people were actually doing at the end of a project.
The original context is worth holding in mind too, because it explains the paperwork. The 1975 procedures were written to train large numbers of people across multiple military services, where documenting every step is what makes a training system auditable. That is where the model got its reputation for heavy process, and it is the part a small team should leave behind.
The Five Phases in Detail
Each phase answers one question and produces one artifact, and the fastest way to hold the model is by artifact rather than by activity. If a phase produced nothing you can point at, the next phase is running on assumptions.
| Phase | The question it answers | What it produces | Where small teams go wrong |
|---|---|---|---|
| Analyze | What goes wrong, how often, and is this a training gap? | A one-sentence problem statement and a baseline number | Skipping it entirely, then having nothing to compare against later |
| Design | What must the person be able to do unaided? | Observable objectives, a module outline, and a practice task | Writing objectives that start with understand or be aware of, which nobody can check |
| Develop | What are the materials, and where does the content come from? | The module, a one-page reference, and real practice cases | Building slides instead of a reference page people will return to |
| Implement | Who takes it, when, and on whose time? | Assignments with a due date and a retrievable completion record | No pilot, so 20 people hit the same confusing step at once |
| Evaluate | Did the baseline number move, and what changes? | A verdict: keep the module, revise it, or drop it | No calendar reminder, so the phase silently never happens |
Analyze is the phase that decides whether the other four are worth running. Its real job is not to catalog everything people do not know. It is to answer one question: if this gap closed, what would be different, and can I count it today? A training needs assessment is the long version of this phase, and for one module you need about 45 minutes of it.
Design is where most of the leverage sits, and it takes the least time. One sentence per module, in the form: after this, the person will be able to do X unaided. The verb has to be something you could watch. Explain, calculate, decide, escalate, and demonstrate all work. Understand, know, and appreciate do not, because you cannot tell by looking whether they happened.
Develop is the phase everyone thinks is the whole job. It is the most hours and the least judgment. The one decision that matters here is format, and for small teams the answer is usually a narrated screen recording plus a one-page reference. The recording gets watched once. The reference page gets used for years, which is the reverse of how most people allocate their effort.
Implement is where a small business has an advantage worth using: you can pilot with one person before anyone else sees the module. Sitting with one learner for 20 minutes catches the two confusing steps that no amount of re-reading your own material will surface. It is also the phase where required training gets its due date and its record.
Evaluate is a comparison, not a survey. You wrote a number down in Analyze. Look at the same number 30 days later and again at 90. If you also want to know how the session landed, the Kirkpatrick four levels give you the vocabulary for the levels above completion, and a short feedback form handles the reaction layer.
The Five-Phase Worksheet
The entire model fits on one screen, and it should, because a planning document longer than the training it plans is a sign the process has taken over. The worksheet below has three sheets: the five phases with their questions pre-filled, a module outline, and an evaluation log.
| A | B | C | D | E | F | G | |
|---|---|---|---|---|---|---|---|
| 1 | Phase | The question this phase answers | What we decided | Artifact it produced | Owner | Due | Done |
| 2 | Analyze | What goes wrong, how often, and is it a training gap? | Problem statement plus baseline number | ||||
| 3 | Design | What must the person be able to do unaided, and how will we check? | Objectives, outline, and practice task | ||||
| 4 | Develop | What are the materials, and where does the content come from? | Module, reference page, and practice cases | ||||
| 5 | Implement | Who takes it, when, on whose time, and who confirms completion? | Assignments and completion record | ||||
| 6 | Evaluate | Did the baseline number move, and what do we change? | Verdict: keep, revise, or drop |
The first sheet is the discipline. Five rows, one per phase, each with the question already written and two columns you have to fill in: what you decided, and what artifact came out of it. An empty artifact cell is the honest signal that the phase did not happen, which is more useful than a checkbox you ticked out of momentum.
The second sheet is the module outline, and the column that does the work is the objective, written as something you could watch a person complete. Next to it sit the practice task and the check, so the three decisions that have to agree with each other are visible on one row. If the objective says decide and the check says score 8 out of 10 on a quiz, the disagreement is obvious at a glance.
The third sheet is the evaluation log, and its most important column is the one for what else changed. A number that moved after training did not necessarily move because of training. Writing down the new hire, the price change, or the seasonal dip beside the result is what keeps the verdict credible when somebody asks.
A Worked Example
Here is the model run end to end on a problem small enough to be real. Take a nine-person company where roughly 11 refund requests a week get escalated to the owner, each one costing a few minutes of interruption and a slower answer for the customer.
| Phase | What happened | What it produced | Time spent |
|---|---|---|---|
| Analyze | Asked the two support staff what they escalate and why. The answer was not how do I issue a refund. It was I do not know if I am allowed to. | Problem statement: the team can process refunds but cannot judge which ones need approval. Baseline: 11 escalations a week. | 45 minutes |
| Design | Wrote one objective and picked the check at the same time. | Objective: decide a refund request under $200 unaided and explain the decision in two sentences. Check: five real past cases, decided cold. | 30 minutes |
| Develop | Wrote the decision rule on one page, recorded a narrated walkthrough of two real cases, pulled five more from the last quarter as practice. | A one-page rule, a 9-minute recording, and five practice cases with answers. | 2 hours |
| Implement | Piloted with one person, fixed the two steps that confused them, then assigned it to the team with a due date on paid time. | Two assignments, a completion record, and one clarified sentence in the rule. | 25 minutes per person |
| Evaluate | Counted escalations at day 30 and again at day 90, and noted a new hire joining in month two. | Verdict on whether the rule holds, plus the confounder written next to the result. | 20 minutes, twice |
Total build time: 3 hours and 15 minutes, plus 40 minutes of checking spread across the following quarter. That is the honest cost of one module built properly, and it is well inside what an owner can absorb in a week.
Two things in that walkthrough do most of the work. The first is the Analyze finding, which reframed the problem from a procedure gap to a judgment gap. Had the module been built on the original assumption, it would have taught people something they already knew and the escalations would have continued unchanged.
The second is the practice task. Five real cases, decided cold, is a better check than any quiz because it measures the thing the objective named. It also produces a useful side effect: the cases people disagree on are exactly where the written rule is ambiguous, which sends you back to the reference page with a specific fix.
ADDIE Without a Training Department
All five phases run fine with no instructional designer, no project plan, and no review committee. What changes is the scale of each artifact: one page instead of one document, one pilot learner instead of a review cycle, and one number instead of a measurement framework.
The phase to protect is Analyze, and the phase to cut is Develop. That is the opposite of what happens naturally. Analysis has no visible output, so it feels skippable, while development feels like the real work because you can see it accumulating. Roughly 45 minutes of asking against 2 hours of building is the right ratio for a single module.
One cost belongs in the Implement phase and is almost never counted. Time spent on required, job-related training is working time. Under 29 CFR 785.27, attendance at lectures, meetings, and training programs is excluded from hours worked only when all four conditions are met: it is outside regular working hours, attendance is in fact voluntary, the course is not directly related to the job, and no productive work is performed (Legal Information Institute). A module on your own refund policy fails at least two of those, so for non-exempt staff the minutes count toward overtime under the Fair Labor Standards Act.
Knowing that number changes how you design. A 25-minute module taken by a team of nine is a few hours of payroll, which is cheap. A half-day workshop for the same nine is not, and the difference should show up in the Design phase as a shorter module rather than in the Evaluate phase as a disappointment.
The Implement phase also has a records dimension that outlives the module. Who completed what, and when, is what you need a year later when a role changes or a question comes up, and it is far easier to retrieve when the completion record sits with the rest of the employee file instead of a spreadsheet on one laptop.
That is the seam where training and onboarding stop being separate projects. The same assignments, due dates, and completion records serve both, which is why the training modules and task workflows in FirstHR sit alongside the onboarding flow rather than in a separate product.
ADDIE and the Alternatives
Most of the frameworks people compare ADDIE to are not competing with it, because they answer different questions. ADDIE answers how to build training. The others answer where learning comes from, how to evaluate it, or how to pitch an objective at the right level.
| Framework | What it answers | How it relates to ADDIE | Cost to run |
|---|---|---|---|
| ADDIE | How do I build this training, in what order? | The parent process | Low at one module, high if you reproduce the enterprise paperwork |
| SAM (successive approximation model) | How do I avoid discovering a wrong assumption at the end? | Same activities, run as short repeated cycles instead of one pass | Low per cycle, harder to schedule |
| Dick and Carey systems approach | How do the pieces of instruction connect to each other? | A more detailed relative of the same systems tradition | High, built for formal curriculum design |
| Kirkpatrick four levels | Did the training work, and at what level? | Fills in the Evaluate phase | Low to moderate |
| 70-20-10 | Where does professional learning actually come from? | Tells you how much of the problem a formal module can solve at all | None, it is a design compass |
| Bloom’s taxonomy | At what cognitive level should this objective sit? | Sharpens the objective written in Design | None |
The comparison that matters in practice is ADDIE against iterative design. The successive approximation approach runs short cycles of design, build, and review rather than one pass through five phases, on the argument that a rough version in front of a real learner beats a polished version built on an untested assumption.
At small scale the argument largely dissolves. A two-hour module is cheap enough to rebuild, so you get most of the iteration benefit by inserting one pilot learner between Develop and Implement and keeping everything else sequential. That is the compromise I would recommend to anyone building their first few modules.
The framework worth reading alongside ADDIE is 70-20-10, for a reason that has nothing to do with process. It is a reminder that a formal module is a minority share of how anyone gets good at their job, and that the on-the-job practice around the module usually deserves more design attention than the module itself.
What ADDIE Gets Wrong
The criticisms of ADDIE are real, and they are worth knowing because they tell you which phases need a guardrail rather than whether to use the model at all.
The waterfall criticism is the substantive one, and the fix is cheap: one pilot learner between Develop and Implement. That single insertion converts the model from a straight line into something with a feedback loop, at a cost of about 20 minutes, and it catches the class of error that would otherwise surface after everyone had already taken the module.
The evaluation criticism deserves the most attention because the failure is structural rather than intellectual. Everyone agrees evaluation matters and it still does not happen, because by the time it comes due the module is live and the urgency has moved on. Organizations that reliably evaluate training tend to be ones where somebody made it mandatory: federal agencies, for instance, are required to evaluate their training programs annually to determine how well those programs contribute to mission accomplishment and meet organizational performance goals, under 5 CFR 410.202 (Office of Personnel Management).
You do not have a regulation forcing your hand, so use the substitute: a calendar reminder set on the day you write the baseline. It is a weaker commitment device than a federal rule and considerably stronger than intending to remember.
Common Mistakes
The failure patterns repeat, and nearly all of them come from starting in the middle of the model rather than at the beginning.
Starting at Develop is first and by far the most common. Someone identifies a topic, opens a recording tool, and produces a competent module aimed at a gap nobody confirmed. The output looks like progress right up until the behavior does not change.
Writing objectives nobody can check is second. Understand the policy, be aware of the process, and know the product are not objectives, because two people can disagree about whether they were met and neither can prove it. Swap in a verb you could watch and the rest of the design gets easier immediately.
Building one giant module is third. A 40-minute module has a completion problem and a diagnosis problem: when the number does not move, you cannot tell which part failed. Three short modules with separate objectives tell you where the gap actually is, and they fit into a working day. This is the practical case for shorter modules, independent of any theory about attention spans.
Skipping the baseline is fourth, and it is the one that cannot be repaired later. Every other mistake on this list is fixable in a second pass. A missing pre-training number is gone the moment the training runs.
Treating the worksheet as the deliverable is fifth. The artifacts exist to force decisions, not to be filed. If filling in the sheet takes longer than the phase it documents, shrink the sheet.
And skipping the pilot is last. It is 20 minutes with one person, and it is the only step in the whole model that shows you your own material through somebody else's eyes before it is too late to change cheaply.
Whatever the verdict, keep the record. What was built, who took it, when, and what the number did at 30 and 90 days is the institutional memory that stops you rebuilding a module that did not work. Storing it alongside your other training documents rather than in a folder on one laptop is the low-effort version, and a simple training matrix makes it retrievable a year later.
Frequently Asked Questions
What is the ADDIE model?
The ADDIE model is a five-phase process for building training, run in a fixed order: Analyze, Design, Develop, Implement, and Evaluate. Each phase hands one artifact to the next. Analyze produces a problem statement and a baseline number, Design produces observable objectives and an outline, Develop produces the materials, Implement produces assignments and a completion record, and Evaluate produces a verdict on whether to keep the module, revise it, or drop it. Its main contribution is the sequence rather than any individual phase: content production sits fourth, which forces you to establish what the gap is and what people must be able to do before anything gets recorded or written.
What are the five phases of ADDIE?
Analyze asks what goes wrong, how often, and whether the gap is a training gap at all. Design asks what the person must be able to do unaided and how you will check it, producing objectives and an outline. Develop is where the materials get made: the module, the reference page, and the practice cases. Implement covers who takes it, when, on whose time, and who confirms it happened. Evaluate returns to the number written down in Analyze and asks whether it moved. On a small team the first two phases take a little over an hour combined, Develop takes about two hours for one module, and Evaluate is two short check-ins.
Who created the ADDIE model and when?
The model traces to a 1975 US military project rather than to a single author. The executive summary and model for the Interservice Procedures for Instructional Systems Development was published in August 1975 by the Center for Educational Technology at Florida State University, credited to Robert K. Branson, and sponsored by the Naval Education and Training Command. Its ERIC record lists the five functional phases as Analyze, Design, Develop, Implement, and Control, so the familiar fifth phase is not the one the original used. Michael Molenda later went looking for the source of the acronym and concluded in Performance Improvement in 2003 that the term came into use by word of mouth, as a label for a whole family of systematic instructional development models.
What is an example of the ADDIE model in practice?
Here is one at small scale. A nine-person company escalates about 11 refund requests a week to the owner. Analyze establishes that people know how to issue a refund and do not know where the judgment line sits, so 11 becomes the baseline. Design writes one objective: decide a refund under $200 unaided and explain the decision in writing. Develop produces a one-page decision rule, a narrated screen recording, and five real past cases as practice. Implement assigns 25 minutes of paid time in the first week with one person piloting it first. Evaluate checks the escalation count at 30 and 90 days against 11. Total build time is 3 hours and 15 minutes.
How long does ADDIE take for a small business?
One module, start to finish, runs about 3 hours and 15 minutes of build time plus 40 minutes of checking spread across the following quarter. Analyze is two questions asked of the person closest to the problem, roughly 45 minutes. Design is one sentence per module, about 30 minutes. Develop is the bulk of it at around two hours: a narrated screen recording, a one-page decision rule, and five real cases pulled from the last quarter. Implement is 25 minutes per person on paid time. Evaluate is two 20-minute check-ins at 30 and 90 days. The long timelines associated with this model come from the enterprise version, not from the phases themselves.
What is the difference between ADDIE and SAM?
ADDIE runs its phases in sequence, while SAM, the successive approximation model, runs short repeated cycles of design, build, and review. In ADDIE, the module is finished before a learner sees it, which makes planning predictable and makes a wrong assumption expensive to discover. In SAM, a rough version goes in front of a real learner early and gets rebuilt several times, which surfaces the wrong assumption sooner at the cost of a fuzzier schedule. At small scale the distinction mostly dissolves, because a two-hour module is cheap enough to rebuild. The practical compromise is ADDIE phases with one pilot learner inserted between Develop and Implement.
What are the main criticisms of the ADDIE model?
The most substantive criticism is that ADDIE is a waterfall, so a wrong assumption made in Analyze survives untested until Implement, where correcting it is expensive. A second is that Analyze has no natural stopping point and can consume a project that never ships. A third is that the model assumes training is the correct intervention: if people already know what to do and are not doing it, five well-run phases produce a well-designed module that changes nothing. A fourth is that Evaluate sits last, which is exactly where work gets cut when the urgency fades. The fix for that one is to define the measure during Analyze rather than promising to get to it later.
Do you have to pay employees for time spent on training?
Usually yes. Under the federal rule at 29 CFR 785.27, attendance at lectures, meetings, and training programs need not be counted as working time only when four conditions are all met: attendance is outside regular working hours, attendance is in fact voluntary, the course is not directly related to the employee’s job, and the employee performs no productive work during it. A required module on how your own refund policy works fails at least two of those tests, so the time is hours worked. For non-exempt staff those hours also count toward overtime. This belongs in the Implement phase of your plan, because it is the number that makes a 25-minute module a real cost rather than a free one.