Analyse, Ontwerp, Ontwikkeling, Implementatie en Evaluatie geven namen aan werkzaamheden die in veel onderwijsprojecten voorkomen. Het risico ontstaat wanneer die namen een keurige volgorde suggereren: analyse klaar, ontwerp klaar, bouwen, invoeren en pas aan het einde evalueren.
Curriculumwerk gedraagt zich zelden zo. Een prototype kan aantonen dat de analyse te grof was. Een roosterbeperking kan een ontwerpkeuze blootleggen. Feedback tijdens invoering kan vragen om een nieuw besluit.
Maak van iedere fase een beslismoment
| Fase | Te nemen besluit | Benodigd bewijs |
|---|---|---|
| Analyse | Welk probleem en voor welke lerenden pakken we aan? | Bronnen, waarnemingen, kaders |
| Ontwerp | Welke leerroute en welk bewijs passen bij de bedoeling? | Ontwerpprincipes en alternatieven |
| Ontwikkeling | Wat moet getest worden voordat we opschalen? | Prototype en testcriteria |
| Implementatie | Welke ondersteuning en randvoorwaarden zijn werkelijk aanwezig? | Rollen, planning, systemen |
| Evaluatie | Wat behouden, herstellen of heroverwegen we? | Leerling-/studentwerk, gebruik en feedback |
Teken de terugweg
Zet bij elk beslismoment vooraf welke uitkomst het team terugstuurt naar een eerdere fase. Als een prototype bijvoorbeeld geen passend bewijs oplevert, gaat het team terug naar ontwerp; het bouwt niet alleen een mooiere versie.
Bewaar ook wie het besluit neemt. Een ontwikkelaar kan een probleem signaleren zonder bevoegd te zijn om een opleidingseis te wijzigen.
Gebruik het model niet voor schijnzekerheid
Een ingevuld ADDIE-schema bewijst niet dat de analyse goed was of de implementatie werkt. Vraag bij iedere fase welke bron is gebruikt, welke onzekerheid overblijft en welke aanname in de volgende stap wordt getest.
Het model is bruikbaar wanneer het een team helpt terug te keren naar een eerder besluit. Zodra de fasen alleen voortgangsvakjes worden, maskeert de methode precies de iteratie die curriculumontwikkeling nodig heeft.