There has always been pressure to do more with less but the globalization we have experienced since 2000 has made this acute. We have all experienced the phenomena of off-shoring in the development of eLearning. Rapid prototyping is one possible response emphasizing proximity and collaboration with the client.
Rapid eLearning prototyping uses modular design patterns (templates and components) for courses of different but standard types with the goal of reducing development time 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
Over the Wall
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.The waterfall method (Figure 1), although the most common, has several significant disadvantages:
- It has the longest possible development cycle
- It puts all of the risks in the testing and customer-acceptance stages
- The long cycle encourages changes in requirements
Fig 1 – Traditional waterfall process maximises risk
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.
A typical version of the waterfall process as used in eLearning is shown in Figure 2.
Fig 2 – Traditional waterfall process in eLearning
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 has to change.
Iteration Moderates Risk
Figure 3 shows a phased or gated approach that reduces risk by iterating the waterfall process. There can be as many gates or iterations as required by the project. (Note there are other project methods not discussed here.)Typically a phased approach will focus on completing specific work packages within a phase. Projects are likely to take less time than with a waterfall. One possible disadvantage is dependencies (risks) on earlier phases that might not have been foreseen.
Fig 3 – Iterating reduces cycle time but can overlook dependencies
Rapid Prototyping Minimises Risk
Figure 4 shows one variant on rapid prototyping that the author has used in eLearning to speed development and reduce risk to a minimum. It goes beyond phased iterations to introduce some Agile aspects of development but is more correctly a form of rapid prototyping.
Fig 4 – A rapid-prototyping process
A key aspect shown in Figure 4 is scope elaboration to develop a working architecture using templates and objects. What this means is that we develop a working shell of the course with branding, navigation and placeholders for content. It’s a bit like a wireframe but interactive and more complete. It’s something the customer can relate to and provide feedback, removing risks at an early stage.
After the customer has approved this design model, what is left is to replace the placeholders with actual content.
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. This is an area of confusion in many organizations.
In this rapid approach there are several iterations in each phase and the phases are time boxed to control the schedule.
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.
Task Management
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 for every task can be based on semi-weekly or weekly estimates of effort required to complete versus the budgeted effort to complete.
Ask 1-2 times a week, “What is your estimate to complete at this moment?”
This method of reporting should be used only at a granular level for individual tasks and not for the overall project. 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. The variance can also be tracked over multiple projects, as a performance indicator in the development group.
Simple Task Status Report
|
||
Work
to Date
|
Days
|
|
Actual work in days to current date
|
A:
|
5
|
Estimated days to complete phase
|
B:
|
4
|
Total estimated days to complete phase
|
C= A + B
|
9
|
Budgeted days for this phase
|
D:
|
7
|
Variance (positive is bad!)
|
= C - D
|
2
|
Percentage complete
|
A/C
|
5/9
|
Integrated Development Environment
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. This we don’t have.
When scanning the market for the current set of tools they are still centred on converting PowerPoints and, until recently, creating Flash. Flash is now being replaced by HTML5.
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 (MobiOne) and objects, the author developed a smartphone app for both iPhone and Android in less than a week. Design, develop, test and deploy were fully integrated. To get your head round this, think about how you insert a table in Microsoft Word. Now imagine this as an object in the left pane that you simply drag and drop to a position on the screen.
However, even without good IDEs we can still make advances through rapid prototyping with small cross-discipline teams.
