It was suggested to me that a useful blog post would be one explaining some of the benefits of APMS by comparing processes before and after its implementation.  It seemed like some visualisations in the form of process maps might be a useful way of doing it, but after looking at some it became apparent that they don’t really represent the changes as well as I had hoped.

The fundamental principles of programme management have not changed as a result of the project, and nor was it intended to change them.  What has changed, and in my view at least has a big impact on the way we work with programme information, is how we go about recording information and the mechanisms that lie behind the various processes.  Process maps make things like modifying a programme still appear fairly convoluted when it comes to the approvals, whereas in fact the workflows in APMS mean that it is fairly simple to either click the button to decline approval (sending it back for further work) or click the button to approve the changes (forwarding it to the next stage).

Here, then, are a few examples:

Stand Alone Credit Creation

To create a new Stand Alone Credit module, there was a Microsoft Word form to complete containing information about the module selected, type of activity, academic school, and so on.  There are sections to confirm approval at the end.

To accomplish the same in APMS, the module is selected from the list of existing modules, and the other information entered (many items as list selections).  The academic confirms College approval and submits it to the Quality team who, having checked it, click the approved button and that’s it.

Short Course Creation

To create a new short course there was a Microsoft Word Short Course Application form to complete with fields including the course title, level, credit points, course leader, school and confirmation of approvals.  Accompanying the application form would be a the Short Course Specification, based on a Microsoft Word template, containing the course title, level, credit points, school, delivery mode, rationale, learning outcomes, learning and teaching strategies, module specification(s) and so on.

To accomplish the same in APMS a proposal for a new short course is created and items selected from lists where available (e.g. school, course leader) or information typed in.  The modules are selected from the module list (or new ones created) and the proposal submitted through an approvals and validation process.  There is no duplication of information needed and each person involved can see all the information related to it.

Programme Modification

To modify a programme an academic would complete a Programme Modification Form in Microsoft Word.  A series of tick boxes would indicate whether all evidence had been provided, external examiner approval gained, revised module specifications provided and more.  Details about the school, campus, affected programmes and modified modules would be provided, along with the rationale and summary of the change.  New programme and modules specifications would be written and attached, which themselves would also contain details about the school, campus and other duplicative information.

A programme modification in APMS starts with a discussion between the academic and a Quality Officer to determine whether the magnitude makes it a revalidation or a modification, and the Quality Officer starts the appropriate workflow.  For a modification, certain fields are then available for change by the academic whilst others (that would require a revalidation) are not.  Once the changes have been made to the programme and/or modules, the academic submits the modification proposal for approval, and it goes through the workflow getting the appropriate approvals until validated.  There is no duplication of information, and everyone can see where in the process the modification is and all information relating to it.

Benchmark Statements

As one final example we briefly look at benchmark statements.  The format of benchmark statements vary from subject to subject – in some cases they can be presented as numbered items whereas in others they are paragraphs of text.  In APMS each item for a subject is presented as an individual item, having been painstakingly extracted from documentation by our project intern, Louise.  Statements are presented automatically once the benchmark subject is selected, and the system presents them in a matrix with programme outcomes so that the programme leader can map where each is covered.  Previously, each programme leader would need to conduct this exercise themselves and duplicate information throughout the document to make sure it was presented in the appropriate way.

The day finally arrived. After what seems like countless hours of work and a huge amount of effort by the team (mainly because it did involve countless hours and a huge amount of effort!), APMS launched formally on Monday.

An email was sent to all academics informing them of the launch, but I know this kind of launch can often be fairly quiet in that it can take a few days or even longer before people actually start logging in and using it. However, I know from the logs that quite a number of people, mainly academics,  have been having a look around the system which is very positive. I have even had a couple of queries about the programmes in it and how changes can be made to those programmes, which is great.

One glitch we came across quite late relates to external examiner email addresses. APMS integrates with our Active Directory (AD) for its login credentials and along with University staff, External Examiners have user accounts in our AD that get transferred into APMS. External Examiners will need to access APMS to approve modifications to programmes, and to submit annual monitoring reports for the programmes they examine.  An integral and crucial feature of APMS is that it emails users to let them know when something has happened that involves them or to notify them that something is waiting for them to do.  This notification process uses what is known as the ‘Primary email address’ in AD. We want to make sure these emails go to External Examiners ‘real’ addresses (e.g. joe.bloggs@cambridge.ac.uk), but for various reasons it isn’t feasible to enter those as the primary email addresses. Instead we need to use a secondary email address field, and Worktribe are looking at how to pick up email addresses from different AD fields depending on the group the user is a member of. Hopefully we will have all of that sorted out in a few weeks, but in the meantime if we need to notify any external examiners of anything waiting for them (which is fairly unlikely for now) we can use manual workarounds.

