7.5. Communication

7.5.1. The need for a communications strategy

McCredie and Updegrove have highlighted the complexities of implementing 'enterprise-wide' systems in educational organisations, and the need for good communication. Their remarks might also be applied to MLEs:

Implementing a new enterprise-wide administrative application will be one of the most complex software projects in which you are likely to be involved. The technical components of the project are complicated, but most of the really hard issues will arise from the functional process changes and organizational adjustments that are inherent in these implementations.

Most individuals on the periphery of the project will not understand the intricacies of such a large effort. Faculty members who may be involved in various review committees are likely to be very critical of the amount of time, effort, and money required to rebuild a major part of the organization's administrative infrastructure. Even if they are part of the communication process they are likely to be unhappy about any large investment in administrative support. A coordinated communication plan is a good way to explain the goals, timelines, benefits, and problems of the project.

(Jack McCredie and Dan Updegrove. Enterprise System Implementations: Lessons from the Trenches. CAUSE/EFFECT journal, Volume 22 Number 4 1999.)

The authors' solution is to 'communicate broadly about the complexity of the implementation process' - 'An up-to-date Web site and extensive electronic mailing lists are helpful and many projects find that a periodic newsletter is very popular. Regular reports to the executive levels of your college or university are absolutely essential.'

MLE Implementation is a highly political process, because (as discussed elsewhere in this infoKit):

• MLE development cuts across traditional organisational boundaries

• There are several different groups involved in e-learning development with different cultures, different perspectives and priorities

• By integrating previously separate systems, the MLE can expose problems, incompatibilities, and/or flawed academic or administrative processes. There is a danger that the MLE is seen as creating these problems and/or that technology alone can solve them.

Because of this MLE implementation needs to include a carefully considered dissemination strategy. Absolute clarity and consistency is needed - there is a great capacity for messages to be misunderstood. Dissemination needs to promote the system, to encourage interest and uptake among staff and students. At the same time great care needs to be taken to manage expectations. For more discussion on this area see 'Why might you want an MLE?'.

7.5.2. Promoting the system

At DMU, a range of methods has been used to publicise the MLE to data owners and end users:

• the MLE Web site

• presentations to various groups

• various powerpoint presentations, including a stand-alone presentation, with voice-over, which could be circulated

• a global email to all staff

• a section in the DMU Student Handbook

• handouts

One thing that has become clear is that while each of these methods has succeeded up to a point, no single one has reached all its intended audience (a recent staff survey found that, in spite of the publicity, over 20% of respondents had not heard of the MLE!) Communication needs to take place at multiple levels, multiple times and in multiple formats. The form of publicity that many staff seemed to find the most useful was a basic one-page flyer aimed at introducing the MLE to students (see Key Resources). Methods of promoting the MLE are also discussed in this infoKit in the section 'Understanding your organisation - Planning dissemination and evaluation'.

7.5.3. Managing expectations

The GIMIS project recognised the danger of creating unrealistic expectations:

... As more functionality is made available to staff, their expectations have increased exponentially. A number of discussions have ensued with colleagues asking if GIMIS can help them either to eliminate the repetitiveness of the task in hand or in some cases to be able to do quite complex data analysis e.g. Activity Based Module Costing. Whilst this represents a watershed i.e. colleagues using the system, unless it is carefully managed it may cause the project to creep. It is therefore important to acknowledge the enthusiasm, whilst at the same time carefully managing expectations i.e. don't over promise and be guilty of under-delivery.

(GIMIS Management Report 5)

Their solution was to use formal written agreements - to manage expectations and prevent 'project creep':

As GIMIS continues to develop, a milestone has now been reached where it has become necessary to codify a set of logic construct rules, applied within the source code. A set of bespoke Departmental Rules are being drawn up and will be amended as changes are made to the underlying logic, set out in clear unambiguous terminology stating what GIMIS will be doing with their source data and their responsibilities towards their data ... Each set of rules will be signed off by the GIMIS Project Director and the Department Manager, any adverse feedback from users will be directed to named individuals to cite their case for a rule amendment. The documentation will adhere to all version control standards already in place ... The project team has been proactive in authoring the Project Initiation and Definition Document. This document will act as a control mechanism to avoid scope creep as the project gains momentum and conflicts arise from Departmental Process as distinct from the College's Management Information Systems (MIS) systems Finance, Library, Student Records and Timetabling.

Perhaps because of the difficulties in defining an MLE, diagrams have played an important part in their dissemination. The earliest is probably the one produced by the British Educational and Communications Technology Agency (BECTa) in 1999. This is reproduced in the JISC briefing paper 'MLEs and VLEs explained'.

It shows the MLE as a number of linked systems, and is useful for showing the relationship between an MLE and a VLE (Virtual Learning Environment). The disadvantage, at least for a Higher Education audience, is that some of the concepts and terminology are specific to Further Education.

Another type of diagram visualises the MLE in terms of its underlying software. The JISC's Technical review of the systems developed by the 'Building MLEs in HE' programme, includes diagrams of each of the six systems reviewed, and one that synthesises these into a suggested 'generic MLE architecture' (see below).

Another useful source of diagrams is The JISC report 'Developing a Shared Understanding of the Managed Learning Environment' (See Key resources.) The report also discusses diagramming in general and alternative methods of representing MLEs.

Follow this link for key resources for this section (these open in a new window)