Course Data - St Mary's University College


Funded by the: Jisc e-Learning programme.

Lead Institution: St Mary's University College.

Learner Provider Type: Higher Education

Project Duration: January 2012 - March 2013

Key Words: Course Data

Case study tags: course data, process improvement, enterprise architecture (ea), course information, st mary's university college

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

 

Moving to a single authoritative source of data to provide XCRI-CAP 1.2 feeds

 

St Mary's University College Poster

Project Summary

The University College is moving to more cost efficient and effective ways to publish its course information that are both sustainable and supported by technology. It also needs to ensure that such data are comparable to that of other institutions and can be used by external websites. St Mary’s needs to replace manual sourcing of information to have an integrated data collection at the point of course approval. It aims to do this by co-ordinating both process and technological change to ensure the provision of good quality course information is embedded in the University College procedures.

 

The overall aim of the project is to move to a single authoritative source of data that is electronic and can produce an XCRI-CAP 1.2 feed and other internal and external data for use by external third parties as required.

To achieve this the aims of the project were to:

 

The project intends to disseminate its experience with other small HEIs who do not have access to the resources and economies of scale that may be available to other larger HEIs. During the project, this has been undertaken through posting reports on the Jisc website and participation in Jisc meetings. Another valuable two way exchange of experience specific to ACMS  (Agresso Curriculum Management System) has been through the UNIT4 User Groups. At the conclusion of the project, as part of the Jisc and ACMS communities we will seek to maintain links with other institutions of similar size, or using a similar approach, to share experiences. 

 

What did we learn?

Lessons have been learned throughout the project and broadly fall within two themes: those relating to the management and governance of the project and those relating to the technical aspects of the project.  A further self-evaluation will be undertaken more formally at the conclusion of the project and again some months after project completion to ensure benefits are being realised.

 

Lessons learned – project management

Beyond the IT department, project management methodology has not hitherto been widely adopted throughout St Mary’s.  A more robust approach to project management may have reduced the adverse impact of some of these learning lessons.

 

Need to establish full user engagement early in project, e.g. through establishing project governance from the outset: the loss of the sponsor early in the project led to a loss of momentum and the lack of engaged users meant there was nobody obvious to step onto the vacant position.

 

Maintain visibility for project including amongst the University College executive to ensure delivery remains a priority and project resources are not diluted by needs of other projects: throughout the project there has been a significant risk that other projects at St Mary’s would “poach” project resources that had been set aside to support ACMS.  This was resisted but a higher profile for ACMS would have ensured the risk was much reduced.

 

Need to ensure priorities of external partners align with own priorities to ensure project resources are made available in a timely way, especially at critical points where partner input is critical: the heavy reliance on UNIT4 meant that their input was critical to the project.  Indeed the project’s continuing progress was reliant on the timely input from UNIT4.  When UNIT4 were unable to give the input required, the project stalled substantially before it resumed momentum on the appointment of a new UNIT4 project manager.

 

Project needs to make enough internal resource available to work with external supplier and ensure knowledge transfer from external partner to in-house team: the emphasis in project planning and budget was to ensure that enough money had been set aside to pay for the project’s external commitments.  It would have helped considerably if internal resource required for the project had been identified and quantified at the outset of the project and made available thereafter, for example by appointing a dedicated systems administrator.

 

Hiatus in key internal personnel, notably the departure of the project sponsor in May 2012, put the project back by several months: the loss of key project staff had been identified in the project risk register but in practice the risk management of this had been superficial and it took some months before the role of project sponsor could be adequately filled.

 

Project governance structures including Project Initiation Document (PID) and Project Steering Group established quite late in project: this was a direct consequence of the project sponsor’s departure early in the project, but a more robust approach to project management by users would have ensured these key documents and structures were still put in place in a timely manner.

 

Training on use of software was too early: better approach would have been to adopt a Just in Time philosophy, but this can be difficult due to availability of supplier trainers.

 

Lessons learned – technical, operational and data related

