How to write a specification for selecting an LMS

The selection of a learning management system (LMS) usually fails not because of technology, but because of vaguely defined expectations. A carefully prepared assignment will unify the language between your team and suppliers, bring comparable offers, and significantly shorten the subsequent implementation. 

This article will introduce you to selected areas of the tendering process: from defining objectives and users, through content and functionality, integration and security, to evaluation criteria.

Tip:If you are already considering specific platforms, we recommend that you first formulate your "must-have" requirements internally and only then begin negotiations with suppliers. This will help you avoid distractions caused by discussions about features that are not essential to your needs.

When to start the assignment and why it matters

It makes sense to create the assignment when you know at least the general outline of the project and have a basic overview of the market. This is absolutely crucial when creating a public tender. Properly written tender documentation serves as a reference point for all parties involved: your internal team and potential suppliers. The more precisely you describe the context and expectations, the more realistic and comparable bids you will receive. 

Context and objectives: set measurable results

The introduction to the tender documentation should explain in a few paragraphs who you are, why you are implementing or changing the LMS, and what results you expect. Avoid general formulations and prefer measurable indicators: for example, "reduce the time to complete mandatory training for new employees from 30 to 21 days within six months of implementing the LMS" or "increase the annual completion rate of mandatory training from 85% to 95%." You can then translate these goals into evaluation criteria, scenarios, and acceptance tests.

Tip:Include negative goals in the assignment – i.e., what the system does not have to do, does not have, or is directly undesirable. This will prevent unwanted customizations or scope creep on the part of potential suppliers.

Users, roles, and growth: impacts on licensing and performance

Many cloud or boxed solutions have a pricing model based on the number of licenses (i.e., users in the system). Suppliers need to know how many users will be active in the system, what their roles will be (student, lecturer, administrator, manager, auditor), and how you expect the number of users to evolve over the next 12–24 months. It is not just a matter of the number of users (and therefore the number of licenses), but also the server load and thus the costs of its performance. If you anticipate seasonal peaks—for example, for mandatory or product training—include this in the tender documentation so that the supplier can include the actual costs of operating the infrastructure.

Real-life example:A retail chain planned to launch mandatory OHS training for 7,000 employees within two weeks. Because it clearly described the peak in the tender documentation, the supplier proposed a temporary increase in performance and prevented outages and queues in the system. Subsequently, server traffic was lighter, and operating costs could be clearly defined in advance.

Tip:Ask the supplier to demonstrate how to work with the system in a demo/preview. Many shortcomings will become apparent immediately.

Content and standards: consider analytics

Describe what content you will be running in the LMS: whether it will be courses in SCORM 1.2/2004, xAPI/cmi5 standards, or videos, PDFs, or webinars. Specify which authoring tools you use and what the publishing workflow will look like. If you are planning more detailed analytics (e.g., tracking educational activities outside the LMS), consider requesting an LRS (Learning Record Store). 

Tip: Consider whether you require export and import tools, sample migrations, and data field overviews. If so, be sure to mention this information in the Assignment to avoid manual data "flip-flopping" or vendor lock-in in the future.

Functional requirements: scenarios are more valuable than lists

Instead of long "yes/no" tables, we recommend describing several representative scenarios that reflect your real needs. For example: "A new employee at the Brno branch is automatically assigned to an onboarding path based on their job position and language; their manager receives a weekly performance overview, and HR receives a monthly aggregate report." Only then should you follow up with a structure of functions (tests, certificates, learning paths, content recommendations, gamification, notifications, course catalog, library, skills and competencies, dashboards, report content). Use examples to describe what users will be working with the system and how. This will give the supplier a better understanding of the process, priorities, and planned use of the system, enabling them to propose a relevant configuration. 

Real-life example:In shared center services, it was enough to define three well-described scenarios to eliminate one of the original favorites—it was unable to provide regular and clear reporting to managers without additional development.

Integration: describe data flows and responsibilities

