Publish and Deliver eLearning Projects

5 steps to successfully get your eLearning course across the finish line

ULTIMATE GUIDE TO ELEARNING DEVELOPMENT

Bonus 1: eLearning Development Calculator
Bonus 2: eLearning Best Practices Pro Tips

You’ve come a long way in your eLearning project and are nearing completion. Take a moment to pat yourself on the back and appreciate all the hard work you’ve put into your program so far. Now it’s time to get it done and get it delivered!

In this section, we’ll take a look at this final project stage, and — heads up! — help you understand why it’s one of the most critical (and rarely discussed) stages in the entire project process.

Here, we’ll cover the stakeholder review and revision process, your final quality assurance (QA) review, publishing and testing the file for your LMS, and file delivery. Let’s get started on getting this project D-O-N-E!

1: Let the Stakeholders Have At It

Most every time you are developing an elearning project, you will be doing so at the request and sponsorship of stakeholders, and these people (and, possibly, departments) need a chance to review the product they’ve arranged for.

Typically, several rounds of review and subsequent revisions will be planned for in the early project discussion and planning stages. Think of these as script draft, first draft, second draft, and final draft reviews, for example, with each subsequent draft delivering a program that’s closer to completion.

There are several positive benefits that come from this process, including:

Stakeholder input helps you create a better program.
More “eyes” on your project means more issues are likely to be detected.
Suggested changes often result in improved content delivery.
Subject matter expert stakeholders can detect content-related issues that you as a developer cannot.
The period during which your program is “out for review” may give you a small, but welcome, break from the project. (Enjoy!)

Not all review rounds turn around as quickly as planned, however, due to different stakeholder personalities, time availability, and interest levels. Instead of becoming frustrated with a review process that’s not proceeding as expected, we remind ourselves of the positive benefits and remember that, like raising a child, an elearning project takes a village.

That said, if you see your project going too far off plan due to stakeholder review rounds, gently ask your key contact if they are OK with the date of final delivery being changed as a result of the slowdown. That will often be the only nudge needed to get things back on track. Communication, as always, is key.

And there’s one final thing to keep in mind regarding stakeholder revisions: There is no need to take them personally! We’ve all been there, and it’s frustrating to receive a request to change something you’re proud of or to revise something that took a long time to create. Blow off a little steam, gripe a bit, and then get back to work on creating the best program possible. You’ve got this!

2: Find Someone with Fresh Eyes

It’s safe to assume that by the time a developer nears completion of an elearning project and stakeholders have reviewed several times, everyone involved is mostly blind to the on-slide details. That means it’s smart to have someone with “fresh eyes,” who has not seen the project before take a look at the final project.

Line up this person (bribing as needed!) and ask them to look out for anything that seems to them to be amiss. Typical gremlins to ask them to watch for include: word misspellings and other typos, missing or incorrect punctuation, slides that cut off too soon or run too long, unexpected slide behaviors, incorrect answers on quiz questions (that is, the correct answer is not credited properly), mistimings, and broken links and attachments.

Once you’ve received their input, go into the program and fix each issue. Do this with full concentration even though it seems like a no-brainer task. At this point, you don’t want to introduce new problems!

3: Complete the Final Steps

After the stakeholder revisions are done and the fresh eyes issues are addressed, you are ready to move into the final phase of the project. It’s easy to be in a bit of a rush at this stage, but this is a great time to reduce distractions and bring your full attention to the steps at hand. See it as your last chance to get everything right, so the project won’t come boomeranging back after delivery with some little issue you overlooked.

Here are the suggested steps to follow:

Confirm the correct publishing specifications for your/your client’s learning management system (LMS). These will typically be SCORM, reading something like: “SCORM 2004, 3rd edition.”
Confirm the method for tracking viewer completion. Examples include tracking on the number of slides viewed or on achieving a certain quiz score.
From within the authoring tool, publish the file for LMS to the correct specifications.
Zip the resulting folder.
Upload the zipped folder to SCORM Cloud (if needed, sign up for a free account that offers limited access sufficient for testing all but the largest of projects; if you have access to a different LMS, this testing can be performed there instead).
View the project as though you are new to it, noting any issues you see along the way.

