Rollover
In the current ‘manual’ portfolio of definitive programme and module information, a programme specification exists in its approved state until it is either changed or archived. (It can also be revalidated if not changed for some time, to make sure it is still up to date and valid). A programme can, in theory, go a number of years without change.
Things need to work a little differently in the APMS for two main reasons:
- Versions of a programme need to be carefully managed when proposing changes to that programme to be delivered in future academic years.
- Agresso Students (the University’s student management system) needs both ‘static’ (unchanging across academic years, delivery modes and sessions) and ‘sessional’ (unique per academic year, delivery mode and session combination) versions of a programme. These need to be output from APMS and imported into Agresso Students.
As a result, there will be a need to roll-over programmes, including their modules and all associated modules, from one academic year to another. Taking a new 3-year undergraduate programme starting in 2012/13 as a phased introduction as an example, for the cohort enrolling in 2012/13 level 1 will be delivered in 2012/13, level 2 will be delivered in 2013/14 and level 3 will be delivered in 2014/15. When that programme is rolled-over to the next academic year (2013/14), for the cohort enrolling in 2013/14 level 1 will be delivered in 2013/14, level 2 will be delivered in 2014/15 and level 3 will be delivered in 2015/16.
In a normal modification or revalidation situation for the example programme, the modification will be made to a future academic year version of that programme once it has been rolled-over in APMS. So for example, in December 2012 the delivery team may decide to swap one of the level 1 modules for the 2013/14 cohort. The programme would be rolled-over and the modifications then made to the 2013/14 version of the level 1 module(s) and programme.
This all sounds much more complicated when trying to explain it in writing than it will be in operation! And of course a Quality Officer from the Office of Quality, Standards and Partnerships will be available to guide people through the process and offer advice.
Update
Between the project team, the Communications Development & Marketing Department (which I’ll call the Marketing Department for short) and Worktribe, we have now worked out how marketing information about programmes will be stored in the system, maintained and made available to be published on the Univerity’s website. There will be a tab on a programme record in APMS for marketing information. The academic proposing the programme will be able to enter the marketing copy and information, which is split into quite a number of fields to allow it to be presented appropriately on the website, into a marketing record on that tab and start a workflow that sends it to the Marketing Department. The Marketing Department will be able to review and suggest amendments as appropriate, and also add certain information that the proposer will not know. At the end of the workflow the marketing information is approved and will then be output, in XML files, to a shared location. The website content management system (CMS) will pick up these XML files and use the content within the programme pages on the website. There is some manual work I haven’t gone into detail about, such as APMS notifying the web team in the Marketing Department that a new programme has been created because they need to manually create the basic page on the CMS. We’ve seen the first iteration of this from Worktribe and work to get it finished is going well.
Workflows to handle programme modifications and revalidations have been developed, and after some final adjustment will be complete. For those that might not know, and at a very basic level, a programme modification allows some changes to a programme and its modules, but for more extensive changes a revalidation is needed. A revalidation basically sends a programme through the same (or at least very similar) process to that when it was originally validated as a new programme. The workflows do not change the fundamental regulations about changing programmes, which will be familiar to programme leaders, but help to improve information flow, progress tracking and make things simpler.
Worktribe has also made the first iteration of the tools to delete/archive programmes that are no longer running, which we have tried out. Again, the fundamental principals do not change but we of course need a way of doing it in APMS. The basic outline is in place, and after some updates by Worktribe should be done.
The APMS project board asked for External Examiner reports to be included in the system. These reports are currently submitted by using a form on the University’s portal site, but the board felt that since they are integral to programme management they should be incorporated into APMS. The team tested the first version of this functionality today, and it’s looking good. We came up with a few suggestions for the next iteration, and there are some field changes and template design to come, but it should be a good way of getting reports from external examiners. The inclusion of external examiners in the system also means they can approve programme modifications electronically using APMS – another benefit.
Finally, Worktribe has been busy programming for the system integration elements. We now have functionality to get outputs from APMS of curriculum information that can be imported into Agresso Students to avoid having to re-key information and set up programmes and modules where it can be avoided. We also have the facility to (currently manually, but this will change) get an XCRI-CAP file out of APMS which will eventually form a new XCRI-CAP feed on our University website. After some final tweaks and development work, this will be complete.
As you can tell from all of the above, this is a particularly busy and hectic time, but it’s very positive seeing the substantial progress being made.