eLearning course development… how do you do it?
Creating anything is an exercise in balancing ideals with realities, or ambition with available resources. We should know that, as we used the same introductory statement for the first post in this series and didn’t have the resources to update it for this one.
In the previous post we discussed how e-learning course creators can plan and manage their costs (or budget, if you prefer the fancier term).
However, cost itself, is just one element of the cost-size-time triad, and when one changes, the other two change as well (e.g. wanting your e-learning service to be deployed faster (time) makes it more costly (cost) or scales down what you can offer (size)).
Size, by the way, is frequently called “scope” when discussing such matters, which is the terminology we’ll adopt from now on.
Scope
Scope is a fancy word to describe what you want (and/or can) include in what you’re building. As we’re talking about e-learning course creation, the thing we’re building would be an e-learning service or a particular e-learning course.
As we already hinted at (and as anybody who ever tried to built something painfully learned), scope is affected by available time and money.
The same way you can’t build a skyscraper with the budget for a cottage you also can’t build a top-tier web service without top-tier funding (of course modern technology, like a good LMS platform and affordable cloud hosting levels the playing field, but only up to a point).
Managing scope is all about good planning and knowing your limitations (especially the limitations in your budget and available time).
The most important part is having in advance a pretty good idea of what you want to build. Nothing throws estimations off as much as unexpected changes in requirements and direction, while you’re already building your project.
So much that there’s even a special term for it:
“It is generally considered harmful” is, of course, an understatement.
Scope creep has killed more projects that perhaps all other reasons, and there are even several development methodologies, in software and web development, attempting to deal with it.
Plan ahead
The first step in defining your scope is to have everything you want to deliver written down, along with a time and cost estimate. It doesn’t matter if you don’t get it right in the first draft — you can iterate until you’re happy.
The point is not to describe the final result with 100% detail, but to avoid sudden changes that affect large parts of your initial design.
When determining your project’s scope you have to know the associated time and monetary costs for each feature you add.
You also have to keep in mind that your initial estimates will be somewhat off.
Programmers, for example, are notorious for under-estimating the time it takes to program a feature, but the same thing can (and will) happen with any other item you try to estimate (like when a course’s text will be ready).
If this is your first foray into creating an e-learning service, add some “padding” to every date and cost you write down, so that you’re somewhat covered for sudden change or delays.
Experience will help you get better at your estimations, but even experienced project managers get things wrong all the time.
Adapt to change
It doesn’t matter what your original plans were.
If you find that you can’t accommodate for a feature, due to budget or time constraints, then your best bet is to scale down. You can always add it in a later revision of your e-learning service.
Insisting on a feature that takes too much time or money to develop just because it was on the original plans or because “we’ve already invested a lot of money into implementing this” can easily lead to more delays and general disaster.
This behavior has even its own name in economics, were it’s known as the “sunk costs fallacy“.
Prioritize
Knowing when and what to scale down is all about prioritization.
Some things are necessary for a fully functional e-learning deployment, others are secondary or luxuries.
You already have a list with all the features you want along with cost and time estimates (and if you don’t, make one now). To it, add another column: priority.
Items with low priority and higher time or monetary costs are the first candidates to go when scaling back.
There’s a rule of thumb in project planning (one that originates from economics) called the Pareto principle or the 80/20 rule.
The gist of it is that you can cover 80% of your use cases with 20% of the features (think of how you never use more than a few dozen of the thousands of features Microsoft Word has).
Of course you still need to know which features belong to that 20%, but the takeaway point here is that you probably need less features than you think you need, to keep your users happy.
There’s another useful notion in economics that also applies to project planning, called “opportunity cost“.
This is about how, when you have limited resources and you have to make a choice among several alternatives, everything you add means you don’t get to add something else. Or, as the dictionary puts it, “opportunity cost” is “the loss of potential gain from other alternatives when one alternative is chosen”.
Thus far, we’ve briefly covered managing cost and scope in this series of posts. Stay tuned for our next and final installment about managing time.
Do you have something to add from your experience?
Let me know in the comments below.
