Appendix A – Category B Projects · The business case for this proposal focusses on improved system efficiency throughout the busiest part of the admissions process; streamlining

Appendix A – Category B Projects

Finalised proposals yet to be reviewed by SSSG:

• UG Bulk CAS Upload• No Marks Modules in LUSI

ITGC15-P3721 October 2015

IT Services Project Management Office Project Proposal Document v2.1

ITS Project Proposal Document 1

Section 1 – Project Proposal

To be completed by the Proposer: for more information see https://lboro.service-now.com/kb_view.do?sysparm_article=KB0010911

Project Title Undergraduate CAS Bulk Upload

Project Sponsor Jennifer Nutkins Date 19/03/15

Proposed Project Manager Dawn Fendell Business Change Manager Dave Norton

Summary of Project Purpose In response to changes relating to Tier 4 visas, a CAS (Confirmation of Acceptance of Studies) Bulk Upload facility is required. The purpose of this system is to transfer data for UG applicants from LUSI to the UKVI’s Sponsorship Management System (SMS) and vice versa. This facility should be similar to the PGT/R system already in place with some minor differences to allow for the variation in structure between the UG and PGT/R sections of LUSI with UG applications coming via UCAS. This facility will need to transfer required data from LUSI to SMS for relevant applicants to enable the creation of a CAS. CAS status updates and other relevant information should be returned from the SMS through to the UG section of LUSI to provide admissions staff with up-to-date information with which to process applications and advise applicants. The CAS data should also be linked to the student record. Reporting features have already been set up for PGT/R but some minor amendments will be required to take account of UG applicants. This system was originally agreed to be delivered by August 2010 but timescales have since been continually pushed back with manual data re-entry used instead. Business Case The business case for this proposal focusses on improved system efficiency throughout the busiest part of the admissions process; streamlining processes, saving staff time and effort and improving applicant experience. It is important to note that the vast majority of CASs issued for undergraduate applicants is during the ten week period surrounding Confirmation, Adjustment and Clearing when the admissions team is inundated with decision making, processing, enquiry handling and support for academic Schools (this is the busiest part of the admissions cycle). This will free up valuable time to allow a focus on other important activities to help conversion, will reduce the risk of error due to current manual creation of CASs, and will improve our service to applicants and Schools. Approximately 300 CAS records were created manually for 2014 entry and hopefully a greater number for 2015 are expected with increased Confirmation, Adjustment and Clearing activity following increased International Office interventions. Increased efficiency is expected in central admissions in the form of reduced time required for inputting and checking CAS data on SMS, as well as dealing with error messages and queries. Most significant time savings will be (all calculated at mid spinal point rate within grade x1.25 to include pension contributions and National Insurance/(210 x7.4)):

