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
|
|
