Modular e-Administration of Teaching: Assembly Report

The Centre for Applied Research in Educational Technologies (CARET) in Cambridge University hosted a JISC assembly for the Modular e-Administration of Teaching (MEAoT) project on Thursday, 10 December 2009.

The list of participants included:

Richard Prager, MEAoT project PI, Cambridge University Engineering Department (CUED)
Laura James, CARET
Anne Clarke, MEAoT project, CARET and CUED
Guy Chisholm, MEAoT project, CARET
Avi Naim, MEAoT project, CARET
Cecilia Loureiro-Koechlin, JISC BRII project, Oxford University
Bridget Taylor, DAISY project, Oxford University
Jenny Mackness, JISC liaison for MEAoT
Rachel Tuley, Teaching Administrator, CUED
Jen Pollard, Computer Officer, Cambridge University English Department
Carmen Neagoe, Teaching Administrator, Cambridge University Judge Business School
Helen Marshall, Teaching Administrator, Cambridge University Physics Department
David Goode, Computer Officer, Cambridge University, Department of Divinity

The programme was designed to make the meeting a pleasant event. It started with a historical overview of the project (by Prof. Prager). This was immediately followed by lunch at a nearby restaurant, which helped break the ice and make everybody more comfortable.

We then had five short presentations (15 minutes or less each). Three of these were by MEAoT staff (Prof. Prager, Anne Clarke and Avi Naim) and explained aspects of the project. The other two were by our guests from Oxford: Dr. Loureiro-Koechlin gave an overview of the BRII project and explained how it approaches potential customers. Dr. Taylor described the large scale DAISY project in the social Sciences division of Oxford University.

A coffee break allowed free discussion between the participants and led naturally to the round table discussion of software distribution models. The forum was not very large but it was particularly varied, and this allowed us to get several different perspectives.

We were discussing four approaches to distributing software, each the result of particular circumstances:

1. The Teaching Office Database (TODB) of CUED is the first part of the MEAoT project. It was conceived as a light-weight solution to the particular problem of allocating teaching duties fairly to members of staff. It was deliberately designed as an independent software, without any connection to other systems. In order to distribute it to other departments effort was invested in customization, with the explicit intention of the departments adopting the code and assuming full ownership of it from that point onwards. So far seven departments at Cambridge have received a customized version, and a generic version of the code is also available for other interested parties at future times, when the project team will no longer be available to customize the code for their specific needs.
2. The examination entries module for the Cambridge Physics Department is the second part of MEAoT. Unlike the TODB this module is required to integrate with a preexisting Teaching Information System (TIS) in Physics. The module is under development currently. Future adoption by other departments will crucially depend on the ability to make the TIS more generic, because it will be impossible for other departments to take the exam entries module on its own. Therefore in this case distribution of the software depends on making it more generic, not more specific as in the case of the TODB.
3. The BRII project collates data from various resources in order to create a searchable repository of knowledge for researchers. While the underlying software is monolithic, the various users around Oxford university need to interact with it in many different ways. Here the distribution of the code depends on separating a generic piece of code that works directly with a database (the back-end) from user-customized interfaces (the front-end).
4. The DAISY project creates a wide reaching system of internal administration within the Social Sciences Division at Oxford. It is developed as a large, monolithic system. The distribution of this software relies mostly on its provision of crucial services for costing activities. The fact that the various departments need these services makes them much more willing to accept a single large central system.
   

We attempted to understand how these distribution models work and what conclusions could be drawn from them for future projects. It was clearly stated by a computer officer (Jen Pollard) that she can see the benefit in adopting (and further adapting) the TODB software to the needs of her department. The other computer officer present (David Goode) agreed. The administrators raised the issue of having to "sell" such systems to their academic staff. Their ability to do so relied equally on the functionality provided by the system and its look and feel.
Cecilia Loureiro-Koechlin emphasized the point that the belief of each of her customers that they are getting something customized to their specific needs was the single most important "selling point" of the BRII software. This point was echoed by Richard Prager in viewing his experience of developing the initial version of TODB. Bridget Taylor talked about the provision of costing services as the "hook" with which to gain acceptance for the whole of the DAISY project across the division.

The term "centralized system" is universally unpopular and should therefore be avoided when introducing new software in the academic arena, even if the software is in fact monolithic and centralized. The clear hurdle that should be overcome is the unwillingness of the users to try it out. Considerable effort must be put into working with the intended users in order to make them feel that they want to "own" the software. The willingness of TODB staff (Matthew and Anne) to work with the various departments, listen to their needs and change the software to suit them was mentioned as the best aspect of TODB, and the thing that set it apart from other software projects. The ability of Dr. Loureiro-Koechlin to "hide" the central aspects of the BRII system behind user-customized front-ends helped her in persuading reluctant users to try it out. Even the accepted centralized system of the DAISY project benefits from being characterized as "Divisional" rather than "University Wide".

It was therefore expressed in several different ways that the most important aspect of getting new software accepted is the feeling of the intended customers that they are getting something that was prepared especially for them. Those functionalities of the system that serve a particular customer best should be emphasized over other functionalities (even if these happen to be more important to the system as a whole), and the look and feel of the system should be tailored to make the user comfortable with it (even if this means generating several different user interfaces for the same underlying software).

The conclusion is that "customer-friendly" measures should be incorporated into the planning of software projects and allocated sufficient time and resources. The success of the project as a whole may depend of such measures.