Integration should not just be a list of logos. Specify which systems you use (HRIS/ERP, Microsoft 365 or Google Workspace, webinar tool, etc.) and which system will be the "source of truth" for user data (will it be your CRM or future LMS?), clearly describe the organizational structure, roles, and permissions in the system. Describing data processes—who creates users, who manages and assigns roles, who plans webinars, and where results are stored—will prevent misunderstandings during implementation. 

Security and compliance: define the minimum without compromise

Formulate security requirements specifically: what certifications do you require (e.g., ISO 27001), how will data encryption "at rest" and "in transit" be handled, how long should audit records be kept, and what will the contractual arrangement for personal data processing look like? For international projects, specify where the data should be stored (e.g., in the EU). Clearly defined minimum requirements will significantly speed up the legal and security assessment after the supplier has been selected.

Real-life example: In financial services, the selection process for an LMS supplier was delayed by several weeks due to requirements for audit logs. The assignment included "logging records for future needs," but it was not clearly defined what should be logged, why, in what form, where, or for how long.

Accessibility and localization

Accessibility is not an add-on, but a necessity. Specify that the user interface must comply with WCAG 2.2. Specify language versions and requirements for localization or system branding – do you want your own colors, logo, or typography? How often will the system's appearance change? Will that even be possible? Such information helps to estimate the scope of work in advance and prevent "quick" fixes later on.

Operating model and SLA: cloud vs. on-premise and support expectations

Deciding between cloud and on-premise is based on security, integration, and operational requirements. The cloud usually wins in terms of deployment speed and lower burden on internal IT, while on-premise has its place where strong isolation and detailed control of the environment are required.  Define the expected availability, response and repair times for support, backup plan, and recovery tests in the assignment. A clearly formulated SLA is the best prevention against disappointment.

Migration and implementation: plan realistically and step by step

Migrating existing data is often the most challenging part of the project. Should the new solution allow for the migration of existing/archived data? To what extent? Where is it stored? In what format can you deliver historical data? Describe the scope and sources of data (users, results, certificates, courses), mapping rules, and expected data cleansing.
For implementation, define roles on both sides, a training plan for administrators and instructors, and an acceptance procedure. Request a test environment in advance so that scenarios can be verified on an ongoing basis.

Real-world example: An organization with a legacy LMS transferred only ongoing certifications and mandatory records to the new system, while leaving archival data in the old LMS, which was locked to regular users. The LMS delivery became cheaper and the implementation of the solution was shortened by almost a month.

Evaluation criteria and matrix: how to compare offers fairly

To compare suppliers' offers, standardize the criteria and their weights. In practice, it has proven effective to give the greatest weight to functional requirements and integrations, to assess accessibility and security separately, and to transparently evaluate the total costs over a 12-36 month period. Also consider references – the supplier's experience in similar environments is often key to a smooth implementation process. 

Tip: As part of the tender, ask bidders to provide a table summarizing the fulfillment of your requirements with the options offered by the LMS (fulfilled / partially fulfilled / not fulfilled + comment) – in the case of "boxed solutions," ask for a controlled demonstration according to your scenarios. This will give you a more objective basis for scoring.

Pricing models and cost of ownership: look beyond the first year

The price of an LMS is not just about the number of users. Distinguish whether licensing is based on total or active users, and how "activity" is defined (monthly, quarterly). Specify which modules you consider mandatory and which may be optional. For implementation and modifications, get a clear description of what the fixed items are and what the expected items are that may increase during implementation or subsequent operation. Assess costs over a longer period, as integration, ongoing modifications, training, and development are also included in the costs.

Common mistakes and how to avoid them

The most common mistakes include missing measurable goals, unclear division of "must-have" and "nice-to-have" requirements, and underestimated integration and migration. Another risk is focusing on the purchase price without considering subsequent operating costs. Most of these issues can be addressed during the creation of the assignment and reflected in the evaluation criteria or service contracts.

Don't want to do it alone?

Not sure where to start? Get in touch. We will analyze your needs, prepare clear specifications together, and help you choose an LMS that fits your goals and budget.