One of the big challenges in e-Learning management is bridging the gap between instructional design and project management. Over the next few weeks, I’ll explore the relationship between the generic life cycle of e-Learning and the documented processes of project management.
In this week’s column, my focus is on a high-level overview of ADDIE, the generic life cycle description applied to traditional learning materials, and on the generic project management life span. This will include highlighting some key concepts that will help you close the loop on these two in your own work. (If you aren’t familiar with ADDIE, don’t worry: I’ll show you a picture of it later in this column, and I think it’s fair to say you’ll be familiar with the process by the time this series is finished.)
Assumptions, assertions, and conflicts
Many questions that come up in e-Learning design, development, and management arise from what I believe are basic flaws in the way individual designers and project managers relate the instructional design life cycle and the project management life cycle.
In particular, ADDIE is often spoken or written about as if it is an outline of how to manage e-Learning projects, which it is not. ADDIE does provide a convenient summary of instructional design activities in terms of broad, generic phases. However, there are two points to bear in mind.
First, ADDIE is so broad and generic (at least in the way many designers understand and apply it) that it does not have much value in guiding or in documenting project life cycles. In fact, a superficial understanding of ADDIE combined with a smattering of knowledge — at most — about instructional methods and architectures, will almost guarantee a bad learning product (with or without the “e”). ADDIE was developed, and first appeared, at about the same time as the “waterfall” life cycle in software programming. These two life cycle models have much in common, including inherent weaknesses that have been amplified by the failure of practitioners to understand the thinking behind the models. For example, both ADDIE and the waterfall model tend to be applied as “sewer pipe” processes: one pass through, no going back or iteration, no re-use of content or code, get through it as fast as you can. Yet the originators of both models were careful to specify that iteration is very much part of the respective life cycles.
Second, I think it’s worth remembering that ADDIE was popularized over 30 years ago as part of a movement to guide the creation of better instructor-led classroom courses. In those courses, the highest application of technology involved a 35mm slide projector and a “programmable” tape deck. (“Programmable” meant the instructor could record inaudible cues on the tape; when the slide projector received one of these cues, it would advance to the next slide.) Nobody then was particularly worried about ROI, and it was possible to estimate costs pretty closely early in the development process by using a variety of handy rules of thumb. Other than a few academic researchers in the (then) esoteric and unproven field of cognitive psychology, practically nobody was aware of any model of learning other than the behaviorist one. Our bible was Bloom’s Taxonomy, and our catechism was Mager’s Preparing Instructional Objectives. While Bloom and Mager are still important, our understanding has grown, not to mention our technology. We need a more carefully articulated process to deal with the complexities of e-Learning design and development.
Figure 1 is a fast summary of some critical relationships between what the designer must think about and what the project manager must think about during the project life cycles. There are three critical observations about this situation that may explain a lot about the challenges we face when we decide to create e-Learning.
Figure 1 Instructional design and project management are parallel processes.
1. Instructional design and project management overlap.
Instructional design (ID) and project management (PM) are two separate components in any rational approach to the planning of instructional systems. But they do not map directly across one to the other. They complement rather than duplicate.
In my opinion, a lot of the frustration and wasted motion in e-Learning product development arises from failure to account for these parallel processes. The same failure also leads to impatience with “analysis paralysis” on the part of decision makers.
The key element missing from many, probably most, e-Learning initiatives is documentation. Documentation helps to focus the design, supports completion on time and within budget, and facilitates communication between development team members, customers, and sponsors. I’ll have more to say about the role of documentation, especially in the next article and in the last article of this series of columns.
2. The skill set required for project management is not the same skill set required for instructional design.
We’ve known for some time that there are a number of “subspecialties” in e-Learning (The Guild article categories — management, designer, developer — are built around the major distinctions), and their number is growing. However, we often don’t appreciate how hard it is for one person to fill multiple roles, and we often forget the need to “shift gears.”
Because of the complexity of e-Learning technology, the speed of change in that technology, and the impact of e-Learning on IT infrastructure and on other business processes, project management is an emerging competency sub-specialty.
If e-Learning development is a problem solving process, then, to the instructional designer, the problem appears to revolve around, among other things:
- employee performance gaps;
- learner experience and current knowledge and skills; and
- the options for addressing this combination in order to reach desired outcomes.
The designer’s role with respect to these elements manifests in ways that are congruent with some particular philosophy about how people learn. But note that meeting a project schedule and budget is not an instructional priority.
On the other hand, to the project manager the problem seems to involve:
- deliverables;
- developer resources; and
- schedule and budget
These issues can be handled with standard project management techniques. But note that philosophy about learning, and reaching improved performance outcomes, are not on the project manager’s list of things that keep her awake at night.
Another way to look at this is to understand that the instructional designer says, “It isn’t a project until the analysis is done.” But the project manager says, “It isn’t a project until it has a sponsor, a scope, and a budget.” If the same person is in both roles, it’s no wonder he might feel a little bit conflicted most of the time.
I’ll address these differences in a column in November. But for now, if you are managing e-Learning in your organization, how are you developing the project management specialist skills of the individual ID professionals that you call on most often to lead projects?
3. The handoff from instructional design to project management must be planned.
The focus shifts from instructional design to project management at one particular point in the history of an e-Learning product. There are three key aspects of this handoff that can make or break your e-Learning development effort and I will reveal these three points next week.
The relationship between instructional design and project management
To close this column, there are two important points about learning models that I want to make, because these points inform much of what I will be writing about for the next month. I’ll get into these in more depth in a couple of weeks, but here’s a summary.
As with everything else, our models of learning — theories about what learning is, what instruction is, how do you know if someone has learned something — increase in number as the years go by. Today, there are four common models that are the basis for nearly all e-Learning, and under these four are two fundamental orientations to learning.
Basically, learning designers tend to build their products either under the assumption that the point of learning is memorization of knowledge or behavior, or under the assumption that the point of learning is the creation and articulation of knowledge. (This is a very broad and lazy summary, and I’m not writing a doctoral dissertation here, OK?)
Three models are in the memory camp. The absorption model is driven by transmission of information from an expert to the learner. The behavior model is driven by a teaching/testing methodology, and focuses on observable behaviors. The cognitive model is also driven by a teaching/testing methodology, but it is more complex because it includes several different architectures and it focuses both on observable and on covert behaviors.
The fourth model seeks to support the creation and articulation of knowledge. Problem solving drives the constructive approach. The constructive approach tests for performance by using an assessment process. The constructive model is the latest development, but it almost certainly won’t be the last.
Why are these models important? First, they are important because most designers use one and only one of them as the default when creating learning products (including e-Learning). Hold that thought for a minute.
Second, the models are important because a designer should understand all of them, and be able to match the model selected to both the outcome desired and the organization’s culture.
Third, the models are important because the nature of “e-Learning” is not constant across all models of learning. In particular e-Learning changes significantly with the shift from the memorization models to the construction model:
- In memorization, the instructor/system uses technology to efficiently deliver information and knowledge to the learners.
- In the constructive model, the learners use technology directly to explore, converse, articulate, collaborate, and reflect, facilitating the creation of knowledge.
Are you still holding that thought about defaults?
The decision about the learning model affects everything.
I believe that understanding this proposition — that the decision about the learning model affects everything — is the key to improving your product, your results, and your ROI. This decision:
- Determines project scope.
- Determines what the major deliverables are going to be, i.e. linear transmission products, modules/lessons/exercises, or problem context/representation/manipulation.
- Affects costs and time.
- Affects skills needed by development team.
If a designer defaults to the “absorption” model, the e-Learning product will consist of text and PowerPoint, and the occasional lecture canned in an MP3 object. Will this work for every assignment? Probably not. But, as Abraham Maslow famously said, “If the only tool you have is a hammer, then everything looks like a nail.” and so many e-Learning designers go on month after month whacking away at the world with their hammer and wondering why they aren’t getting anywhere.
If you look closely at ADDIE, you will see that nowhere in it does the designer explicitly make a decision about which learning model applies. This means that the implicit and tacitly selected operative learning model is nearly always going to be the one with which the designer is most familiar or comfortable, regardless of whether it is the most appropriate one for the desired outcome, audience, and topic. I think this is a weakness of ADDIE that needs to be addressed as a priority, and I will do so in future articles and columns.
In the meantime, I hope that by the time you have finished this series of columns, you’ll find a couple of new tools in your kit.