I admit, a cheesy and arguably weak take-off on the Stanley Kubric doomsday classic, but the sentiment is there.
There's an almost tragic community (including those who should know better) who espouse the beliefs and all the wonders of ADDIE. I see it time and again in job postings where an "understanding of the ADDIE model" is an essential job requirement.
For an instructional designer planning e-learning solutions.
From organizations claiming to be on the leading edge of innovative solutions and technologies.
So, maybe it's time to look at what ADDIE is and what it isn't.
What it definitely is NOT is a model for instructional design. There's no evidence amongst educational theorists and researchers to support the claim that it *is* a model. (For more info on that subject, I'd invite you to read Barbara Bichelmeyer's treatise on the issue, along with some interesting commentary in the Educational wiki at San Diego State University.)
In practical terms, it's also NOT designed for scalability, because it's really a waterfall/cascade kind of approach to design. If you have high volumes of content to produce, or a really broad spectrum of stakeholders, you'll get bogged down pretty quickly. We're under constant pressure to
But, let's talk about what it is.
ADDIE is something that really reflects a flow of events and actions when designing and managing the build of instructor-led training content, and it can still work effectively in that sphere. And, let's face it, it's a familiar process....but it's just that: a Process flow. ADDIE is also a good reminder that we need to close the loop on the training cycle - e.g. you don't just "do some training" and call it a day. You need to evaluate and then start the process over again and engage in some continuous improvement activities...but we know that continuous improvement tends to get less attention than it should (a subject for another post at another time).
I know that the next question to emerge from this discussion is something along the lines of, "so if you're dissing ADDIE, what do YOU use, smart guy?"
I thought you'd never ask!
The model I prefer to adopt for building e-learning content follows the lines of Rapid Prototyping (Tripp & Bichelmeyer, 1991). You see, in 'traditional' e-learning development settings, people are spending a lot of time on storyboards and other flat planning tools. In principle this is a great idea because you can get things hammered out on paper before you commit to the challenges of development. But that was of more use in the days before rapid e-learning development tools made things easier for the instructional designer.
So what this means for me (and for clients) is that we can start working on the design and course structure right away. While we have a web-based environment, I'm pretty confident I could accomplish the same thing with the right desktop tool. The client can see the basic structure of the course developing in real-time, and we can even get into the details of selecting screen layouts, assessments, and other course-level parameters. What used to take days and weeks to do back & forth via email and paper now can be accomplished in a matter of hours. More importantly, because we get to work in the design environment right away, the client immediately has a sense of the learner's visual experience - rather than waiting for a "beta" developed from a long storyboard document.
The other advantage of this rapid prototyping method is that we don't have to wait for objectives to be completely defined before we develop content because the development environment is flexible enough for us to make incremental adjustments to suit the evolving outcomes instead of making a wholesale transformation of the course.
So...long, slow method with asynchronous client contact and difficult-to-manage review cycles? Or a collaborative, real-time development of a prototype that evolves and grows through incremental changes that allows us to go from concept to production in a fraction of the time?
I know which one I'd choose...how about you?