A History of FLAG

Background

FLAG was first raised Flying forward (May 2011), this blog highlighted the reasons why a tool for supporting  course developments focusing Flexible Learning, and in consequence all course developments. FLAG (Flexible Learning Advice and Guidance) has been designed as a support tool, designed to address a number of issues highlighted by Enable. To reiterate the issues here:

• Difficulty in finding the right advice on course design at the right point
• Knowing which source of information would be the best/ most up to date
• Identification of champions to support stakeholders engaged in course design
• Reduction in faculties having to produce own advice and guidance
• Takes burden off staff to hold expert knowledge in the whole process

The project blog from May 2011discusses the concerns around doing the project, including adding to an already perceived arduous process and ensuring the right level of stakeholder engagement.

Approach

As previously mentioned in the May 2011 post the project team treated FLAG development as an internal project, which included a full project plan with clear roles and responsibilities and a list of relevant stakeholders. In September a new bog, New Product Design, was posted around the approach of FLAG. This blog discusses the issues highlighted from engaging stakeholders across the University with a clear focus on the process of course development, using the baseline information from Enable. This focus with stakeholders helped the project team unpick issues not previously noted by Enable, or reinforced issues noted during the base lining process.
The project team spoke to course developers with examples of the ArchiMate models from the baseline that focused on the different stages of course development. For initial interviews with faculty staff the model was printed out that was then drawn on to update the model to what was taking place internally. It is worth noting that the initial models focused on University level processes, by discussing these with the faculties we were able to capture the unique processes from faculties.
Each updated model was then used to create a best practice workflow broken down into three stages of course development Strategic Approval, Planning, Validation (similar to the stages in the Manchester Metropolitan University Accreditation! game, also for a screenshot of the game check out the CETIS Blog) These stages were used to help break down the workflow, even with those stages each workflow was one side of A3 paper! These workflows were then taken around for a second round of interviews, and updates, changes and other aspects of course design were then added to the workflows. For example how the faculties engaged with both Partnerships and Quality needed further modification. This round of interviews helped capture the supporting documents used by staff at different points in the flow and where they needed links to useful documents.
After the second round of interviews with the workflows the project team input the master workflow into the Pineapple system. This then helped the team sharpen the workflow, and the links to supporting documentation. Once the workflow had been completed a draft handbook was written to support the use of the software, and both were given to staff within the Learning Development and Innovation team for testing purposes. Successful completion of the tests resulted in the project team promoting FLAG as ‘in pilot’ with faculties & partners and volunteers from each were collected.
At the start of the pilot the volunteers were asked to complete a short online questionnaire asking about how they managed course developments and whether they felt that they focused on traditional course design. At this point the pilot was blogged again. However since the launch of the pilot a number of changes have occurred in the University causing engagement to decrease. The first was the restructure of faculties and schools from 6 to 4, the second was the change in credit structures for modules, and finally the process itself started to go through some change. The changes to the process had a limited impact on the pilot as they have yet to be approved by the committees and in the long term these changes will be of benefit to the project as by putting them straight in to FLAG we can ensure that course design follows the latest process, with the most up to date support documentation.
Due to these changes, and the length of time it takes to go through course development, the project team have left the piloting teams to work on FLAG at their own pace, with a number of emails every 3 weeks ensuring staff are still happy using the tool. Unfortunately recently the project team have been informed that one course design team have stopped using the tool, and we are in the process of organising a meeting to find out the issues that stopped their engagement. The project team are also organising interviews with other staff engaged in the pilot and developing an exit questionnaire for these staff to find out if their approach has been improved by the use of the tool or whether it helped them think outside of the traditional course development box.
Information about FLAG, its models and work flows have been handed over to two new initiatives in the University, the first is the Student Records System which would store information on courses post validation and the other is the JISC funded XCRI-CAP project. The project team also intend to work with the Document Management initiative to discuss opportunities to further develop the tool within that environment.

Lessons Learnt

By using FLAG as a way of starting conversations about course design within faculties it was clear that the ‘uniqueness’ of each faculty was more of a perception within that faculty rather than the reality. This is important to capture to ensure continuing stakeholder engagement – and can help them realise similarities in behaviour.
Start with interviewing senior staff engaged in curriculum design, before interviewing those ‘on the coal face’.  This then can highlight the difference between perceived processes and what actually occurs.
It is useful to interview stakeholders in small groups, for example tutors from the same faculty, business and quality administrators from the same faculty, and service teams (partnerships and quality teams are important), before getting a mix of groups together to discuss the models and workflows.
As highlighted in the Flying the Flag blog post be prepared for the pilot to take some time, initial engagement with the pilot was high, however as the course development continued some pilots became disengaged with using the software. This could be expected depending on when course teams feel they need the most support. Continued engagement with the course development teams is required at this stage.
Process ownership can be difficult, especially over a large process such as course design and is often easy to ignore in a project. It is important to get buy in from those involved in managing the process so that they can take ownership of updating the tool when the processes change. It is often easy to think around one process owner, but consider a process ownership team for those larger processes.
Make sure you are clear about the purpose of the project is and what its scope is. Although this was a project within Enable using a project plan really helped communicate the scope and purpose of the project, and how if the project was a success the tool would be handed over for further development/ embedding to the process owners, not left with the Enable team.