Six Modules in 30 Days! + Recommendations
Any instructional designer worth their salt knows that creating six standalone modules in thirty days can be a challenge. If you’re new to eLearning development, here is a huge tip: What makes this challenging is squeezing in 2-3 review cycles for SMEs and stakeholders who tend to be very busy people.
With so many employees working from home indefinitely, we know many training departments are rushing to create online programs at lightspeed. Recently, we helped a manufacturing client’s marketing team offer product training to associates at a national retailer, also at lightspeed.
Creating six interactive elearning modules in one month was a challenge in itself. Factor in that they needed to also be marketing-team approved for an external-facing audience just made the project that much more daunting. Now that we have had some time to rest and recover, we have some recommendations for others who are gearing up for short project timelines.
1. Confirm stakeholder commitment.
Do not attempt this if your Subject Matter Experts and other stakeholders are not 100% committed to meeting their review deadlines and providing clear and actionable feedback. Do not pass go. Do not collect $200 dollars. Turn back while you still can.
In this case, we have been working with this particular client for over three years, and we still offered the standard disclaimer on compressed timelines before accepting the project. We set expectations about what we expected from their team before we even committed to completing the project!
Be clear about what you need from stakeholders and SMEs, and when you are going to need it. It’s ok to let them know that it will take time and effort, and it may feel challenging due to the urgency of the timeline. They need to know what they are signing up for and what exactly they should be doing to make the project successful from the start.
2. Be prepared for global changes.
There are some people that estimate the timeline for multiple-module courses by multiplying the time for one module by the number of modules. We don’t agree with this method, especially when operating in a compressed timeline situation. We always plan for additional time for global updates. (You know, that thing where someone requests a change to module 6, and modules 1-5 also have to be updated for consistency?) Yeah, it happened to us! It happens often, and it’s usually ok as long as you plan for it.
On a rapid development timeline, not all edits will be requested in the first round of review before the whole set comes together, and this means you need to be prepared for global changes during the crunch time. Schedule an additional round of edits for all modules at the end, and plan for this from the start.
3. Test your prototype early in the LMS.
If you’re not familiar with the deployment system, are using the latest version of a tool, or plan to include custom features, be sure to test your prototype/proof of concept early on in the system. You want to ensure that the navigation, tracking, resume functionality, and exit instructions all function as intended. Tip: this is a good practice anytime you introduce new variables into your process. More on why it’s important to test from a hosted location and basic testing steps here.
In our project, the modules were deployed in the client’s new LMS, and they launched from a heavily customized external-facing launch page. The typical upload settings didn’t work as intended, but we were able to catch this and adjust before it caused problems. Because everything was tested thoroughly.
4. Anticipate authoring tool bugs.
This isn’t our first time writing about this topic, and it probably won’t be the last. Today’s authoring tools are constantly offering new features and updates, and there will always be bugs. No tool is immune. In our most recent case, we ran into this big time. We had some issues with closed captioning and navigation that we had to solve for. In the end it was fine, but that’s because we expect this, test for it, and accept the reality of the authoring tool ecosystem. That last part just helps with stress level. Instead of fighting reality, we proactively plan for it.
One thing you can do on a compressed development timeline is to focus your innovation around your content, instead of getting fancy with your tools. A four-week project may not be the best time to use things like custom navigation, advanced logic, or the latest features. We aren’t saying you can’t or shouldn’t. Just weigh the pros and cons to make sure it’s worth it, and plan for extensive testing.
It was tough to keep this list to only four items, but these were the ones that stood out the most based on recent experience. We hope it's helpful!
