Dogma as a two-edged sword.

Susan Smith Nash writes on Xplana ("Course Development Wars: A Content Expert's Cry for Help") about her experience doing a "work for hire" project. She is not happy about the way it turned out, and blames the ID model, the Education Department, and the graduate student who was the project manager.

This is so typical of the problems we get into in development. On the one hand there is blind dogmatic insistence on doing the ID model step by step (without ever understanding the model or its function). On the other hand there is blind dogmatic insistence on sticking with what the content expert has come up with: "quite subtle and ingenious."

Instructional Systems Design (my term for "ID") is a systematic way to make sure that the structure of a product intended to facilitate learning is sound. ISD is supposed to ensure accountability. It should support learning, it doesn't create it. The ISD product is only an armature upon which the finished product is built.

Reading Susan's article, several things are clear to me. First, the Education Department was producing an application intended to support near transfer and implemented a project management structure designed with behaviorist outcomes in mind. A leads to B and the result is measured by C. Some people think of this as "low road." Susan was thinking "far transfer" and produced a design to support that. F and R, mediated by G, lead to a result K that won't be measured but that the learner can apply (or not) either to learn more or to obtain a personal goal later in life. Susan would probably think of this as the "high road" approach. Neither of these views is right or wrong, but in this case they were terribly mismatched.

Second, it isn't the ISD model's fault, it isn't Kendra's (the graduate student project manager) fault, and it isn't Susan's fault. (Although Kendra and Susan both bear responsibility for the unhappy result, and I'd bet both of them would disagree with me about that.) Kendra and the Dean were working to produce an Industrial-age training product. Frankly, it's about money and getting funding, pure and simple. Susan was pursuing a means to bring students to a higher level of intellectual accomplishment. She wasn't thinking about money, especially. The irony is that, properly applied, ISD can support either outcome. The designer and the subject matter/content expert can take the low road or the high road, they can go for near transfer or for far transfer, and ISD is the vehicle that can get them both there safely --- but the designer and the expert must both be going to the same place via the same route. Otherwise they wind up fighting about who gets to drive the damn bus.

Third, the real lesson here is not about the technology or the model. It is about the vital importance of relationships and communication. This is so trite to say, but so true. And it bites us in the butt so often.

In the original ISD, and in its best implementations, the largest amount of time is spent at the beginning of the project. The function of the "needs assessment" is to identify and resolve the desired outcomes among all parties before the team ever gets into methods, means, and crafting of "deliverables." Too often, "needs assessment" is twisted beyond recognition by people who think they "know" what the problem is and what solution is called for, and who try to bulldoze their solution over everyone else. Stories like Susan's are the result.

In graduate school thirty-plus years ago, one of the professors in the Psychology department (who also happened to be a Greek Orthodox priest) used to make a little diagram. He said, let Sigma (and he would draw the Greek character) stand for "Systemia" (system), and Alpha (again drawing the Greek character) stand for "Anthropos" (human beings). When you add them together, you get "SA", which is the abbreviation for the Greek word for "Sickness." It's a lesson that has stayed with me because it is true in many areas of life, but nowhere more true than in using ISD.

Predictably, others have a different view of Susan's experience. I can't say I disagree, but I do think it's a shame to blame the tool for the workman's inability to use it.

Further thoughts and elaboration (added after the first part of this post).

Susan's article is more about poor project management and uncommunicated expectations than it is about Instructional Design and Subject Matter Experts. What she describes was surely a disaster all the way around, but don't blame ID or even the Education Department. This was totally avoidable.

How did it happen that the project manager never discussed the model and the requirement for behavioral objectives with the SME until after the SME turned in her deliverables? That was a truly cosmic dumb new-project-manager-suddenly-in-deep-doo-doo mistake.

How did it happen that the SME didn't catch on immediately to the fact that what was being written was not "her course" but a work-for-hire, meaning that there were specifications to be met? A writer on contract cannot afford to have any ego tied up in the deliverables. If that's unacceptable, don't do work-for-hire.

I've been designing, delivering, and managing training and education since 1968, and I've been both a hired gun and an employer as well as being tapped to be an SME in my own areas of expertise. Never once has the ID model been a problem, whether the design was to be behaviorist in nature, collaborative, or constructivist. ID, intelligently applied, will support any educational outcome. All that ID does is to provide a framework for the project and a basis for accountability. It does not create knowledge and it does not dictate objectives, methods, or means. Problems in development nearly always come as a result of poor communication, incompetent project management, or unclear expectations/specs.

10:03:28 AM