Page 1 of 13

Digital Campus Steering Group, June 2014: Business Case Assessment

Title of Proposal: Integration and Sustained Support for Systems Underpinning the PGR Code of Practice

1

Brief Description of proposal including key objectives.

This proposal is for new funding for a major update and sustainable support of the portfolio-related systems that underpin the PGR Code of Practice. This includes University-wide mandatory processes for all PGR students including Project Approval and Annual Progression. The proposal has the input and support of the University ePortfolio Steering Group and all PG Deans.

Figure 1. Overview of current systems and proposed work

An overview of the current systems and the proposed outcome of the work is shown in Figure 1. This will transform the PGR services from a fragmented and in some parts outdated (and “at risk”) collection of systems to an integrated service.

Although often referred to collectively with “ePortfolio” the PGR Code of Practice processes are technically separate systems; conceptually they are different: the PGR-specific components are structured, institutionally owned processes, whilst ePortfolio is student owned and less structured.

The key objective is to have an integrated and coherent system with which we can demonstrate that the University is meeting the PGR Code of Practice in place for the period of consideration for the QAA HE Review in 2015. The proposal is inherently future proof, building in on-going support for allowing transfer of data to subsequent systems, as well as supporting

Page 2 of 13

attendance monitoring requirements.

2

Drivers / needs identified as giving rise to proposal (i.e. statement of requirements). The requirements must be clear and fully agreed by all authorising officers.

• ePortfolio is crucial to the administration of PGR, the delivery of the PGR Code of Practice and Attendance Monitoring for PGR students.

• There are issues with the on-going resilience and sustainability of the current system because components of the software platform are no longer supported and the number of staff with experience of the old platform is limited.

• The PGR ePortfolio was a state of the art system developed by FMS in 2004 and rolled out across the University to record student meetings with their supervisors and their training and development. It was developed to meet the needs of the Roberts generic training agenda and was highlighted as exemplary practice in the HEFCE special review of PGR in 2005.

• Subsequently ePortfolio has been extended and enhanced to meet the evolving needs of the University e.g. related modules to support PGR Annual Progression (‘eProgression’) and Project Approval processes have been added. These are mandatory processes used by all PGR students and supervisors. They have a high-level of engagement e.g. 1,572 PGR students completed Annual Progression online, and 442 Stage 1 PGRs completed Project Approval online in 2012/13. 98 students have completed Nomination of Examiners online (pilot).

• These University-wide PGR services have not been centrally provided and therefore have not been sustainably funded, but rather there has been a series of financial one-off investments: University strategic funding in 2007 (Progression) & 2010 (Project Approval). Therefore the PGR-specific modules are now somewhat outdated and the updating that has been done has been in a piecemeal manner i.e. it has not been fully integrated into one system. It remains 4 separate modules and does not fully meet the administrative needs of the Research Student Support Team (RSST). Long-term support for the system has been insufficient.

“As Chair of the PGR Sub-Committee of ULTSEC I would like to offer my unreserved support to the proposed new investment in the PGR-ePortfolio system. This investment is essential if we are to demonstrate that we deliver the contact between students and supervisors required in the PGR Code of Practice, and the related UKBA attendance monitoring for PGR students. PGR-ePortfolio also provides the functionality to deliver key parts of our PGR Code of Practice - learning agreements, project approval and annual progress review, as well as a record of student-supervisor interactions. Without this proposed new investment these functions will be compromised. The proposal builds on the existing work that has been done on the ePortfolio for Personal Tutoring and Taught programmes. With similar investment it is possible to achieve a high quality and efficient system to support the PGR Code of Practice, which will benefit students, supervisors, panels and School and Faculty administration. If wider discussions of the future delivery of ePortfolio are likely to delay matters may I respectfully request that the developments in the PGR-ePortfolio system proposed in this investment are supported to ensure that PGR-ePortfolio can operate in a functional and reliable manner in the interim.”

Page 3 of 13

Professor J N Marshall Postgraduate Dean Faculty of Humanities and Social Sciences

