How long does it take to build an eLearning course?

Who this answer is for

This answer is written for the person who has to put a date in a plan and then defend it: an L&D lead asked “can we have this by the end of the quarter”, an agency producer scoping a fixed-price statement of work, a compliance or operations manager whose deadline is set by a regulation or an equipment installation, or a product enablement lead shipping role-based training before a release.

All four have the same underlying problem. They are asked for one number, and the honest answer has two parts: how much work the course contains, and how long that work will take to move through their organisation. Those are different questions, and they are routinely conflated. As a matter of professional judgment rather than measured finding, that conflation is a frequent reason eLearning projects are reported as late when the production team never fell behind.

Why the answer changes by context

Five conditions move an eLearning timeline more than anything else. Only two of them are about building.

• Course complexity. A linear knowledge module with text, images and multiple-choice checks is a fundamentally different build from a branching scenario or a software simulation with recorded steps, custom illustration and voiceover.
• Source-material condition. Whether the content already exists in an approved, current, structured form, or has to be elicited from people’s heads. In our professional judgment this is among the largest hidden cost drivers on a course build, and it is routinely left out of a quote.
• Review latency. Not how many reviewers you have, but how many working days pass between you sending a deliverable and receiving one consolidated, reconciled set of feedback.
• Approval structure. One named approver behaves completely differently from a committee of six with no consolidator, and a legal or regulatory sign-off gate behaves differently again.
• Standards obligations. Accessibility conformance, localisation, and LMS packaging requirements each add real work, and they add more of it when retrofitted than when designed in. The model below carries all three as explicit factors rather than leaving them as good intentions.

A useful estimate has to take those conditions as inputs. A single number that ignores them is a guess dressed as a commitment. If you are working through the wider build question rather than just the date, there are other answers on eLearning build practice that sit alongside this one.

The Two-Clock Estimate

The model below is designed to structure a timeline conversation rather than settle it with one number. It is called the Two-Clock Estimate because it deliberately produces two figures: a production clock measured in effort hours, and a calendar clock measured in elapsed weeks. Every range in it is professional judgment offered as a planning heuristic, not measured industry data. Published development-ratio benchmarks exist and are survey-based; treat them, and the tables below, as starting values to be replaced with your own delivery records as soon as you have any.

One convention runs throughout, and it is the part most estimates get wrong: effort is counted in hours, latency in business days, and elapsed time in calendar weeks. Five business days is one calendar week.

Clock one: production effort

P = M × B × S

Where M is finished minutes of learning, B is base build hours per finished minute for the complexity tier, and S is the source condition multiplier.

These bands cover analysis, design, storyboarding, asset production, development, internal QA and revision cycles — everything except waiting.

Then apply the standards uplifts, which are additive on the base build:

• Accessibility, designed in. Add 5 to 10 per cent. Conformance becomes cheaper when planned from the storyboard, not free: alternative text, caption files, focus order and a keyboard pass on every custom interaction are still production hours.
• Accessibility, retrofitted. Add 10 to 20 per cent instead, and expect rework in visual design as well as code.
• Localisation. Add roughly 15 to 25 per cent of the base build per additional narrated locale.

Clock two: elapsed calendar

W = (P ÷ C) + L × (1 − O) + F

• C — weekly production capacity in effective hours. Use 55 to 70 per cent of nominal hours for anyone who also attends meetings and works on other projects. This adjustment is judgment, but planning at 100 per cent utilisation is the fastest way to a late project.
• L — total review latency in weeks. Sum, across every review gate, the business days from submission to consolidated feedback, plus consolidation and reconciliation time, then divide by five. Add extra days on top for public holidays, shutdown periods and known reviewer absence: those are calendar events and they do not respect business-day arithmetic.
• O — overlap factor. Zero for a single-module course, because there is nothing to build while a deliverable sits in review. Use 0.3 to 0.5 for a multi-module curriculum where module three can be developed while module two is under review.
• F — fixed gates that do not compress if you add people: kickoff and discovery, LMS and technical setup, packaging, pilot and user acceptance testing. Two to five weeks in total for most projects.

Packaging is the line inside F that varies most, and it is worth setting separately rather than absorbing into the lump:

• A single SCORM 2004 package into an LMS your team has published to before: a few days, comfortably inside the two-to-five-week allowance.
• Multiple packages — several modules, several locales, or a SCORM and a non-SCORM variant: add time per package for build, upload and retest, and expect at least one defect that only appears in the target environment.
• An xAPI implementation: add a week or more, because the statement vocabulary has to be agreed with whoever owns the reporting. That agreement is itself a review gate, so it belongs in L as well as F.

Review latency deserves its own planning heuristic, because it is rarely measured:

A typical project has four gates: objectives and outline, storyboard, alpha build, and final. The structural insight the model exists to expose is this, and it is a professional-practice judgment rather than a measured finding: review latency and source condition frequently contribute more elapsed weeks than the build itself. They are also the two variables the client organisation controls almost entirely, and the developer controls almost not at all.

Step by step

