What Decision-Makers Should Prepare Before Issuing an E-Learning RFP
A program lead finally gets the green light for a new learning initiative. The pressure to show momentum is real, so the instinct is to move fast: draft an RFP (Request for Proposal), send it to a shortlist of vendors, and wait for the proposals to land. It feels like progress, and when leadership is watching, visible progress matters. But the RFP often goes out while the team is still working out what the project is meant to fix.
That is where even well-run projects can drift. When a brief leaves room for interpretation, the proposals that come back are hard to compare, and the decision quietly narrows to price and polish. It is rarely a matter of anyone dropping the ball; real discovery takes time that procurement calendars do not always allow. It is just worth naming, because the quality of a learning project is usually shaped long before a vendor is selected.
This is not an argument for slowing down. It is an argument for spending your early energy on clarity instead of paperwork. What follows is less a list of what teams get wrong than the questions we work through with organizations ourselves before an e-learning RFP goes out.
Why Even Well-Run Projects End Up With Mismatched Proposals
When a brief has gaps, and under deadline pressure, most do; vendors fill them with their own assumptions, and those assumptions rarely line up. You end up comparing five proposals that quietly answer five slightly different questions, through no fault of your own.
The symptoms are familiar to anyone who has run procurement for a learning project:
- Proposals that each solve a slightly different problem
- Budgets that balloon once the real scope surfaces mid-project
- Timelines that slip as requirements are discovered rather than stated
- Vendors who look almost identical on paper, forcing a decision on price alone
- A finished product that runs smoothly and changes nothing
None of these are vendor failures, and none of them mean a team dropped the ball. They are simply what happens when a brief carries less clarity than the project needs. The good news is that the brief is the one part of this you can shape entirely before procurement even begins.
What to Prepare Before You Issue the RFP
Preparation does not require a large team or a long delay. It requires answering seven questions honestly before procurement starts.
1. Define the business problem, not the learning request
“We need a course on data protection” is a request. “Staff are mishandling sensitive data, and we have had two near-misses this quarter” is a problem. The first tells a vendor what to build; the second tells them what to solve, and leaves room for a better answer than the one you walked in with. Start from the operational gap, weak sales performance, slow onboarding, a compliance exposure, a program that cannot scale. The training comes later.
2. Identify the performance outcomes you expect
Be specific about what should look different once the program lands. What will learners do that they do not do today? Which organizational number should move, and by roughly how much? If you cannot describe the change in observable terms, no vendor can design toward it, and no one will be able to tell later whether it worked.
3. Understand your learners, honestly
Not job titles but realities. How many people, in which countries, working in which languages? What devices and bandwidth do they genuinely have? How digitally confident are they? A program built for head-office staff on fast laptops will fail in the field, and you want to know that before a vendor proposes a solution, not after.
4. Gather your existing learning assets
Most organizations already own more than they think: current materials, subject-matter experts, brand guidelines, past courses, and internal documentation. Knowing what exists changes both the scope and the price. It is the difference between asking a vendor to build from scratch and asking them to shape what you already have into something that works.
5. Establish your real constraints
Budget, timeline, internal approval cycles, technical limitations, compliance, and data requirements. Naming constraints early is not admitting weakness; it is the information a serious partner needs to design something that survives contact with reality. A constraint named in the brief is a problem solved. A constraint discovered mid-project is a delay.
6. Define success metrics before design begins
Decide upfront how you will measure impact. Completion rates are the easy number, but they tell you who finished, not who changed. Pair them with behavioral indicators and operational KPIs that connect back to the business problem in point one. Metrics defined late tend to flatter the project rather than test it.
7. Build internal alignment
An e-learning project touches HR, L&D, the program teams who own the content, IT, procurement, and the leadership who hold the budget. If those groups are not aligned before the RFP goes out, they will surface their disagreements during the project, where they are far more expensive to resolve. Have the conversation about priorities early, in a room, not later, in a change request.
A Practical Pre-RFP Checklist
Before you publish the RFP, you should be able to answer “yes” to each of these. Anything still marked “not yet” is work to do before procurement, not during it.
- We have defined the business problem, not just the training request.
- We have described the performance change we expect to see.
- We understand our learners’ real context: location, language, devices, connectivity.
- We have inventoried existing content, experts, and brand assets.
- We have named our budget, timeline, and technical constraints.
- We have agreed on how success will be measured.
- Our key stakeholders HR, L&D, IT, procurement, and leadership are aligned.
Lessons from Real Learning Projects
The pattern holds across very different programs.
When NetHope set out to build its Leadership Skills Development Academy, the starting question was not “which platform?” It was “what does digital-age leadership actually require inside humanitarian organizations, and which capabilities are missing?” That needs analysis shaped the architecture, the cohort model, and the sequencing. The technology decision came last because by then it had the least left to decide.
In the IFI–UNHCR refugee studies program, learners had unstable access to connectivity, time, and quiet study conditions. Any brief that started from a platform would have specified the wrong thing. Mapping the learners’ reality first is what made the program completable at all.
The Lebanon Export Academy, an initiative of UNIDO and UNDP, came to us with disorganized slide decks and no real structure for getting small businesses export ready. The fix was not a nicer platform. It was diagnosing the actual gap, designing nine practical courses around an Export Plan tool that learners completed as they progressed, then choosing delivery to fit. The result: 71 enterprises trained, 62% of them women-led, and a 91% satisfaction rate.