3 State clearly how this business case proposal fits into the overall strategic direction of the University and other plans. Reference should be made to: a. The major aims and objectives of the University. b. The University strategic plan. c. The Capital and infrastructure plan. d. Major Funders. How does this proposal fit with the Strategy of its funders?

This proposal plays a supporting role for postgraduate research and as such is complimentary to the institutional mission of being a world-class research-intensive university (Vision 2021). The proposal supports the Learning, Teaching and Student Experience Strategy, in particular ‘G. To provide access to an environment and community, physical and virtual, within which effective learning can take place’, by providing the environment for PGR students for ‘iv. Delivering a coherent and distributed network of effective facilities, technologies and professional services that support staff and students throughout the student lifecycle. This will include scoping and implementing the findings of the DC Task and Finish Group on the Future Development of Systems to Support Learning, Teaching and the Staff and Student Experience’. By directly supporting the delivery of the PGR Code of Practice, it will support delivery of the key KPI: Postgraduate research student submission rate. The proposal is also in concordance with the Task and Finish Group recommendations in relation to UI/integration requirements and existing systems identified for supervisory support for PGR students and their supervisors.

It also has impact on cross-cutting themes, including e-learning, internationalisation (Annual Progression already being used in Singapore) and the broader postgraduate student experience (Learning, Teaching and Student Experience Strategy). In relation to the Digital Campus theme the PGR systems already involve close collaboration of various technical teams across the University (see Section 6 below for details) and already ‘plumbed into’ the Institutional Data Feed Service (IDFS). In relation to Environmental Sustainability the PGR systems reduce paper, printing and photocopying costs – these can be extensive as there are separate forms for students, supervisors, and panel /HOS/Dean in addition to photocopying and circulation of documents submitted as evidence to multiple panel members. The work will also compliment the Growth Agenda by demonstrating quality in the PGR delivery and facilitating the support of existing and future DTC provision which is core to our PGR strategy. At the policy level the proposal is important for supporting the PGR Code of Practice and aims to provide “cradle-to-grave” support for all administrative aspects of the PGR life cycle (learning agreement, project approval, annual progression, and nomination of examiners). Outside of ePortfolio, the systems also provide Schools and Graduate Schools with the ability to monitor recording meetings with supervisors (specific requirements for PGRs), with the data feeding into the Student Attendance Monitoring – SAMS process).

4 State clearly the key benefits / outputs and deliverables from this proposal.

Major update of eProgression (7 years old) Despite it being an important business system for the University, there has been no explicit funding to maintain this since its development and University-wide roll-out in 2008/9. Work on an update is underway (~30% complete) but needs resourcing to complete this.

Page 4 of 13

• All stakeholder groups will benefit (including PGR students, supervisors, School Panel members, HOS, PG Deans, School Administrators, Graduate Schools, University).

• Improved support - currently support load is high because it is in an older technology and not able to share benefits of other up-to date developments, such as the University ePortfolio, and it includes redundant complexities relating to student-supervisor mappings required for RAE at time of initial development.

• Reduced paper and printing costs by having online processes for Project Approval, Annual Progression and Nominations of Examiners.

Requested enhancements to eProgression / Project Approval • Delivering priority requests identified by Graduate Schools/School

administrators, including more flexibility with workflow and other features to better support students and staff in Progression, Project Approval and other processes.

Consolidation and integration of 4 PGR systems All stakeholder groups (as above) will benefit from greater efficiency and better user experience from: • A single consistent source of information covering all stages of the PGR

lifecycle. • Improved and more cost effective on-going support and development. • Consistent site-wide features such as filters by Schools / stage. • Sustainability gains, e.g by the use of shared software libraries • Refine Nominations of Examiners, based findings from pilot.

Increased Integration with SAP Individual work data / BW Following development by ISS, data from the ‘Individual Work’ section of SAP SLcM is now available in IDFS (Feb 2014). Work will be required to integrate this data set from SAP SLcM into the systems that support the PGR Code of Practice. Benefits include: • This will solve numerous problems related to reliance on registration

dates (not always relevant for PGR) & students who change programme codes

• Increased potential to automate processes based on this information, which will be useful for the scaling-up the Nominations process.

