Closure Report

Completion Report SAS011










Lisa Dawson

Project Sponsor

5 Feb 2020

Confirmed by email

Amanda Percy

Programme Manager

5 Feb 2020

Confirmed by email

Stefan Kaempf

Senior Supplier

5 Feb 2020

Confirmed by email

Brandi Headon

Service Owner

5 Feb 2020

Confirmed by email





Project Team




Paul Horrocks

SSP Senior Developer



Tomasz Pogoda SSP Senior Developer 5 Feb 2020 Confirmed by email
Suran Perera Production Management 4 Feb 2020 Confirmed by email



The University of Edinburgh committed to a review of key professional service functions.  Colleagues in Colleges, Schools and the Centre are running the initiative, known as the Service Excellence Programme, together in a joint approach.

The Student Administration & Support (SA&S) programme started in May 2016 as a sub programme of the Service Excellence programme “SEP”. As part of project SAS002, a pilot was carried out of a new contact details application to prove technical capabilities of MyEd. The evaluation report of that pilot was presented to the SA&S Board (approved 9th March 2018) and UCP Steering Group members (approved on 30th March 2018) and its recommendation to roll-out the application to all students was approved. SAS011 was therefore established to deliver that roll-out.

Were the project goals met?   

The objective of the project was to:

  1. Improve existing contact details application, and related interfaces (microservice/APIs) so that it is fit-for-purpose and scaled for all students; and
  2. To test and sign-off the application prior to publishing in live MyEd environment, and to support it there until handover as a service to Production Management.

Both of these goals were met. However, not all deliverables were achieved, as detailed below.

Were the project deliverables fully or partially accomplished?   

Partially accomplished

Deliverables Achieved:



Review of contact details application and related interfaces

Fully Delivered - Project team reviewed prototype application and APIs built under SAS002, and agreed a new build was required. 

Improving contact details application functionality and technical structure

Fully delivered - New build detailed in technical architecture document, system design document. System functionality signed off with service (Brandi Headon), after User Experience (UX) and usability reviews with students.

Improving interface API/micro-services to resilience, monitoring and error-handling

Partially deliveredThe work on the API (started as part of SAS002) was consolidated by:

  • Improvements to the euclidstudent-ms api endpoints
  • Exposing additional student data via stutalk and euclidstudent-ms api
  • Establishing new authentication model using the jwt tokens
  • Development of the (QAS) quick address search micro service so quick address search functionality can be used outside Euclid
  • Detailed stress and load testing of stutalk and euclidstudent-ms api was conducted


  • Sentry error reporting tool has been investigated for API monitoring but this work has not been completed

Handover to Production Management

Fully delivered - Confirmed handover of application, with technical documents reviewed and approved by Production Management.

Student Systems Operations updates/communications

Partially delivered - Student guidance pages updated by service. However, will need reviewed once existing EUCLID student self-service functionality "hidden".

Discovered issues

Partially delivered - During the course of the project, a number of data issues in EUCLID/SITS were identified. Many of these were resolved, but a number of low priority issues remain with the service, as well as additional support from service. Specifically (by JIRA reference):

  • SAS011-217 - SITS holds for a small percentage of students a third contact number. However, neither EUCLID nor new application can display that number nor can it be updated in either place by students
  • SAS011-224 - MyEd portlet does not contain links to student systems help/guidance pages (although those are still available directly)
  • SAS011-211 - Student preferred name doesn't handle mixed case in either EUCLID or new application
  • SAS011-234 - Staff Hub does not display all student emergency contact data. Existing issue  regardless of source (i.e. happened with data entered via EUCLID too)
  • SAS011-239 - Address type can be blank in SITS, so clean up required. This is for data entered via other methods, but means student can't confirm that address, and has to re-enter.
  • SAS011-233 As future addresses not viewable/editable within application, and very rarely used in EUCLID, registration forms and staff hub need updated to remove facility to create them
  • SAS011-236 Staff hub should be updated so that emergency contacts are non-mandatory as they are not always provided in practice.
  • SAS011-237 Mobile and emails not saving for both student addresses when updated in staff hub or SITS.
  • SAS011-235 Staff hub doesn't save emergency contact email and mobile when entered via staff hub.

NB These will be reviewed by the service, prioritised and included in backlog for SITS (and other SSP) developments with Production Management. Where practical, SSP developers carrying out SITS training will fix these issues as part of learning those skills.

Deliverables not achieved:


Why not achieved

EUCLID functionality decommissioning/application embedding

Application developed and embedded in MyEd (for students). Existing EUCLID self-service was not decommissioned. New application not embedded into EUCLID, and would require further development work to do so.

Project resources not available to develop application to be functional outside of MyEd deployment.

Service decision to decommission/hide existing self-service functionality will be picked up as part of their business as usual activities.

NB Although the application was not embedded in EUCLID/SITS, components from it were reused in the development of Annual Registration/matriculation contact details forms, which reduced both UX and development work required for that project.


Did the project deliver a solution to the problems being addressed?

Yes. The application provided a facility for students to review and update contact details via MyEd.

Does the Project Sponsor agree that this project can be closed at this time? 



The overall costs from the PID were: 

Projected Effort (Days) 191
Actual Effort (Days in ASTA) 223.6
Difference Over 32.6d

Key Learning Points:

NB These are a collection of learning points gathered from the project team, including previous members, and do not reflect the views of any one individual.

What went well?

  1. API skills - The project improved SSP developers' knowledge and skills of API development
  2. MyEd UCP - The project provided lessons for MyEd UCP developers for portlet development/migration
  3. Existing issues - Identified existing data issues in EUCLID - many of which were resolved while testing application
  4. Reduced data errors - Feedback from service is that application has reduced data errors compared to entries via student self service in EUCLID
  5. Support - The application has not generated any support calls to the service
  6. Component re-use - As above, components from the application have been able to be re-used in other applications

What didn’t go so well?

  1. Investment - The development of the project took a lot of time/cash. This was partly because the development was more complex than initially anticipated (e.g. addresses) and partly that it was being developed in parallel with MyEd being restructured
  2. Stage-gates - Clearer stage gates for approving continuing development were required so that the benefits expected could have been reviewed regularly. In particular, a review of benefits/costs should have been carried out once the technical review of the pilot/prototype was completed and the scale of development work agreed
  3. UX/BA design - While usability/UX testing was beneficial, a clearer set of mock-ups could have been taken to students at an earlier stage
  4. Service testing - Although the service was involved in the business analysis stage, a lot of the complexity of the existing application only became apparent once service testing started. Having that service lead (Elise McDonald) involved at a much earlier stage would have saved a lot of development time
  5. API Programme - The project developers had to develop their own skills and knowledge of API development. While this has provided longer-term benefits to the SSP department, the expectation initially was that the API Programme would have reached a level of maturity that key decisions about API design would already have been taken. There is a risk that API standards may need revisited now that the API programme has progressed

If you had a project like this again, what would you improve?

  • Communication of the project, its components, and API work could have been better shared with colleagues in SSP
  • Gateway checkpoints should have been more clearly defined and formalised
  • Clearer ownership of API between project, SSP and API programme should have been defined
  • The project was not an ideal first application for API development, and would have benefited from learning from other projects proceeding in the API programme

Outstanding issues:

As noted above but categorised into:

  • Monitoring of servers/application/API.
  • Decommissioning of EUCLID self-service
  • Embedding of application within EUCLID
  • Data issues identified in EUCLID

Project Info

Student Centred Portal - Contact Details Roll Out
Service Excellence - Student Administration and Support (SAS)
Management Office
Project Manager
Ranald Swanson
Project Sponsor
Lisa Dawson
Current Stage
Start Date
Planning Date
Delivery Date
Close Date
Overall Priority