If there are things that must be fixed before you’re ready to call the project ready for delivery, make careful corrections and repeat steps 3 – 6 above. You’ll know that the project is ready to deliver when you view the published file, detect no issues, and receive the score/pass-fail you expect.

4: Get the Delivery Done

Depending on the nature of your job, you may be delivering your project to an external client, to an internal client, or uploading it directly to an LMS.

If delivering directly to an external or internal client, you will likely have a procedure for what files are passed along from you to them. These can include the following:

The zipped published file, ready for loading onto their LMS.
The production file, in the authoring tool format.
Any external files that must be attached to the production file before publishing.
The complete script that matches the program.
Any other files that are expected by the client.

Graphics and audio files that are embedded in the program will travel automatically with the production file, but you may need to package these and deliver them separately, too.

(Important note: It is not possible to edit an elearning program using the file published for LMS. Only the production file (that is, the Storyline, Captivate, or other authoring tool source file) can be employed to make changes in the program. Delivering the production file to the client means that they will have the file they need to make changes in the future should they be unable to come back to you for that work.)

If you’re in charge of uploading the program to an LMS, that should be an easy step, following a procedure that fits with your LMS. We suggest that before releasing the program to its entire intended audience, you may wish to assign a number of beta test users (usually members of the program’s intended audience) to complete their viewing early. They can help you confirm that everything is working as expected and reporting correctly.

5: Set Up for Easy Relaunch

With all of your deliveries completed, be sure to return to the files you used to build the project to get them organized and secured. First, place the final versions of the list given above in a location where they will not be lost and clearly designate them as the jumping off point for any future work on the same project. Next, archive all past versions of the program, scripts, and graphics, so these will not be mistakenly used in the future. For the few minutes of organizing you spend today, you will thank yourself later, guaranteed!

In Conclusion

And that’s it, your elearning project is now complete! We hope that this guide has helped you move through the typical steps, phases, and challenges of building a successful elearning project. Got something to add? Let us know!

What is a learning management system (LMS)?

A learning management system, usually referred to by the acronym “LMS,” is a web-based software application. An LMS is specifically designed to host elearning programs and to allow tracking of learner interactions with those programs. Most LMSs use a software protocol referred to as “SCORM” (which stands for “Sharable Content Object Reference Model,” but you don’t need to worry about that, everyone just says “SCORM”). It sounds very technical, but SCORM’s role is to complete the handshake between your published elearning program and the LMS on which you host it. There are many different LMS providers and specifications vary. Be sure to learn all you can about the LMS your program will be delivered on.

How do I host an elearning program on my website?

If you don’t care about tracking how your viewers do in a course, it’s actually pretty simple. When you’re using a popular authoring tool like Articulate Storyline or Adobe Captivate, you’ll have an option to publish to/for the web. At that point, your course is really just just a self-contained set of .html pages grouped in a single folder. Once you’ve uploaded the published folder to your website, you can grab a link to the program’s launch file, and share that link with your viewers. (It’s not difficult, but there’s a small learning curve at first. Plan a little extra process and testing time your first couple times through.) Depending on your web hosting platform, you may be uploading directly via your content management system (or “CMS,” such as WordPress) via a plugin, or you may use an FTP (file-transfer protocol).

What is the best way to deliver large files to my client?

Elearning file sizes are often large, so you will likely not be able to deliver by attaching the files to an email. Instead, for course development and final published files, delivery via cloud storage such as Dropbox, Google Drive, or OneDrive works well. Note, though, that these file systems do not allow published courses to play from within their systems. As such, to deliver a published project for client review, you must do one of the following: Post the project to your own website and share a link, send a zipped version of the published course via email or cloud-drive link, use a review site such as the Articulate review portal from within Storyline, or set up an Amazon Web Services platform.

How can I test my SCORM published program?

You can (and should) test your SCORM-published program before calling it finally complete and delivering it to your client or LMS manager. If you have access to an LMS, test the program there in a non-public, “sandbox” environment. If you do not have access to an LMS, SCORM Cloud offers free basic-level access to their LMS environment. Upload your zipped, SCORM-published program to your library there, and view, test, and troubleshoot until the program is working 100% as you would expect.