• Inputting – assume 5 mins per CAS at Grade 4 (£17 per hour x 25 hours work = £425 per annum

• Checking – assume 2 mins per CAS at Grade 5 (£21 per hour x 10 hours work = £210 per annum

• Dealing with queries/error messages = assume 50 hours work at Grade 4 (£17 per hour = £850 per annum

https://lboro.service-now.com/kb_view.do?sysparm_article=KB0010911




Total staff savings of around £1,485. There will also be some significant gains expected in the International Office who were brought in last year to assist with the manual input of CASs (at grades AD4/5/MA6) following the hugely successful Clearing period to ensure that CASs were sent to applicants as quickly as possible to facilitate their visa applications. In the increasingly competitive recruitment environment, it is absolutely essential that the issuing of CASs and associated support for international students is made a priority. From the experience of the PG Bulk Upload system, significant customer service benefits were gained. Turnaround times for providing CASs to students were reduced from around five working days to around twenty-four/thirty-six hours in most cases. This is particularly important given the limited timeframe in which these international students (an important source of income for the University) have available to apply for their visas and may make the difference between a student being able to obtain a visa and not being able to obtain a visa. This would allow us to gain a very small number of extra international students which would easily compensate the time and costs invested in this project. The lack of a bulk upload facility currently causes error messages to be created for many UG applicants by the CAS Bulk Export process currently used for PGT/R admissions and LUSI students. These error messages have to be investigated and dealt with individually. The implementation of this system will prevent these messages from occurring. From a process point of view, the current process is clearly inefficient involving significant duplication, as information already held on the LUSI student record has to be manually re-entered into the UKVI SMS system. In addition, the proposed system would give much better management information than is presently available and allow admissions staff to better advise applicants on the status of their CAS. This project has been on the table for a significant period of time and it is important that the process of issuing CAS is consistent across all areas of admission to the university (UG, PGT, PGR). This will ensure the process is far more robust. We have agreed that no amendments to the UG Electronic Admissions System (EAS) would be needed as part of this development so there would be no other resource implications). The business case relates to the University strategy through: • Investing in Staff - the current manual process is hugely time-consuming and frustrating for all

parties. A more automated system will free up staff time to be more proactive in other areas at a crucial business period.

• Educating for Success – Attracting well qualified International applicants is essential to support our global outlook and can only be achieved if we can improve the processes and procedures needed to ensure their successfully arrival to the university.

• Growing capacity and influence – International students represent a significant funding stream for the University. The market is growing increasingly competitive within and outside the UK, and we need to be able to turn-around the issuing of a CAS to ensure applicants have adequate time to complete their visa application.

• Raising standards and aspirations – The University needs to continue to be attractive to international students, and promoted by overseas Agents. The current CAS process is not efficient and does not provide an effective applicant experience. It is likely to make the University appear less professional and of a lower standard than our competitors.

2.2 Options and Recommended* Solution. Option Key Deliverables *

Option 1: Do Nothing



Option 2: Replicate similar system to Postgraduate

A facility similar to that of PG Admissions is desired. This would require:

1. The relevant CAS information fields (to be determined) to be normalised in order to cater for more than one CAS per applicant.

2. Creation of new database structure to record details of CAS documents.

3. Creation of a Bulk Upload screen amended to fit the UG Admissions database structure.

4. Relevant reporting

*

Option 3: Review and refine current manual processes, again using International Office staff to help at the busiest time of year

1. A more streamlined manual process (though it should be noted that the process has already been refined over several years)

2. Additional International Office resource to help with the process in August and intention to give more detailed training to IO staff ahead of August to help support a more streamlined process.

Scope

Focus is on undergraduate admissions processes. PGT/PGR already have this functionality in place (as above) so are out of scope. Direct admissions processes are covered in a separate proposal.

Risks Mitigation • Development/Testing phase isn’t completed

early enough in the admissions cycle (ideally by April/May latest) to then allow for further testing with ‘live’ CAS by end June/July. This could lead to significant issues during what is then the busiest business period in August.

• Resource is re-prioritised for other Student

system developments

• Obtain approval for project pilot in timely manner.

• Projects prioritised by the ITPB

Key Stakeholders UG Admissions Manager Senior User: Dave Norton, UG Admissions Senior Tech/Supplier: Tricia Breen, IT Services

2.3 Constraints and Dependencies Proposed: Start Date February 2016 End Date April 2016

Projects Impacted Make me a Student Project.

Other Services Impacted Internally – LUSI. Externally – UKVI SMS.



2.4 Financial and Resource Implications Initial Revenue Costs No specific costs

On-going Costs None

Capital Costs None

How Funded From within IT Services existing budget

Project Approach

Project Plan (inc. milestones) • Develop core LUSI database back-end to enable CAS processing for UG

applicants (April – May) • Develop LUSI front end for above processes (May – July) • Develop reporting tools / further refinements (June – July)

Key Deliverables • Database structure within core LUSI to enable processing of UG CASs • Bulk CAS upload functionality, similar to the PG functionality • Relevant reporting • Technical documentation for the system developments • Support documentation (both for support and user training)

Transition to Live will be determined for each of the key deliverables as they are developed, to be in line with standard LUSI rollout practices. It should be noted that timescales are dependent on resource being available in ITS at the times required, and is given as elapsed time rather than actual.

2.5 Staff Requirements & Time Staff Grade Team Role Days

Required Day Rate Total Cost

ITS Staff Time (costs of Grades here https://lboro.service-now.com/kb_view.do?sysparm_article=KB0010911) Dawn Fendell MA7 Student

Information Services

Project manager 5 days

£266 £1,330

Dawn Fendell MA7 Student Information Services

Technical developer 30 days £266 £7,980

Non-ITS Staff Time Dave Norton MA7 UG

Admissions Quality Assurance and Business Change Lead

5 days £266 £1,330

UG Admissions team member

AD5 UG Admissions

User Acceptance Testing 7 days £164 £1,148

2.6 Ongoing Support Requirements Staff Grade Team Role Days


ITS Staff Time (costs of Grades here https://lboro.service-now.com/kb_view.do?sysparm_article=KB0010911)





Covered by existing LUSI support

Non-ITS Staff Time

Section 2 – PMO Governance To be completed by the PMO : for more information see https://lboro.service-now.com/kb_view.do?sysparm_article=KB0010910 Project Code Approved Date (ITPRT) Submitted to IT Portfolio Board Approved by ITPB

Notes of Review/Decision

Project Name Post mandate review recommended?

Project Board PMB Chair

PMB Membership

Project Team Membership

Filing Location







Please delete explanation text before submitting.

Project Title No Marks Modules in LUSI


Proposed Project Manager Ropinder Heer Business Change Manager Chris Carpenter

Summary of Project Purpose Currently in LUSI, when a student withdraws from a programme, goes on a leave of absence (LoA) or transfers from one programme to another, modules on the current part that have no marks entered are deleted. Though this works well for the LUSI student record, it creates a duplication of effort if the modules have to be reloaded on the new programme (in the case of transfers), and issues for the HESA returns as the deleted modules may need to be counted for the module load. Currently a long-winded trawl through the module audit has been programmed to deal with the HESA issue; however, this method is not transparent and is prone to errors (further details are given in the business case). It is therefore proposed a better method of determining no-mark modules for the HESA returns is developed which will also impact on other areas discussed in the business case. Business Case The current use of the module audit which has been programmed to deal with the HESA issue is complex and difficult to maintain or for ITS staff unfamiliar with it to provide support. It is also not transparent (so can be difficult to audit) and makes editing for individual students very difficult. Additionally, it is prone to errors as modules that have been added in error and subsequently deleted cannot be distinguished from the modules deleted as a result of a withdrawal, transfer or LoA being processed. This means that a small amount of load could be included as part of the HESA return for a small number of students when it should not and unpicking this as part of the returns process is difficult and time consuming. The current practice therefore has the potential to affect student to staff ratio calculations as additional load could be still be picked up from modules which were deleted to rectify an admin error. It is believed that this would only be a very small impact in reality, but the risk does exist. If modules were not deleted, there would be time savings in processing programme transfers as modules would be available to select for transfer to the new programme, rather than staff having to identify relevant modules from the audit of the original programme (which is not a straightforward task and is therefore prone to human error) and re-entering them on the new programme. There are also management information benefits in knowing where students have commenced but not completed a module which cannot be fully realised whilst these modules are being deleted. Finally, the processes for billing part-time PGT students are currently also having to make use of the module audit due to modules being deleted. The same issues around complexity, lack of transparency, difficulty in supporting, accuracy and risk which affect the HESA Student Return also apply here. If such modules were retained, this would mean that billing could be based on a pro-rata charge of such modules where students had withdrawn or gone on a leave of absence and would eliminate these issues.





The primary benefits therefore would be: • savings in staff time in IT Services and Academic Registry • increased transparency to all LUSI users • improved accuracy and reduced risk in compiling the HESA Student Return and running PT PGT

billing • improved management information



• Pros – no development or testing resource required for core LUSI.

• Cons – development and adjustment resource for the HESA returns for this area remains disproportionately high. This can affect high risk HESA fields (e.g. non completions) as this approach can pick up load for modules that were never studied, as well as PT PGT billing.

Option 2: Revisit the programming of this area of the HESA return to see if it could be done differently or made more efficient.

• Pros – potentially no changes to core LUSI processes required.

• Cons – core root of data anomaly (i.e. missing module load) will not be addressed; the trawl through the audit has already been revisited in previous years. This option, though warranting investigation, is unlikely to provide a useful return on the resource input into it.

Option 3: Alter the way no-mark modules are processed when a student withdraws, transfers or goes on LoA. It is proposed that a new ‘include record’ entry is created for student-module registrations (current values are Yes, Capped, No, History) which will indicate that a particular student-module registration is a historical no-mark registration and should not be used for marks calculations or other processes besides billing and HESA.

• Pros – the core data issue is resolved at source and the HESA returns and PGT PT billing are simplified and made more accurate. Further

Addition of a new entry for student-module registrations Exclusion of new entry from any module, part or degree calculations. Exclusion of new entry from any processes for boards, Learn, module feedback, timetabling, data extracts, or similar. Inclusion of new entry in calculations (pro-rated) for module load in HESA returns (relates to students who withdraw or go on leave of absence).

*



pros given in the business case. • Cons – development and testing resource is

required, especially in ensuring existing processes such as those mentioned above continue to work correctly.

Inclusion of new entry in PGT PT billing (pro-rated) (relates to students who withdraw or go on leave of absence).

Scope

The scope is limited to the key deliverables given in the options.

Risks Mitigation


system developments • Testing of changes to module records

highlights the need for more development work to core LUSI than is scheduled.


• Test results to be reported to the PMB as

early as possible by the project manager

Key Stakeholders Senior User: Chris Carpenter Senior Tech/Supplier: Tricia Breen

2.3 Constraints and Dependencies

Proposed: Start Date July 2015 or July 2016 End Date

A solution would need to be in place for the start of a new academic year.

Projects Impacted

Other Services Impacted HESA Returns, PT PGT Billing, Interfaces to Learn and CMIS, core LUSI (module registrations and marks calculations, transcripts, results promulgation)


On-going Costs None

Capital Costs None




Project Approach

Project Plan (inc. deliverables)

• Development and testing of data correction (i.e. new value and change from deletion of modules to updating a flag) (July)

• Testing of core LUSI processes and interfaces to other systems to ensure they all work with the new ‘include’ status (July)

• Possible adjustments to LUSI, depending on results of above (August) • Changes to HESA return (September)

Transition to Live will be determined for each of the key deliverables as they are developed, to be in line with standard LUSI rollout practices. It should be noted that timescales are dependent on resource being available in ITS at the times required, and are given as elapsed time rather than actual.



ITS Staff Time (costs of Grades here https://lboro.service-now.com/kb_view.do?sysparm_article=KB0010911) Ropinder Heer MA7 eAdmin Project Manager and

Technical Lead 5 £266 £1,330

Jane Snape MA7 SIS HESA return development and testing

5 £266 £1,330

Software Engineer

MA7 eAdmin Core LUSI development and testing

15 £266 £3,990

Non-ITS Staff Time Academic Registry

MA7 Student Office

Quality Assurance and LUSI and HESA testing

5 £266 £1,330



ITS Staff Time (costs of Grades here https://lboro.service-now.com/kb_view.do?sysparm_article=KB0010911) Covered by existing LUSI support

Non-ITS Staff Time











PMB Membership


Filing Location

Appendix B – Category C Projects

Proposals with limited review work required:

• Confirmation Management Information (UG Admissions) • Online Applications for Non-standard Programmes (Direct Admissions) • Online Forms for Student Administration • Online Module Update and Approval System Enhancements • Online Student Module Feedback • Careers Registration Questions (PG) • myGraduation • Individual Electoral Registration (IER)





Project Title Undergraduate eConfirmation Management Information


Proposed Project Manager Ropinder Heer Business Change Manager

Dave Norton

Summary of Project Purpose To enable real-time reporting on the admissions position during the August Confirmation period to aid management decision making and School planning. This would involve:

• University MI View: Overview for Senior Management (and to aid decision making at Intake Management Committee) with overall numbers split by fee status (UK/EU and International) at School and Department Level. An overview would distinguish likely position from intake targets to include: Accepts (UF), Near miss/Undecided (CF and CI classified by grade band), Change of Course Offers, predicted yields from Incompletes and from Insurance, and to factor in predicted rate of withdrawals/deferrals.

• School/Department MI View: (to replace current paper-based School Action Plans). To assist

School/Departments with displaying real-time progress against intake targets in the eConfirmation system as they work towards these through concessionary offer making. This would need to be at School, Department and Programme level.

• Admissions MI View: operational reporting to help manage the admissions process e.g. to identify and follow up outstanding decisions and Exception reporting to highlight critical aspects of the admissions process – e.g. Criminal Convictions, Under 16s, DTUS/SDC.

This MI facility will also need to integrate with the data within the eClearing/eAdjustment system (currently under development ) to ensure that Management Information reporting is ‘joined up’ over the entire Confirmation, Adjustment and Clearing period to ensure that progress against intake targets is effectively monitored. Business Case The business case for this proposal focusses on enabling better management of admissions numbers against intake targets. This will improve the effectiveness of the admissions process throughout the busiest and most important part of the cycle. This would significantly improve the information available for strategic and operational decision making as well as ensuring data accuracy. It will streamline processes and increase efficiency, save staff time and improve the experience of Senior Management and Schools by allowing access to accurate real time data. The Current Process The current process involves a dedicated Access database updated via spreadsheet input which in turn is populated from a LUSI data extract. The extracts are downloaded at several points throughout the day before being linked into the Access database to provide updated information.





Creation of the current Management Information relies on Excel pivot tables pulling data from the Access database. These Excel pivot tables then provide the conduit for the production of the Intake statistics (circulated to Senior Management and used at Intake Management Committee), the School Action Plans (to provide schools with the actions that need completing with regard to concessions) and to run a multitude of operational reports to facilitate the successful management of the process. The Admissions Office currently also maintains an additional discoverer designed LUSI data extract which is downloaded by Schools to assist with managing their own numbers. This presents risk of the data fields in these extracts being misinterpreted in addition to the significant School overhead in downloading these extracts (and for the Admissions Office maintaining them). Issues with the Current Process

• Data extracts are designed in Discoverer which is soon to be unsupported. • There are time implications for (a) running data extracts from LUSI, (b) manipulating data in

the Access database through running of queries and (c) refreshing the Excel pivot tables. • Due to time implications, the LUSI data extract can only contain the bare essential data fields.

This means that additional data extracts have to be run alongside this to provide the full picture which therefore gives an element of work duplication.

• The entire process is very manual increasing the risk of errors in what is crucially important data for the University.

• Since data is relying on data extracts it is not always as up-to-date as required in what is an extremely fast-paced changing environment. There is a complete lack of real-time data which featured heavily in feedback collected from academic Schools as part of review of the first year of eConfirmation – Reference to this functionality has been included in the benefits Realisation report submitted for the Electronic Admissions System (EAS) project.

• Having Schools maintaining multiple data sources outside of the EAS system is not an efficient process. There is a significant School overhead in downloading these extracts (and for the Admissions Office maintaining them). There is also a risk of the data fields in these extracts being misinterpreted.

• Currently, we have to maintain a separate list outside the system of how many applicants have been accepted against targets. This is neither an effective nor an efficient process.

Possible Business Benefits from a New System Speed

• A more streamlined process – the process should be fluid, flexible and accessible allowing the Admissions Office, Schools/Departments and Senior Management to easily access data which they require.

• Real-time data – the system should allow data to be viewed to give the ‘live’ situation regarding admissions numbers.

Accuracy • Reduction of errors – the system will reduce the amount of manual data manipulation and

therefore the risk of errors.

Efficiency • Time-saving – without the need to wait for data extracts to run or to manually manipulate

data, the system should free up valuable time to allow focus on other important tasks. • Less manual process – the current process requires multiple stages which increases the risk

of mistakes. • Removal of work duplication – there will be no need for schools to maintain separate data



sources or each run time-consuming data extracts.

Quality • Improved service to Schools – the system should allow for more targeted data and more

accessible data which will allow more focused decision making. • Reduced pressure on staff – a more robust system will put less pressure on key staff, feeding

back in to improvements in accuracy and service quality.

Relationship to the University Strategy The business case relates to the University strategy through:

• Investing in Staff – the current manual process is highly time-consuming and diverts resources from the core admissions functions, putting pressure on staff.

• Education for Success – a more accurate, efficient data model will allow better adherence to targets to ensure courses run at optimum student levels.

• Raising standards and aspirations – the current process is clunky and has the possibility of causing errors or delays which may lead to the University appearing less professional and therefore deterring applicants.



Option 2: Develop an addition to the LUSI UGEAS and eClearing systems as described above

• University MI View: Overview for Senior Management on real-time high-level admissions figures

• School/Department MI View on real-time School-related admissions figures

• Admissions MI View on real-time operational admissions figures

*

Option 3: Further develop existing manual / spreadsheet workarounds

As option 2, but this approach would be limited and probably only provide static data for Schools and Admissions.

Scope

Focus is on undergraduate admissions data during August Confirmation period. PGT/R admissions data is therefore out of scope.

Risks Mitigation



• Resource is re-prioritised for other Student system developments

• Requirements for reporting needs are unclear


• Project team to clearly and tightly define and prioritise reporting requirements. Representation from Schools and Admissions, and input from Senior Management should inform the requirements gathering.

Key Stakeholders Senior Users: Sarah Hannaford Senior Tech/Supplier: Tricia Breen


Proposed: Start Date End Date A solution would need to be in place for August of an academic year

Projects Impacted eClearing/eAdjustment system

Other Services Impacted eClearing/eAdjustment system, LUSI, UG EAS.


On-going Costs None

Capital Costs None


Project Approach

Project Plan (inc. milestones) • Refine requirements (up to April) • Develop MI for Admissions (April) • Test MI for Admissions (May) • Develop MI for Schools (May) • Test MI for Schools (May - June) • Develop MI for Senior Mgt (June) • Test MI for Senior Mgt (June) • Implementation (July)

Key Deliverables • MI for Admissions • MI for Schools • MI for Senior Management • Technical documentation for the system developments • Support documentation (both for support and user training)






ITS Staff Time (costs of Grades here https://lboro.service-now.com/kb_view.do?sysparm_article=KB0010911) Ropinder Heer MA7 eAdmin Project Manager, Business

Analyst and Technical Lead 15 £266 £3,990

Software Engineer

MA7 eAdmin Development and testing 40 £266 £10,640

Software Developer

MA6 eAdmin Testing and documentation 10 £203 £2,030

Non-ITS Staff Time Dave Norton MA7 UG

Admissions Quality Assurance, Business Analyst and Business Change Lead

10 £266 £2,660

Dave Norton MA7 UG Admissions

User acceptance testing 5 £266 £1,330

Schools Team members

MA6 Schools (various)

User Acceptance Testing 5 £203 £1,015




Non-ITS Staff Time











PMB Membership


Filing Location






Project Title Online applications for non-standard programmes (Direct Admissions)



Wendy MacDonald

Summary of Project Purpose To develop the existing on-line Application Portal (currently used for PG and FE applications) and LUSI/EAS to handle a wide range of non-standard Direct Admissions or visiting students across all levels. Ideally, this will need the following functionality: • Top-level generic form to capture common details, with routes to cater for different types of direct

admissions students, to enable the on-line form to appear bespoke. • Viewing of applicant information via an Electronic Admissions System (EAS) to permit Schools to

view applicants and make decisions. • Facility to attach documents. • Transfer of applicant data into LUSI Student once firmly accepted. • Automatic archiving of supporting documents into File Director once record transferred. • Capacity for tuition fee and scholarship/bursary information to be captured (where relevant) and

transferred to LUSI. • Production of applicant communication, e.g. offer letters, visiting student visa letters. • On-line reply functionality for applicants. • Additional Apex reports, to track the number and type of direct admissions over time.

Business Case

Loughborough University has a history of admitting students to taught programmes as visiting, or temporary, students. Students are admitted to undergraduate, postgraduate taught and postgraduate research levels, and are referred to as ‘Direct Admissions’. They include: • Fee-paying visiting students (mainly from Europe) • Non fee-paying Exchange students (including Erasmus) • Non fee-paying short-stay students doing a lab project • Science without Borders scheme (noted that SWB applicants have a separate application route

coordinated by the UUK, but still have to have LUSI records created manually) • China Partnership (3+1+1) • Intercalated Year (SSEHS) • Short courses run on behalf of an employer • Students admitted to individual module(s), either by attendance or distance learning • CDT research students attending taught module(s) • Short Summer Schools run by a number of Academic Schools The Change Team conducted a process review of the Erasmus exchange students in 2014 and it would be wise to use the review findings as a basis for this project. It should be stressed, however, that the Change Project focused primarily on outgoing Exchange students, with only minimal work looking at incoming students. In addition, other direct admissions in the above categories were not considered by the project, so a review of these will need to be undertaken. A downloadable paper visiting student application form and guidelines are on the





web www.lboro.ac.uk/admin/ar/student/forms/RG1036%20Visit/index.htm but because this form is a ‘one size fits all’ it is not always easy for the applicant to understand which parts are relevant to them, and some Schools are reluctant to use it. Multiple bespoke application forms have therefore been adopted by Schools for their cohorts of applicants. The fact that the form has to be downloaded, completed manually and emailed to the University is clunky and not representative of a world-class University. The one thing all applicants have in common is that they have to be logged onto the Direct Admissions screen (FM5056). This screen has had no development work since the establishment of LUSI in 2007, and is now barely fit for purpose. For example, it does not allow for the collection of highest level qualification information, leading to manual and time-consuming query resolution, or any reporting/statistical analysis. The PQTP office is responsible for logging the Erasmus exchange students onto LUSI FM5056, while the Admissions Office is responsible for all other direct admissions. The number of Direct Admissions handled by the Admissions Office has grown significantly in the past few years, as illustrated below, and is becoming a significant drain on resources.

Entry Year No. Direct Admissions

2011 102 2012 142 2013 269 2014 272

Whilst these numbers look low in comparison to the number of UG/PGT applications processed, because the systems that are used for Direct admissions have not been updated and are no longer fit for purpose, the admissions process is very inefficient and time consuming and involves re-entry of data, multiple handoffs and some failure demand. The University recently agreed that students would be permitted to do one or more postgraduate modules, without gaining a complete qualification (this is something which may become particularly relevant for LUiL). If the University wishes to continue to expand its provision to non-standard students, systems by which these direct admissions are processed and admitted will need to be streamlined, or additional staffing resource found. The Admissions Office currently maintains a Direct Admissions Access database, which has very recently been significantly upgraded to speed up and simplify the process of capturing, processing and even sending offer letter emails to applicants. However, despite this enhancement, all students still have to be logged onto LUSI FM5056 as well as this Access database. This creates a triplicate process (including the entry of the information by the applicant in the first instance). It was previously calculated that to log an applicant onto the direct admissions database and onto LUSI FM5056 takes approximately six minutes per applicant of AD3, AD4 or AD5 time. Where additional processes are required, such as creating offer letters, logging reply forms, creating visa letters, other applicant communications, and liaising with other Professional Services, the time required to handle a single direct admission can be as much as 18 minutes per applicant of AD3, AD4 or AD5 time. Supporting documentation then has to be manually scanned into File Director by the Student Office, which is a further drain on resources. The business case relates to the University strategy through: • Investing in Staff - the current manual process is highly time-consuming and diverts resources

from the core admissions functions, putting pressure on staff. • Educating for Success – A more streamlined direct admissions route will permit the University to

open up more programmes, short courses and modules to a much wider range of students. • Growing capacity and influence - Being able to admit a wider range of students will allow the

University to compete more effectively in the direct admissions market. • Raising standards and aspirations – The current manual direct admissions process is clunky and

http://www.lboro.ac.uk/admin/ar/student/forms/RG1036%20Visit/index.htm



does not give a good applicant experience. Is likely to make the University appear less professional, of a lower standard than our competitors and deter potential applicants.

Option Key Deliverables *


Option 2: Further develop the Direct Admissions Access database recently created by the Admissions Office, to make it more resilient, allow import of data into LUSI and some of the other functionality identified in Summary of Project Purpose.

A more streamlined process by which direct admissions can be handled within the University, which will save some time. Remove the need to complete two separate databases. Will not solve problems with multiple application forms, manual re-entry of data and document management. Issues with data being held in an Access database rather than a corporate system in terms of ongoing support, good data management and risk.

Option 3: Develop the existing on-line application portal to permit all direct admissions applicants to use it, allow Schools to view applications and make decisions through (PG) EAS, facilitate easy transfer into LUSI Student, archiving of supporting documentation and straightforward reporting/statistical analysis. Extend the CAS bulk upload facility into the UKVI Sponsor Management System (SMS) currently in place for PG applicants, to enable Direct Admissions applicants who require a CAS to be bulk uploaded into SMS, and their CAS record to be imported from SMS into LUSI.

A more streamlined process by which direct admissions can be handled within the University through a corporate system. Allow more control over direct admissions, remove the need to complete two separate databases through manual re-entry of data provide document management. Will solve the multiple application form problem and make the process more accessible to applicants. Bulk CAS upload will save time and resources, improve accuracy, and cut down on CAS import error messages within LUSI.

*

Scope

This scope of the project is essentially as outlined in the Options section above. The project will need to be broken down into clear phases, with each phase representing one or more types of (similar) applicant, e.g. Phase 1 may cover more straightforward categories of student (e.g. fee-paying visiting, China Partnerships); Phase 2 incoming exchange students, etc. The project will not cover the admission of school students coming for work experience.

Risks Mitigation



• Without IT developments, if the University continues to expand the number and range of direct admissions, it will only be possible to maintain an acceptable turnaround by putting the other, mainstream, admissions processes at risk.

• The Online Application Portal cannot be developed sufficiently to cater for the nuances of each of the different types of direct entrant


• If project cannot be prioritised, additional staffing resource is provided for the Admissions Office to ensure all applications are processed in a timely manner.

• Direct Admissions data capture to be standardised as much as possible before IT developments begin


Key Stakeholders Senior User: Wendy MacDonald Senior Tech/Supplier: Tricia Breen


Proposed: Start Date November 2015 End Date Est. June 2017 – will be refined once the project starts.

Projects Impacted Make me a Student, Agents Commission Payments

Other Services Impacted LUSI, (PG) EAS, Online application portal.


On-going Costs None

Capital Costs None


Project Approach

Project Plan (inc. milestones) • Refine and standardize direct admissions data capture requirements

(November – December 2015) • Define stages of project, depending on no. of groups of similar applicants

(December 2015) • For each stage (to be repeated):

o Make changes to Online Application Portal (2 months) o Make changes to EAS system (1 month) o Reporting (1 month) o Implementation (including help and support with process

changes) 1 month

Key Deliverables • Standardised processes and data capture for all types of direct applicants

(some of this work has been progressed by the Change Team). • Development of the Online Application Portal to cater for different types of

direct applicant. • Development of the EAS system(s) to cater for different types for direct

applicants.



• Relevant reporting. • Technical documentation for the system developments • Support documentation (both for support and user training)

Transition to Live will be determined for each of the key deliverables as they are developed, to be in line with standard LUSI rollout practices. It should be noted that timescales are dependent on resource being available in ITS and Admissions at the times required, and is given as elapsed time rather than actual.





Software Engineer

MA7 eAdmin Lead Developer 100 £266 £26,600

Non-ITS Staff Time Wendy MacDonald/ Dave Norton

MA7 Admissions Quality Assurance and Business Change Lead

30 £266 £7,980

Admissions team member

AD5 Admissions User Acceptance Testing, Business Change Champion

30 £164 £4,920

PQTP team member

MA7 PQTP User Acceptance Testing, Business Change Champion

20 £263 £5,320




Non-ITS Staff Time











PMB Membership


Filing Location





Project Title Online forms for student administration



Summary of Project Purpose Effective and fit-for-purpose processes and systems for student administration are crucial to the efficient operation of Schools and the Academic Registry, and in providing an excellent student experience. A number of key student administration processes still operate in a paper-based manner meaning that they are sub-optimal and give a poor impression to students. We therefore wish to request IT resource to bring a number of fundamental taught and research student processes into an online system. Such processes include (but are not limited to):

• Programme transfers (and route changes) where students request to be transferred to a different programme (or route – i.e. placement or non-placement variant) either within the same School or into another School.

• Withdrawals where students wish to completely withdraw from their studies at the University and Leave of Absence where students wish to request a temporary suspension of their studies, in both cases often due to health, financial or other personal circumstances.

• Extension to submission deadline request where research students wish to request an additional twelve months in which to complete and submit their thesis.

• Reassessment registration for students exercising reassessment rights to enable them to register for the specific modules in which they intend to take reassessment following the outcome of their programme or review board.

• Impaired performance (IP) claims where students wish for circumstances beyond their control to be taken into account in relation to programme and review board decisions. As well as the IP form itself, supporting evidence is also submitted.

In all of the above cases, students are required to complete a paper form which is submitted to the School or Academic Registry for different stages of approval and processing. Business Case

The current paper-based approach to the above forms is associated with a number of disadvantages which an effective IT solution could address. The benefits of such a system would therefore include the following (note, the strands of the University strategy which the benefits underpin are indicated in brackets and italics):

a) Improved student experience (Raising standards and aspirations) – o Currently, when filling in forms, students must complete details already held about

them on the LUSI database (such as ID number, name, School, programme name/code). Linking the system to the LUSI database would enable this data to be pre-populated (students would be required to be logged in through single-sign on) saving them time and improving their experience, as well as improving accuracy.

o Students would be able to see the status of their request at any time reducing follow up enquiries (and failure demand).

b) Improved efficiency and time savings (Investing in our staff) – changes in status would occur as approval is made at each stage meaning no delays in waiting for forms to pass through the internal post or be scanned and emailed/stored on a workspace. Re-entry of data





into LUSI would be eliminated reducing the time taken to process – this has the potential for significant time savings at particularly busy times of year (in excess of 1,000 route changes and 1,000 programme transfers are processed each year alone, with many occurring during the busy summer period).

c) Improved transparency (Investing in our staff; Raising standards and aspirations) – audit features would keep a record of who had approved the form at each stage and when. Students and staff would be able to check the status of a form at any time. Holdups could be easily identified and addressed rather than forms sitting on any one individual’s desk (also reducing batching).

d) Improved security and accuracy (Raising standards and aspirations) – the potential for paper forms to be lost would be eliminated and data would be held securely on the central database accessed via logins. Information already held would be reused rather than re-entered reducing the potential for errors in the process.

e) Improved record maintenance (Investing in our staff) – scanning of forms to FileDirector (or a workspace with subsequent transfer to FileDirector) would be eliminated reducing the potential for error, saving time and automating records retention. This would also eliminate the need to securely dispose of paper forms and filing within Schools.

f) Reduced requirement for local systems (Investing in our staff) – the ability to easily access records reduces the need for local tracking systems in Schools saving staff time.

g) Reduced storage requirements – scanned copies of forms on workspaces and FileDirector require much more storage space than data in database fields.