Although the findings and lessons learnt from this project derive from our specific experiences with the Agresso Curriculum Management System (ACMS) and Agresso Students information system (QL), many are generic in nature and may indicate areas for future work and revision. Whilst using a curriculum management system for sourcing marketing data makes a lot of sense, it can also present some conflicts and highlight data quality issues and operational/procedural deficiencies. Some of these are discussed below:

 

Conflict due to time spans: Curriculum Management is inherently cyclical in nature, usually, but not always, on an annual basis following HESA academic periods.  Courses are typically set up to reflect this sessionality  (in the case of QL, for each academic period, by means of an Area of Study (AOS) Code and an AOS Period – the latter reflecting ‘when’ aspects of the AOS). Many courses extend over several academic periods and are defined by a series of sessions. This can create difficulties when storing marketing information within this framework because marketing information needs to cover the complete span of the course.


For example, a typical undergraduate course will extend over three academic periods. There will be three sessional records, say Y1, Y2 and Y3, with start and end dates Sept 2013 – June 2014 (Y1), Sept 1014 – June 1015 (Y2) and Sept 1015 – June 2016 (Y3), each bearing 120 credits. As far as marketing is concerned, the start and end dates would be Sept 2013 – June 2016 and the credit value of the course should be 360. A similar situation can arise for PG masters courses that, in most cases, straddle two academic periods, even when studied full time.


It is important to ensure that within any system that attempts to generate marketing data (including XCRI-CAP) as well as manage validation and curriculum management that provision is made for setting dates and credits for the course as a whole (static level, in QL). This itself would need to be updated every year.

 

Conceptual differences between sessional data representation in QL and ACMS: Related to above, but concerned with the way subject curriculum units are connected to programme curriculum units in ACMS. This relationship is through the sessional level code. This means that AOS periods in QL need to be specified for each year of study if compatibility with ACMS is to be achieved, even though is not a pre-requisite in QL itself.

 

Difficulties of computerising a paper based system (illustrated by difficulties dealing with joint honours degrees):  Our current validation procedure is almost entirely paper based. Undergraduate programmes are effectively validated as programmes in a single subject, albeit with rules about which other subjects it may be combined with.  After the main validation process, the subject may be combined with other subjects to create a joint honours programme, which is at the top of our three tier curriculum unit hierarchy. There is a form of implicit conversion of the validated course from a second tier curriculum unit to a top tier curriculum unit. In a paper based system this hardly goes noticed, but once computerised, with clear cut definitions of the different tiers of the system, this becomes quite a difficult step.

 

Avoiding duplication of data input: XCRI-CAP provides for the data to be entered at different levels (in particular at course and presentation levels) for the same topic (e.g. objectives, learning outcomes).  This can potentially lead to duplication of data and extra data entry work. A convention for the most appropriate level(s) to hold information is advisable.

 

Differences in emphasis and presentation for textual information according to usage: Although textual content may be similar for different topics (e.g. learning outcomes), the style of presentation may differ according to mode of delivery. The prospectus may use different styles compared to the leaflet, which may differ again from those used on the external website. As far as XCRI-CAP is concerned, the current best practice seems to be to keep formatting simple.  Similarly, the actual depth of coverage may differ according to destination.

 

Lessons learned – other issues

The project has been undertaken during a time of great upheaval at St Mary’s.  A considerable amount of systems integration has taken place over the last two years.  The student record system has been called upon to provide data direct to numerous systems around the institution, including security, a new virtual learning environment, a web payments system, a new customer relationship management system, the library system, a new MS SQL reporting service, a new catering system, a new leisure centre, a new attendance monitoring system.  In addition Student Self Service has been introduced for student registration and changing personal details.  This is against a background of increasing need for improved business intelligence driven by keen competition for student enrolment, ensuring student retention and meeting statutory requirements.  Much of this business intelligence comes from the student records system.

This dependency on the student record system has led to the need for a programme of improvements in student record quality that addresses many areas including the ability to identify a greater range of cohorts and sub-cohorts, which has resulted in embarking on the revision of curriculum coding conventions.  Similarly, many areas of data quality and accuracy, such as definition of start and end dates, and award titles, are under review. Many of these improvements involve process review as much as technical solutions and are institution-wide in scope.