• Ability to ‘close the loop’ e.g. administrators see progression, approval and agreement data from SAP

Additionally we will provide a data feed from PGR Admin (potentially available to BW reports, via IDFS, subject to agreement). • Reduced data entry time • Better assurance of consistency between systems

Implementation/ training • Training for supervisors, graduate schools, School administrators &

students – for each Faculty to meet both existing demand and training for the modified system.

Faculty Training programmes integration • Equity with FMS students in automatically adding attendance records

Page 5 of 13

(useful for Progression) + extending value to students.

Review/update of Self Assessment PDP Improved utility for students and better integration with ePortfolio (and useful for Progression evidence). We will consider terminology: this is perhaps better referred to as ‘training needs analysis’.

5 How will the proposal be undertaken? Describe alternative options available and whether these have been explored.

Undertaking the Proposed Work Project Management: The 8 Work Packages (identified above in Section 4) will be delivered in close collaboration with the Graduate Schools/RSST. An Operational Group will be set up, to meet at least monthly for the duration of the project, reporting back to the PGR ePortfolio Management Group and the ePortfolio Steering Group. This Operational Group will comprise Graduate School/ RSST staff, LTMS development team, NUIT rep, and later incorporate School-level admin reps and a student representative. NB the main route by which students navigate to access the PGR Admin functions will be made via the University ePortfolio (in line with Task and Finish Group recommendations). A project plan and time-line will be developed by the Operational Group, but broadly it is intended that the bulk of the developments be completed in a 12 month period, with a further 12 month period to embed the system and complete and refine features based on evaluation/feedback. Student input: In addition to input from students on the ePortfolio and training development committees, we will also employ a student intern (ideally a PGR) via the Careers Service. The internship will be for 100 hours during term time (matched funding from Careers) to help with formative evaluation, including running student and staff focus groups. This will include input into the way the portfolio interfaces with the PGR Admin functions for students, integrates with the training programmes and the review of the Self Assessment (training needs analysis). Exploring Alternative Options Other options have been explored. Few comparable ‘off the shelf’ systems exist but a Dutch HR company, Peoplexs, have a “PhD Management system” (http://www.peoplexs.com/) and Unit 4 Business Software have recently released “Agresso Graduate Progression” (http://www.unit4software.co.uk/).

We have also investigated external broader-scoping Research Management (‘CRIS’) systems (potential replacements for MyImpact) to explore if these would match PGR Code of Practice requirements (as outlined in Appendix 2). In the event that a CRIS system could potentially cover PGR student management a second costing option has been included for an 18 month project to do the essential work and support before such a system was implemented (see Section 14). A detailed comparison of external options is attached as a separate document. Both PeopleXS and Aggresso systems could potentially support some of the Newcastle University Code of Practice processes, but have substantial overlap with and duplicating functions in the University’s SAP SLcM system, publications database, finance and features of other

Page 6 of 13

systems. Both would require major work for integration with both the core SAP product and (to integrate or replace) the ‘Individual work’ module of Campus Management (specific to Newcastle University and containing detailed PGR information). A number of potential Comprehensive Research Information Systems (CRIS) have been investigated (Converis, Research in View, Pure) to see if they would also cover PGR Code of Practice.

A high level assessment and comparison with external options are included in Appendix 3. A CRIS option for meeting PGR Code of Practice Requirements is not viable at the present time, however if at some future date this changes then it would be possible to transfer data and switch at a later date.

Advantages of developing internally Key advantages of the in-house updating the established systems are i) existing deep integration with institutional data and processes, ii) embedding into the broader institutionally supported ePortfolio, iii) building on existing expertise and deep understanding of academic data and processes and iv) having the flexibility to respond to changing local and national requirements. However, either in-house or external approaches would need both technical and process support.

6 Boundary with others. What are the dependencies and impacts both internally and externally to the University. Describe any implications of this project in terms of Information Technology and or Information Systems and Services (NU-IT).