h) Reduced paper/printing costs – in addition to the financial benefits, this would have a positive environmental impact.

Note, some improvements have been made by making use of workspaces to address aspects of d) and f) but this solution has been taken as far as is practical and the other benefits cannot be realised through this approach. The project would have a positive impact on all groups of students, as well as staff involved in student administration both in Professional Services and in Schools. In the case of the forms covered under Phase 1 (see project approach below), the processes are very straightforward and generally led by the University regulations. Although process review is therefore expected to have limited impact, all processes would be reviewed before undertaking any development work to ensure that a clean flow is in place. The processes in Phase 2 are more complex and full process review would be required to ensure they are as efficient as possible and to help inform the requirements.



Option 2:Further develop the student self-service facilities to incorporate new self-service forms for students, with the appropriate workflow for staff and schools in order to administrate them.

• Student administration area (linked to Student Self-Service facilities) to enable students to log-in (via single sign-on) and complete an online form for the relevant processes.

• Web pages linked to the student administration area to provide students with guidance in completing the forms and seeking advice and support

• Workflow to enable approval by

*



relevant staff • Link to LUSI to eliminate the

need for students and staff to re-enter data when completing their aspects of the forms

• Link to LUSI to enable quick processing by Academic Registry staff without any re-entry of data

• Tracking features to enable students and staff to see the status of submitted forms at any given time

• Audit functionality to indicate who has approved each stage and when, plus any data changes made

• Built in validation of fields to improve accuracy

• More complex functionality for Phase 2 forms (to be fully determined) to include links with programme/review board functionality, reassessment module loading and document upload (for supporting evidence)

Option 3:Review the market for a package solution. It should be noted that preliminary investigations have shown that a package solution is unlikely to provide the close integration with LUSI that is necessary for many of the forms.

A package solution would need to provide functionality as per option 2 above.

Scope

The scope is limited to the key deliverables given in the options, and will be further defined when each phase of the project is progressed.

Risks Mitigation


• Students fail to engage with online system. • Failure of self-service facility. • Schools fail to engage with online system.


• Student representation will be required on the project team and communications will be sent out as appropriate throughout the course of the project.

• Manage processes in timely manner, allowing any technical issues to be addressed; develop a robust IT solution and ensure that support is in place at key points.

• Schools representation will be required on the project team and communications will be sent out as appropriate throughout the course of the project.



Key Stakeholders Senior User: Chris Carpenter Senior Tech/Supplier: Tricia Breen Project Group to include:

• Representation from Academic Registry (Student Office and Research Student Office) • Representation from Programme Administrators Liaison Group (PALG) • Student representation


Proposed: Start Date

Can start at any time of the academic calendar

