Jisc case studies wiki Case studies / Course Data - University of Birmingham
  • 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 - University of Birmingham

Funded by the: Jisc e-Learning programme.

Lead Institution: University of Birmingham.

Learner Provider Type: Higher Education

Project Duration: January 2012 - March 2013

Key Words: Course Data

Case study tags: course data, process improvement, course information, university of birmingham

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


Single Source: An Integrated Approach to Managing Programme and Module Information

University of Birmingham Poster

Project Summary

At the University of Birmingham, programme and module information is collected, modified, approved, stored and published in different ways on the basis of whether the information is required for statutory quality assurance purposes; for marketing and recruitment activity; or for internal academic management in Schools, including the publication of information to students.


The Jisc funded project Single Source project: An Integrated Approach to Managing Programme and Module Information has enabled the project team to

  • Describe the scope of programme and module information via a curriculum information map
  • Identify the different ways in which programme and module information is collected
  • Pinpoint where there is duplication in terms of data entry
  • Describe the different methods of approval for information relating to new programmes
  • Identify different system repositories (Banner; Contensis; ad hoc databases)
  • Identify different data outputs (Specification; Prospectus; Coursefinder, for example)


By being able to see the way in which the institution manages its programme and module data across central and academic units, the project has been able

  • to draw together the majority of the data sources, via middleware, in order to produce an XCRI-CAP feed
  • to re-design its internal catalogue of programme and module specifications
  • to begin discussions around rationalising (i.e. sharing or turning off) data sources
  • to automate some local data collection through a single user interface


One of the key benefits of the project will be the improvement to data quality that will arise from better and wider access to programme and module information.


The project has led to discussions of subsequent phases

  • the development of an electronic approval workflow process which would see academic colleagues designing curricula at their workstation before editing and approval and repurposing of text for a range of different outputs;
  • the local use of central data, i.e. how central data might support the production of Student Handbooks


Plans to pursue these are to be discussed more fully in academic session 2013/14.


What did we learn?


Project Scoping

One of the key lessons learnt was that it was essential to evaluate and revise project plans and deliverables on the basis of emerging information.  The project had set out to provide an automated programme approval system, as it was felt that this was the most effective and efficient means of ensuring data quality.   A system that would allow a module to be designed at local level, sent for comment, redesigned, and sent for approval and subsequent publication was extremely attractive – and continues to be so – compared to a paper rich, complex approval process that currently resides.  


There were a number of stages however that needed to be tackled before work could begin in terms of designing a workflow.  These only become apparent as the project progressed.  Despite this, the outputs will be invaluable for any future work in that they are a foundation from which to build a fully informed approval and modification system.


Programme and Module Information Complexity

The complexity of the project was demonstrated by the multiple uses of the same core curriculum data as shown in the Curriculum Information Map; alongside the need for the same information to be written/displayed in different ways depending on the audience and the purpose. For example module descriptions for QAA purposes versus those for marketing and recruitment purposes.  The project set out to determine how this could be better managed.  It was not clear at the start of the project how difficult it would be, particularly when the project refocused, to keep the right lines of communication in place.  This was overcome by ‘discovery’ sessions so that colleagues from different areas of the institution, with different responsibility and access to the data could meet together, for example the central Curriculum Management Team and the Web Co-ordinators in Colleges. 



The project was challenged part way through by the change in project director but this also enabled a fresh pair of eyes to consider if the project could deliver on time and with the resource identified.  The change in scope has delivered demonstrable benefits to any future phases of the project but did also mean that there was a change in pace, including the adoption of a new methodology and a new project team, at a critical moment in the process. 


The change in direction of the project, although essential, was a source of some frustration at local level, particularly Schools, who had looked forward to a different set of benefits.  It is still hoped that, via the work undertaken in the Jisc project, these benefits might be fully realised in future phases.


Unanswered Questions

There remain some unanswered questions as the project closes, for example

  • How KIS and XCRI-CAP data can be aligned and optimised
  • Whether data that is captured as part of our institutional management of quality and standards, and which is not entered into any system, should be part of the Single Source (for example, discipline benchmark statements which are meant to inform the student’s learning outcomes);


Technical Perspective

From a technical perspective a number of lessons were learnt. These are as follows:

  • The standard XCRI-CAP output itself is quite limited in what is being provided, i.e. the number of fields. As a consequence there will probably be the need to revisit this at a later point, either because Jisc extend it or we need to extend it (or provide a local version of it) for the posting of data from Single Source to other recipients.
  • In using the XCRI-CAP standard to move data from Single Source to Contensis (and potentially other systems) there is a need for any data fields that included html, to have the html valid and well formed. Without this the recipient system/s, Contensis will reject the data.


