Closure Report

Project Summary

Background

The use of a central notifications service will transform task-related communication at the University.  It will ensure that the full benefits of the changes introduced by Service Excellence, are made easily available to students and staff through an efficient and personalised notifications interface.    It will improve the end-user experience, increase efficiency and effectiveness of internal communication,  and standardise and simplify key communication processes. 

The study completed by Headscape, "Transforming students digital lives at the University of Edinburgh", highlighted the "lack of notifications for current students" as one example of the "you're bright, you'll cope" approach to digital service, and questioned if this was an appropriate quality of digital service for one of the world's top universities. We aim to realise Headscape’s “picture of the future” for notifications:

• Notifications are delivered how and when students want them
• Notifications need not be by email.
• Notifications would arrive at the student’s device.
• Users choose how they want to be notified and when they want to be notified – aggregation service

Two previous IS Applications projects (WEB007 and WEB010) have already been addressing this challenge, by building a production-ready Notifications Backbone, which:

• Securely imports, stores and distribute personalised notifications 
• Supports initial integrations with the following publishers of notifications
  • EUCLID
  • Learn
  • Administration Support
  • Emergency Notifications
• Providing a user interfaces for schools or other groups to create notifications, targeted at groups

The overall project will now roll-out a Notifications Service incrementally over a period of three years, including:

• Integrating it with more sources of notifications for students and staff
• Enabling users choose their preferred mediums for certain notification types
• Delivering native device notifications * Enable tracking and auditing use of notification-based communications
• Providing a solution for any user-authenticated web platform in the University to display the notification feed
• Actively engaging with the open source community, preferably through an existing organisation, such as Apereo, to build a community of adopters, supporters and developers. 

Scope

The scope of this Phase 1 project will cover :

Staged roll out of notifications service for all student users including: 

• Consult-on and draft, policy and guidelines, including
  • Choice of communication channel
  • Use of notifications versus email
  • Integration with Digital Experience Standard (being managed via DTI010)
• Define SLA, and agree OLA, support plan and budget with Production
• Business-process and technical documentation for integration partners

Integration with further publishers of notifications for students including:

• Library Management Platform
• eFinance
• Card systems
• Accommodation systems
• Unidesk self-service

Integration of priority subscribing channels

• Email - Office 365, Timetable on My Phone
• SMS

Research and Review Learn APIs integration (Cloud)

Consult students about their priorities for integrations for delivery in Year 2

• External subscribing applications, such as WhatsApp or Facebook 
• Internal or external publishing sources

Out of scope

WP6 Notifications from USG systems (Include specific applications ): It is expected that integrations with USG systems will be owned and implemented by the SSP, using the existing email integration facility, but a USG activity thread is included for completeness, and the project to be ready to support any additional integration features required by the SSP being delivered via SAS002 Student Centred Portal Pilot.

However this element was descoped on the withdrawal and closure of SAS002. Also SAS011 Contact Details it as deemed out of cope for this project as well.

Objectives, Deliverables,

Deemed out of scope during project :

WP1 : Although both EUCLID and LEARN where part of the original proof of concept, both were descoped during the life cycle of the project for the following reasons;

1. The LEARN integration was developed as a database pull this allowed both system and course announcements to be made visible via Notifications Service. With the strategic direction of LEARN moving to the cloud, it was decided that it would confuse Students and Academics if we made notifications available and then have to remove on migration to the cloud. Blackboard did not have an API available for Course announcements and system announcements were deemed not the key information students wanted to be made available to then. Also concern raised around the level of data and quality information available via LEARN would not be appropriate for this channel and as there were projects to standardised VLEs going forward it would be best for these to be completed before looking at this integration in the future. 

2. The EUCLID integration was developed in previous projects but required further testing to ensure notifications were suitable for the service. However developments expected to be delivered via SEP projects (SAS002 and SAS011) were descoped for notifications. Other opportunities to deliver notifications for examples such as Post graduates were not deemed high priority by SSP due to resource constraints therefore it was agreed for EUCLID to be descoped to allow the project team to focus on other work packages.

3.  WP2 : Library and Card - Although the project team worked closely with the Library team and gathered requirements for integration with Alma, it was felt that the changes being implemented to new MyEd were in a similar vein to what was being developed via Notifications therefore decision made to not progress with these via this project and may be reviewed and developed for future development.

4. WP4 : SMS use of Connect Text - The project team explored the options to develop this integration using existing ConnectText which is managed by LTW however on closer investigation there was issue with support of development environment with supplier. Also from student engagements SMS text messages were not seen as an essential. Integration with SMS is available with the community Apereo version 'Fiosan' therefore this can be reviewed by the Service team when the decision to move to this version in the future,

5. WP5 : Corporate e.g. Finance and Accommodation - at the early stages of the project the upgrade of e-Financials was a priority project therefore limited support to engage with developments for notifications. Also Accommodation Service were not keen to be involved in the early development of the Service and stated they preferred to engage with this once there was more advocacy / adoption of the service in the future. However in the past 6 / 9 months Finance and Accommodations have expressed an interested in using the service and are working closely with the Service team to adopt similar process to Student Surveys

