Tag Archives: programme specifications

How many ways can you describe a course?

During the early stages of our OPMS project, it became apparent that most courses have not just one or two but many published freeform text descriptions of their content.  Currently, these are mostly created in Word documents, distributed internally and published via various web and paper routes.  In order to scope this information set, it was decided that I would undertake an audit by approaching the academic departments responsible for five specified programmes, on in each of our Faculties.

This work is still ongoing, but I am beginning to analyse the findings.  When visiting departments, I have tried to gather copies of all of the available programme descriptions, to determine responsibility for their creation and maintenance and ask for details of the processes involved.  Back in the office with the various descriptions in front of me, I have firstly mapped the links between descriptions available online using Visio, and secondly copied the descriptions into a spreadsheet and used a colour coding system to analyse their content (for example, blue indicates a mention of the learning aims of the programme, while brown indicates text about the department’s reputation, facilities etc.).

My findings so far include:

  • Each programme I’ve studied has between 5 and 8 descriptions, some of which do have significant overlaps
  • The descriptions include course marketing texts on the prospectus, departmental websites and external aggregator sites; student handbooks; formal programme specifications and drafts of HEAR 4.2 texts
  • Audiences include prospective students, current students, accrediting bodies, internal quality assurance staff and graduate employers
  • Different programmes focus on different aspects of the programme, e.g. knowledge gained or the employability of its graduates.  This is mostly done with consistency across programme descriptions published in different locations.
  • Shorter texts, such as the prospectus entry, are more likely to have broad coverage e.g. a sentence covering each of the programme aspects I identified, while longer descriptions such as those on departmental websites are likely to closely tailor this to a particular portrayal, e.g. repeatedly highlighting the flexibility of the programme.
  • Responsibilities for creation and maintenance of these descriptions varies widely between departments.  In many cases, responsibility for updates is not well-defined – perhaps the Head of Department will decide that updates are required across the board when a significant change occurs in a programme, or sometimes someone will spot that something needs updating and direct it to the programme leader, or a member of support staff.

The next step after completing this analysis is to decide what it means for the OPMS project, and I will post about this at a later date.

 

OPMS is underway!

Our Online Programme Management System project is now officially underway, since the first meeting of the Project Board last week.  Although a lot of background work has been completed before this point, including mapping the ‘as-is’ state and beginning to collect user requirements, this formal initiation hands responsibility for strategic guidance to key stakeholders from a wide range of academic departments and professional services.

The ‘vision’ is beginning to look quite ambitious: for a newly-designed system and related processes which will manage “all programme-level information”, and link seamlessly to systems which hold module data and regulations while providing a single intuitive interface for users to manage their own course data.  The system is expected to cover the entire programme lifecycle: from an initial idea through development and approval stages, supporting the effective management of changes and updates to information while the programme is running, and handling discontinuations.  The system will provide a single, definitive source of programme information for internal and external purposes, including the HEAR, KIS, XCRI-CAP, the prospectus, PBS, ATAS and others.

We hope to learn from the experiences of others who have taken similar routes now or in the past – if this is your institution we’d be very grateful to hear from you how you went about it, what worked and what you might do differently!

Modelling course data schedules and deadlines

How do you model what your course data is used for and when, if there are multiple, over-lapping deadlines over the course of several years just for one cohort of students?

This is the challenge we faced when collecting this information to inform the design of a new system to hold programme data centrally.

Rationale

During stage 1, programme approvals and the programme- and unit-level information created at this stage were identified as key areas for improvement.  Programme approval and review processes currently rely on the transfer of Word documents between academic departments and professional services, leaving information that could be usefully shared with prospective students trapped in an internal paper-based system.

JISC funding is also helping us to co-ordinate a collection of related course data projects, for example the KIS and the HEAR, which require information that is not consistently collected in a re-usable, electronic format.

The spirals

A group was set up to examine the potential for changing the relevant systems and processes.  We realised that while significant change was possible and desirable, we did not have the luxury of a ‘blank canvas’.   There are external key dates to work around, for example UCAS deadlines, and changes to internal deadlines should be co-ordinated to ensure that there are no unexpected knock-on effects.

During stage 1 I mapped key processes (e.g. reviews of module content, and the prospectus) using MS Visio.  However, these various linear maps did not clearly show the order in which course information must be gathered to recruit, admit and progress a particular cohort of students.

A participant in our meetings suggested that the process could be represented as concentric circles, and I worked with this idea to create a series of course data ‘spirals’, which referenced the experiences of different categories of students (UG full-time; UG part-time; PGT and so on) in terms of the deadlines by which course information is needed to move the process forward.  An example of my model, for UG FT students, is displayed below.

Schedule of UG course data events

Schedule of UG course data events