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

  • Stop wasting time looking for files and revisions. Connect your Gmail, DriveDropbox, and Slack accounts and in less than 2 minutes, Dokkio will automatically organize all your file attachments. Learn more and claim your free account.


Course Data - Leeds Metropolitan University

Funded by the: Jisc e-Learning programme.

Lead Institution: Leeds Metropolitan University.

Learner Provider Type: Higher Education

Project Duration: January 2012 - March 2013

Key Words: Course Data

Case study tags: course data, process improvement, course information, leeds metropolitan university

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


Project Summary

Course Data is an essential part of any HEI’s public information, available to prospective students and others as they research potential courses.  The challenge is to ensure that these data are presented consistently, to a common format, which can allow easy comparison across institutions and their courses.  This final report provides an insight on the challenges faced in delivering this project.


The project, part of a wider stream across a range of HEIs, has allowed Leeds Metropolitan University to develop a ‘feed’ of data, according to the XCRI-CAP standard.  This feed, of all our credit-bearing programmes meets the definitions of the XCRI-CAP standard and will allow us to provide data to a wide group of individuals and organisations but on a consistent basis and without the need for multiple data entry and the risks that are associated thereto.


Developing an XCRI-CAP feed has been a learning experience for us – particularly in identifying consistent locations for the relevant elements of data, given that we have sought to develop a feed of both credit-bearing and non-credit-bearing provision.  Ultimately, though, we have been successful in this endeavour and a feed of our data is now available.  Though it does not include all the elements of the XCRI-CAP definition (it does, though, include all mandatory fields) we are considering how we might expand this in coming weeks in order to provide a fuller set of course data.


What did we learn?

There were four immediate lessons that have come out of this project for us.


First, we were over ambitious in thinking that we would be able to produce a feed that contained every field within the specification.  When we analysed our course data at the point of bidding for the project, we feel, we were unduly optimistic about the fields that were not available in corporate systems (specifically in Banner) and our ability to translate existing data or business processes in a way that would allow us to develop these fields.


In reality, some of the fields that were not available in Banner were available elsewhere but not to a level of quality that allowed us to use them within the feed.  Instead, as noted above, we concentrated on the mandatory (and some optional fields) and are now working on the remainder to incorporate these once the formal project has ended.


Secondly, whilst the project has led to change in our approach, this is limited in some respects to members of the project team.  Others have not yet understood the benefits of a single feed of course data, but this is not wholly surprising.  In one respect, it is understandable that until the data is published (and thus its use understood) colleagues will be less clear as to why it is important, but conversely until they understand why the data is important then the quality of that data is compromised.  This ‘chicken and egg’ approach has caused some considerable debate within the project team, and it is for this reason that we approached the Project Board to map only the mandatory fields within the feed at this stage.


The third lesson we learned was that we were over-reliant on two key staff who were also trying to maintain other projects.  These two staff (from our academic registry and IT teams) did complete everything that was needed, within the staffing budget allocated, but not without presenting a business risk in the meantime.  If we were to repeat the project we would seek greater resilience in terms of project coverage.


Finally, we underestimated the value that the project support team provided.  The project support officer left the university towards the end of the project and, thereafter, project support was provided by use of fractions from different colleagues.  This approach led to a partly disjointed response (though the outcomes were met).



Immediate Impact

The immediate impact of the project is limited to the project team, and immediate support, in some respects, since the project team are far more aware of the impact that the data quality is having on the feed than are others.


As noted above, there is a ‘chicken and egg’ effect here: until colleagues in the wider community see the data being used they will not understand the value of it, but until they see the value of it the data quality (for non-controlled fields, at least) will be an issue and the data cannot easily be used.  It was for this reason that we concentrated on the mandatory fields.


The project has made a difference within the institution in terms of understanding the need for longer-term consideration of integrated processes, for example around the management of a recruitment portfolio.  In the past our marketing, admissions and registry teams have approached this in separate exercises, but we are now working together on a new and integrated approach to this – working towards a ‘single conversation’ that allows one part of the journey to inform the next.  The course data project has allowed this, and facilitated the start of the new process.


Future Impact

Moving forward, this project will have significant impact within our university.  Our intention is to replace our own course data publications (specifically our online course finder, our web presence showing which courses are available in a given session) with a product that accepts an XCRI-CAP feed.  This is envisaged in around 15 months’ time, and the long lead-in time is a factor predominantly of the need to capture the remaining fields (and a number of other fields outside of the XCRI-CAP definition).  We anticipate that this will give greater sustainability to the XCRI-CAP project.


The other major impact will come with UCAS and other major stakeholders accept the XCRI-CAP feed rather than require manual data input, and it is a disappointment that this has yet to be facilitated.



The conclusions from this project are as follows:

  • The completion of the XCRI-CAP feed itself was relatively straight forward, though this is limited to those fields where central data exists or where existing business processes could be manipulated to produce this.
  • The completion of the feed where central data does not exist has been much more difficult.  Specifically, until the data is used within the sector it has proved difficult (despite much effort) to persuade others of the importance of improving the quality of the data until they see it published, but until it is of good quality it cannot be published.
  • We need to understand better how these data will be used by the sector as a whole – for example UCAS as noted above – and until this moves forward the feed feels to some as an academic exercise.



Our major recommendation to JISC is to persuade UCAS (and others) to adopt the XCRI-CAP feed as a way of our providing data to them.  Until this happens, the data feed will be seen as an isolated exercise and the ability of a group of colleagues to influence change will be rather limited as a result of this.



Project Contact Details:

Project Director:        Professor Sally Glen

Project Manager:       Stewart Harper

Contact email:            s.harper@leedsmet.ac.uk

Project Web URL:     http://leedsmetcoursedata.wordpress.com