Given my project specifications, how should I build my framework?

Hi Joseph,

IMHO, you may want to consider separate courses. As sexy and slick as 8 customized paths of content within a single course sounds, living with such a decision can be a different story...

• What happens when you have to update just one of the paths? Do you republish the entire course?
• What happens when job descriptions/roles change in the company? Do you scrap the whole course and start over?

One thing we did, is create the common front-end module as an "intro" or "fundamentals" module that everyone took. Then created distinct modules by role for the specialized training. Your LMS should be able to handle this kind of set up through a learning plan/job role sort of functionality.

That way you can easily change/update courseware as needed and provide each learner with exactly what they need... and nothing else they don't.

Hope this helps,

Bob

Bob, thanks for your input!

Updating content on the course(s) would require republishing each time, and that is a problem we know will come as the subject matter will be changing slightly every 6 months or so. It wouldn't matter much if it were one course or separate courses, as they all share similar content so we would be making changes to more than one slide either way.

As far as roles and responsibilities changing go, we haven't thought about that ahead of time but the roles pertaining to this project are pretty concrete and have been like that for decades. Not to say it wouldn't change, but I'm not to worried about it. 

I can see what you mean, but I'm still weighing which would be better. One large project would be a headache to initially create, but in 8 separate courses with similar content, I would later need to republish 8 different courses for revisions. Wouldn't maintaining 8 different courses be a bigger headache? Given how you did your course, did your "distinct modules" share any common slides with each other? How similar is it to what I am trying to achieve? 

You are helping greatly,

Joe 

We culled out the info that was truly baseline and common for all roles.

Next we identified the info that was a bit more advanced but still common to most/all roles.

Finally we confirmed that the remaining info was truly unique to a single/few roles.

This process above is the key. Once you've done that, then you can look at your options.

For example, if you find that the majority of what you have is common to all all roles, and only a fraction is role-specific, you may choose to go one way. Conversely, if there is only a small amount that's common but it was all basic info (our case), you may choose to house that in an "intro" or "fundamentals" module. You get the idea.

Our final solution was a bit blended....

• "Basics" module with all common info
• 5+ "Core" modules that were role specific and contained a repeatable format with some common info and some role-specific
• 12+ "Advanced" modules that were completely role specific and scenario driven with role-specific scenarios the learners would work through based on the previous two modules and additional role-specific info.

Finally, also remember that if you identify a topic that is really arcane and uncommon for a unique role, consider NOT including it in the course at all. Instead include it as supplemental info/material so that it's there if needed for the rare situation, but not clogging up your learning for "just in case" inclusion.

And yes, with separate modules, we did indeed have to maintain them separately. But in our case, we found that the majority of the volatile info was role-specific. The "basics" were pretty evergreen. So the decision to structure as we did made sense.

Hope this helps,

Bob

Great Bob, that was some very helpful advice. Thank you.

Joe