Are you using ADDIE without realizing it?

Posted by gminks on Sunday, July 25th 2010   2 Comments   

This post came to me after a discussion as our Rock Band BBQ party was winding down Saturday night. There is so
much misinformation about ADDIE – so here is my post to try and shine a  little sunshine on the topic.

You may be using ADDIE without even realizing it. ADDIE is a process  model used to aid the design process for
training and/or performance support tools. For my techie friends, its like ITIL for the education crowd. This
particular model was documented at FSU for the military. I say documented because this was the method
developed and documented by the folks at FSU to hand over to the military so they could carry on building
instruction in a systematic way.

ADDIE is an acronym, lets go through each letter and you can decide for yourself if you are already using it.

A is for Analysis

Analysis includes determining if there is a need for instruction, if a performance support tool will do, or if there is a
larger systems problem causing a performance gap. Some of the things my organization looks at is how many
people are impacted, is this customer installable, etc.

The analysis should include can you develop the training – do you have the right SMEs, the right developers, the
instructors with the right skill sets (or can you get people up to speed)?

Its very important this analysis is not done in a vacuum – it must include all the stakeholders. Everyone should have
input into the analysis.

D is for design

Once the analysis is done, and everyone agrees some training needs to be written, its time to start to designing.
The results from the analysis should inform the design.  The analysis should influence modality if instruction is seen
as a need (eLearning, face-to-face, boot camp, etc).

Here’s the thing that trips people up about ADDIE – they think you have to deploy it like you read English words –
from left to right. But here’s the beauty – you should bring the Big E (Evaluation) into every step! Once the design
is set, evaluate it against the original analysis. Did you learn something from the design process that no one caught
in the A step? Bring in the big E!
D is also for development

The second D in ADDIE is for development. This is where you take the design blueprints you made after the
analysis (and hopefully evaluation) and actually start writing the training course. This is another great time to bring
in the big E.

At EMC we have technical folks from our field organization evaluate training before it goes live, and our technical
instructors are probably our harshest critics.

I is for implementation

Once the course has been written, its time to implement it. Its time to make it live, let students take the
instruction.

You have probably guessed it, this is another great time to introduce the Big E. Once its live, are there technical
issues? Do students understand all the learning objectives? Do students even know the course is available?

At EMC we have “smile sheets” after every course that are taken, and instructors encourage students to write
issues with the course in the notes (thanks guys…).

The Big E is evaluation

Hopefully you have figured this out already – but evaluation should happen at every step. This is going to slow you
down. This is going to make it impossible for you to interchange blanket forms and processes for all the
performance gaps you identify.

If someone comes in saying they want to implement ADDIE and the forms come out, run the other way. ADDIE is
simple and straight-forward, but it is a lot of work. People misuse the concept of ADDIE, just like they do with ITIL.
If someone comes to “implement ADDIE” armed with templates and pre-made processes, run quick the other way!
I think this tweet from Jane Bozarth sums up why: