Supporting Partnerships

Why use partners?
The Enable project has worked at supporting changes within the institution, not just for the benefit of the University but also for its partners, including other HEI, FEI's and commercial partners. The project team specifically worked with 5 partner colleges, however due to issues with engagement with one college this dropped to 4 colleges. Although the project team had direct contact with these colleges it had indirect access to other colleges and their perceptions through the spoke initiatives and the stakeholder interviews completed as part of the general Enable approach.  The project aimed to use the partners to measure how successful changes within the institution would be when designing awards in partnership. It was decided that also engaging employers in the project would be problematical, due to managing their expectations and often their engagement with the institution is a one off to develop a course. They were engaged indirectly via the spoke initiatives and through discussions with internal stakeholders who engaged with commercial partners through the process of course design.
The approach
The project used a number of approaches to supporting partners in capturing expectations for the project and perceptions of course development with the University. The Project Manager started the project partners engagement with a face to face meeting of the project co-ordinators for the colleges, ( Enable: Partners Join in ) followed up by the Project Manager attending Higher Education forums at each of the colleges ( Enable: Partners). This face to face approach was important in building a relationship up with the different colleges, this was something that needed to continue through the project, but unfortunately failed whilst the Project Manager was on maternity leave. Although the Project Manager did manage some visits on returning to work it was difficult to rebuild an enthusiastic engagement with the project.
 On top of the face to face engagement the project team implemented two further communication tools, the first was simply reporting on a scheduled basis to the Project Manager and the other was the development of an online community, initially in Ning. The reporting to the Project Manager included a tracking document that would document new courses being designed, where they were in the process and noting any issues encountered with the process, on receipt of the report the agreed funding would then be released to the relevant partner. The Ning community caused the project some problems, as it changed it's funding model half way through the project, which meant previously private forums would become open to the wider community. It was felt due to the nature of some of the conversations occuring that it was important to keep the forums private, and the team subsequently moved the Ning content to a new site that offered the same functionality. However the  technology chosen to replace it subsequently also changed its funding model to that similar to Ning, causing some technical difficulties for partners accessing the site, and a lose of engagement by project partners.

Lessons Learnt

• Have a robust partnership agreement signed at the start of the partnership, this helps with any issues around engagement and managing expectations. It helps partners understand the level of commitment needed for the project to succeed.
• Understand that your project expectations have to match the level of engagement a partner already has with the University, if they have only got one award at the institution or a small cohort of students don't expect the same level of engagement with an institution with a large cohort or number of awards being delivered at the institution.
• Make sure any funding to partners is given after an expected delivery or output.
• Partners appreciate the effort of face to face meetings, and they often help with keeping up enthusiastic engagement with the project, using online tools/email is no substitute.
• Be prepared for online tools to change their funding models, this happened twice with the project team and caused disengagement with online communication for the project teams. 
• You need to be sympathetic to changes in structure at a partner college, although this should not change how you handle payments to them it may require further meetings to support new staff.

The Final Story: Change Management

The Beginnings of Enable: Enable began as the University recognised that it had always been quite good at running individual change projects and managing change within curriculum design, however that recognition was tempered with the realisation that its change projects occurred in isolation, so they produced silos or they didn’t join up effectively with other things. It was also acknowledged that, although changes in curriculum design were effective at the point of teaching and learning, the administrative aspect could be made more efficient and flexible to meet the changing requirements of the institution. Each of these issues caused effort to be duplicated. The challenge for Enable was one of joining up the numerous change initiatives and looking at how they impacted on each other, whilst supporting change.

