Selecting a VLE/LMS is an enormous decision for a university to undertake.  Due to the many stakeholders that will be affected by the choice including students, staff, administrators, and professors, the decision can’t be taken lightly.  This means that it will take a very long time to select a system, from the initial review phase of the available options to the eventual decision stage after all stakeholders have had an opportunity to review the systems and offer their opinions.  Stakeholder input is critical for expectation management, to ensure that the stakeholders have understood the limits and the fluencies of the system when they are sharing their opinion regarding which system they prefer.  Adding to the seriousness of the choice are the costs involved, both upfront costs for the software – if any – and the human resources costs, which are hard to calculate in advance.

Human resources costs are difficult to anticipate, as this is the cost of the time required from the staff to deliver the transition to the software, including ensuring that all necessary data is imported into it.  New VLE/LMS systems are just that, new, so their implementation needs, in terms of time, remain a bit of an unknown until the work is being done.  After the implementation is successfully completed, the ongoing support of the system is crucial to its success and functionality for the users.  Sometimes the system support requires special skills not available from the university that has implemented the VLE/LMS, and other times the university doesn’t have the budget to provide adequate staff to offer the support needed for the system to meet the expectations of the users.

A major design factor that will greatly affect the stakeholders is the choice of the focus of the VLE/LMS system on students or learning.  These are choices that are made by the designers of the system so they are fundamental to its particular functionality and will affect how everyone involved with the university interacts with it.  It is critical that the university selects a system that is designed in a way that best supports the wants and needs of their stakeholders.  The design of the system also figures in strongly to the support needed for the system and its ability to meet stakeholder expectations in terms of its accessibility.  If the system is not designed in a way that makes it stable and reliable, it will be inaccessible more than other, more reliable systems, and the support needed for the system will be much greater.  Its security also affects support and usability.  If the system isn’t secure it will require a lot more staff time to manage security threats, and with less trust in the system, it will see decreased use by stakeholders.