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.

FLAG Flying

The FLAG tool has now been launched in its pilot phase. A very exciting moment as months of mapping, tweaking and moving things around has now been put on hold as real staff get to use the tool to support their developments. Feedback has already been positive, with some very useful suggestions on improving the tool.

Initial demonstrations have highlighted the different needs of course design stakeholders. Each sees the tool as useful in different ways, from e-learning facilitators, business managers, and lecturers. It has been noted by a number of stakeholders that the amount of information collated during course development, and the use of the information for different audiences, would be useful to take on next. This is much more than was originally intended from FLAG and links to the work of the XCRI project and the embedding of a document management system at the University.

Demonstrations with partners has also highlighted a new focus for developments. Should we be looking at a separate process when partners are driving the development? Or do we need to look at a tool that allows different people to take ownership of different steps in the process? This aspect of the tool for supporting partnerships will become further unpicked as the work within the Partnership office continues.

One of the questions we were recently asked from JISC and I fully expect the same question from our senior management: 'So what are the time-scales for this?' The time-scale for this is very flexible by the nature of course design. In an ideal world we would give a two month period for pilot, however we would like those piloting the tool to go through if not all, at least most, of the work-flow. Therefore I envision a more fluid end to the pilot as the different awards are completed. We have got a questionnaire for each end of the pilot to capture how course design is considered, but one aspect I believe will be changed by FLAG is communication between the different stakeholders engaged in a particular award design, and I need to consider how this gets captured.

New Course Product Design

As Enable moves towards its final phase we are making some great progress with the work we have been doing for the FLAG project and for supporting the work around developing unified course development theory!

We have created a number of ArchiMate business layer views from a model of CDD. This has been based on the baseline Sam did for the project, but as we knew the processes had changed since then thanks to the Quality Review work we also needed to read a lot of documentation and have discussions with stakeholders involved within faculties (Directors of Teaching and Learning, Tutors and administrative staff) and services (such as Quality and Partnerships).

ArchiMate Model of Stage 2 - Award Planning (high level)

During the stakeholder discussions with the views we noted a few interesting factors:

• What is believed to happen by managers often isn't the case for those on the ground
• Processes that are believed to be sequential are often running in tandem to ensure speed in development (can cause problems)
• Responsibility of the process of new product development can sit with different individuals without any joining up.

Although the model and its views have been useful for my own purposes, and for discussions with stakeholders they were not quite at the right level to be used with the Pineapple software, which worked at a lower, business process/ work flow level. With the ArchiMate views  it was hard to create links between different stages and the support resources available to the University and highlighting the different preparation points within the processes. At this point it was clear a work flow was needed to pull out all the information from stakeholders around the advice and guidance needed to complete the course development processes.

The first attempt at creating a work-flow from idea to validation is shown below - all information in black is considered part of the core/ parent process, the text in red is information that sits within child processes (Completing documentation, Understanding Employer Engagement, Assessment etc). 

This helped clarify my thoughts before moving on to using Word as a standard tool to create the workflows, with the relevant advice attached to the different preparation points. At first each point in the core work-flow became a new stage in the process, however we soon changed that to match the stages from modelling.

• Idea 
• Initial Approval 
• Award Approval Documentation 
• Preparing for Validation 
• Validation 

 An example work-flow at this point, including questions to ask at each preparation point:

Flow and Advice v1 for Stage 3 - Preparing for Validation

These models have since been distributed to the project team to help create the child processes, as they are more familiar with that area. This was one of the reasons I chose to use Word to create the flows, so that they could copy the standardisations easily. Even so it has required a short demo document so that the flow fits the set up of Pineapple, including a two page document where on one side was the actual flow in Pineapple using screen shots and on the other was the actual flow created. As I am very close to this work it has been invaluable to hand it over to the project team for review and also over to faculties already interviewed. It has also been vital that I keep impartial to the work so that I can view all aspects of the suggestions made. I also believe it has helped that I am not a process owner in creating these flows. It has been demonstrated by some of the work already gone on that process owners have a very narrow view of curriculum design and development!

These workflows have been designed to be printed out and used for each stakeholder discussion to ensure we captured each faculties nuances around course development before building the process into Pineapple.

Models to flows to Information, Advice and Guidance

As mentioned in 'Flying Forward' the Enable team, and others in the department, have been working on creating a ToolBox (known internally as the FLAG project) for supporting curriculum design and development for those roles involved in the process.The project team started with the original baseline models and then modified them based on the existing information available on the websites, once a 'trail' process was in place interviews took place with Teaching & Learning Directors, faculty quality staff, and the Director of Quality Improvement.



