I’m increasingly helping Not for Profits choose a Learning Management Systems (LMS), particularly since the pandemic began. One study believes the global LMS market is worth over US$15 billion in 2021 with at least a thousand vendors offering more features than I can possibly document in a single article. So, with this many vendors to choose from, what is the #1 criteria for choosing a LMS as a RTO? In my opinion, it’s ensuring there’s local support.

Let me explain why.


Why local support should be your #1 criteria for choosing a LMS as a RTO

For the more sophisticated systems, vendors will implement their solutions themselves or through partners. As an example, any version of Moodle (i.e. Moodle, Moodle Workplace, Totara) is done via a partner. While others like Canvas, Brightspace and Litmos will do their implementations themselves.

Simpler systems like LearnDash or Talent LMS can be installed by yourself (or via your website administrator). However, you’ll unlikely to be able to capture RTO reporting data as integrations with Student Management Systems are limited.

While you could look for the LMS vendors that have such integrations available, I believe your #1 criteria for choosing a LMS should be to look for local, Australian support instead. Why? Because integrations can be built, but you can’t do the same for local support.

Most of the LMS vendors are from the US where their formal tertiary education is extremely different than in Australia. Those that have local Australian support recognise this difference and have added features and integrations to meet our unique needs here.

Furthermore, with business-critical systems like a LMS, being in similar timezones do matter. There’s nothing worse than seeking support when your system isn’t working and getting a message or voicemail that you’re outside of their normal operating hours.

These are reasons why I will never recommend a LMS vendor to a RTO that doesn’t have local Australian support.

Tammy Ven Dange is a former charity CEO, Not for Profit Board Member and IT Executive. Today she helps NFPs with IT decisions.

Related Articles 

7 Ways to Blow your IT Project Budget

One of the biggest fears for any transformation executive is blowing the IT project budget your Board already approved. There are few things harder than having to go back to them again (and again), asking for more money and with very little information to explain why....

Manual Processes in a Not for Profit

Regardless of the project I do for a Not for Profit, I always perform a Current State Analysis at the beginning. The results usually surprise the Executives. This is especially true regarding the number of manual processes their staff do on a day to day basis. The...

Why Not for Profits should be in the cloud

The use of public storage clouds like Microsoft Azure or Amazon Web Services to host organisational data is not new. Neither is the use of Software as a Service (SAAS) such as Salesforce or Xero. Nevertheless, I still hear about organisations trying to replace old...

Why the RFT process often fails Not for Profits

I started my career as a contracting officer for the US Air Force where I wrote and evaluated Request for Tenders (RFTs) for a living. I did this again later in my career as a consultant in the IT industry - helping clients purchase systems and outsource software...

I started my career as a contracting officer for the US Air Force where I wrote and evaluated Request for Tenders (RFTs) for a living. I did this again later in my career as a consultant in the IT industry - helping clients purchase systems and outsource software development.

I've also been on the other side of the fence as an IT Sales Executive writing proposals in response to RFTs, as well as the buying customer as a former Executive.

It's with this wide lens that I believe the RFT process fails NFPs most of the time. Let me explain why.


The standard RFT process is broken

Let's start with a scenario I've seen too many times.

The Request for Tender (RFT) process is standard way for organisations to receive competitive bids for an expensive service such as an IT system implementation. The standard process is for a Not for Profit (NFP) to hire an external consultant to gather requirements and write the RFT. They are often paid a daily rate, and it can take months or even years to do this as there's no incentive to complete it faster.

Then, the RFT is sent to a list of potential service providers who are given a month to respond to pages of detailed requirements the consultant put together based on their understanding of the organisation's needs (but not necessarily what's available out of the box for the vendors). The providers scramble to put a bid team together as it's a huge undertaking. Then, they realise after reading the RFT that what the customer is asking for is probably not what the customer needs or can afford.

The providers are only allowed clarification questions during this part of the process that will be shared with all. So, they're not sure if they want to reveal their concerns now to their competitors. They answer the questions the best they can in their proposals but worry they have outpriced themselves. Still, they submit it with fingers crossed.

The NFP opens the Tenders and is completely surprised by the prices they received. Some providers may not have responded at all. The Executive is now required to show the results to the Board, knowing that it's unlikely to get approved for the next phase of work. The project is dead before it really began, but money and time have already been spent with nothing to show for it.

A year or two goes by, and the organisation still doesn't know what went wrong. At the same time, the need is still there, but they're afraid to start the process again because they're not sure how they can afford the solution. 

I'm not making this up. This is the common story I hear from both clients and providers, as well as something I have personally experienced multiple times while in their shoes.

You're paying for the design process twice

What few NFPs realise is that a RFT process results in you paying for the design process twice.

So, you've just spent a good amount of time and budget to gather the requirements into a RFT. The reality is that no matter how good your requirements document is, the provider will still require a detailed design process as part of their implementation. Why? Because they do not know enough about your organisation's business processes to determine how much of their solution will require configuration and customisation.

Instead, the provider will have to guess how much work is required for the unknowns in their tender. Therefore, there's a risk component added to their price and a bunch of assumptions declared to allow them to give you a change request later.  I know this because I used to write proposals for IT system implementations, and it was always a challenge to balance the submission of a competitive price with the risk of under-scoping the work.  

This is the reason why the first part of every implementation schedule is a set of design workshops.  And yes, you are paying for this whether or not it's visible in the proposed price.

You don't need a RFT process to have a competitive selection process

Rather than a formal RFT process, I have found that a collaborative approach with vendors is more likely to get a better outcome.  It's like a long courtship process with numerous suitors rather than an arranged marriage with the best on-paper offer.  I call this my Rapid Evaluation Process (REP).

This process uses discussions, interviews and demonstrations with all potential vendors before asking them to submit prices based on their understanding of your requirements.  It not only gives you an indication of price and their solution, but also what kind of partner they will be to work with in the future.

For IT system implementations in particular, almost all vendors and service providers can provide you a fixed quote for a Design Phase. They can also provide indicative prices for the Implementation. So, why pay for a consultant to write your detailed requirements when it can be done by the actual provider who intimately knows the system?

You'll still need a scoping process to narrow down your potential suitors to a manageable size, but requirements do not have to be written down to the level of a RFT process to do this. As an example, for a stand-alone system decision like a Learning Management System (LMS), I often complete the entire competitive selection process with clients in a month. This includes a board-level report to document the decisions and process along the way.

So, before making your next major IT decision, consider whether or not a RFT process is really necessary to get the best outcome.

You also might want to check out my other article, 7 Ways to Blow your IT Budget.

Tammy Ven Dange is a former charity CEO, Not for Profit Board Member and IT Executive. Today she helps NFPs with IT decisions.

%d bloggers like this: