Process Automation and Continuous Integration in the JISC Enable Project

Continuing the JISC Enable Project technology retrospective, this post describes the approach we have used to automate parts of the software development process to improve the effectiveness of the development team.

Agile Project Management

The development team works in partnership with the customer to identify required features. We take a Scrum-style agile approach to software development which has the core roles of:

• Product owner - who identifies and priorities features to be developed 
• Development team - who develop features according to self-organised plans
• Scrum master - who shields the development team from distractions and removes impediments.

In the case of our external examiner application, a colleague from our central quality service department acted as product owner and regular meetings were held with the intended user base to keep other stakeholders 'in the loop' with development progress and to show new features of the application as they were developed.

We use a free online agile project management tool called Pivotal Tracker to help manage the list of features to be developed and track progress in delivering those features.

Pivotal Tracker supports iterative development processes like Scrum, where development is 'time-boxed' into short regular iterations (or sprints in Scrum terminology). In each iteration, typically lasting a week or two, software features are developed by the team. At the end of the iteration, the software is demonstrated to the product owner. Because the product owner gets to see the software regularly as it is evolving, they get a better idea of what they really want from the software. During each iteration, the product owner can change the list of features to be developed by adding, removing and reprioritising features. In this way, the product owner can steer development direction to ensure a higher quality, more appropriate product is developed.

The Process Of Delivering A Software Feature

As each feature is developed, the developers follow a process to build and test the feature before it is deployed into production. An Archimate model of our current feature delivery process is shown below. The following sections describe the steps in the process and indicate where we have introduced automation to speed up development.

Archimate 'as is' view of feature delivery

Develop Feature (Tests and Code)

Software features are developed on the Java Platform Enterprise Edition version 6 (Java EE 6) Platform as described previously on this blog. 

Create Code and Tests Using Integrated Development Environments (IDEs)

The developer creates code to implement a feature and also writes code that tests the feature. These tests can be run automatically later in the software build process. 

The developers use Integrated Development Environments (IDEs) to maximise their productivity. IntelliJ IDEA is our primary IDE but we also use NetBeans if it is better suited to a particular task.

Our IDEs have a host of features to improve productivity. These include: 

• Intelligent coding assistance
• Code generation
• Easy navigation and search of the codebase 
• Automated refactoring 
• Static analysis 
• Support for languages other than Java
• Support for technologies and frameworks we use

Automated Builds With Maven

We use Apache Maven to build and manage our software projects. We have used Apache Ant in the past to manage software builds but creation of the build files became too time-consuming. Maven takes a different approach by introducing a standard build lifecycle and a standard project folder structure which, as long as the developer abides by the convention, allows maven to build the software and run tests without the developer having to write any build files. For example, if a developer writes some unit tests and puts them in the /src/test/java folder of the project, Maven will detect and run the tests with each build automatically.

Maven is useful for getting developers to standardise on a project layout which helps new developers to get up to speed more quickly. It is also very easy to work with if you just want to perform the usual type of build activity in your project. If you need to do something that Maven can't accomplish by default or via plugins then it becomes harder to work with.

Maven also helps to manages dependencies of your software on other software libraries. This feature works very well in most instances but manual inclusion or exclusion is sometimes required when project libraries have transitive dependencies on different versions of the same library. 

Automated Tests With JUnit

We use the JUnit unit testing framework to run unit tests. Unit testing is the practice of testing individual units of code in isolation from any other units. It is the lowest level of testing in the process. The aim is to ensure that the individual units are performing correctly before they are combined to produce software applications.

The unit testing approach involves setting the unit into a known state, calling an operation on the unit with some known input data and then checking the returned value to ensure it is as expected. Developers write code which performs this setup/test/teardown behaviour. JUnit provides a way to identify tests so that they can be run automatically (by Maven) during a build and provides support for setting up before each test and tidying up afterwards and support for checking the results through use of assertions.

Source code management

When multiple developers are working on the same project, it is important to use a source code management tool (a.k.a. version control tool). A source code management tool allows multiple developers to work on the same codebase without overwriting each others changes. It keeps track of the history of changes to the code, allowing changes to be rolled back if required. It can also automatically merge changes from different developers into the latest revision. 