Additional Delivery:

• With the redevelopment of new MyEd Student Surveys portal was being decommissioned and therefore they took the opportunity to move from the portal to Notifications, c.100,000 Student survey notifications successfully processed - April 2019
• Involved in Start of year activities using Notifications Service to deliver EASE / AD Password Sync notifications to students during -  July, August and September

Analysis of Resource Usage:

Staff Usage Estimate: 320 days

Staff Usage Actual: 314 days

Staff Usage Variance: 98%

Other Resource Estimate: £ see table below

Other Resource Actual: £ see table below

Other Resource Variance: 

Outcome

2018 Activity

Notifications Service deployed to live – User Interface, API, Notification and Emergency Portlets available via MyEd  - May

Student Engagement

• Pilot with Employ.Ed for Summer Student Interns (60) - July
• Pilot with CMVM Yr1 and Yr2 Undergraduates 500 students approx. 2 x notification per student, 1,000 notifications generated, visible in MyEd, upon login - November

Exam Scheduler Integration to Notifications Backbone live - November  

Student Engagement

• Pilot to undergraduate School of Divinity students approx. 300 students –December

2019 Activity

Apereo Open Sourced version of Notifications Backbone known as ‘Fiosan’, community / collaboration version available - March

Student Surveys moved from MyEd portlet  to Notifications Service c.100,000 Student survey notifications successfully processed - April

EASE / AD Password Sync for Start of Year - July

Explanation for variance

Key Learning Points

• This project encountered a number of challenges :
  • Dependency on outcomes of SEP projects which were withdrawn SAS002 and restrictions on deliveries from SAS011
  • Key senior stakeholder changes in November 2017 whereby Project Sponsor and Service Owner left University and the project was without key stakeholder until January 2018 which could have resulted in the potential withdrawal of project, it also had no Business Service Owner. Project was championed by the then UCP programme manager/project manager to keep project open as the benefits of the Notifications Service could be evidenced for the future.
  • During this project's lifecycle it has had 3 Project Sponsors and 2 Service Managers as Business Lead
  • The point to note that the Notifications Service from inception has been managed via a number of projects from idea to Live deployment via 3 project WEB003, WEB007 and DTI020 and originated from a vision back in 2011.
  • It is always difficult to keep momentum for a project when the key stakeholders - Project Sponsor, original developers etc are no longer part of the University
• This project has delivered to live Notifications Service, portlets and open source code due to the commitment and tenacity of key project teams members in particular Brendan Owers as initial Service Manager , Colan Mehaffey project Sponsor and Karen Stirling Project manager working as a team to progress and promote the service
• The project concept was possibly ahead of its time with other key programmes of work not ready for adoption at the point where the project team were trying to gather requirements, consequently the service team are now being approached to use the service from areas which were originally in scope but at the time not wanting to be forerunner for the service.
• Key activity for the Notifications Service going forward is to built advocacy for the service and communicate benefits to build up subscribers and integrations
• Engagement with pilot schools for initial requirements gathering was key to aid direction of project and also acknowledge Alison Ramsay from Exam Scheduler team who supported the integration of Exam Scheduler with the Notifications Service.

• Open Source - One of the commitments at the start of the project was to make the code open source. Although we did get there in the end, this proved to be a lot harder than we originally anticipated and highlighted the fact that there is currently no structure or support system in place for us to do open source development. The project was actually able to make considerable strides towards this. In the end we were able to deliver an open source project under Apereo as well as securing the legal agreement for us to do so, putting a process in place for future work to follow.

•  The priorities at the start of the project were not clearly defined and were more based around internal service needs as opposed to user needs. This then made it difficult for us to evaluate the impact of doing/not doing particular pieces of work. This has highlighted the need to carry out more user engagement and requirements gathering up front as an initial stage in the project.

• User Engagement - Originally, the project did not plan to release Notifications until the end of the project. We changed this partway and as a result we were able to do more user engagement and uncover potential issues before the project closure. For future projects we should definitely consider doing more of a soft release approach so that we can benefit from user feedback earlier in the project. 
• Conflict with APIs Programme - Some of the deliverables in the project were blocked because of the timing of the APIs Programme. The lack of available APIs meant that we were limited in terms of what notifications could be delivered. This should be considered for future Notifications project work. Without the development of more APIs, development of Notifications will be costly and time-consuming. 
• Continuity - After the closure of the project, no further funding has been put in place to support the continued development of the Notifications platform. This will severely impact how this service is able to deliver in future.

Outstanding Issues

• No key issues outstanding there are JIRA logs which can be taken forward as Service Improvements
• As part of the Open Source activity there is now a community version available that can be promoted to test and live using additional features which have been developed by the Apereo community that can be put to good use within the university. Due to the time constraints and lack of available funding in 19/20, and not part of the original scope of work this was not deployed and should be consider for future improvement of the service.