The introduction of ACMS and the generation of XCRI-CAP needs to be seen in perspective against this broader picture. Progress can be dependent on other changes taking place, e.g. new coding conventions and changes in validation processes, both of which are currently work in progress. The converse of this is that ACMS may require changes in our system, e.g., possibly how we represent our middle tier subject level curriculum units. There is also huge competition for resources between the various projects, of which ACMS/XCRI-CAP is but one.

 

Immediate Impact

It is difficult to pinpoint outcomes from the project that will have immediate (3-6 month) impacts on the user community.  However some immediate benefits can be identified.

 

The use of Agresso Curriculum Management System has given us insight into the technology of Agresso Business World (ABW).  This has raised the levels of understanding of ABW which, at a time when we are considering our long term system needs, will help in our understanding of the strengths and weaknesses of this leading product used in higher education.

 

The use of PRINCE2 Lite project management methodology has exposed more key users to the discipline, structure, rigour and benefits of project management which is already being applied to other IT-related projects in the same user area.

 

It has highlighted areas for additional work and data quality improvement within our existing system.

 

Future Impact

 

Conclusions

Most of the conclusions of the project flow directly from the Lessons Learned.  They can be separated into those conclusions relevant to a wider project community, and those that are quite St Mary’s specific:

 

Conclusions for the wider community

The bigger and more complex the project, the more important it is for users, project delivery team and external partners to work closely together.  An effective framework of user-led project management greatly mitigates this risk.

Reducing the scope of the project to a subset of all project deliverables, e.g., just a single postgraduate programme rather than all programmes, is a pragmatic and successful way of piloting the technology and changed business processes.  Where risks to full project delivery were becoming more pronounced, reducing the scope was a more viable option than extending the budget or the timescales.

 

The need for rigorous and thorough project planning cannot be overestimated.  Adequate resource and time contingency needs to be built in at project planning stage because there will be unforeseen technical and resource difficulties during the project

 

If project risks are properly identified and then monitored, managed and mitigated throughout the project, the chances of project success rise significantly.

 

Conclusions for St Mary’s

The work carried out on this project probably represents the start of a journey. We have a pilot system in place which can open up new marketing opportunities and improve existing management of ‘hard’ course data and a more centralised management of ‘softer’ textual and narrative data, hitherto held in documents of various kinds around the institution and not easily accessible. Given the will, the system can be developed to cover the full spectrum of course types offered by St Mary’s. This will require continued collaboration with UNIT4 and other institutions using ACMS to add additional functionality to make the system more flexible, for example, more options for controlling branching of work flow.

 

The project has also provided St Mary’s the opportunity of familiarising its staff with Agresso Business World (ABW), which is the platform on which future development of the student records system may be based.

At a time of rapid change in the institution, a project such as this that is significantly interdependent on other institutional systems will affect and be affected by rate and nature of development in those systems in ways that are hard to forecast. 

 

Recommendations

As this project reaches its inclusion, any recommendations that flow from it will be of most value where they have wider applicability to other projects and developments at St Mary’s.

 

Future development of ACMS and XCRI-CAP at St Mary’s should be integrated into the institution’s wider business strategy.  The institutional IT Strategy, currently under review, may be a key bridge to achieve this.

The partnership with suppliers is crucial.  However development should be driven by the pace that suits the institution, rather than the suppliers.

 

In an institution where project management is not widely used, a pragmatic approach to project management such as use of PRINCE2 Lite should be adopted.  The benefits of project management are very significant but an overly sophisticated version of project management can alienate users if it is imposed.

 

Further details: email and contact names etc

Project Director Dr Claire Taylor: Vice-Principal (Students External Relations)

Project Manager Richard Greathead: Senior Manager - Database Applications and Integration

Contact email richard.greathead@smuc.ac.uk

Project Web URL http://www.jisc.ac.uk/whatwedo/programmes/elearning/coursedata/stmarys.aspx