There is (positive) overlap with the University ePortfolio; this proposal differentiates between ‘PGR Admin’ systems (Project Approval, eProgression, Nomination of Examiners etc.) as distinct to the separate ‘ePortfolio’ system (focusing more on the student-owned content). Where possible common software libraries will be used to enhance the longer-term sustainability of both systems.

The PGR Admin system and ePortfolio are dependent on the established data feeds from SAP and IT account information (via IDFS) and existing use of the University’s Active Directory service (for authentication). This proposal requires the continued close collaboration with NU-IT already established with ePortfolio. This includes collaboration across various teams including LTMS (development and technical support), IT Service Desk (front-line support), NU-IT Infrastructure team, IDFS and SAP teams and Learning Technologies team (e.g Blackboard integration for ePortfolio).

7 On-going Revenue

impact. Please summarise the impact of this proposal in terms of revenue income and associated expenditure on an on – going basis.

After the initial 2 years a further £62K per annum for staff (1.0 FTE developer + 0.2 FTE manager) for on-going support and development will be needed to support, sustain the service and respond to changes in requirements. The PGR Admin system is used by all PGR students at Newcastle and international campuses – and supports all stages of the postgraduate life-cycle, including essential mandatory processes such as Project Approval, Annual Progression and Nomination of Examiners. As well as students the systems are used by PGR Supervisors, staff on assessment Panels, HOS, Deans, and a substantial number of School and Graduate School administrators. Experience shows that requirements change (e.g. changes in University regulations and procedures and suggested improvements from stakeholders) and there are on-going technical queries (many are complex data / software issues resolved by LTMS staff via NU Service).

Page 7 of 13

8 Does this project give rise to any ethical issues that EB should be made aware of.

The work does not raise any ethical issues per se, however, part of the work will be to improve monitoring of mandatory ethics applications as part of the PGR Project Approval Process – regulations were changed in 2013 requiring all students to complete a Preliminary Ethics submission.

9 Timescales: What are the timescales and deadlines for the proposal?

2 years – the bulk of the developments be completed in a 12 month period, with a further 12 month period to embed the system and complete and refine features based on evaluation/feedback.

10 Who is the Project

Sponsor? Who is the Project Manager?

Prof. Suzanne Cholerton (as Chair of the ePortfolio Steering Group) and the 3 Postgraduate Deans. Project Manager: Simon Cotterill

11

Key Financial metrics: Taken from detailed Financial Summary.

The development costs will be £184K over 2 years with a further £62K per annum for on-going support and development.

12 Value for Money. State clearly how value for money has been taken account of in this business case proposal Reference should be made to: Industry Standards / Benchmarks etc.

The proposal provides good value for money. The level of investment required is modest compared to scale of the impact: the PGR Admin systems are used by all PGR students at Newcastle and international campuses (>2,600 students) – and support key business processes at all stages of the postgraduate life-cycle, including mandatory processes such as Project Approval, Annual Progression and Nomination of Examiners. As well as students, the systems are used by PGR Supervisors, staff on assessment Panels, HOS, Deans, and a substantial number of School and Graduate School administrators (e.g. >2,500 staff have logged into eProgression). Savings on printing, photocopying and admin time are difficult to quantify as they are distributed across schools/units with different practices – but are likely to be substantial (e.g. >1m A4 pages generated per year by Annual Progressions and Project Approvals based on 2,000 students x 130 pages of forms + evidence such as draft chapters and project proposals x 4 copies for Panels / HOS).

13 Risk The main risks relate to not doing the project i.e. degradation and systems becoming increasingly out of date and the impact on the postgraduate experience.

Page 8 of 13

See Appendix 1: Risk Register

14 Financial Summary #1 Full Project (Recommended):

Year 1 1.5 FTE (F36) developers from existing LTMS team £69,151

0.2 FTE (G) manager £11,385 100 hrs Student Intern (matched funding from Careers) £ 600 0.25 FTE Training (E25) existing IT trainer £ 8,559 School/Unit costs (consumables etc) £ 1,200

Year 2 1.5 FTE (F36) developers from existing LTMS team £71,640

0.2 FTE (G) manager £11,794 0.25 FTE Training (E25) existing IT trainer £ 8,559 School/Unit costs (consumables etc) £ 1,200

