In some organizations, they simply list the LOs and get to making them. In other organizations, especially those who have to deliver courseware to customers, the customer wants a step for seeing that the design will meet their needs.
Because training has been historically driven by learning objectives and their associated Bloom’s levels, for appropriate content and test items that align to the LOs, many organizations have come to expect or require a Courseware Design Document or CDD.
Some customer organizations spend small amounts of time reviewing LO scope and sequencing with particular emphasis on the evaluation or assessment strategies planned. Then they expect a collaborative session with their stakeholders on the plan to implement the LOs with particular instructional strategies.
Some customers just want the CDD at the end of the instructional/LX designer’s work.
Some organizations spend lots of time on these documents up-front.
The ideal Lean-Agile approach emphasizes prototypes over design documents, but you may still have to make a CDD for some customers if unsuccessful at convincing them to drop CDDs. First attempt to persuade the customer stakeholders that prototypes produce less expectation mismatches than design documents. The following figure shows how textual CDDs can be misunderstood and agreed upon even when the text may be interpreted to a different mental image by different readers.
Some buyer stakeholder’s actions seem to indicate that they think a “perfect” CDD will reduce the risk of the project coming unraveled. We have seen some organizations focus excessively on the design document out of habit and end up spending valuable resources creating many versions of the CDD. This is what Lean calls waste, but you may not be able to get everyone to agree to that. While fiddling with documents for days or weeks, there is no courseware prototyped yet, so the CDD only has the lower fidelity that text and images provide. Text can be, and often is, interpreted differently by different parties involved as shown in the following figure.
This situation is analogous to Realtors telling you to use fresh paint because some buyers cannot envision a beautiful home when your paint has hand prints and smudges all over. Some stakeholders visualize differently when decoding text to their own mental image. Working prototypes provide a higher fidelity to the intended courseware design. The following figure depicts the prototype better representing what was meant and how excessive CDD effort may not reduce risk as much as we have thought in the past, especially when newer courseware has expected behaviors that are harder to depict with text.
Design is important in courseware products. We do not mean to malign the CDD. We simply emphasize that Lean-Agile emphasizes prototypes over documentation. How can you do that? What is appropriate for your organization’s needs?
If you make a CDD, pick a maximum time to be spent on it and stick to it. Then move to prototypes. Do more than one prototype if needed to get aligned between the customer’s problem and the proposed instructional solution.
Other alternatives may include a more bare-bones scope and sequencing CDD, one that lists the LOs and their sequence with the assessment strategy instead of a 100+ page CDD that elaborates on many things in text.
Remember, you’re going to build the courseware in small increments and have time to correct misunderstandings as you see how the instructional strategies are playing out in each iteration, so you don’t lose the ability to get what you want by pushing more of the design from up-front to distributed to the iterations, a little at a time.
If you have flexibility, try experiments on what is minimally acceptable, and if it works, go with it. If you have detailed contracts with requirements lists, try to influence the customer before the contract stage so the contract does not force both parties into spending more on the CDD than may be needed.