Immediate Impact

The most immediate impact has been in the following areas:


Programme and Module Handbook

The Handbook, which will go live for the data quality exercise, is already being used by the central team to more easily navigate around published data (i.e. programme and module specifications)


Closer working between Banner and Contensis data owners

The Banner-Contensis link will be explored more fully in a Curriculum Information Project Plan, which will be co-authored by Registry (the unit responsible for the formal programme and approval process and Banner data) and Marketing and Communications and the Web Team (who, jointly are responsible for recruitment material and Contensis/Coursefinder data).  The paper will propose how these two data streams could be better aligned.


Information efficiencies

These will be mainly around the ability of Schools to manipulate data of a restricted set of fields, via the interface.


Knowledge Built (via the Curriculum Information Map)

There is far greater understanding between the central teams who are using programme and module information (either for records/statutory or for recruitment purposes) around the different mechanisms for collecting, approving and publishing data – and the purpose of the data.  This relationship will continue to reap benefits in the future as discussions continue about how data is streamlined.


Future Impact

  • Future impact will, in the main be demonstrated by improved data quality and improved levels of satisfaction in terms of centrally held data and data processes.   Those most impacted will be academic and administrative colleagues in Schools and Colleges – and also current and prospective students.  This is part of work in progress to enrich programme and module specifications through a Curriculum Data Improvement Strategy.
  • Future impact will also be demonstrated by data efficiencies, not only in the reduction in duplication of sources (i.e. between Banner and Contensis) but also by the reduction in data entry through the use of an interface and editing rights to restricted fields, e.g. contact hours; descriptions; resources and academic lead information.
  • The XCRI CAP feed provides a level of abstraction which potentially means that it could be used by other institutions in that what it provides is the merging of data from Banner (the learning and teaching aspects of programmes and modules) and Contensis (the marketing aspects of programmes and modules). On the Banner side there is a stored procedure which is called via web service (from Nexus) which extracts the standard programme and module information and then merges it with a  web service that extracts data, i.e. programme URLS from Contensis. If institutions that used Banner but stored their programme and module data as it relates to XCRI CAP data in different places in Banner then all they would need to know is modify the stored procedure to extract the data from the appropriate place/s.  The web service itself would not need to change. Likewise if another student record system is used then again what would be required would be a different means of getting at that data in the student record system and again with this approach there would be no need to change the web service.

We should like to explore possibilities arising from this project, such as:

  • the local use of central data, i.e. how central data might support the production of Student Handbooks.  This would meet the transparency and data quality agendas
  • the alignment of programme and module review processes with the annual updating of programme and module specifications




General conclusions

The project has had demonstrable benefits in terms of bringing different central stakeholders together that are responsible for university level programme and module information.  The Team will now work with Schools and Colleges to implement a new data improvement strategy based on this foundation work.


Conclusions relevant to Jisc

The project was of great value to the institution in terms of providing the resource and mandate to begin to better co-ordinate its programme and module information across a range of central services and functions.  It also however highlighted that, in order for the benefits of the project to be fully realised, further support will be required across the sector in subsequent phases.



Recommendations for Jisc

The project has shown that programme and module information – its collection, approval, storage and publication, is extremely complex.  One of the original outputs of the institution’s project was:


the development of an automated approval workflow process which would see academic colleagues designing curricula at their workstation before editing and approval and repurposing of text for a range of different outputs


Once the scale of the complexity of the project was known, this original proposal was deferred until a later phase.  It is recommended that Jisc provide support to the community around workflow solutions.


From a technical perspective one of the biggest challenges was deciding from which system (Banner or Contensis) the data for the XCRI-CAP feed was going to come from. Moreover reconciling inconsistencies between the data held in the 2 systems also proved challenging. One example of this was that the only way to map the data between the two systems was via the KIS ID, as in Contensis the programme code form Banner which could have formed the basis for the link was not always used. This led to the need for a KIS ID needing to be created for all of our PG programmes and for this to be then used to update both Banner and Contensis. Any other institution that needs to go down this path to link systems needs to allow enough time and resource to cover issues such as these and in doing this start the discussions around this at an early point in  the project.


In order to bring systems together there is a need for the institution to have an awareness and ability (if they are writing their own) to understand middleware and web services technology. This knowledge is currently lacking in the sector and it would be worthwhile Jisc considering offering training and mentoring as part of institutions taking on their Nexus product.


Further details: email and contact names etc

Project Director: Clare McCauley (Director of Registry)

Project Manager: Vicky Holmes

Contact email: v.s.holmes@bham.ac.uk

Project Web URL: https://intranet.birmingham.ac.uk/as/single-source/index.aspx