1.2 Who should be involved and why
An initial strategic decision as to how the development should be carried out - between outsource,  turnkey and integrate/build needs to be made at the most senior level.  This is a decision which  has implications for you for many years as an outsourcing agreement is likely to last for several to  many years.  As such it needs to be made by senior management, in conjunction with the Board of  Governors or Council.
It is however rare for the options to even be considered as individual systems are purchased as one-  off decisions, and it is rare for the IT director to be keen on outsourcing their empire.  The result is  the decision is made by default to build / integrate in house.
If it is decided to go for either of these options then a small team of senior managers will have to  make the selection, supported by staff from IT services and purchasing and advised by the same  people who will be more actively involved if an integrate / build approach is taken.
We now look at who will be involved in this latter approach.
Two types of decision need to be made here:
  • System architecture - primarily whether to go for open standards or a proprietary architecture.
  • Individual systems - the components that make up the MLE.
As with so many aspects of the creation of MLEs involving the right people will be critical to  ensuring their buy in to the project, and thus its continuing success.  Most people are resistant to  change, but when they have been involved in the decisions they are much more likely to accept the  system and work with it, making the implementation and embedding considerably easier.
Unless you are going for a turnkey solution, where all the systems and their integration are handled  by a single supplier (who may use their own products or integrate other peoples) there will be a  series of decisions to be made covering the architecture and the individual systems that will be  included within it.
There are therefore three types technology / vendor selection that can be made:
  • Turnkey solution
  • Architecture selection
  • System selection
1.2.1 Turnkey solution
This is a massive, strategic decision, which will cost millions of pounds to implement in a university  and hundreds of thousands to millions in a college.  As such decisions will have to be made at the  highest level, involving principals or vice-chancellors (or their deputies) and boards of governors or  their equivalents.
Because an MLE cuts across nearly all departments in an institution, and must meet their needs  (and some of their wants) it will be important to involve the key decision makers in all areas  including:
  • learning and teaching - MLEs have a significant impact on learning and teaching  and the head  of learning and teaching will need to be actively involved to ensure that the system actively  addresses the institutions learning and teaching strategy.  An MLE provides opportunities for  improving student support, assisting with progression and addressing e-learning
  • registry - many of the systems that will be integrated within an MLE are owned by the registry,  and there will be a big impact on how they work as the development of the MLE changes the  nature of the way systems operate and who has access to and may enter and amend  information.  
  • student services - Creation of an MLE will have a fundamental effect on student services.  More  and better information from disparate sources will be available as needed, and delivery can be  integrated with other functions.
  • estates - if automated timetabling and space allocation is included within the MLE then  estates should be involved
  • council / board of governors / senate - a decision of this magnitude which will have a significant  effect on the college's medium term development, and council or the governors should have a  significant say in such an important decision.
  • IT services - should have an advisory role.  This is not primarily a technology decision, and it  would be a mistake for IT services to allow itself to lead the project here.  While the technology  is important and IT services need to have an input the development of an institutional MLE is  about driving the institutional strategy and thus the project needs to be led from there and not  from the technology.
  • Users - Users should be involved in all stages of the project.  They will have to use the system  and if does not meet their needs then they will resist, and in some cases may be able to put  the project at risk through non-cooperation.  As in all areas care needs to be taken to include  more than just a few keen people and to draw in staff from a variety of departments and levels  of interest in the work.
  • Representative from partner institutions - closer integration of systems in regional consortia is  growing, it will therefore be useful to involve someone from one or more of the partners to  ensure that the systems can interoperate successfully.
If you have a "round table" see section  <link> then it would be advisable to use that too.
1.2.2 Architecture selection
While the selection of the architecture is primarily a technical issue it will have a major impact  down the line as it limits the systems which can then be integrated.  A couple of examples will  illustrate this.  One area where many institutions are trying to rationalise is on the operating  systems used for central services, with some trying to move to a Unix, and others moving towards  Microsoft.  Either of these systems will limit the systems which can then be used to those that  have been implemented on that architecture.  Even the selection of standards will impose a limit on   the possible selection systems.
Thus, architecture selection is not neutral and everyone needs to understand the effect that these  early choices will have on the MLE down the line.
The selection of the architecture will have to be led by IT services, as only they have the  competences to understand the technologies involved and their implication for the development of  the MLE.  However, members of other departments need to be involved to ensure that they are  happy with the results and their implications.  A couple of examples will illustrate this.
The security architecture needs to meet the needs of all departments, and some - such as registry -   will need to be comfortable with the decisions made if they are going to make their information  available.
Does the architecture allow for users to update as well as read data from central databases?  Although this may not be wanted at first, with functions maintaining control over their systems  there is likely to come a time when the automated input of student marks from VLEs or directly by  teaching staff is required and the architecture must enable this.
Representative from partner institutions could also be involved given the closer integration of  institutions in regional consortia is growing and this involves closer integration of the supporting  systems including those that make up the MLE. It will therefore be useful to involve someone from  one or more of the partners to ensure that the systems can interoperate successfully.
1.2.3 System selection
There is little that needs to be said here.  Institutions have been buying and developing systems for  many years and the issues are little different when they are part of an MLE.  There is, however one  difference to be borne in mind, and that is because of the integration of a systems that is  fundamental to the VLE the departments and users involved goes much wider than in before, and  there it is essential to ensure that it meet all the users needs.  This is discussed in more detail in  the section on organisational issues.
Top