End Date Depends on how each phase of the project is prioritised

Projects Impacted a) Possible project to implement Review Board functionality in LUSI, and b) IP review currently underway (both Phase 2 of this project)

Other Services Impacted LUSI. Student Self-service.


On-going Costs None

Capital Costs None


Project Approach

• Phase 1: develop a central, generic, customisable workflow solution within LUSI (a successful proof of concept is already developed)

• Phase 2: develop online forms and administration facilities for programme transfers, LOA, withdrawal, PGR extension to submission deadline request, suspension of studies request, and other straightforward forms.

• Phase 3: develop online forms and administration facilities for reassessment registration, and IP submission which are more complex and require integration with boards functionality and documentary evidence (for IP submission)

• Phase 4: redevelop the existing “intention to submit” system which has been developed via technology that would not now be chosen so needs to be replaced in the longer term and brought in line with the others above.

Timescales Phase 1: 2 months For phases 2 - 4 (to be repeated for each phase):

• Refine and standardise workflow of form administration – 1 month (per type of form, can be done concurrently for similar forms)

• Develop front end for students – 1 month (per type of form, can be done concurrently for similar forms)

• Develop back-end workflow and administration processes – 2 months (per type of form, can be done concurrently for similar



forms) • Testing – 1 month (per type of form, can be done concurrently for

similar forms) Key Deliverables • Standardised processes for form administration for each of the forms to be

developed • A central, generic workflow solution within LUSI for online forms • Online facilities for students to interact with for each of the forms to be

developed • Relevant reporting. • Technical documentation for the system developments • Support documentation (both for support and user training)





Analyst and Technical Lead 20 (per phase) = 80

£266 £21,280

Software Engineer

MA7 eAdmin Lead Developer 30 (phase 1 only)

£266 £7,980

Software Engineer

MA7 eAdmin Analyst and Lead Developer

80 (per phase 2-4) = 240

£266 £63,840

Software Developer

MA6 eAdmin Testing and documentation 25 (per phase 2-4) = 75

£203 £15,225

Non-ITS Staff Time Chris Carpenter MA8 Student Office Quality Assurance and

Business Change Lead