1. Fix the seat time. Agree finished minutes before anything else. An open-ended “we’ll see how long it needs to be” makes every downstream number meaningless.
2. Assign the tier. Pick Tier 1, 2 or 3 from the interaction and media the design actually requires, not from the ambition in the kickoff meeting.
3. Audit the source material honestly. Ask to see it before quoting. If most of what you need is in someone’s head, you are in Absent, not Serviceable — and you should plan structured elicitation. A disciplined SME discovery process is what keeps that multiplier from drifting upward mid-project.
4. Name the standards targets. Conformance level, locales, and packaging target are scope decisions, not preferences. Settle them before you compute P, because all three move it.
5. Compute the production clock as a range. Use the low and high ends of B. Never present the midpoint alone.
6. Map the review gates. Name the approver for each. If a gate has no named approver, it has unbounded latency and your estimate is not defensible.
7. Compute the calendar clock and present both numbers. State the assumptions as conditions of the date: this timeline holds if feedback returns within N business days and if the source pack is delivered by date X.

A worked example

The following scenario is hypothetical and constructed to demonstrate the arithmetic. It does not describe a real client or project.

A manufacturer needs a 25-minute onboarding module on a new quality procedure. It requires narration, custom interactions and a scored assessment, so Tier 2. The procedure exists as three conflicting slide decks and a draft SOP, with the real detail held by two line supervisors — Scattered, S = 1.3. The pod is one designer full time and one developer at half time: 1.5 FTE, 60 nominal hours a week, discounted to 55 per cent effective, so C is about 33 hours. Four review gates, feedback handled by a committee of five with no consolidator. Single module, so O = 0. Single SCORM package, one locale, accessibility designed in from the storyboard.

Production clock: 25 × 6 × 1.3 = 195 hours at the low end; 25 × 12 × 1.3 = 390 hours at the high end. Call it 195 to 390 hours, or roughly five to ten person-weeks. The designed-in accessibility uplift is treated as absorbed inside the tier band here rather than added on top — a choice worth stating out loud to the client.

Production weeks: 195 ÷ 33 = 5.9 weeks; 390 ÷ 33 = 11.8 weeks.

Review latency: 12 business days per gate including consolidation, across four gates, is 48 business days — 9.6 calendar weeks.

Fixed gates: 1.5 weeks discovery, 1 week LMS setup and packaging, 1 week pilot — 3.5 weeks.

Calendar clock: 5.9 + 9.6 + 3.5 = 19 weeks at the low end, and 11.8 + 9.6 + 3.5 = 24.9 weeks at the high end. So roughly four and a half to just under six months elapsed, for a project containing one to two and a half person-months of work.

Now change one variable. Replace the committee with a single named approver at four business days plus one day consolidation — five business days per gate, 20 business days across four gates, four calendar weeks of latency instead of 9.6. The band moves from 19 to 25 weeks down to roughly 13.5 to 19.5 weeks. Nothing about the build changed. Five and a half weeks of elapsed time came out of the plan through a governance decision, not a production one. That is the conversation the model is designed to force.

Common mistakes

• Quoting person-weeks as calendar weeks. “About a month of work” becomes a promise of delivery in a month. Always say both numbers in the same sentence.
• Treating review time as free. On many projects it is, in our judgment, among the largest line items in elapsed time, and it is rarely costed at all.
• Scoping before seeing the source material. The difference between Curated and Absent is close to a doubling of effort, sometimes more.
• Assuming more developers compress the schedule. Adding builders shortens P ÷ C. It does nothing to L or F, and on a single-module course those often dominate.
• Skipping the storyboard to “save time”. Approving content at the storyboard stage is cheap; changing narrated, animated, published content is not. The storyboard is the cheapest place to be wrong.
• Deferring accessibility. Retrofitting colour contrast, focus order, captions and alternative text after build costs materially more than designing for conformance from the start, which is why the model carries two different uplifts for the same requirement.
• Estimating a conversion as if it were a build. Converting existing slide material can sit below Tier 1 if it is genuinely a reformat — or above Tier 2 if the deck was never instructionally sound in the first place.

Closing decision table

The model is deliberately transparent so a client can run it themselves and see where their own timeline is being consumed. If you want the estimate produced as part of a scoped plan rather than an internal calculation, that is the front end of our custom eLearning development work.

Sources and review note

Editorial owner: IETERNUS Learning Systems. Last updated: 8 August 2026.

Established fact. Accessibility conformance targets are defined by published standards: the Web Content Accessibility Guidelines 2.2, a W3C Recommendation; Section 508 of the Rehabilitation Act in United States federal procurement; and EN 301 549 in European public procurement. LMS packaging and tracking behaviour is governed by published specifications, principally SCORM 2004 4th Edition from the Advanced Distributed Learning Initiative, and xAPI from the same body. These obligations are real, externally defined, and add scope that must be estimated rather than absorbed.

Professional judgment. Everything in this article that is not one of those published standards is professional judgment offered as a planning heuristic. That covers the numeric ranges — the hours-per-finished-minute tiers, the source condition multipliers, the standards uplifts, the review latency bands, the effective-capacity discount, the overlap factors, the packaging allowances and the fixed-gate durations — and it also covers the structural claims built on them, including the claim that review latency and source condition frequently outweigh build effort in elapsed time, and the claim that source condition is among the largest hidden cost drivers. None of these are measured findings from a study or from IETERNUS delivery records. They are starting values and working assumptions, to be replaced with your own measurements.

Assumption. The worked example assumes a two-person pod at 1.5 FTE, four review gates, a single module, one locale, a single SCORM package, and accessibility designed in. Change any of those and the arithmetic changes. IETERNUS is a new practice and publishes no client metrics, case studies or delivery averages; nothing in this article should be read as a claim about past projects.

Learning topic: eLearning Development