Evolution of an e-Learning Developers Guide: Do You Need One?

Project management

E-Learning can be expensive and time consuming to develop, and thus risky. It has many parallels to software development. The impact of mistakes and rework increases the further along they occur in the project life cycle.

Like software, the courseware development process can become more productive and efficient with certain methodologies and tools. I assume anyone developing online courseware has the main tool, an authoring system, so I will focus here on the methodology.

Similar to software development, one proven way to develop online training, as with any training, is with a “waterfall” methodology such as ADDIE. The idea, of course, is to identify the target audience, requirements (objectives in our lingo), context, and opportunities and obstacles up front. After that, design before we develop (it’s less costly to make changes on paper or prototype screens than to make changes after the program is coded), pilot test before we implement, evaluate the degree to which the objectives were met, and capture our lessons learned. As an alternative to ADDIE or ADDIE-like models, some developers prefer rapid prototyping in both the software and courseware worlds.

In her article in Learning Solutions eMagazine last December, Monique Donahue did a marvelous job of describing how the Design Document can be used to ensure the development team adheres to the chosen methodology and thereby reduces risk. (See The Design Document: Your Blueprint for e-Learning Standards and Consistency, December 5, 2005.) Table 2 shows a variation on that theme that we try to follow. This is our course development process in a nutshell, augmented by our Pre-launch and Launch and Support checklists in Sidebar 1 on page 6. Note the deliverables identified for each of the ADDIE stages. As I said last month, and as Ms. Donahue said in her article, these are living processes and documents that we continue to adapt over time. Ours is a condensed version; refer to her article for a more detailed description.

Notice the phrase “try to follow” in a preceding paragraph. As I have composed this two-article series over the last several weeks, I have been struggling with how best to describe the way I would like things to be, and the way they are. (Such is life, eh?) The truth is, we don’t always get the advance notice that we would like, or the forethought, or a clear picture of expected performance outcomes, nor convenient access to SMEs. I suspect this may sometimes hold true for external courseware developers as well as those of us doing it for internal audiences. This goes back to that other word I used earlier: “adapt.”

Then I remembered something from the software development community that migrated to the project management world: the capabilities maturity model, or CMM. First pioneered by the Software Engineering Institute at Carnegie-Mellon University, then adapted by the Project Management Institute and its membership, a CMM provides a way to categorize the environment in which projects are managed. In fact, it is sometimes referred to as an Organizational Maturity Model, or OMM, with respect to the particular discipline.

Maturity models describe ways for organizations to assess their current state, their desired state, and ways to get there. They examine the way the organization performs certain processes such as planning, chartering projects, managing project portfolios among competing priorities, the capabilities of individual project managers, and continuous process improvement (toward the desired state). Having been a manager of internal courseware development in three quite different organizations, I think the same thing applies to online courseware development. We thus have to manage upward, diplomatically and gently, educating those who sponsor courseware projects in the process, risks, and implications of certain decisions, etc.

Tools such as a Design Document or Table 1 are to help this process. We need to explain why the input and decisions we’re asking for are important at this time. Even then, the people we’re asking may not recognize the implications until they have been experienced once or twice. As internal developers, especially in small shops, we may have a bit more latitude to exceed planned development effort or delay course launch dates than those operating in a system of billable hours do, but that should not be license for sloppiness.

So, we “try to follow” the checklists in Sidebar 1. Admittedly, we don’t always follow the process as rigorously as we should. But we are learning, and we help our internal business partners learn, too.

Conclusion: Instructional design of the Developers Guide itself

What about the design of your Developers Guide itself? It’s a training or job aid, so let’s apply the ADDIE model to our own performance support tool. “Physician, heal thyself.”

Analyze. What is the problem we’re trying to solve with a Developers Guide? For some, it may be to convey standards to third-party courseware developers, whether internal or external, so the final product conforms to a certain look and feel. For others, it may be to serve as a “coach” for various parts of the development process.

Who is the target audience? Courseware developers, obviously. But consider other stakeholders, too, even if just a part of the guide pertains to them. It may behoove you to involve them in the guide’s creation. Here again, some of this can be done case by case with the Design Document. But if you want to establish underlying guidelines, put them in the Developers Guide. For example, what documentation will each phase produce, and who must approve it? With what IT standards must you comply? We found the guide improved communication with our IT department. For example, we found that a QA person had a suite to test compatibility with all end users’ systems across the company. That saves us many hours of pilot testing with individuals in various locations. IT also helped us store videos outside the courses with smaller file sizes and better response time.

Design. I looked at several developers’ guides on the internet, and then chose one that seemed closest to our needs and obtained permission to adapt and use it.

Develop. Our guide is a continual work in progress.

Implement. Although our guide has been “published,” it is admittedly easier in a small shop to just talk and remind ourselves of past decisions or solutions than it is to maintain and refer to a document.

This is especially true for solutions to technical issues. We’re usually resolving them under time pressure and don’t take the time to document them. In this regard, we share the bane of software developers: we know we should document, but it’s the least favorite thing to do. The Developers Guide itself could be a repository for such lessons learned, especially in a shared online folder that would be both convenient and accessible.

One rather painless way, albeit perhaps not the purest from a software standpoint, is to use the second screen of each course to document any special features and logic, and then make this screen invisible to the learner. This way the documentation stays with the course, and it’s rather easy to jot a note about special features or code at the moment it is created. Since we’re still trying one or two new things with each new course, this helps preserve any unique coding or features for future course maintenance. All documentation though, takes energy to make it happen.

Evaluate. Recently I asked my two other teammates if our Developers Guide is valuable. One of them feels she really doesn’t need it. The other appreciates having it all written down for easy reference. I think the value of such a guide may increase with the size and complexity of the courseware development operation. Yet even in our small shop I find situations where rework is needed because someone — me included — either forgot to follow a certain guideline and the instruction or navigation isn’t clear, or a situation occurs that should have been addressed in our guide but wasn’t — yet. As I said earlier, it’s a living document.

References

Donahue, Monique (2005). “The Design Document: Your blueprint for e-Learning standards and consistency.” Learning Solutions e-Magazine, December 5, 2005. Retrieved from http://www.learningsolutionsmag.com/articles/242/

Knowles, M. (1980). The Modern Practice of Adult Education. From Pedagogy to Andragogy (2nd ed.). Englewood Cliffs: Prentice Hall/Cambridge

Paulk, Mark C.; Curtis, Bill; Chrissis, Mary Beth; Weber, Charles V. (1993). “Capability Maturity Model for Software v1.1.” SEI. Carnegie-Mellon University, Pittsburgh.

Schlichter, John. PMI’s Organizational Project Management Maturity Model: Emerging Standards. Proceedings of the Project Management Institute Annual Seminars & Symposium. Nashville, Tennessee, November 2001.

Strickland, A.W. (2006). ADDIE. Idaho State University College of Education Science, Math & Technology Education. Retrieved September 12, 2006, from http://ed.isu.edu/addie/index.html

Comments

Login or subscribe to comment