Since my last post there has been a lot of working making final tweaks and fixing bugs that were found during testing. We already did a ‘technical’ launch of APMS which means we are now populating programme information directly into the live system.  We’re now getting ready for the full launch of the system to the rest of the University, which will take place in a few weeks.

All of the programme information needed to produce Diploma Supplements for this year’s graduates is now in the system, and work will be continuing for some time to enter all of the other information about remaining programmes. Temporary staff that were helping with that task are now concentrating on entering all of the current marketing information about our programmes. That marketing information will then be output in the form of an XCRI-CAP feed to replace the current one on our public website, and XML and PDF files that will feed the programme pages.

Worktribe have done the work to take reading lists in real time from our new reading list system (Talis Aspire) and released it to us for testing on our test system. Depending on how things work out, this could either go in the live system before we fully launch or slightly afterwards.

Worktribe has also now provided access to the APIs on the test system, which give programmatic read access to the information stored in APMS. For ON Course, this means we can start to look at using live data from APMS to feed outputs from ON Course.

We are doing a final push to get all the outstanding items finished, and then we’ll be ready to hit the metaphorical launch button (if only the button really existed like that!). I am on holiday for 2-weeks shortly, so the launch should happen very soon after I’m back.

I haven’t blogged recently about APMS, but nevertheless there has been a huge amount of working going on to get everything ready.

A great deal of testing, bug fixing and re-testing has taken place. Last week this culminated in a full run-through of the User Acceptance Test (UAT) suite to determine how ready the system is.

This week we did a ‘technical’ launch of the live system. What this means is that our internal live server is now holding the real data, is configured for use and is being used by a small number of individuals. Those individuals are continuing to input the vast amounts of programme and module data from manual sources, and efforts are being concentrated on the versions of programmes that have been taken by those graduating this year so that their diploma supplements can be produced from the system. The task is greatly complicated by the fact that programme modifications need to be retrospectively entered into the system from the correct dates so that APMS, and subsequently graduates’ diploma supplements, contain exactly the right details about what was studied.

One of the last changes we made before the ‘technical’ launch was to include the option for different titles for earlier exit awards.  For example, for “BSc (Hons) Intergalactic Space Travel Studies”, those exiting at CertHE or DipHE levels actually get the award title “CertHE/DipHE Space Studies” (in case you’re wondering, we don’t really offer that programme).  There are still some adjustments to be made before a full-scale launch, such as getting the export format for our student management system exactly right, working out the final detail of support procedures and some tweaks to programme specifications, but things are certainly looking good. In addition to the soft launch of our live server, our internal test server also had all the live data copied to it and is now in full use for final adjustment and testing. From now on, all changes have to be made on the test server first and properly tested before being released in a controller manner to the live server.

An additional item of work that Worktribe have started on is integrating APMS with the library’s new reading list system, called Talis Aspire. We wanted to avoid academics having to maintain reading list information in two places, and Talis Aspire offers functionality never intended to be in APMS so is the obvious (and right) place for reading lists to reside. What we do need to ensure, though, is that reading lists exist and can be reviewed when programmes are proposed and changed. An additional piece of work was therefore agreed to put in place a link between the two systems.

To recap what APMS does…

• Programme, short-course and stand-alone credit
  • Stores the details!
  • Proposal and building, including all module information
  • Approval and validation (both internal and external)
  • Modification and revalidation
  • Deletion
  • Rollover to next academic year
• Marketing
  • Copy writing and approval
  • Information and feeds, including XCRI-CAP and XML files for use to feed our own web pages
• External examiner reports
• Diploma Supplement production
• Generation of documentation and files
  • Programme and module specifications
  • Programme proposal proformas
  • Programme deletion forms
  • External Examiner report forms
  • Export to Agresso Students

When you look at that list and compare it with all the work that has been done, it seems like there isn’t as much there as you would expect. I can assure you there is a lot to it though, and it will make a significant difference to how we manage programme, module and related information.

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:

1. Versions of a programme need to be carefully managed when proposing changes to that programme to be delivered in future academic years.
2. 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.