10 per phase = 40

£301 £12,040

Academic Registry team member

MA6 Student Office User Acceptance Testing, Business Change Champion

15 per phase = 60

£203 £12,180



User Acceptance Testing, Business Change Champion

15 per phase = 60

£203 £12,180









Non-ITS Staff Time





PMB Membership


Filing Location







Project Title Online Module Update and Approval System Enhancements



Summary of Project Purpose In 2013 the Change Projects Team commissioned a project to create an online module update and approval system. The project had been proposed in response to feedback from ALT regarding the annual update process. The Online Module Update and Approval System was subsequently developed by IT Services and introduced to Schools ahead of the 2014 annual update of module specifications. The system incorporates some of the elements of the annual update process but not all of them, as insufficient time and resource were available to complete the project. Attempts to accommodate the needs of different Schools have resulted in a system which is more complex than is necessary for some Schools and not able to accommodate the complicated requirements of some others. As a result two versions of the system exist: one for the Science Engineering and Foundation Studies and International Foundation Programmes, and another for the rest of the University. In addition, some Schools are choosing to use the system for only parts of the process and have retained paper-based systems for other elements of the process. With this in mind, some further process review will be required to address these differences before IT developments proceed. The project will seek to incorporate all elements of the annual update process and improve user experience, simplifying the update and approval process where possible.

Business Case As mentioned above, the business case for the proposal focuses on completing the work undertaken in 2013 to deliver a single module update and approval system to replace the previous paper-based system. The business case relates to the University Strategy through: • Investing in our staff: The system is used extensively by academic staff, School administrators and central

staff to update, approve and activate module specifications. It is hoped that the project will cut down on time-consuming and less user-friendly elements of the system, and enable existing users to focus on other priority tasks. It is also hoped that with a more effective system, those Schools which have not yet fully engaged with the system will be encouraged to do so, thus avoiding duplication of effort within Schools.

The project will affect academic staff, School administrators and Academic Registry staff.



Option 2: Complete the work undertaken to create a single online system for use by academics, School administrators and Academic Registry staff.

Fit-for-purpose functionality to enable: • Functionality for modules linked to

programmes administered across more than one School (including SEFS and IFP)

• Simplified process for REs

*





• Improved search function

• Audit function available to all users

• Improvements to functionality to allow more than one set of changes for each module and changes to modules after activation during the academic year

• Inter-School consultation to be incorporated within system

• Export of data to allow Schools to monitor progress/review changes offline

• Improvements to interface/screens to help users

• Inclusion of prompts, flags and reminder message to assist users

• Changes to elements of LUSI screen FM5007 to be blocked whilst awaiting approval and after activation/suspension

• Potential option to send email prompts (needs review)

• Academic Registry users to override workflow settings when actioning modules on behalf of Schools.

• Removal of rejected changes

Option 3: Review the market for externally available solutions to manage module (and programme) review and approval processes.

Integrated solution for managing all aspects of the module and programme review and approval processes.

Scope The system will cover the annual update process for Loughborough and LUiL-based modules, but not those owned by Loughborough College and BUE which are considered to be out of scope. It will also allow Schools and Academic Registry staff to obtain approval for changes that are proposed after academic sessions have begun, which require more detailed scrutiny.

Risks Mitigation

• If existing issues are not resolved Schools/ departments/ individual REs may decide not to use the system in future and may revert back to the paper-based version.

• The existing system needs a major re-write in order to incorporate the required changes


system developments

• Decision could be made to make use mandatory for all involved in the update process.

• Analysis and findings of the current system to be reported to the PMB by the project manager as early as possible in the project


Key Stakeholders



Senior User: Rob Pearson Senior Tech/Supplier: Tricia Breen Project Group members to include:

• PALG representatives • ADT representatives • RE representatives • Martine Ashby


Proposed: Start Date End Date

A solution would need to be in place for December of an academic year

Projects Impacted

Links with the following projects: • Online Module Choices (Student Choice) system (previously

approved by ITPB) • Programme update and approval system (needs process review and

IT development)

Other Services Impacted LUSI


On-going Costs None

Capital Costs None


Project Approach

Phase 1: Requirements analysis – 2 months Establishment of project working group Current process review and detailed requirements specification High-level system technical proposal Analysis of current system to establish suitability for required additions and amendments Phase 2: Development and Implementation – 4 months System technical design and development Testing, feedback and prioritisation of further development Training for Central staff/ School administrators. Implementation and go-live Technical documentation Phase 3: Post-implementation – 1 month Post-implementation review Minor post implementation enhancements Project closure Transition to Live will be determined for each of the key deliverables as they are developed, to be in line with standard LUSI rollout practices. It should be noted that timescales are dependent on resource being available in ITS at the times required, and are given as elapsed time rather than actual.







Software Engineer


Software Developer


Non-ITS Staff Time Chris Carpenter MA8 Student

Records Office

Quality Assurance, Business Analyst and Business Change Lead

20 £301 £6,020

Academic Registry team member

MA7 Student Office


25 £266 £6,650

Martine Ashby MA6 PQTP User Acceptance Testing, Business Change Champion

25 £203 £5,075




25 £203 £5,075




Non-ITS Staff Time











PMB Membership


Filing Location





Project Title Online Student Module Feedback

Project Sponsor Morag Bell Date 8/4/15

Proposed Project Manager TBD Business Change Manager Rob Pearson

Summary of Project Purpose The ITPB is asked to consider the approval of a project to implement an Online Student Module Feedback process which will enable students to submit their feedback on modules via an online system, rather than the existing paper-based methods. The project is recommended on the basis that there is potential for improvements to the student experience and a reduction in recognised failure demand across campus. The process involves students, Schools, Professional Services and IT systems. Business Case

Background

Student module feedback questionnaires are part of the University's continuing process of evaluating and improving the quality of its taught provision. Participating in module feedback is a valuable opportunity for students to provide feedback in order that a consistently high quality of teaching and learning can be assured for all students. About one third of modules in each School are assessed per year, with each module being assessed at least every 3 years. The questionnaire is split into two sets of questions: questions 1-12 about the module (the outcomes of which are shared with staff and student representatives); and questions 13-18 about the lecturer (the outcomes of which are confidential to the lecturer and their line manager). Responses are used in conjunction with information derived from other sources (e.g. External Examiner reports; the National Student Survey; the outcomes of internal and external reviews) to monitor and enhance programme structures, curriculum content, teaching and assessment.

The Current Process

The current process involves multiple actors and services, and is summarised below:

1. School identifies module to be reviewed. 2. School creates and prints their own feedback form in Word using a template and list of optional

questions. 3. Academic distributes paper forms to students in teaching session and provides oral guidance on how

to complete the form. 4. Completed forms are collected by a nominated student, who is invited to place them in an envelope,

seal the envelope and put their signature across the seal. 5. Envelope returned by the academic to a designated person within the School who will remove and

destroy any forms containing offensive comments. 6. School delivers the forms to the Print Unit for OCR processing. 7. The data appears on LUSI in spreadsheet format for nominated School staff to access, normally within

one week of completed questionnaires being scanned by the Print Unit. 8. Deans of School or their nominee make a written report to the appropriate Staff-Student Liaison





Committee on the quantitative outcome of questions 1-12. 9. Data for questions 1-12 and 13-18 and any written comments from students which relates to

individual members is reviewed by the academic and their line manager.

Feedback on the process

Feedback has been received from staff and students that the current paper-based process is no longer fit for purpose. Staff have raised concerns about:

• the inflexibility and inappropriateness of the current template and question bank; • the inconvenience of moving large volumes of paperwork between school offices, teaching rooms and

the Print Unit (this will prove particularly challenging for modules evaluated at LUiL from 2015 onwards);

• the data which appears on LUSI, which is not in a user-friendly format and often error prone. Student representatives have raised concerns that reports are not received at SSLCs and in the LSU within expected timescales, leading to student disenchantment with the feedback process. Several Schools have started to use the survey capacity in Learn to undertake programme part surveys (mirroring the NSS questions), and this has prompted many to question whether Learn or some other technology (such as an app for mobile devices) can be used for Module Feedback. The following comment from SSEHS in their submission to the 2013/14 Annual Programme Review (APR) is typical:

