You want to turn an onboarding programme, product training or compliance course into e-learning. Then you want to know what it costs, how much work your own team will have, and what exactly you will receive at the end.
A usable budget starts with three choices: what should participants be able to do, what material is already available, and how will the training work in your learning environment? Those choices determine the development work and the costs after delivery.
In this guide you will read how to scope an assignment, compare quotes, and verify that the e-learning is ready for use.
What exactly are you having built
E-learning can be broken down into three components:
- Learning content: learning objectives, explanations, practical examples, assignments and test questions.
- Digital module: screen design, interactions, visuals, audio and the technical build.
- Learning environment: access, enrolments, progress, reports and possibly certificates.
Those components can be part of one assignment, but they do not have to be. A quote for a module does not automatically include setting up Moodle or an integration with your HR system.
Already have a learning environment? Then have the vendor establish upfront how the new content will be offered in it and which results need to be recorded. That way you compare quotes on the same assumptions.
What does e-learning development cost
Costs depend on the work that is required. The length of a module helps to discuss scope, but is not enough to set a price. A short simulation with multiple decision paths can take more development work than a longer module with explanations and practice questions.
Ask for a budget in which these components are visible:
- Content and didactics: how much material still needs to be written, checked or reworked?
- Design and production: does an existing template suffice, or are custom interactions, illustrations and videos needed?
- Review and testing: how many feedback rounds are included and who tests what?
- Technical setup: which settings or integrations are needed for progress, assessment and reporting?
- Handover and maintenance: what is delivered and who can make changes later?
A worked example for your budget
Suppose you have one Dutch-language module developed based on existing, content-approved material. You use an existing design, record no video, and agree on two bundled feedback rounds.
The example below uses fictional hours and a fictional rate. It is not a market average or a quote from Ldesign Media.
- Intake and learning objectives: 6 hours
- Structure and script: 16 hours
- Design and build: 24 hours
- Review and processing: 10 hours
- Testing in the LMS and handover: 8 hours
- Project coordination: 6 hours
- Total: 70 hours
At a calculation rate of €100 per hour, you arrive at €7,000 excluding VAT. Platform costs, licenses, translations and later updates fall outside this example.
The value of this calculation is in the breakdown. If your source material still needs to be written, the budget changes. If a template is reusable for ten modules, the design work can be distributed differently. So always ask which assumptions sit behind the number.
Also reserve time from your own subject-matter experts. Their content review, feedback and participation in the pilot are part of the real investment.
Start with a task participants must be able to perform
"Employees know our privacy policy" gives a developer little direction. "Employees recognize a possible data breach and know where to report it" makes clear which explanation, practice and testing are needed.
Take an onboarding module for a service desk, for example. After finishing, participants must be able to classify a customer question, find the right information and know when to escalate. You can use recognizable customer questions for that and let participants choose what they would do, with feedback on their choice.
For each learning objective, determine how you assess whether it has been achieved. A completion record shows that someone has finished an activity. For application on the work floor, a practical assignment or observation may be needed in addition.
Agree on the process and decision points
A workable approach consists of six steps:
- Scoping. Fix the target audience, learning objectives, source material, languages and technical requirements.
- Developing the content. Have subject-matter experts approve the script and structure.
- Building a prototype. Assess a representative part on content, design, operation and behaviour in the LMS.
- Building the module. Work out the approved approach and collect feedback through one point of contact.
- Running a pilot. Let participants from the target audience go through the training and check the recorded results.
- Delivery and handover. Deliver the agreed files, access and management instructions.
Ask for a schedule with feedback deadlines for both parties. A generic promise like "done within six weeks" says little when the availability of subject-matter experts and the delivery of source material are still unknown.
Also record when a change falls outside the assignment. A content correction during an agreed review round is something different from an extra language or a new scenario.
Choose a solution your team can maintain
The choice of tool determines how you can adapt the content later. So show during selection already who will do the management.
- Activities directly in Moodle: can fit when you want to manage explanations, assignments and assessment inside Moodle. Establish upfront which roles may make changes and how the course is handed over.
- H5P in Moodle: can fit when you want to use interactive exercises inside your learning environment. Establish upfront which content types are needed and how editing, results and accessibility work.
- An external authoring tool: can fit when you want to develop modules outside the LMS and deliver them as a package. Establish upfront who gets access to the editable project and which licenses remain necessary.
- Custom development: can fit when a specific simulation or interaction cannot be realized well with existing tools. Establish upfront who maintains code and content and how future changes are carried out.
Moodle supports H5P activities and adding content from the content bank. The precise assessment options depend on the activity and settings. [1]
At handover, ask for a practical demonstration: can your administrator independently adjust a text, replace a question and publish the changed version? That turns "maintainable in-house" into a testable agreement.
Make agreements about SCORM and xAPI
An export format must connect to the learning environment and the desired registration.
For the standard SCORM activity in Moodle, SCORM 1.2 is the supported version. Moodle does not fully support SCORM 2004 as a native solution. So have a vendor record the required version and test a trial package in your own environment. [2]
xAPI is a standard for exchanging data about learning activities. That data is stored in a Learning Record Store, or LRS. [3] The mention of "xAPI" on a quote therefore does not yet tell you how the content is launched, how participants are recognized or which reports become available. Agree on that separately.
Above all, ask which information you need: an end result, individual attempts, answers to questions or events from multiple systems. Let the technical choice connect to that.
Build accessibility into design and acceptance
Think from the start about keyboard operation, readable contrasts, subtitles and understandable instructions. Also assess whether participants can complete an exercise without exclusively dragging, recognizing colour or hearing sound.
For government bodies, legal accessibility obligations apply. That also covers public-law institutions that meet the legal definition; "semi-public" is not a sufficiently precise demarcation for that. Which obligations apply to your organization and application must be established upfront. [4]
Record the intended standard, version, level and test scope. A tool choice by itself is no guarantee of accessible end content. H5P, for example, refers to an accessibility overview per content type. [5] The chosen texts, media and configuration must also be assessed.
Test the whole journey at handover
A module can work well in the vendor's preview and still produce different results in your learning environment. So include the situations below in the acceptance test.
- Starting as a participant: the right target audience gets access with the right permissions.
- Interrupting and resuming: the module resumes according to the agreed behaviour.
- Passing and failing: score and status are processed correctly.
- Doing a resit: attempts and the valid score follow your policy.
- Viewing the report: the recorded data matches what the participant did.
- Receiving a certificate: where applicable, it is only issued under the agreed conditions.
- Mobile and accessible use: the agreed devices and forms of operation work.
- Updating content: the update has the agreed effect on existing progress and results.
Make explicit what "completed" and "passed" mean. Someone can have viewed all parts and still score insufficiently on the test. Those situations must be properly distinguished in the setup and reporting.
Avoid dependency after delivery
A playable package is not automatically the editable source project. So agree which project files, account access, usage rights and instructions are handed over. Also check the rights to images, music, fonts and other purchased components.
In addition, appoint a content owner. Record when the training is reviewed and what happens when policies or work processes change. With updates, also discuss what participants must do: only view the change, retest, or follow the entire training again.
That makes maintenance a planned part of the training.
Build it yourself or outsource
Developing in-house can fit when your team has time, masters the content and has the necessary didactic and technical knowledge available. For more complex scenarios, a lot of media or specialist requirements, you can buy in that expertise in a targeted way.
You can also divide the work. For example, have a specialist work out the design and the first module, and teach your team how to make the next modules. Then agree upfront which parts are reusable and which support is included in the handover.
Make your first conversation concrete
Take an example of your source material to a vendor, together with your target audience, desired learning outcome, deadline and existing learning environment. Add who will approve the content and who will maintain the module later.
At Ldesign Media we help organizations with custom Moodle development, integrations and technical setup. Want to know what your e-learning requires from Moodle, the assessment or the reports? Look at our LMS development service or contact us with your assumptions and an example of your material. Then we can discuss which technical approach fits your situation.
