Jisc case studies wiki Case studies / Course Data - University of Sunderland
  • If you are citizen of an European Union member nation, you may not use this service unless you are at least 16 years old.

  • You already know Dokkio is an AI-powered assistant to organize & manage your digital files & messages. Very soon, Dokkio will support Outlook as well as One Drive. Check it out today!

View
 

Course Data - University of Sunderland

Funded by the: Jisc e-Learning programme.

Lead Institution: University of Sunderland.

Learner Provider Type: Higher Education

Project Duration: January 2012 - March 2013

Key Words: Course Data

 

Case study tags: course data, process improvement, course information, stakeholder engagement, change management, university of sunderland

Note: This is an abridged version of this project's final report.  The full version is available here.

 

 

University of Sunderland

 

Project Summary

The overall aim of the project was to develop a comprehensive database of undergraduate programme information to permit extraction of data in a standard format (XCRI-CAP) for:

  • access by authorised external agencies (such as UCAS, HEFCE, HESA);
  • internal purposes including the provision of information to prospective students;
  • quality assurance processes.

 

Core module information was already held on the student record system SITS. This included the information needed to:

  • maintain records of student registration;
  • create reports for assessment boards;
  • provide transcripts and degree parchments; 
  • return data to HEFCE,  HESA and other bodies.

 

There was also further descriptive information at module level  (the ‘module catalogue’) including learning outcomes, content and reading lists which  faculties were responsible for keeping up to date. SITS held a limited amount of information about programmes, particularly the programme ‘structures’ which show which modules are associated with each programme, but no text fields such as programme learning outcomes or content. This sort of information was held mostly in Word documents such as programme specifications.

 

The aim of the project was to develop a single database to hold all the programme and module information in fields designated at the lowest possible level of aggregation so that they could be re-assembled flexibly for a range of purposes including:

  • programme or module approval and review;
  • provision of information to prospective and current students;
  • data returns to external agencies; 
  • other purposes including the Key Information Set (KIS) and the Higher Education Achievement Report (HEAR).
  • To ensure that the information would be continually available and accurate the vision was to integrate the database into online processes for approving and modifying programmes and modules: thus these processes would both draw on the database and secure its currency.

 

To populate the database we took the opportunity to redesign the programme specification to foreground issues of particular importance to the University (such as employability) and to present the documentation in plain English, accessible to prospective students and their parents, without ‘dumbing-down’.

 

What could have been improved?  What lessons have been learned?

The most important factor was the involvement of key stakeholders at an appropriate level, either within the project team or through wider consultation and communication. We are aware that project teams in some universities struggled to engage their quality management professionals in the Jisc project but this was not an issue for us and the key ‘selling-point’ in working with faculties was the longer-term saving of time and effort including:

  • immediate access by faculty and central staff to the up-to-date version of programme and module information;
  • removing the ‘paper-chase’ which characterised quality assurance processes, saving time and streamlining procedures;
  • providing easy access to materials for handouts, handbooks and other uses.

 

The Director of Academic Services had developed a more limited version of this kind of process (for module use only) at a previous institution and so had some ‘proof of concept’ including the viability of rolling this out within faculties. There were other drivers, particularly the imperative to publish programme specifications which were fit for that purpose without sacrificing academic integrity. We are aware that a culture change is being effected in faculties and in approval and review teams (‘more’ is not necessarily ‘better’ and plain English need not be a barrier to academic precision). We will have to maintain the momentum to ensure that the balance between accessibility and academic integrity is maintained, to revise requirements if we have got them wrong and to secure further progress as programmes are modified and new ones approved.

 

User testing with the widest possible range of colleagues was essential. The programme leaders who prepared draft plain English programme specifications were keen to be involved and we widened this to as many colleagues as we could.  Access to the system as it is built via the test server has been crucial.

 

The greatest worry was access to development time at Tribal. They were slow to respond initially and development was not quick. Although they established appropriate means of holding the data, we were disappointed with the speed of progress and with basic mistakes including failure to follow a colour-code used in the programme specification template to distinguish between questions, options, guidance notes and set text. This made it harder to discuss the more complex issues raised by the fields. Clarity about this on our part at an early stage proved to be crucial as it gave us a basis for commenting on developments without having to revisit discussions about requirements (However the errors kept being repeated and it became very clear that Tribal had failed to allocate sufficient build time and probably failed to anticipate the scale of the work to be done. This also meant of course that they had not grasped the potential benefit for themselves of mastering this system development. It would be worth considering for future projects whether there is any mechanism for getting major suppliers involved with and committed to the project at a national level right at the start, perhaps with help from Jisc, rather than having individual HEIs ‘fight their corner’ with the vendors. The difficulty with this approach, however, is that, while there are generic lessons to be learnt, the final build will be specific to each HEI). In retrospect we probably should have made Tribal give us a full project plan at the outset, but having had a demonstration from them at Easter 2012 about the functionality they could provide we assumed that they knew what was required to implement it. In February 2013 some robust discussions led to significant improvements in the quality and speed of delivery. We are now more optimistic and have been promised a formal project plan for the rest of the build.

 