The Change Management Approach: The project team contacted Heads of Service and Deans asking about initiatives that were running in their areas that would impact on Curriculum Design and Development within the University. The original list included 15 initiatives (for the full list of initiatives raised during the life of the project check the list out here http://www.projects.staffs.ac.uk/enable/). These initiatives included reviews, projects, and administrative changes. The project team identified the responsible 'initiative manager',  who was subsequently interviewed to discuss the origins of their work, issues they were hoping to address and any issues they encountered that were outside the scope of the original project but would nevertheless impact on their ability to deliver a successful output to their initiative. The project also discussed issues around curriculum design with other stakeholders, including tutors, administrators and support staff. The project team collated 'out of scope' issues and raised them with the Senior Management Working Group, a group of individuals from senior management and the executive. Based on the presentations, a number of new initiatives started up. These new initiatives used the recommendations of the Enable project team with regards to stakeholder engagement and understanding the requirements of everyone engaged in a particular area.

Lessons Learned: The project team felt this Change Management Approach was successful in its aims. It raised awareness of the need for Change Management across the institution and was able to highlight issues that projects were experiencing with the relevant staff to achieve action. The project team note that the benefits of the Change Management Approach would not have occurred without the following:

• A consistent message which could be given out from project team to all stakeholders engaged in initiatives. This resulted in hearing our own message repeated back to us.
• Independence/ neutrality of the project team - the project team were well known in the University, and were seen as discreet and independent of any service or faculty. This allowed stakeholders to speak freely about perceptions and issues encountered. An 'agent provocateur' department is very useful.
• The ability to understand and communicate links to systems and processes, this was something that developed during the project but was very useful in explaining how we could move forward as an institution. This was particularly useful in highlighting issues with our quality processes for external examiners and the work taken on by administrators in the faculties. Enterprise Architecture models were a useful tool to communicate the duplication of effort and information to senior management.
• A leader with sufficient weight to open doors to the right people at the start of the project, which helped in organising initial meetings with senior staff.
• Presentation is important and needs to fit your organisation. For example, for us it was important not to badge things internally as 'Enable' as this had the issue of being seen as an external project, not something internally driven. By stating 'we have found.../evidence/experience has shown us that....' it was seen as part of our day to day work, which means the work we are doing can carry on beyond Enable. 
• A consistent executive/senior management team, with a clear strategy is helpful when trying to say where you are going. Alongside this, governance needs to be clear and needs to support both the initiation of initiatives and their closure when necessary. It's OK to stop initiatives where there is no longer a benefit to them running, where their benefit is outweighed by a negative impact elsewhere or where they don't have a clear goal.

Using Archimate in the Enable Project

The project team are nearing completion of the development of an application to support external examiner appointment and reporting processes. This has provided an opportunity to assess the value of Archimate modelling in a limited scope.

Background

At the start of the Enable project, projects in the programme captured a snapshot of curriculum design and development practice to act as a baseline against which changes could be evaluated later on. We carried out an extensive series of interviews with a wide range of stakeholders to capture current practice, problems and concerns. From this we identified two major barriers to innovation with curriculum design and development processes. These were:

• a lack of communication and coordination between change projects leading to conflicting project goals and duplication of effort and a sub-optimal result for the organisation as a whole
• a focus on business process re-engineering leading to changes at the business level alone, with the potential benefits of supporting IT often overlooked.

These were aspects of change management that could be improved. Project alignment and co-ordination could be realized by introducing programme management and the focus on business architecture changes could be reduced by applying an Enterprise Architecture approach.

Quality Review

An opportunity to pilot the EA approach on a small scale arose from the recommendations of an internal quality process review which had looked at re-engineering course development, approval, monitoring and review processes.
The review identified some duplication of effort and recommended further work be done to streamline quality processes. We consulted with the University business re-engineering manager who had led the review and agreed that improvements to external examiner processes would provide an appropriate scope to try out enterprise architecture modelling.

Stakeholder Interviews

We took process maps created in the review and interviewed stakeholders from faculties and the central quality improvement service to create a snapshot of the current processes.
We used the enterprise architecture practice of looking at the processes in the context of the surrounding ‘system’. In the interviews, this required a shift away from capturing process detail (as you might if you were looking to produce BPMN models) towards capturing overviews of processes and what applications and data are used to support the processes.
This omission of process details in favour of high-level dependencies is a hard task initially as traditionally we do not model the big picture and there is a natural tendency to want the details. What must be understood is that these models are for a very different purpose than business process models. The intent of enterprise architecture models is not to document all the details but to document the coherence of the system. They show where dependencies exist and act as a focus for discussion of issues and trade-offs with stakeholders. The stakeholders know the details.

Archimate Modelling

A key part of the enterprise architecture approach is to model the current situation (the baseline or ‘as is’ model) and the future situation as it would be with your proposed changes in place (the target or ‘to be’ model). Then you analyse the gap between the two models and plan developments to bridge the gap. This could be all in one go for small scale developments or it could involve a series of incremental steps for a more strategic-level engagement.
We created a model representing the current state of the business processes based on the information provided by the stakeholders during our interviews. We then created another model to represent our vision of how the processes would operate after the improvements had been made. We used the free Archi modelling tool to create the models in the Archimate modelling language.

Using The Models

From the models, we created a series of slides to illustrate our proposal and presented it to the Enable Senior Management Working Group. In the slides, we built up the ‘as is’ and ‘to be’ models incrementally to explicitly illustrate the duplication of effort in the current situation, and how we were going to solve it.
An updated version of the slides, refactored to use Archimate 2.0, is shown below. They are best viewed full-screen to see the detail.

Archimate in enable

View more presentations from theparsnip.

Based on our presentation, we secured approval from the Senior Management Working Group to develop the application.

Conclusions

We found that the Archimate language provides a powerful means of communication with stakeholders at a relatively low cost in terms of extra effort. In particular, we found that:

• the duplication-induced chaos introduced incrementally in the slides provided a more compelling call to action than a verbal description of the problem
• the ‘to be’ model presented a clear overview of our proposed solution in the same context in which the problem had been described
• Archimate models show the big picture (coherence and overview) making them particularly well-suited to communication with senior management
• the modelling itself was a relatively small task with the bulk of the effort spent interviewing stakeholders which we would have done anyway to investigate the problem, even if we were not using Archimate
• the modelling exercise provided extra insight into the problem and the models helped to quickly develop shared understanding of the problem between stakeholders
• the Archimate language is easily accessible and stakeholders immediately engage and ask questions about the content of the model rather than what the symbols and shapes mean
• the models provided useful business context for the software developers showing explicitly how their application would support the business processes.

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.  

Survey - Funding and Innovation

Link to Survey - Perceptions of Funding, Governance and Innovation

We are hoping that staff at different institutions will help the Enable project in the search to understand how perception of institutional funding and governance can influence innovation in higher (and further) education. It only takes a few minutes and will be completely anonymous (unless you want to know more about the results or survey).

This survey has come from our thoughts and experiences from interviews with staff and discussions at different events over the last 2 and a half years. Now that we are all in a state of transition there is a hope with evidence from this survey that we can start addressing perceptions about institutional governance and how we look at innovation.