Electronic student feedback: The recent decision for Schools to gather student programme feedback electronically by part, via Learn, is a positive development. Some SSEHS staff and students have also expressed a preference for individual module feedback to be collected electronically and we wonder whether any developments are or could be planned to progress this.

The university trialled electronic module feedback about 4 years ago, but dropped it due to low take-up (although one School reported in APR that take-up for them was comparable with their paper-based take-up). There was a consensus in discussions with Schools during the 2013/14 APR, and with the LSU and Programme Presidents, that due to the increased prevalence of mobile devices among the student population take-up would be higher than in the trial if the University adopted a well-designed online system. Learning and Teaching Committee (LTC) discussed these concerns in March 2014 and agreed that feedback from students on their modules and the teaching they receive is a vital component of our teaching quality processes. Therefore the principle of module feedback should be retained. However, LTC agreed that it would be timely to review the process to ensure that it was as efficient and effective as possible. Members believed that the review should investigate alternative and innovative ways of conducting Module Feedback, with a preference for an online system noted.

Summary

The ITPB is asked to support a project to implement an Online Student Module Feedback process. It is anticipated that improvements could be made to the process that would benefit Schools, students and Professional Services.





Option 2: Development of an online Student Module Feedback System

• Functionality to be able to select the modules to be surveyed in any given year.

• Functionality to update the questions on an annual basis.

• Functionality for students to complete Module Feedback Surveys online, including mobile and tablet friendly views.

• Appropriate reporting features to enable non-respondents to be identified for follow up and outcomes to be made available to staff and student representatives in an agreed format.

*

Option 3: Review the market for externally available solutions to manage module (and potentially, programme) feedback

As per option 2 above

Scope

The scope of this project is to collect feedback from students on modules only. Collection of programme level feedback and feedback from other groups (e.g. staff) are both out of scope. To be clear, the provision of feedback to students on their work in modules is another process entirely and is thus also out of scope for this project.

Risks Mitigation

• Students do not engage with an online process.


system developments

• System is made as accessible to students as possible, including making mobile/tablet friendly, and follow ups to be sent at appropriate intervals to those that have not completed a survey.


Key Stakeholders Senior User: Rob Pearson Senior Tech/Supplier: Tricia Breen


Proposed: Start Date End Date

A solution would need to be in place for December of an academic year

Projects Impacted • Online Module Choices (Student Choice) • Online Module Review and Approval System



• Online Programme Review and Approval System • Programme Optimisation Tool All of the above projects are linked to each other in some way. Making use of the data from each, there is potential to display programme and module data in a more user friendly format to students to aid their module choice decisions. There is the potential for the aggregated module feedback data from this project to be incorporated this view of module data and thus enhance student choice further.

Other Services Impacted LUSI. Potentially the systems listed under projects above.


On-going Costs None

Capital Costs None


Project Approach

Phase 1: Requirements analysis – 2 months Establishment of project working group Current process review and detailed requirements specification Analysis of technical options High-level system technical proposal Phase 2: Development and Implementation (assuming an in-house solution is selected) – 5 months System technical design and development Testing, feedback and prioritisation of further development Training for School administrators. Implementation and go-live Technical documentation Phase 3: Post-implementation – 1 month Post-implementation review Minor post implementation enhancements Project closure Transition to Live will be determined for each of the key deliverables as they are developed, to be in line with standard LUSI rollout practices. It should be noted that timescales are dependent on resource being available in ITS at the times required, and are given as elapsed time rather than actual.



