Rapid eLearning Prototyping

By David Shaw

 A PDF of this article is available by email from the author.

Rapid eLearning prototyping uses modular design patterns (templates and components) for courses of different but standard types. The goal is to reduce development cycles by 50%. Some examples of components are re-usable HTML objects such as Navigation Object, Multiple Choice Object, Feedback Object and so forth. The business objective in rapid prototyping is:

•  Reduce cost
• Reduce development time
• Better meet client requirements
• Reduce time for future updates
• Create better and more consistent courses
• Allow developers to spend 80% of effort in creative tasks

Like many activities that require some project management, eLearning has traditionally used the Waterfall method. It’s a sequence of mostly linear activities sometimes called, “throw it over the wall” because it does not encourage collaboration. It’s baked in Microsoft Project and most project methodologies.

Figure 1 shows a typical waterfall process for developing eLearning courses. It assumes that all requirements are understood at the outset. Even if this were true (it never is) the development cycle is lengthy so there are many opportunities for requirements to change before the project is finished. Updates for new versions are also time consuming as they have to go over the steps in the waterfall. With the waterfall team members often spend the bulk of their time managing the process and creating the many reports and other documents it requires.

This too has to change.

Fig 1 – Traditional waterfall process

Developing eLearning is a lot like developing a software application, and one thing the industry is lacking is an integrated development environment (IDE) to increase productivity through rapid prototyping or other form of incremental development.

Studio applications like Camtasia or Captivate are a step in the right direction toward an IDE. With Camtasia or Captivate you can create a course and embed graphics and video. If you open media-editing software and revise the graphics or video it will update automatically in the course stream in, say, Captivate. At the end of the process you can publish a course with all of its components and then load it into an LMS for final testing.

Although suites like Adobe’s eLearning Suite or the Lectora set of tools have good integration between tools, an IDE presents a single development environment with a higher degree of integration between tools and the testing environment. When scanning the market for the current set of tools they are still centred on converting PowerPoints and creating Flash.

An ideal IDE would drag and drop course modules in a graphical learning-path or other course-breakdown diagram with all its branches. Clicking on any part would open an editing environment for easy updates of all types of content. Templates with basic elements for re-use, ready-made interface and navigational elements, widgets, media and other objects would be drag and drop.

It’s not an exact analogue but, for example, using an IDE the author developed a smartphone app for both iPhone and Android in less than a week.

However, even without good IDEs we can still make advances through rapid prototyping with small cross-discipline teams. Figure 2 shows one variant on rapid prototyping that the authors have used in eLearning. The goal is to continuously improve the time to completion with successive projects by developing and improving design patterns that can be re-used. A key principle is the separation of roles between Subject Matter Expert and Instructional Designers.

Fig 2 – A rapid-prototyping process

In this rapid approach there are several iterations in each phase and the phases are time boxed to control the schedule. Instructional designers work one-iteration ahead of developers and testers to keep their work-product backlog full. The make-up of the instructional team in each phase is entirely dependent on the context of each project. Sometimes more people are better in a discussion, sometimes less. Either way, daily communication and review within the instructional team is essential. The frequent participation of the Client and Subject Matter Expert (SME) is also essential.

The goal with the time box is to ship a course that meets core requirements. If the course does not meet all enhancement requests, then a follow-on project should be funded to develop the next version of the course. This implies the need to develop and manage a roadmap for the development of the course.

Short iterations may add too little functionality, leading to significant delays in final iterations. Because development is rapid documentation tends to be less than found in a waterfall process. A significant amount of post-project documentation may be required. It is a good practice to keep functional requirements updated and records of screen shots as the project proceeds. Every enhancement, change request and decision should be documented in an email and filed as a PDF.

It may also be difficult to communicate progress and status to management. Including the Client in this process will help alleviate concerns. Because each phase is time-boxed, progress reports can be based on semi-weekly or weekly estimates of effort required to complete versus the budgeted effort to complete.

The following table shows how to calculate and present the variance and percentage complete. A column for cost could be added but note that percentage spent is not equivalent to percentage complete. This method of reporting should also be used for individual tasks. The variance can also be tracked over multiple projects, as a performance indicator in the development group.

Status Report
Work to Date		Days
Actual work in days to current date	A:
Estimated days to complete phase	B:
Total estimated days to complete phase	C= A + B
Budgeted days for this phase	D:
Variance (positive is bad!)	= C - D
Percentage complete	A/C