There is a need to take a strategic decision on the approach to implementing an MLE, whether to  acquire one, build one or integrate a variety of systems.  The decision will be far reaching and its  impact felt for many years.

One place to start is to look at the total cost of ownership (TCO) of the system. This covers more  than just the purchase and implementation costs, it includes the running and maintenance costs,  staff development (for those running and those using the systems), management costs etc.

In higher education it is rare to properly cost things as staff time is often left out of the equation.  There are innumerable occasions on which I have heard discussions which go something like:

HE person "Free software is always cheaper as you don't have to pay for it", 

me "but the time required to adapt and support them may be much higher"

HE person "Oh, yes, well, we have the people anyway so that's free"

Of course, it is not.  Either they already have other work that they should be doing and this is either  a distraction or an additional burden or they do not have enough to do.

Calculating the total cost of ownership of what you are doing is hard enough, calculating the TCO of  a variety of options is even more fraught and inevitably will be full of guesses and estimates.  This  does not mean that it is not worth attempting, indeed the results can be quite surprising and  provide re-assurance for the selection of technologies and implementation that the right path has  been chosen.

Information on the Total Cost of Ownership can be found at:

No solution will give you everything that you need (let alone want), and At each stage compromises  have to be reached.  Previously in looking at the user requirements, competing requirements will  have been balanced to achieve what the institution as a whole needs rather than any set of  individuals, however important they and their work may be.

Once you come to select the technologies to implement further compromises will be inevitable. The  cost and technical feasibility will preclude some options (at least for now), and you will almost  certainly have to iteratively re-visit the user requirements several times while selecting technologies  and systems.

It is also worth noting that each of the options that we will be discussing in this section will impact  differently on the user requirements.  If you acquire an integrated system from SAP or PeopleSoft  of FD then there will be less flexibility in making the system do what you want, and you will have to  adjust some of your processes in ways that do not meet your user requirements in order to be able  to use the system. 

Similarly, if you buy (including open source) systems they are unlikely, even after adaption, to do  precisely what you want and compromises will need to be made, but as you should be able to  choose individual systems that are as close as possible to your requirements the adaption of your  requirements may be less.

It is often assumed that if you build a system that it can perfectly match your requirements.  Unfortunately this is rarely true.  In part this is because of the changing nature of the requirements,  so that by the time the system is built the requirements and the understanding of the requirements  will have changed.  Further, the system will have to be built in such a way that it can be adapted of  extended as requirements change.  Indeed it could be argued that building the system too tightly to  existing requirements will hamper flexibility (probably a requirement in itself).

In short then, you will never get exactly what you want and you need to think about which  compromises are acceptable and will give the flexibility that you need to carry the system into the  future.

Each of the possible methods will put different burdens on the organisation and require different  skill sets.  It is essential that as part of the process of determining the most appropriate route  forward you ensure that you have, or can acquire, the skills needed to complete the process.  For  instance, if you require a large number of programmers for a short time do you already have the  skills in house? can you divert them from what they are doing at the moment? Can you recruit any  additional ones that you may need.

Generally speaking the more of the work that is done in house the greater the technical skills that  you will need to have available to you.  You may already have the skills or be able to acquire them  (by training or recruitment), but will you be able to retain the people, and what happens to them at  the end of the project.  A big danger historically is that projects like this have run in fits and starts  on short term funding with the result that staff are appointed on short term (fixed term) contracts.  Six months, or more, before the end of the contract they are already looking for their next job, and  they may leave early which can cause major problems.

However, outsourcing or going for a contract with a systems' integrator will require significant  amounts of senior management time working with bidders and developing the details of the  contract.  Perhaps the biggest mistake that can be made is to under-estimate the amount of time  and effort that senior manages will have to devote to ensuring that any outsourcing contract  actually meets your needs.  According to Gartner 50% of enterprises do it wrong and end up  regretting having outsourced.  And remember that many of these are for simpler, or relatively self-  contained operations such as cleaning and catering.  Outsourcing should not be attempted unless  you believe that you have access to the necessary skills either in house or through the use of  expert consultants in the field.  Even then, I would not attempt outsourcing IT operations unless I  had already tried it in a simpler area and so understood some of the pitfalls.

MLEs are for life, not just for Christmas, as the saying goes, and as with puppies they grow up and  change.  The education environment is changing rapidly, as is the technology.  It would be a bad  mistake to buy for the present.  Changing MLEs will cost a fortune, so it is essential to purchase  for the future.  This means looking closely at any options and looking not just at whether they meet  the current requirements, but whether they will be adaptable to changes in technology or the  educational context. 

It is often assumed that open standards will resolve this problem, but while they can be a great  help they cannot alone solve the problem.  This is discussed in greater detail in the section on  standards.

What should you be looking for to reduce the risks of being stuck with a system which will not  grow to meet your needs?

some of the things that you can do include:

One of the drivers for MLEs will be the need to provide better support for students, and this in turn  will be driven in part by the Special Education Needs and Disability Act and the Data Protection  Act, and certainly it will be important to ensure that developments support that.  However there are  a number of other considerations which need to be borne in mind when selecting the technologies,  and especially when considering the ways in which information will be delivered to users (students  and staff)