The first thing we learnt with using the model from the original baseline was that the 'viewpoints' hadn't been fully considered, and were therefore either too detailed or included too many different roles. Therefore the team went back and created models from the viewpoint of the person who had come up with the new course idea.

Example: Stripped down ArchiMate view used for discussions

This then raised a number of issues with complexity of the processes, and how the main process of 'Create a new Course' consisted of different, lower level processes, and what course initiators and designers needed to consider as opposed to a module designer. The main process was broken down to different processes, and as such different views:

• Approving the idea in Faculty,
• Approving the idea in the institution,
• Developing the Idea,
• Preparing for Validation

To keep it simple we needed the 'parent' process (Create a New Course) to go into Pineapple and become the backbone of FLAG (creating a work-flow that would be developed around the 4 sub processes above).  This backbone would then allow the stakeholder engaged in CDD to move to 'child' work-flows whenever needed (we would consider developing partners a child process of getting the idea approved in Faculty).

Stakeholders happy with the high level process of CDD could then directly move to specific child process they could be struggling with (How do I set up an international partner? What can I do differently around assessment? etc).

This was great in theory,  however it was noted that there was no clear way to link process within Pineapple. Thankfully the Plymouth team were contacted before we started this project and have been very supportive in developing Pineapple to support processes beyond the original intention of APEL. After putting together a specification document for this change they are now working on making this possible.

UPDATE: 
2012/07 It is now possible to create parent, child and grandparent relationships between processes within Pineapple. 

Enable had already noted that the course development process was under review, and that faculties have their different ways of doing their side of the development process. The creation of the 'trail' process within Pineapple has helped us identify a baseline for faculties and the Quality Improvement Service to discuss and view issues/ holes already highlighted. It helped those engaged in the process see how the tool would be used, identify differences in their processes & best practice, and inform us of any useful information/advice/ guidance (IAG) that they provide to members of staff for the different steps.

UPDATE:
2012/07 The review of course development processes is almost complete, and discussions with business owners means that FLAG will soon be handed over to our Quality team. The new process is already partly in FLAG and once approved the Quality team will make it live to users.  

Flying forward

As part of the interviews with course designers undertaken by the Enable team, and with feedback down from executive, it has been noted that course development and design could be more efficient by bringing together all the relevant documentation, guidance and advice into one 'ToolBox'.

Issues it will address:

• 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 tool will be designed to align information, advice and guidance to the workflow and decision processes surrounding flexible course delivery and design. It will bring together work done in faculties, services, by our e-Learning Models project, and work by the LDI on bringing together course design roles and competencies. Initially we envisioned this to be a 'quick and dirty' tool based on hyperlinking in documents, however we soon saw this would not be the best solution (and as mentioned in previous posts) quick wins are often not the best solutions, and often make more quick loses. We are now hoping to use software created by the University of Plymouth and the core Pineapple software.

However as the process of course design/development is already perceived as being very arduous we need to ensure we don't add to it with an extra level of complexity. This is in some way addressed by the fact that we aren't embedding this as the one and only way of doing course design, it will simply be available for those who want/need it. It should be viewed as a support tool and by engaging stakeholders throughout the process we will (hopefully) avoid this issue.

Having seen, through Enable, projects that start without clear issues to resolve, in isolation, with inadequate stakeholder engagement and without clear goals and success factors we have taken a leaf out of our own book and started with a project plan. We have used a JISC project plan template (with some adaptations for accounting for the internal nature of the project). This plan will be used to why we started the project, what we hope to achieve, how we are evaluating it and the time-scales to achieve a pilot state. We even (possibly) have an acronym 'FLAG' (Flexible Learning Advice and Guidance) subject to agreement with the rest of the team. This can lead to project slogans like "Flying the FLAG for Course Design", well we all have to get our smiles somewhere!

A project plan on its own can't, however, be considered the best method of communication across the university. Across the university projects are often accused of communication failure. As a result of this we have already informed our SMWG about the work, asking for initial feedback (which was positive once it was recognised that no one would be forced to go through the process if they felt confident enough with flexible delivery/ design course development) and the project plans first stage is discussions with relevant stakeholders. We also have another spin off from Enable that will help with communication, this is something known internally as the 'Change Heap' and I'm planning another blog on this tool soon.