ITS Staff Time (costs of Grades here https://lboro.service-now.com/kb_view.do?sysparm_article=KB0010911) TBC MA7/MA8 TBC Project Manager, Business

Analyst and Technical Lead 30 £266 /

£301 £7,980 / £9,030

Software Engineer

MA7 TBC (depending on technology

Development and testing 120 £266 £31,920




chosen)

Software Developer

MA6 TBC (depending on technology chosen)

Testing and documentation 30 £203 £6,090

Non-ITS Staff Time Rob Pearson MA8 PQTP Quality Assurance, Business

Analyst and Business Change Lead

20 £301 £6,020




25 £203 £5,075



ITS Staff Time (costs of Grades here https://lboro.service-now.com/kb_view.do?sysparm_article=KB0010911) TBC (depending on technology chosen)

Non-ITS Staff Time





PMB Membership


Filing Location









Project Title Careers Registration Questions – PGT and PGR students

Project Sponsor Helen Smith Date 12.3.15


Eve Uhlig/Sally Western

Summary of Project Purpose This project builds on one initiated at the start of this academic year – including career questions in online registration for undergraduate students. As the UG project has been successful in a number of ways (see below), this request is to extend the inclusion of career questions in online registration systems for postgraduate students (both PGT and PGR). The aims of the project are:

• From question responses, capture each student’s level of career awareness, engagement and activity at the start of each year of study

• The accumulation of responses over the full period of study will enable the measurement of the ‘distance travelled’ of each student in terms of career readiness

• Analysis of responses will identify the level of guidance and support students may need. In terms of the UG project analysis has identified differing guidance/support needs across disciplines and this has enabled the better utilization of resources and the tailoring of services appropriately, e.g. focus for some Schools is on identifying what students want to do, whilst for others supporting them through the recruitment process as they already know what they want to do

• The overall aim is to provide the best and most relevant careers guidance and support services to all students whilst making best use of CEC resources.

Feedback on format of questions has been sought from colleagues and newly started PGR students and questions subsequently refined to meet their comments. Business Case Responses gathered at an individual level means that career guidance and support can be tailored to develop students as individuals. This will contribute to a life shaping student experience by developing career readiness of students who on graduation are ready to impact society, and in the case of PGRs contribute to pioneering research, and reach their full potential. Increased career readiness will substantially prepare graduates for their future lives in a global market place and enhance future collaboration opportunities. With information about motivation to undertake PG study, we may be able to target recruitment activity more accurately thereby increasing recruitment whilst also making best use of resources This project will affect PGT and PGR students, IT services and Careers and Employability personnel The results of the responses may be shared with specific Schools/Departments in order to tailor career services appropriately.

Registration process for initial registration and annual re-registration will be affected for relevant students.







Option 2: Incorporate questions into online registration and re-registration for PG students

• Inclusion of additional page in online registration system for PGT students incorporating relevant questions

• Inclusion of additional page in online registration and re-registration systems for PGR students incorporating relevant questions

• Reporting facilities to enable data collected through both registration systems to be retrieved by CEC

*

Option 3: N/A

Scope

Three questions have been drafted for inclusion in the PGT and PGR registration questionnaires – please note: these questions differ between PGT and PGR. PGT questions will only require including at initial registration, whilst PGR require including across the subsequent years of study (re-registration) as well as initial registration.

Risks Mitigation


system developments

Projects prioritised by the ITPB



Proposed: Start Date 2015/16 End Date By August before the start of a new academic year.

Projects Impacted

Career Registration Questions for UG students Potential efficiency gains could be realised in the development process if project is run in tandem with the above UG developments and the potential IER developments within online registration/re-registration

Other Services Impacted LUSI, online registration/re-registration, Discoverer or other reporting facility




On-going Costs None

Capital Costs None


Project Approach

Project Plan (inc. milestones) • Refine questions for PGT and PGR students (up to June) • Develop changes to online registration for PGT and PGR students (June) • Test changes to online registration (June – July) • Implement changes to online Registration (July) • Develop changes to online re-registration for PGR students (July) • Test changes to online re-registration (July – August) • Implement changes to online re-registration (August) • Management reporting (August - September)

Key Deliverables • Addition of Careers questionnaire for PGT and PGR students to online

registration system • Addition of Careers questionnaire for PGR students to online re-registration

system • Relevant management reporting for Careers. • Technical documentation for the system developments • Support documentation (both for support and user training)






Software Engineer


Software Developer


Non-ITS Staff Time Academic Registry

AD5 Student Office

Quality Assurance and User acceptance testing

5 £164 £820




Careers MA6 Careers Management reporting acceptance testing

2 £203 £406




Non-ITS Staff Time





PMB Membership


Filing Location









Project Title myGraduation


Proposed Project Manager Ropinder Heer Business Change Manager Mark Lister

Summary of Project Purpose To enable current graduation processes to be handled through a self-service approach. Through the use of this facility, students would be able to perform graduation related tasks such as confirming their attendance status for upcoming ceremonies as well as the number of guest tickets that they would like to request. This system would be linked to the LUSI database which would be updated as and when students access the self-service screen.

Business Case At present, students provide Graduation related data to the Student Office via an online form which generates an email to a generic mailbox. Once received, this data is then manually input into LUSI by the Student Office. The process of logging replies is equivalent to approx. 4 weeks’ work spread across several staff during two relatively busy periods. Students are not able to access this data once submitted and any corrections need to be performed via a subsequent email to the generic inbox. A self-service portal would significantly streamline the above process in that data would be input directly to LUSI and thus remove the need for manual re-entry. This would greatly increase the speed in which the data is captured and also enable greater flexibility in terms of continued communications with students as ceremonies draw nearer. This would enhance the Student Experience as individuals would be able to access accurate gradation data at any time and update it, as well as receiving real-time updates as and when appropriate. Data validation at source would also improve data accuracy.



Option 2: Build a self-service screen that will enable students to confirm their likely attendance status at their graduation ceremony, whilst at the same time confirm the number of guest tickets that they would like and other relevant information.

• Facility to provide students with access to relevant page once they have reached a particular status ‘Invite to next ceremony’.

• Facility for student to enter data relevant to their attendance at their ceremony.

• Facility to update LUSI with data entered onto self-service screen.

*





• Facility for students to edit their data if/when their circumstances change, including data validation.

• Facility for students to review their data at any time.

• Facility to extract report on data.

• Facility for staff to view students’ myGraduation record (i.e. see what the student sees)

Option 3: Change existing online form to provide/enable a spreadsheet extract for upload to LUSI

• Facility to collate responses. • Facility to extract report. • Facility to upload report into

LUSI and update relevant fields.

Scope

The scope of this project is limited to the key deliverables outlined in the above options.

Risks Mitigation

• Students fail to engage with online system.

• Failure of self-service facility. • Resource is re-prioritised for other Student

system developments

• Student Office continues to email students to prompt them to access service in the same way as current online form.

• Manage process in timely manner, allowing any technical issues to be addressed; develop a robust IT solution and ensure that support is in place at key points.




Proposed: Start Date June of an academic year End Date

A solution would need to be in place for October of an academic year, to enable a pilot for the winter ceremonies

Projects Impacted None

Other Services Impacted LUSI; potentially Student Self-Service.




On-going Costs None

Capital Costs None


Project Approach

Project Plan (inc. milestones) • Refine requirements (up to June) • Develop online form for students (June - July) • Test online form (August) • Develop interface between online form and LUSI (July - August) • Test interface (September) • Reporting (September - October) • Implementation (October)

Key Deliverables • Online functionality for students to administer their graduation • Streamlined processes and functionality for Academic Registry to interact

with students re. Graduation • Relevant reporting • Technical documentation for the system developments • Support documentation (both for support and user training)






Software Engineer


Software Developer


Non-ITS Staff Time Mark Lister MA7 Student

Office Quality Assurance and Business Change Lead

10 £266 £2,660

Catherine Smethurst

MA6 Student Office

User acceptance testing 5 £203 £1,015









Non-ITS Staff Time





PMB Membership


Filing Location






Project Title Individual Electoral Registration (IER)

Project Sponsor Richard Taylor Date April 2015


Catherine Smethurst

Summary of Project Purpose The UK government introduced a system of online individual electoral registration in 2014. Loughborough University can no longer pass details of students who are eligible to vote in some or all UK elections to Charnwood Borough Council en masse. Instead students must opt in to register on an individual basis. Data has been collected in 2014/15 on paper forms at registration and Students’ Union led halls events, and through an online form hosted in Learn and subsequently via the Students’ Union website. The Student Office have manually collated the paper-based information and added further data in Excel using a Discoverer report, before passing the information to Charnwood Borough Council so that students may be registered to vote. For 2015/16 and beyond, a more systematic approach is required. Business Case The impact of the student population in Charnwood and local wards is significant. It is essential that the voice of Loughborough students residing in the local area is heard by elected representatives. By assisting our students to register to vote and ensure that their political views are taken into account at a local, national and European level, we will contribute to the University’s aim to develop creative, confident and adaptable 21st Century citizens who will make a significant contribution to global society. It is also in the University’s interests that the views of students have an impact upon politicians as this may shape future governments’ education policies. This project will impact upon all students with UK/EEA/Commonwealth nationality who are resident in Leicestershire. (Charnwood Borough Council have a local agreement to pass on data to other Leicestershire electoral registration officers.) It will reduce the time spent processing the data and chasing up missing information by the Student Office. It is also anticipated that less resources would need to be devoted to publicising electoral registration by the Students’ Union, Marketing and Communications and the Student Office. This will affect the online registration process for some students, although will require only minimal additional input from relevant students. NOTE: at the time of writing, the outcome of the SU campaign to collect this data was not known. This outcome will have a material effect on the decision over to whether it is necessary to proceed with this project.



Option 2: Incorporate data collection into online registration and re-registration processes

- Facility to display mandatory page to relevant students only in registration and re-registration - Facility to enable students to specify electoral registration preferences and associated data - Facility to report on data and return to Charnwood council once

*



each academic year (per student)

Option 3: Incorporate data collection into online registration and re-registration processes, plus the self-service facility to allow additional data capture points

- Facility to display mandatory page to relevant students only in registration and re-registration - Facility to enter data via self-service - Facility to enable students to specify electoral registration preferences and enter associated data - Facility to report on data and return to Charnwood council several times throughout the academic year per student

Scope

The scope is limited to the functionality specified within the above options and to relevant students only (UK/EEA/Commonwealth nationals who are resident in Leicestershire on a permanent or term-time basis). It is expected that LUiL students would be excluded from the scope of the project, but a policy decision is still required.

Risks Mitigation - Change of government policy regarding electoral registration processes - Risk that students do not engage with the process • Resource is re-prioritised for other Student

system developments

- Monitoring of government policy - Make a mandatory step in registration/re-registration processes with appropriate opt-out options - Projects prioritised by the ITPB



Proposed: Start Date 2015/16 End Date By August before the start of a new academic year.

Projects Impacted Potential efficiency gains could be realised in the development process if project is run in tandem with the Careers Progression development for online registration/re-registration

Other Services Impacted LUSI, online registration/re-registration, potentially self-service, Discoverer or other reporting facility




On-going Costs None

Capital Costs None


Project Approach

Project Plan (inc. milestones) • Develop changes to online registration (June) • Test changes to online registration (June – July) • Implement changes to online Registration (July) • Develop changes to online re-registration (July) • Test changes to online re-registration (July – August) • Implement changes to online re-registration (August) • Management reporting (August - September)

Key Deliverables • Addition of IER question(s) for relevant students to online registration

system • Addition of IER question(s) for relevant students to online re-registration

system • Relevant management reporting for the Student Records Office. • Technical documentation for the system developments • Support documentation (both for support and user training)

Transition to Live will be determined for each of the key deliverables as they are developed, to be in line with standard LUSI rollout practices. It should be noted that timescales are dependent on resource being available in ITS at the times required, and is given as elapsed time rather than actual.





Software Engineer


Software Developer


Non-ITS Staff Time Catherine Smethurst

MA6 Student Records Office

Quality Assurance and User acceptance testing

5 £203 £1,015




Catherine Smethurst

MA6 Student Records Office

Management reporting acceptance testing

2 £203 £406




Non-ITS Staff Time





PMB Membership


Filing Location




Documents

Appendix A – Category B Projects · The business case for this proposal focusses on improved system efficiency throughout the busiest part of the admissions process; streamlining