5.1. Outsource, buy, build or integrate
This section describes different approaches to acquiring an MLE and the benefits of each. It is a descision which has far reaching consequences and should be taken at the highest level within your organisation.
When looking at the technology options it is important to take a strategic view, and this means looking at the entire IT infrastructure and how this is best managed. As mentioned in the overview there are four basic approaches:
Outsource
Turnkey
Integrate
Build
5.1.1. Introduction
Total cost of ownership
One place to start evaluating the different options 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 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:
Lecturer 'Open source software is always cheaper as you don't have to pay for it';
IT Director 'but the time required to adapt and support it may be much higher';
Lecturer 'but we have the people anyway so that's not an additional cost';
Of course, it is. The staff already have other work that they should be doing and this is either a distraction or an additional burden. Calculating the total cost of ownership of one option 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.
Fit to requirements
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, you will have balanced competing requirements to achieve what the institution as a whole needs. Decisions cannot be driven by 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. Cost and technical feasibility is likely to preclude some options (at least for now), and you will almost certainly have to re-visit the user requirements several times while selecting technologies and systems.
It is also worth noting that each of the options we will be discussing in this section will impact differently on the user requirements. If you acquire a system that already contains a number of integrated components e.g. SAP, PeopleSoft or 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 order to be able to use the system.
Similarly, if you buy a number of different third party (or open source) systems they are unlikely, even after adaption, to do precisely what you want and compromises will need to be made. However as you have made 'best of breed' decisions that are as close as possible to your requirements the adaption required may be less.
It is often assumed that if you build a system 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.
Available skills
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 staff 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 managers 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. Remember also that many of these contracts 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, it is recommended that you do not attempt outsourcing IT operations unless you have already tried it in a simpler area and so understad some of the pitfalls.
Future needs
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 major components of your MLE could 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. Follow this link to 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:
Ask vendors what their development plans are, including timescales and investment levels
Look at who their partners are. Few vendors claim to offer all the systems that you need, and often form partnerships with other suppliers. What is the nature of these relationships? Are they with other suppliers that you are dealing with?
See how well they understand the education market (and this includes consideration of how important the education market is to them, as they will inevitably concentrate their efforts wherever it will show the greatest return on investment)
Look at their commitment to open standards (this matters less if all or virtually all your systems are coming from a single supplier using their own proprietary systems but it does matter if you are looking at several suppliers). Of course, some suppliers look to Microsoft rather than open standards and it is not clear which will be the better bet in the long run; Microsoft has won some and lost others.
Legal
One of the drivers behind integrating systems into MLEs is the need to provide better support for students, and this in turn is driven in part by legislation such as the Special Education Needs and Disability Act and the Data Protection Act, and it will be important to ensure that developments support this. 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).
Below are some of the issues that you should consider:
Purchasing: Major components of the MLE such as the student record system or VLE will cost more than the legal minimum for EU procurement rules to kick in, and therefore unless you are developing the system in house you are likely to have to follow those rules. Follow this link to the infoKit on contract negotiation for more about procurement.
Accessibility - The Special Education Needs and Disability Act (SENDA) requires all systems to be accessible. If this is planned in from the start then it need not be onerous, and makes the system more usable for everyone. Follow this link to the TechDis site which offers information and advice on accessibility issues.
Data Protection and Freedom of Information - At first glance these can be thought of as contradictory, one aiming to protect the privacy of the individual, the other requiring you to publish increasing amounts of information. Follow this link to the infoKit on Records Management for more about these issues.
5.1.2. Outsourcing
There is little experience of outsourcing in further and higher education at the moment, though it is more common in schools. Educause (through ECAR) has only recently published anything major on outsourcing, while the Chronicle of Higher Education has published very few articles. This contrasts strongly with the commercial world where IT outsourcing (and facilities management) are very common and have a history of over 20 years attracting some of the biggest IT service companies including EDS and Capita. Educause Quarterly has a good introductory article. It should be noted that according to Gartner research, more than 50% of enterprises get their outsourcing arrangements wrong and end up unhappy with their deals.
A very good discussion of the issues can be found in a white paper from Compass Consulting which says among other things 'There is a general perception in higher education that many educational institutions are outsourcing management of their technology operations. We feel that this misconception arises from the fact that many institutions are outsourcing some technology services - especially student telephone services. .... Compass only knows of one institution where telecommunications is totally outsourced and few institutions where information technology (IT) is totally outsourced. Most of our clients believe that technology is too vital and too strategic to relinquish control to a third party. However, many of our clients do outsource some technology services.'
Is IT a core function?
There is an argument, common in much management theory at the moment, that organisations should concentrate on their core functions and should outsource as much of the rest as possible to companies for whom it is their core business.
Thus we have seen many companies that have outsourced catering, cleaning and other service functions. Others have taken this much further and have outsourced a large number of functions including IT.
There are two primary reasons given for this. First, each of these activities take a considerable amount of senior management time, which is better devoted to the organisations core functions of teaching, research and knowledge management. The other reason sometimes cited, which applies most strongly to small organisations, is that it is difficult to retain staff with a sufficient breadth of skills as many of them will be only rarely needed.
We cannot afford all the skills
One of the major issues for your institution, especially if you are a smaller institution, is how to afford the wide variety of skills needed to support all the applications and systems that exist, not just in the MLE but throughout the institution. Many of the skills may be needed only infrequently or part of the time. This means having staff with a wide variety of skills (potentially therefore jacks of all trades and masters of none).
Two obvious solutions to this are to outsource or to form collaborative consortia with other institutions (in your area). Outsourcing provides the opportunity to buy into an organisation which has all the skills needed, because they are working with a variety of organisations, and to an agreed level of service through a service level agreement. The converse of this is that it can be less flexible.
Outsourcing of IT services has not been popular in higher or further education to date. There are a few examples, and these have not all been a resounding success. In the UK only the University of Durham in HE has outsourced its IT operation, and even then the arrangement covers only part of its IT service.
Major issues that have to be considered include:
rapid changes in IT in terms of hardware, networking and applications make defining contracts problematic
the integration of IT into the institution; many of the services that are outsourced are essentially free-standing, such as catering and cleaning and more recently student accommodation, with few implications for other areas. The way in which IT is implemented has significant implications for virtually all functions of the institution and therefore the way in which it is implemented will impact throughout the institution
lack of flexibility - there is a need to specify everything in the contract, when changes from this are needed (and they will be given the rate of change of technology) it can be very difficult and expensive to negotiate, and what might seem a relatively trivial change can end up being very expensive).
Two community colleges which have outsourced in the US are Salt Lake Community College and Cabrini College. As reported in the Chronicle of Higher Education, Salt Lake Community College outsourced its operation because they could not provide all the necessary expertise in house.
Cabrini College had some firm ideas about the kind of outsourcing organisation they wanted to manage their campus computing operations: one that understood their educational mission, their academic values, and their culture. The small Roman Catholic college, in suburban Philadelphia, didn't have to look far, geographically or otherwise. It selected an academic cousin, the larger and more urban Drexel University, just 22 miles away. See http://chronicle.com/free/2001/03/2001032901t.htm
5.1.3. Buying from a single supplier
By buy we mean buying a solution from a single vendor. It is unlikely that one vendor can themselves provide all the elements that are needed, but there are three possibilities here:
buy a solution from a supplier that can provide (nearly) all the components that are needed to make up an MLE including student records
buy a majority of the components from a single supplier with a turnkey contract from them to integrate the other components from other suppliers
commission a system integrator to buy or build systems and integrate them as a turnkey solution
The primary point is that the development is being done by a third party who assumes responsibility for the delivery of the system. As with outsourcing and private finance initiative (PFI) projects it is essential to ensure that the contract meets the institution's needs and contains sufficient flexibility at a realistic cost. There is a real danger that the loss of flexibility that comes from being in the hands of an external supplier will prevent the MLE from meeting the institution's needs at a manageable cost.
However, that said, it is a relatively common solution in US for universities to buy an integrated product covering the core applications from a single supplier such as SAP or PeopleSoft, but it is very uncommon here, with the University of Newcastle being the best known example.
It is worth noting that the equivalent in industry is Enterprise Resource Planning (ERP) systems and more recently Customer Relationship Management (CRM) systems that have been widely adopted. However it also needs to be noted that many of the attempted implementations have either failed or failed to deliver much of their promise and that this is typically not the result of a failure of the technology so much as a failure to adequately address the 'soft issues' around changing the human systems and staff development.
Take up of these systems is much lower in UK education. Causes include:
the high capital cost
systems are not seen as strategic, so each system is owned and chosen by different departments
many institutions do not see themselves as businesses
many institutions believe that they are unique, and so different from all others that they cannot believe that a standard solution will work
Follow this link to read more about ERP in education.
There are few suppliers that can even claim to be able to supply all the components that are needed to develop an MLE and then they are unlikely to be able to provide all the systems that are needed. The companies involved mostly come from an Enterprise Resource Planning background and have developed systems that were intended for large commercial organisations. Obvious examples of these are Oracle, Peoplesoft and SAP. FD Learning also claims to offer all the components needed for an MLE.
However, because a supplier is able to supply all the systems does not mean that they can be used 'as is' and significant and (generally) expensive modifications are almost certain to be needed, and typically these are not all identified at the outset so that the scale and cost of this can grow during the project.
5.1.4. Integrate
Most institutions will, in the end, decide to develop an MLE by integrating a variety of systems themselves, as all the 'Building MLEs in Higher Education' JISC funded projects have done.
Indeed, the Building MLEs in Higher Education proposals were set up explicitly to look at the issues of integrating existing and new systems to create an MLE. All institutions (except perhaps UfI and UK eUniversities Worldwide) have existing systems which cannot be replaced all at once, so an evolutionary approach is usually required. This approach also allows you to buy 'best of breed' for each system that you need. That is, the system which most closely meets your needs. However, this cannot be done in isolation as products do not cover identical territory and there is considerable overlap and potential gaps if the wrong products are chosen. As John Heap writes in UCISA Update 'It's a mild rant ... about the feature creep of software packages which insist on straying into the territory previously occupied by others'. While that is a problem it is integrating the systems that is the real issue in building an MLE to ensure that the various systems and components can work together.
There are two approaches to this. It can be done in a piecemeal fashion, tackling each set of systems that need to be integrated. This is like painting the Forth Bridge, a never ending task as new systems are replaced and each time the work has to be re-done. The alternative is to develop an architecture and use a systematic approach to data exchange. Thus De Montfort University used an XML based approach building on the work of IMS, while the GIMIS project at Writtle College is using a variety of tools and techniques to achieve integration.
5.1.5. Build
Again, few institutions will be in a position to build the entire systems for themselves. Where there are good commercial or open source systems available then these are likely to be included in any system. Few institutions are going to want to maintain finance or payroll systems when there are many commercial systems available. There may be some that want to build their own systems to support their core business, including student record systems and VLEs this tends to occur mostly in higher education.
Thus, some institutions are likely to build elements of their MLE which will then have to be integrated with other systems. The issues here are the same as for integrating third party systems except that one has more freedom of action as one is not constrained by what vendors choose to provide in terms of an application program interface (API).
Anyone who is considering building their own systems should consider using open source (or similar) products as the starting point. Follow this link to find to find out more from OSS Watch the JISC Open Source Advisory Service.
Follow this link for key resources for this section (these open in a new window)
Follow this link for more resources for this section (these open in a new window)