We use Apache Subversion for source code management. We have a subversion source code repository on one of our servers and all developers 'check out' code from the repository, make changes to it and then commit the changes back to the repository. Support for this process is built into the IDE.   

IntelliJ IDEA version control menu

Test (Local Commit)

The unit tests are run as part of each project build to test the new features that have been developed. All the unit tests are run during every build so that any bug or regression that have might have been introduced in the latest round of development. Because all of the tests are automatically run as part of the build, the developer only has to trigger the build. The unit tests are run locally (on the developers PC) to check that they all pass before the code is committed to the code repository. If the tests do not pass and the developer has a 'broken build' and commits it to the source code repository regardless, other developers who update their code to the latest revision will have the same broken build. For this reason, it is important to get the test passing locally before committing the code.

Inspect/Manually Test

Developers perform some manual running and testing of the software by installing it locally and using it as the end user would. IDEs have support for building, deploying and running software which speeds up the development, deployment and testing cycle. Manual testing is most useful to test usability and look and feel issues.

Commit

When the developer is happy with the new feature and that the tests are passing, the code is committed to the code repository. This is done from inside the IDE. The subversion code repository configuration is stored in the IDE and the developer can simply select the files to be committed and select the commit option. The developer is then shown a list of the files to be committed and is prompted for a commit message. The developer supplies a commit message describing the changes that have been made to the codebase in this revision. The code is then committed to the repository and the commit message is stored in the change history. Commit messages are important because they allow other developers to identify what happened when which is invaluable when trying to determine which revision to roll back to or update to.

Revisions and commit messages - always include a message (unlike some of the examples above)

Test (Commit Stage)

Once the developer has checked the code for the new feature into the code repository the process moves on to an automated test stage where the same commit tests are run in a different environment (on the build server) to check that the new code is portable and can run in a different environment, i.e. it is not tied to the developer's local setup in any way. 

Continuous Integration with Jenkins

We use Jenkins, an open source continuous integration server, to automate many of the operations in our build pipeline. Continuous Integration is the practice of integrating software, created by different developers, frequently, usually at least once a day. The aim is to avoid the situation, often encountered in traditional software development, where integration of software components happens late in a project and leads to significant problems getting the components to work together. With continuous integration, any problems are identified through the automated unit and integration testing which accompanies each build. The problems can be addressed immediately, thereby reducing the risk of the project because integration problems are tackled iteratively rather than in a more risky big bang manner late in the project.

Jenkins dashboard showing build jobs

Jenkins provides a platform for running build jobs. It has support for Maven builds so we take advantage of this to reduce the amount of initial job configuration. To reduce the amount of work even further, we use NetBeans, which has excellent Jenkins support, to create the job in Jenkins from the local Maven project. Strictly speaking, NetBeans has support for Hudson rather than Jenkins. Jenkins was originally called Hudson and was developed by a Sun Microsystems employee Kohsuke Kawaguchi. After Oracle Corporation bought Sun Microsystems and took a rather overbearing approach to engagement with the Hudson developer community, the community voted with their feet and created Jenkins as a fork of the Hudson codebase. Oracle continues to develop Hudson in the absence of the community and Jenkins continues its healthy development with regular updates and a multitude of plugins. Setting up a Jenkins installation as a Hudson Builder allows the developer to create build jobs directly from within NetBeans.

Creating a build job from within NetBeans

Jobs can be manually invoked through the Jenkins Web-based interface or automatically triggered via various mechanisms. We set up our Jenkins jobs to be triggered by changes to the code. Each Jenkins job polls the subversion code repository every 10 minutes to see whether the code has changed. When a developer commits new code, within 10 minutes Jenkins will detect that the codebase has changed and will trigger a new build of the associated Maven project. The Maven project will run as it did on developers machines, checking out the source code, running any automated tests and packaging the code into executable software - Java Web Archive (WAR) files in the case of our web applications.

Code Quality Analysis

We configure each build job in Jenkins to run quality tests on the codebase using a tool called SONAR. SONAR reports on code quality and stores the results for each build results allowing downward trends to be identified, analysed and addressed. 

SONAR dashboard gives an overview of quality metrics for a project

SONAR Time Machine showing trends in quality metrics

Deploy Artifact