Total over 2 Years: £184,088 The development and support costs will be £184K over 2 years with a further £62K per annum for on-going support and development (1.0 FTE developer (F) + 0.2 FTE manager (G). #2 Option for Reduced Project This option is for a reduced 18 month project focussed on ensuring Annual Progression is robust in 2014/15. This option was explored in consideration that a future ‘CRIS’ system might have the required functionality for PGR Code of Practice:

Year 1 as above

Year 2 0.5 FTE (F36) developers from existing LTMS team £23,207 (6mths) 0.1 FTE (G) manager £ 2,873

School/Unit costs (consumables etc) £ 1,404 Total cost over 18 months: £118,379 This covers the deliverables of main proposal except:

• Reduced integration / consistent UI across PGR modules • Reduced scope of productivity enhancements requested by the

Graduate Schools • Integration work with SAP SLcM “Individual Work” data (ISS have

recently completed the work to make this available via IDFS) • Review of PGR Self-Assessment / Training needs analysis • Facility for PGR training records to feed into ePortfolio • Development requests from January 2016

It will include some work on data export for a potential CRIS system. We strongly recommend the full project is full funded at £184k. The reduced integration of Option #2 will detract from the user interface / integration recommendations of the DC Task and Finnish Group, with likely loss of productivity for academics, administrators and students. Implementing an external CRIS system within the timelines for meeting the Code of Practice requirements are not realistic.

15 Assumptions & Sensitivities

The main technical development will be done by existing LTMS staff

Page 9 of 13

working in partnership with colleagues in NU-IT, including staff with expert knowledge of ePortfolio and PGR Admin. The initiative relies on the continuation of established data feeds from SAP via the IDFS service. The time-frame (1 year for the bulk of the work, 1 year for refinements/rollout) assumes building on existing work and integrating libraries that can be shared between PGR Admin, ePortfolio and other systems. Writing ‘from scratch’ would take substantially longer.

16 Decision Required. What decision is being requested at this point in the proposal development?

• Approval of the project • Identifying the appropriate budget

17 Value of project for which approval is requested?

The cost is £184K over 2 years with a further £62K per annum. The impact of the project and value to the University is addressed in Section 12.

Page 10 of 13

Appendix 1. Risk Register

Risk Ref

Description of Risk

Risk Owner

Gross Risk Score

Controls Required

Control In Place and Working

Net Risk Score

Overall Control Status & Proposed additional control

measures I L T I L T

1 Prolonged service outage Triggered by: 1. Some ZOPE software components are unsupported 2. Unavailability of skilled support staff with ZOPE and PGR systems experience Consequences: 1. Impact upon students and staff (supervisors, panel members, HoS, Deans and administrators) 2. Compromise the University's ability to adhere to the PGR Code of Practice - potential negative impact upon HE review q4 2015 3. Disruption to SAMS attendance monitoring for PGRs

S.Cholerton

4

3

12

1. Replace existing system t1. 2. Ensure that the new system can be supported

and developed / customised by at least 2 staff t2.

No

4

3

12

Overall Status:

Amber

2

Systems and processes unable to support the PGR Code of Practice Triggered by: 1. Changes to existing system are more difficult / time consuming to accomplish because of the age and complexity of the code / original requirements in REF #1 2. Unavailability of skilled support staff with ZOPE and PGR systems experience Consequences: 1. Compromise the University's ability to adhere to the PGR Code of Practice - potential negative impact upon HE review q4 2015

S.Cholerton

2

3

6

1. Replace existing system t1. 2. Ensure that the new system can be supported

and developed / customised by at least 2 staff t2.

No

2

3

6

Amber

.

Page 11 of 13

3 Staffing and skills unable to support the PGR Code of Practice Triggered by: 1. Loss of staff with technical

knowledge of PGR systems 2. loss of staff with knowledge and

expertise of the PGR systems and procedures during the development phase

3. Turn-over of PG admin staff at the School/Institute level may potentially be problematic

Consequences: 1. Impact upon students and staff

(supervisors, panel members, HoS, Deans and administrators)

2. Compromise the University’s ability to adhere to the PGR Code of Practice - potential negative impact upon HE review q4 2015

S.Cholerton 3 2 6 1. We are building on the increasingly close working of the LTMS and ISS staff in the critical areas of data management and server infrastructure have moulded a team that is no longer restricted to one School or Faculty. The extended team meet regularly to discuss server and storage requirements, have worked together on a variety of projects in the past and have built a shared infrastructure for data management and governance in the IDFS project. This extended team reduces the likelihood of any individual departing team member having a critical impact on the overall project. t1

2. Involvement of multiple staff in the LTMS development team and in the Graduate Schools/RSST teams. t2

3. Turn over of School staff mitigated by training and training materials/instructions planned in this work. t3

Yes 3 1 3 Green

Page 12 of 13

Appendix 2: Outline of the PGR Code of Practice Requirements and considerations for exploring external ‘CRIS’ vendors

Newcastle University – PGR Code of Practice ~2,700 PGR students ~4,000 staff users for PGR support

Major Components A. Learning Agreements B. Project Approval C. Supervisory Meetings / monitoring D. Annual Progression E. Nominations of Examiners

Structured Online Workflow (similar for B, D & E)

1. Graduate Schools set deadlines 2. Schools assign panel members 3. Student submits form + uploads

evidence 4. Supervisor submits form 5. Panel review & make

recommendation 6. Head of School approval /

comment 7. Dean approval / comment

Additional requirements: 8. Integrate with SAP data (student /

supervisor / school / programme data etc) 9. Assign permissions (School-level admin, Faculty admin, Panel, HOS/Dean

nominees) 10. Refer back to earlier stage in workflow 11. Support different versions of forms over time •

Importance of School & Faculty Level Monitoring of workflow

Questions for Research Management System Suppliers Q1. Does your research management system include a PGR Student Management module?

Q2. What is the cost of the overall Research Management System? (set-up + annual) Q3. Is the Student Management Module an additional cost? (set-up + annual)

Q4. Could it be customized to deliver something close to this outline of requirements?

Q4. Does the company do bespoke development? Q5. What is the lead-in time? Q6. What is the cost of consultancy per day ?

Q7. Could our historical data be imported? Q8. What is the longer-term roadmap for the PGR Student Management module?

Page 13 of 13

Appendix 3. Summary of Investigations of Alternatives Based on Web analysis of CRIS suppliers together with notes on demonstrations from the last evaluation round of offerings:

• we have not been able to find any evidence of modules that would meet the functionality required to implement Newcastle's Code of PGR Practice • Thomson - Reuter have acquired Converis - it is uncertain whether both products will continue to be developed or will merge • Thomson-Reuters and Elsevier have been contacted but have not yet responded to initial enquiries • The Pearson's offerings which were identified do not appear to provide functionality in the required areas • The most credible external supplier still appears to be PeopleXS (not a CRIS system)

The process for acquiring a third party product would require a tender:

• If there were separate tenders for CRIS and PGR requirements then it would be possible for 2 CRIS suppliers to be successful • It would be most sensible for all of the requirements to be considered in one tender - this would mean that the PGR requirements and their delivery would

be dependent upon the overall CRIS project In-house PeopleXS CRIS system(s) Tender needed No Yes Yes Speed of implementation

Q2 2015 ? ?

Migration of historical data

Not needed Yes Yes

Integrated User Interface (ePortfolio)

Yes No No

Staff training Low Medium - High Medium - High Staff acceptance High ? ? Development flexibility High ? ? Data integration / location

High / local Medium / Web Medium / Web

Cost software 140k 150k ? Cost implementation 44k 44k ~£44k TCO - 2 years 184k 194k1 ? ‘Optional’ costs

- Gold support £244 /agent per yr £387 admin training per person Consultancy £684 / day

Consultancy – rate varies by vendor

Viability / % Requirements met

100% 80% Not viable at this time*

* CRIS currently at initial requirements gathering stage 1 Includes 40 days custom development +10 days consultancy (2012 pricing). Admin Training in Europe excludes travel costs.