At the end of our blog post on deconstructing LMS RFPs to find the most popular evaluation criteria, we mentioned that we are working on defining the functional and non-functional criteria. Over the past month and a half, we have worked on grouping the different requirement types. Rapidly, we understood that it’s not a matter of two groups but six different requirement groups.
Update on Requirement Type Grouping
In our initial post, we put all requirements in the same graph, even though we knew there were functional and non-functional requirements. However, to give an accurate picture of disparate RFPs, we standardized them into six types of categories:
- Functional: these state what tools your users will leverage to achieve their objectives
- Non-Functional: these state how the proposed solution will work
- Contractual: detail terms and conditions necessary to formalize a partnership between the institution and a vendor
- Management: detail expectations for the project with the vendor, such as guidelines for solution implementation, training, customer support
- Submission: detail how vendors should submit their proposals, such as the maximum number of pages, document format, and delivery method
- Business: detail the goals the institution plans to achieve by partnering with a specific vendor
With this new grouping, we have created the following graph to represent the importance of each requirement group. We are still working with the same dataset: sixty-nine institutions (13 from 2-year colleges, 20 from 4-year or above universities, 28 from school districts, and 8 from state-wide systems), all from North America. We have over 450 criteria spread across the 69 institutions, which represents an average of almost 7 criteria per evaluated RFP.
The Most Common Requirement Types
The contractional and submission requirements are the most popular because of (a) external compliance (women-owned business, for example), and (b) institutional requirements for how to submit RFPs. What’s interesting here is that functional requirements are the second-most popular, as it suggests that institutional leaders are demanding that vendors meet use cases and user needs.
Evaluation Weight of Requirement Types
Similarly to our first post on LMS RFPs, we looked at the evaluation weight for each requirement type. We define evaluation weight as the percentage associated with one specific requirement in the RFP evaluation. To carry out this analysis, we selected only the criteria for which we had an evaluation percentage from the initial 450+ criteria. We then calculated an average for each of the six requirement types. By doing so, we noticed that they almost evened out. Except for one group (the non-functional requirements, which averaged 14%), all requirements scored between 17% and 19%.
Evaluation Weight for All Six Requirement Types (from 69 LMS RFPs in North America)
| Requirement Types | Percentage |
|---|---|
| Business Requirements | 19% |
| Contractual Requirements | 17% |
| Functional Requirements | 18% |
| Management Requirements | 17% |
| Non-Functional Requirements | 14% |
| Submission Requirements | 17% |
The non-functional requirement has a minor impact on the overall scoring, which can be explained by the fact that the LMS product category has been used for over 20 years in North America and that institutions know what to expect from such a system: course creation and management, content creation, classroom attendance and management, reporting, assessment and grading, and communication with the participants. There are not many non-functional requirements except for the integration of video conferencing features since the pandemic.
In addition, when evaluating the proposals, institutions want to distinguish the best solutions providers for their university or school district. The business requirement is, therefore, critical to the success of a new LMS implementation.
The Precision of This New Grouping
The most significant advantage of grouping the requirements into six groups instead of two is two-fold: to be more precise with requirements within an institution and to be able to compare one institution’s RFP with another. The preparation before launching an RFP is paramount to its success. We discussed this topic in our first blog post, and it will be a central part of our RFP report. The report will be produced over the summer, but if you need it before the launch, do not hesitate to contact us. We always want to help institutions and solution providers to connect more efficiently.