If the build job succeeds, the executable WAR file is stored in our artefact repository, Artifactory. Artifactory stores the WAR files from all successful builds along with details of the build. This enables us to reproduce any build when necessary. Deployment of the WAR file to Artifactory is done by the Jenkins Artifactory plugin. The Artifactory plugin adds options to the build job to deploy the artefact and build information.

Artifactory options in a Jenkins build job

Artifactory stores the WAR from every build

Deploy Application To Staging

The next step of the build pipeline is to deploy the application to the staging server for further tests. The aim is to test the application in an environment which is as close to the production environment as possible. Currently this is a manual step, performed by a developer. 

GlassFish

We develop Java enterprise applications and run them on the GlassFish application server. The developer downloads the WAR file from artifactory and uses the GlassFish Admin Console to deploy it and run it. This takes care of the code side of the application. The database also needs to be updated to work with the new code.

GlassFish administration console

MyBatis Migrations

We use MyBatis Migrations to manage changes to the database schema. The MyBatis Schema Migration System (MyBatis Migrations) provides a simple mechanism for versioning and migrating the schema of a database. When a new version of the application is created, if the database schema has changed, we create an SQL script to update the schema to the new schema and another to roll back from the new schema to the old. These scripts are rolled into a versioned migration script which is used by Mybatis Migrations to apply changes to the database. The developer checks the current version of the database using the Migrations tool from the command line on the staging server and updates the schema to the latest version. Once the database has been updated, the application is ready for testing.

Test (Acceptance)

The acceptance testing stage is manually invoked one but the acceptance tests are automated using Selenium Web Driver to perform browser actions of the tests. Selenium Web Driver is a tool that allows browser operation to be automated. Using it, we can create automated tests which interact with our applications in the same way that a user would.

The tests are created using the Selenium IDE which records browser actions as the user interacts with the application.

Selenium IDE showing recorded interactions

Using the Selenium IDE, use cases or user stories can be enacted and recorded. These can be saved as code to be run as automated acceptance tests.

Saving interactions as a JUnit test

With our current setup, the developer runs the automated acceptance tests from their PC. Because we are testing Web applications via the browser we can test from anywhere. If the acceptance tests pass, the application is ready for deployment to the production server.

Deploy Application To Production

To update the application on the production server to the latest version, the developer downloads the WAR file from Artifactory and uses the GlassFish admin console to deploy it and uses MyBatis Migrations to migrate the database to the latest schema. With the application upgraded the cycle begins again.

Next Steps

We are working towards implementing continuous delivery and the steps outlined above have been put in place incrementally to move us towards this goal. Continuous delivery is a software development strategy that seeks to reduce the risk involved in releasing software by increasing the frequency of release and automating the release process. We have a number of improvements to make to our build process to automate the remaining manual steps, to add a Web-based interface to allow management of builds in the pipeline and to add smoke tests to check that all is well with the environment and that the deployed application has everything it needs to run in production. 

We plan to remove manual steps through automation with Gradle builds

We plan to use Gradle builds to automate the deployment and testing operations in the later stages of our build pipeline and to manage builds pipelines using the Jenkins build pipeline plugin. If you can afford it, there are many commercial tools which will provide this functionality out of the box.

Birth, Death and Resurrection of Senior Management Engagement