Despite this we discovered in the autumn that we were ahead of many other institutions in building the system and we believe that this can be attributed to:

  • a clear vision engaging all main stakeholders;
  • agreement between ‘quality’ and ‘systems’ colleagues such that neither one aspect was trying to drive the other. This resulted from:
    •  the constitution of the project group and the commitment of the individuals;
    •  the level at which the group was chaired (Director);
    • the fact that the project was managed not by a bought-in project manager but by someone with credibility within the institution, who also spent time talking with stakeholders outside the meetings to ensure that issues were addressed and consensus reached;
    • clarity at the outset about the programme definitions and functionality required;
    • an early selection of a SITS solution.

 

We made contact with other SITS users in a group led by Cranfield University who were also involved in the Jisc project and were able to see a similar system in place at Wolverhampton (for modules, interfacing with, but not using, SITS) and Cardiff (for programmes).  As we were further advanced in our development than the Cranfield group we were happy to share with them some of our thinking including process mapping, the functionality  statement, the programme specification and the options matrix.

 

Immediate Impact

It is too soon to evaluate the impact of the project. As indicated above we are still finalising the development of the system, editing the programme data and populating the ‘holding databases’ which will feed the final system. Indications from wider stakeholder groups are encouraging:

  • academic staff are positive about the clearer structure of the revised programme specification which will simplify the process of writing it, allowing academics to focus on the academic content;
  • administrative staff, including SITS teams and quality management staff in central and faculty offices, are positive about being able to access up-to-date information at all times, reducing time-consuming ‘paper-chases’;
  • marketing staff are positive about being able to access current module information and programme specifications.

 

Future Impact

We believe that we will produce:

  • a single source of truth for programme and module information which can be used flexibly to support a range of needs including the requirements of HESA, UCAS, HEFCE, the KIS, the HEAR, programme and module handouts and handbooks, and prospective students;
  • a faster and more streamlined approach to documenting programme and module information  and undertaking approval and modification;
  • a secure basis for further online developments including online module registration;
  • easier access via the VLE or the web to current information for students on and off campus.

 

This has the potential also to be a model for further developments using the same SITS functionality. Extending the system to postgraduate taught programmes and short courses is an obvious development. Another is to develop an abridged version to hold and approve the subject specifications for elements of our Combined Subjects programme. Use of the workflow facility for appeals and complaints is also a possibility. 

 

The impact will be reviewed at the end of 2012/13 (the first full year of operation) through surveys and focus groups as appropriate involving colleagues engaging with the system. This will include module and programme leaders, faculty and central quality managers, SITS teams in faculties and central administration, and programme approval and review panel members. As we become more confident in the use of the system we will keep under review how an online approach to programme approval in particular can be extended. We would be not be prepared to lose the face-to-face discussion which approval panels have with programme teams but we may be able to do more preparatory and/or follow-up discussion on line. The impact on prospective students will be picked up in regular institutional surveys of new students which cover this ground.

 

Conclusions

General conclusions:

  • it is possible to design a system and documentation to serve multiple needs and audiences without compromising academic integrity and to support this online without distorting processes inappropriately to make them ‘fit the system’;
  • this has many of the key features of change management including:
  • a sense of urgency (the availability of funding for a limited time and external drivers such as the need to publish programme specifications);
  • a ‘guiding coalition’ (Kotter, 1996) of stakeholders with relevant expertise;
  • a clear vision including articulation of the benefits which will come from the changes to the process and justify the initial work;
  • champions and supporters at institutional level and in relevant services and faculties;
  • broadening of the support base as the project evolved to increase understanding and buy-in;
  • ongoing support to reinforce and adjust in terms of both process and culture.

 

Conclusions relevant to the wider community:

the importance of

  • a clear vision engaging all main stakeholders;
  • early clarity about the functionality required;
  • an early exploration of the options and selection of a solution;
  • leadership of the project by colleagues from the ‘quality’ team rather than the ‘systems’ team;
  • ongoing staff development and training for all those involved recognising both the technical aspects and the culture shift involved. 

 

Conclusions relevant to Jisc:

Technology has real potential in such a context. Tribal has developed knowledge which can be transferred to other projects and the team at Sunderland has worked through a methodology outlined above which is also transferable. However the technology must serve the processes in the institution which (while they must not themselves be inflexible) reflect culture and structures which rightly vary between institutions. There is therefore no ‘one-size fits all’ solution to course data management but there are generic approaches which are transferable and within a given provider (in our case Tribal/SITS) there are key elements of the system build which need to be developed only once. This includes how and where to store data, attach documents and track email audit trails for example

 

Recommendations

The recommendations arise from the conclusions above, particularly:

  • ensure when designing a system and documentation to meet multiple needs that you do not compromise academic integrity
  • ensure that online support for processes does not create distortion to make them ‘fit the system’ in ways which are not appropriate
  • at the same time be prepared to change processes to operate in smarter, clearer or more flexible ways
  • do not assume that quality management processes have to be paper-based
  • use change management methodology implicitly rather than explicitly
  • ensure that you have
    • a clear vision engaging all main stakeholders;
    • early clarity about the functionality required;
    • an early exploration of the options and selection of a solution; on-going staff development and training for all those involved recognising both the technical aspects and the culture shift involved.

 

Further details: email and contact names etc

Project Director: Prof Julie Mennell, Deputy Vice-Chancellor (Academic)

Project Manager: Beatrice Ollerenshaw, Director  of Academic Services

Contact email: For further discussion please contact the project manager Beatrice Ollerenshaw (Beatrice.ollerenshaw@sunderland.ac.uk) or her deputy Iain Rowan (iain.rowan@sunderland.ac.uk)

Project Web URL: http://projects.sunderland.ac.uk/xcri