At the start of the project a new Executive Pro Vice Chancellor (PVC) for Learning and Teaching had been appointed, who was the initial sponsor of the Enable project. The main role of the Executive PVC, was to chair the Senior Management Working Group (consisting of a number of senior faculty staff (Deans and/or Faculty Directors for Learning and Teaching) and a number of Directors/Heads of Services and senior colleagues. 

In addition to the start of a new PVC, the then Vice Chancellor had indicated that she would soon be retiring but had yet fixed a date.  This was subsequently confirmed as January 2011.  As a consequence, the academic years 2008/9 and 9/10 were characterised by certain amount of “planning blight” and senior managers being (understandably) cautious in the face of impending change.

Not only did the executive start the project in some state of organisational churn, so did the department the Enable team were working from. The Learning Development & Innovation (LDI) team had recently been moved (following an external review) from the University’s Information Service to the Academic Development Institute (led by the Director of Academic Development).

After the first four months of the project the Academic Development Institute was abolished and the LDI team (including all Enable project staff) became a standalone team reporting to the Executive PVC.   During this period, senior management engagement with the project was good .  There was also considerable engagement from staff involved in the various change initiatives across the University, and from award leaders, programme managers and Faculty business staff and quality administrators.

About 18 months into the project, the Executive PVC left the University (and was not replaced for about a year). Following a fairly lengthy hiatus during which it was unclear (even to the Head of LDI) who the LDI team reported to, it was agreed that the team and the Enable project should report to the Deputy Vice Chancellor through the Director of Academic Policy and Development.   Senior management engagement had waned somewhat during the “hiatus” (but “spoke” engagement had remained good), however the Deputy Vice Chancellor became very receptive to the ideas on managing change and sustaining innovation being promoted by Enable, and a good period of senior management engagement ensued.  However, this period also coincided with the “last days” of the previous Vice Chancellor and the selection and arrival of the new Vice Chancellor, who took up leadership of the University in January 2011. As a result, although engagement with Enable’s ideals was good, translation of this engagement into action was very difficult.  However, this period also saw the opportunity – seized by the Enable team – to initiate the “FLAG” work of Enable on the back of a number of Senior Leadership Team initiatives instigated by the new Vice Chancellor.

In June 2011, a new Executive PVC arrived at the University.  At this point, oversight of the LDI team moved into the new PVC’s purview although the Head of LDI continued to report to the Director of Academic Policy and Development who had similarly moved reporting lines.  This move created another “disjoint” in senior management engagement as the new PVC obviously had a great many things to take on board and to plan.  

By the end of the project, 7 of the 17 people who attended the first SMWG meeting had left the University, including the Executive PVC. Nevertheless engagement was subsequently renewed and the Executive team has now picked up messages  sent by Enable including the concept of ‘joined up thinking’, and the development of a Change Management role.  This renewed interest was due to the project team able to present a clear message of Enable to the executive thanks to previous experience with communicating with the executive team, along side this the project team were able to use senior management champions to pass the message of Enable on to the executive.

Despite the considerable “organizational churn” evidenced above, a constant and stable factor throughout has been a recognised institutional need to ensure curriculum development is responsive to demand.   This included ensuring that policies, processes, and supporting technologies for curriculum/product development were designed in a way that was responsive to the needs of both faculties and learners.   This required flexible management of the existing portfolio including the process for creating new product, along with guidelines and workflows to encourage a culture of innovation. 

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.

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.  

Seeing change with fresh eyes

Yesterdays JISC programme meeting on Transformational Change & Demonstrating Impact was incredibly useful (See the Twitter Story for other peoples viewpoints)- first for the informal conversations that occurred during the sessions, and second for helping us as a project recognise what we have been able to achieve over the past 2 years. This is an important step for us as often it is easy to get stuck on what we haven't achieved rather than what we have. This made me feel very positive - we are indeed seeing a change in culture and attitudes in the university, if not changing behaviour, we are ensuring activity within the university is focused and driven by issues now and not solutions, and stakeholder engagement has certainly increased for new initiatives.

Part of the work was done before the meeting, where we were asked to think about six activities we had done as part of the project, and six outcomes we felt had been achieved. We came up with:
Activities

1. modelling of processes to communicate need for change
2. creation of validation documentation with built in guidelines for TSL and general support
3. developing an internal Flexible Learning Toolbox to support the development of new awards using workflow, probably drawing on Pineapple software and including linking roles, competencies to the e-learning models
4. Creating a pilot for Enterprise Architecture and supporting centralised
5. Guiding work in spoke development for example TransAPEL and investigating streamlining validation
6. developing a "change heap" to allow staff to input & search initiatives within the university.
   

Outcomes

1. Understanding the requirement for programme management (Programme, Portfolio, Project)
2. Embedding Enterprise Architecture into new innovations
3. Stronger governance for innovation that is not restrictive
4. Stronger relationships between college partners and faculties; Consistent message about partnerships
5. Reducing course development from +18 months to under a year
6. Understanding by executive / senior management for a holistic approach to managing change

   

At the time of completing this task we hadn’t really put much thought into how the two linked, which was an important part of the second session of the day – how were they linked, and what was the evidence? We were told to put a story together of the points above, and during the session (thanks to us trying to fit the same story example) we ended up in a bit of a mess, with a diagram with the need for supportive notes!

So today I tried the exercise again without thinking about the example or the distractions that were inherent in the session. This gave us a much more understandable diagram - which has helped in our understanding of where the project started, the outcomes that have been supported through the work of Enable, and the impact they have had on activities within Enable. I'm now wondering the value of us documenting activities, outcomes and evidence based on themes from Enable but I think that should be kept for the Cluster to create - and perhaps write more on. I'm going to think about sessions 3 & 4 (focusing on Transformation) and consider whether evidence needs to be added to this diagram? I will blog those thoughts, plus what was discussed on the day a bit later (otherwise would have a massive blog here!).

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.

We make it so hard

Thank you Mark for the welcome back!

As Mark said in the last Enable Blog, the Enable methodologies are being successfully embedded into relevant plans and strategies, and more importantly the message that we need to think about our information as a whole and separate to our systems is becoming widely accepted within the university and we are hearing it repeated at different committees, and was widely accepted at our SMWG meeting.

The SWMG meeting on Friday, left us feeling very positive about what we have already done and the way we can move forward. We spoke about the recognised opportunities that adopting Enterprise Architecture & Programme Management would give the university, and that the lead for this needed to come from Executive. More importantly Executive recognised the need for them to be able to lead it and have gone away with a number of papers, with actions, to consider. We look forward to what takes place over the next few months.

Rather interesting it was clear that discussions around how the university needs to have a corporate view of university systems/ information/ processes, and how we manage them had taken place in other meeting where it had been deemed "to hard", and that it was easier to focus on changing small issues without recognising the projects longer term impact. We discussed that we make things hard for ourselves - by repeating the same mistakes the job becomes harder. We need to understand is using EA / TOGAF too hard? Or is it simply a matter of understanding that it's a job that needs doing, requires time and (the right) staff to enable it to happen (with the right governance)? Once this understanding has taken place and actions taken surely it is simply a matter of time and effort rather than any sort of brain surgery/rocket science? We shall see!

Another useful message we managed to communicate during the SMWG meeting was that stakeholder engagement was vital to successful engagement in managing change and the curriculum development - and this doesn't simply mean engaging in committees. It means talking to people and, importantly listening with out judging/ justifying.

Lastly we were able to successfully demonstrate the two mini projects External Examiners and TransAPEL - but we were very clear that Enable used these two mini projects as proof of concept and was not something the Enable team should be doing day to day. We need to focus on the wider aspects of Curriculum Design and Development, and help the university make good choices in the future about project work and developing its business processes etc. We need to be able to advise the Executive but not be those who implement it. It will be interesting to see how our developments are (if successfully piloted) will be embedded into the university processes. Watch here over the next few months as both systems enter a piloting phase.

Edit (07/02/2011)
Our Presentation (with sound) to the SMWG

Barriers to being flexible – Myth or Reality?

As we have spent time talking to different faculties and services it is interesting that we each have our own perceptions of reality. During a recent interview it was noted that as a university we did not encourage cross faculty working, that our processes were not flexible enough to share funding for example. This was then discussed in another interview where the person mentioned that the university did have processes that allowed for sharing funding. What is the reality? It appears to be both are, depending on your own experiences and point of view. As Mark Stiles says “often the perception shapes the reality”, can we turn this around?

One member of staff (lets call them A) was able to achieve the “miracle” of cross faculty funding by looking at things from a different angle, another (B) tried to get the same result using the traditional point of view and was unsuccessful. At the moment there is no way of telling B about this way of working, or thinking. As Enable moves forward we will be able to share the experiences and the processes from staff member A and give them to staff member B to help change their reality. This is a fairly simplistic view that breaks down as we get into perceptions on what is responsiveness. Depending on who we have spoken to some staff members believe that for an employer lead award a years turnaround from design to delivery is perfectly reasonable, other staff (and employers) however find this an extremely long time to wait to train staff. Staff often say that validation takes too long, but investigation has shown the processes are very responsive, it is the information that takes time, along with organising meetings with relevant staff and employers (where needed). There is a recognition that as a HE organisation we are often obsessed with having meetings when it would be possible to discuss things either via email or online tools such as GoogleDocs or OfficeLive. A lot of the problems around these perceptions are based on changing peoples behaviours, supporting them using new technologies and providing tools to help reduce the amount of input they need to do into forms required for the CDD process.  This is the next 6 months of Enable, as we put together a “to be” model of the university, and plan the stages around how we get there. Along with this we will be implementing some prototypes, focused on supporting our quality service with external examiners.

Dissemination and promotion

The project has being focused on producing a Project Initiation Document to support the work it is doing around modelling course related information within CDD (Course Design and Development). It has also started working towards creating the “to be” view of CDD. The team has pulled out all the interview notes from different faculties about issues around CDD and also a list of issues from its interviews with the staff involved in the different initiatives at the university. I will be recording our next stage with some photos as we try and group together all the different suggestions and issues we have collated using post it notes.

Along with the work Sam has been leading we have also been meeting with deans in each Faculty to talk about their plans for the next year and to keep them up to date with the progress of the Enable project. This has been very useful and Mark will be writing up a summary sheet of our conversations, and about some of the issues that the deans see as needing to be addressed in CDD.

We have also been supporting the SURF Review, although we were unable to attend one of the meetings we have been able to pass on the issues highlighted by the project partners. There was some interesting discussions during this meeting between perception of progress from colleges, the university, and employers. Enable is supporting this work and has provided a lot of information from the partners experiences based not just on the annual report but on the spreadsheets we ask them to complete during the design and development process of a new idea.

Seeing as I called this a dissemination and promotion post I better say a bit about the dissemination we are planning to do outside of the university. We have had our abstract approved for the  Plymouth e-Learning Conference which is in April, and we are also presenting with the rest of our programme at the next JISC eLearning experts meeting in Birmingham in March, and the JISC Conference 2010 in London in April.

Flexible Service Delivery

It has been a busy week, I have been writing a paper for a conference next year on developing an Enterprise Programme Office and using Enterprise Architecture. This has coincided with the FSD JISC meeting down in London and discussions with our Finance Director. All of which have helped with giving me clear ideas of how we should be working as a university, and how to communicate the work both internally and externally to the project.

The discussion with the Finance Director lead to “imagine if..” statements which give basis to the “To Be” model that we need to build into our modelling. I need to capture these for sharing with the project team. A number of our “imagine if” scenarios relate to the work done by the FSD programme. The workshop I attended was on behalf of Sam, but in fact, I can see a real benefit to attending these events as a project manager, as well as those with a more technical leaning. There was a lot of useful discussion about enabling institutions to talk to vendors with one voice, and enabling institutions to be clear about their requirements by using Enterpise Architecture. Although EA isn't the be all and end all it is certainly a useful framework that can be used to help FSD and has helped the Enable project, and the institution, including giving us structure to collating evidence of behaviour within the university. It has also helped us identify the need for an Enterprise Programme Office that fits with the existing Executive Programme Office that already exists.

Here is a useful blog from the session by John Townsend (Liverpool John Moore) who was part of the last afternoon session group I participated in around effective change as part of the FSD business case. He reflects on the the idea of a Programme Office, and the need for effective governance. The governance put in place by Enable has been very useful in effecting change with the use of the SMWG but we need to be clear that the governance needs to go further to support our Enterprise Programme Office.

Programme Meeting in Manchester

Well it was an interesting two days in Manchester, I found them very useful, although often the session discussions did not have clear guidance the discussions we had during them were very useful. Participants used twitter to make general notes as the sessions went on and it's now time to go through them and weed out the useful points that need to be remembered. The main theme for the sessions I attended were around initiation and planning processes. We discussed how programmes are initiated can have an impact on the processes and how we have both supply and demand driven initiation processes. I really like the work being done by ViewPoint and could see their software being adaptable to the early initiation phase to help staff consider why an award is being developed with prompts to think about innovation, engagement, and rationalisation etc.
We discussed the fact that employers attend validation when involved in an award but do they attend annual monitoring, and should learners also be able to attend reviews on awards? We also discussed whether reviews should be annual but triggered by certain events - and what would they be and how would they occur. How do we value content from processes? We need to be able to look at time inovled, re-use of content created and what the outputs are.
This is just a sample of the thoughts raised at the event, so as you can see some interesting discussions took place, its just being able to clarify them for the project and how many can be considered/ actioned within the project. Especially considering this was just one of the themes from the event.

Supporting Innovation

It has been a week of thought, discussion and production of media for the programme meeting next week. I have to say I spent some time on this, the poster should have been a quick job, and in fact the design of it was, but getting the computer to produce the required output resulted in a number of “may be out of space” and “out of memory” errors that resulted in an afternoon of me swearing at the computer! If, as someone with a “high spec” computer has so much trouble doing this simple task is it reasonable to expect staff at the university to be able to do this, and more with the technology they are provided with? Even producing the video for YouTube resulted in a number of software crashes and restarts that would cause frustration in an end user – do I want to send a report to Microsoft and let them know I have a a problem? Yes and I would also like Microsoft to fix it thanks very much!

I have also blogged on the more personal http://jiscenable.wordpress.com site about ALTC and how there is a perception of slowing innovation, based around discussions at ALTC. I also found the CETIS blog on barriers to innovation interesting (http://blogs.cetis.ac.uk/christina/2009/10/07/barriers-to-innovation/) which references a future lab report, with barriers that include Leadership, Shared Vision and Change Management, among others. This links nicely to the Enable project which is trying to address those particular barriers.

Poster for the programme meeting

This is a small version of the poster for next weeks programme meeting that is being held in Manchester.

It’s good to talk!

A big thank you to Manchester, Bolton and Leeds who made their way to Staffordshire yesterday for our second cluster meeting. We had a lot of good discussions around what we have all been working on and found that we have shared experiences in the following areas:

• Costing/ Resourcing any change in the curriculum is difficult
• “On ground” staff see limited value in QA based on the time spent doing it
• Business maps have little value without the extra layers (application etc) as processes themselves appear to be in ok shape – issues at deeper levels.
• How are processes that sit within faculties managed?
• Big focus on managing culture change
• How do we discover the hard cost of developing and delivering modules
• Useful process mapping tools are expensive, but TOGAF and Archimate very useful in themselves.
• A requirement to link awards/ modules with learning objectives and competencies.

In the afternoon Bolton University started a discussion around managing curriculum across partners and ensuring an equitable experience to all learners. This caused further discussion around how universities support dispersed interpretation of module delivery.

Manchester presented their work so far and talked about the disparity between senior staff and staff “on the ground” and how they view what would constitute improvement of CDD. They used the statement “One source of truth and the truth will be trusted” which sums up a number of issues here at Staffordshire University, not only do people consider the need for one source of the truth but also that it needs to be trusted, but how can one source fit all stakeholder needs and how can we get people to trust it?

Internal Projects

We have been talking a to a few more internally managed initiatives that are not part of the executive register and are not externally funded and discovered some interesting aspects to managing projects that has helped highlight some issues with managing innovation in the university.
The discussions we have had with project leads has included concerns. This includes often there is limited or no formal project plans to ensure scope of project, which can lead to misunderstandings as to why a project has been started, what is expected from the project and what the outputs should be. Beyond this is a fear of writing down both positive and negative aspects of cross service working - as comments that show that teams may not have worked well together before a project started, or that there were problems that could not be overcome could be politically sensitive. How can we learn from projects if there is this political fear of sharing issues and lessons? Is this only in particular services or is it across the institution, and more importantly what can we do to stop this fear? What needs to be in place to help internal projects, as a member of staff rightly pointed out - they have no way of seeing the different initiatives on in the university and who is running them. Another issue was how to understand the resourcing of projects, how do we manage cross service resources?

ALTC Presentation

As promised here is the conference presentation we did at ALTC, it is approx 14 mins long

Back from ALTC

Well what a three days! One of the first sessions after the keynote was the one done by Sam and myself (http://altc2009.alt.ac.uk/talks/show/6792), which I recorded and will try and post either later today or at the start of next week. It was a very busy session which was very positive. Sam, Mark and myself attended a number of different sessions looking at different aspects of Curriculum Design and a number of symposiums where done by the different programme clusters.

The experience of ALTC can be broken into three areas – shared experiences, suggestions in supporting Enable and questions that need asking. A lot of my thoughts have been captured in my Twitter, and need collecting along with the fuller notes I made in the sessions. Some of these include:

• can we be more flexible with tasks in CDD and delivery?
• Getting academic trust in information from central services is difficult
• Need to keep in touch with other JISC projects to ensure not reinventing the wheel
• Learner built curriculum is now a big theme for lots of institutions
• How do we embrace the informal processes and feral systems?

Capturing Perceptions

Last week was very busy, and this week will continue in that theme. We had a partner visit and tt was the programme meeting in Birmingham. This was followed by a presentation on Strategy and leadership for my course, which I started to support the work of Enable.

 UPDATE: 

This presentation has since been used at EISTA 2010 and published in Journal of Education, Informatics, and Cybernetics, Vol 2, No 3, 2010. 

This course has since been completed and I have now started an MSc in Innovation and Managing Change in Higher Education by Negotiated Learning. I have finished my first module for this but will be putting the award on hold while I go on maternity leave. 

This week I am doing a fair bit of training The main aspect is looking at TOGAF and ArchiMate with CETIS in Bolton tomorrow. 

UPDATE: 

Blog available on this day here: Enable: Where angels fear to tread 

I am also doing some mentoring/coaching as part of the next stage of my course, this work focuses on supporting another member of staff working on a large scale project. In between these days I am still looking at evaluation and capturing perceptions of stakeholders, and at the structure of a project team event for the end of June.

Perception Questionnaires

I have been given a very useful questionnaire from Cardiff University that originated at BAE on finding out what people want from a project, and then measuring how successful we have been in providing it in the future. The questionnaire has been adapted from BAE and to asks the project lead (or stakeholders in the project) the following:

• List 5 achievements for the project
• For each of the 5 achievements score them 10 (Most Important) - 1 (Least Important)
• For each of the 5 achievements score them 4 (Delighted with how it works at the moment) to 1 (Very Dissatisfied with how it works at the moment).

Each score was asked for twice, the initiative and for Enable. The project lead (or stakeholder) is then asked for what they consider the 'Big One' (i.e. high need but very dissatisfied with at the moment) and the 'Pat on the Back' (i.e. high need but delighted with at the moment).

This has gone out to our project partners via the VSN. I also found a useful questionnaire online "The Organisation Perception Questionnaire" although this relies on rating some statements, so the team needs to think about what needs to go in there.

UPDATE:

The Organisation Perception questionnaire has not been used by Enable, however the BAE questionnaire was used (as adapted above) during the first stage of the Enable project and was found to be extremely useful when revisiting expectations against the reality and being able to capture what was/not achieved and why. It was used in conjunction with a semi-structured interview technique and a Project Overview document to support the Enable team in understanding the outputs expected from each initiative, what outcomes could be expected, and what overlaps might exist with other initiatives running in the University at the same time. This work all fitted with the Programme/Change Management approach adapted by the project team. Further information on evaluation techniques used by the Enable team will be available in August 2012,  through the Evaluation Story & Final Story written for JISC

Partner Engagement

Partner engagement has really picked up after visits have been completed at the partner sites, we are seeing blogging from tutors in Shrewsbury college on the VSN. Hopefully more blogs and discussions will grow in the next few months with the support of college coordinators such as Emma, Richard and Gerard. I will be sending out a reminder email to them all towards the end of the week to ensure that they are all happy with what is happening at their colleges.

UPDATE:

A blog post has been written to cover partner engagement from the perspective of the Enable project team.

Programme Meeting

The Programme meeting in Birmingham had a few useful sessions, although in some cases information was appearing at the wrong level for some project managers. I certainly found the networking activities/ directed discussions very useful although the form filling in the afternoon was probably less informative. One session focused on understanding your organisational type as part of Change Management/ Engagement Strategies. When we looked at the type of organisation we felt Staffordshire University was we were surprised to see such a strong leaning to Innovative Culture, however we felt that we needed a balance across some of the other cultures, in particular Business. There was some interesting engagement methods used by some of the presenting projects that I would like to consider for projects at the university, including posters in hallways for commenting on with post-its and workshops that included stakeholders to look at how they see failure rather than success! There was still not enough "here is how we did it" - in particular the change academy model was used by a project - what is this and how did they modify it and why? It looks like some investigation on their website as it was not easy to find on the HEA site.