Closure Report

Project Summary

The objective of the project was to improve students' satisfaction/user experience by enabling students to make best use of their email addresses based on student name instead of username (UUN). It was been agreed that the best option for a successful implementation is the option to create name based email aliases for new students only. The new service allocating the personalised email address based on student name as the primary email address for all student data created from 15/Dec/17 was successfully deployed.

The background is that in response to student demand for a more personalised experience at the University, the project aims to ensure that students make more use of their email addresses based on student name instead of username (UUN). Their “personalised” email addresses already exist but most students are unaware that they have a second email alias consisting of their name, in addition to the one derived from their matriculation number.

Until now the strategy has been to implement the personalised addresses silently and therefore these aren't immediately apparent in the University's email systems and communications. The scope of this project is to gather and document options on identifying and implementing the potential solutions for the personalised student email address, create a draft options paper and obtain approval of senior stakeholders and EUSA for the recommendation.

 

The stated objectives for this project were:

No.

Description

Achieved? 

O1

Delivery of Options paper 

Yes

O2

Identification of benefits, risks and costs  

Yes

O3

Delivery of Communications strategy Yes

O4

Approval obtained from EUSA for the recommendation 

Yes

O5  Delivery of agreed recommendation Yes

 

The following were out of scope:

  • With the introduction of name based email addresses, there will be areas exposed who currently use other format or hard coding of email addresses/aliases this project will not be responsible for resolving any issues encountered to fix these inconsistencies. Mail delivery will not be impacted, only display.
  • For all existing students to have name based email addresses this requirements will be included in a future project.
  • The passing of name based email address data back to EUCLID (student record golden copy) will be investigated as part of a future project.

The stated benefits for this project were:

No.

Description

Achieved? 

B1

All new students will have a more easily-identifiable and memorable email address. 

Yes

B2

The student experience is improved.

Yes

B3

The outcome reinforces the message that the UoE continues to listen to student requirements.  Yes

 

In the project brief, the following deliverables were identified:

No.

Description

Delivered? 

D1

 Gather options and document business requirements, including:
  • Implementation and training/handover
  • Technology

Yes

D2

Analyse an identify potential solutions the delivery of the personalised student email address

Yes

D3 Identify the benefits and risks, costs and timeline, consequences and impact for the agreed solution Yes
D4 Create a Communication Strategy Yes
D5 Design solution Yes
D6 Consult with and obtain approval from EUSA for the recommendation. Yes
D7 Build solution Yes
D8 End to end testing of agreed solution Yes
D9 Deployment of agreed solution Yes
D10 Change management of agreed solution Yes
D11 Decommissioning SMS feed into EUGEX. Yes.  Student Systems have been informed that the data feed from EUGEX is no longer required and they can stop generating the data.

 

 

Analysis of Resource Usage:

  • Staff Usage Estimate: 100 days were in the estimate  at time of TOR budget but only 45 days were approved for commencement of task. This is noted in the WIS notes of 07/04/17  in the section "END OF PLANNING ( i.e. TORs/Briefs For Approval )". It is also covered by the trail precipitating from Risk 10.
  • Staff Usage Actual:
    • 149 days is the actual total in the usage reported from ASTA:
      • At restart of project, reports show total used as 125.3 days meaning that the usage after restart in Nov was 13.5% of the total used;
      • Time not reported in ASTA includes 10 days effort from Scott Larnach and Kenny MacDonald.
  • Staff Usage Variance: 150% 

Breakdown

Area  TOR   Actual 

 Delta 

Project Management 

28.5

55.6

27.1

Planning

21.5

18.9

-2.6

Design

16

25.6

9.6

Build

16

18.4

2.4

Integration

4

9.6

5.6

Acceptance

7

12.3

5.3

Delivery

5

18.1

13.1

Closure

2

1

-1

 

 

 

 

 

 

 

 

  • Other Resource Estimate: £
  • Other Resource Actual: £
  • Other Resource Variance: %

Outcome

As noted in previous sections, delivery was successfully achieved and a number of issues in data were also cleared in the process.

Explanation for variance

Budget was a low figure as the project was brought in as a "must do" project by-passing the budgeting process for the programme. The agreement was that the project would run as a deficit on anything beyond the agreed/allocated 45 days of effort.

Key Learning Points

Testing data for the service deployment needs adjustment to allow more representative testing prior to going into Deployment. This was highlighted by the following observations in the team:

  • As a result of scope changes, COM033 went through a number of design iterations and the final version had a reduced target but still had to cater for planned enhancements to the service;
  • Initial analysis was felt by some to be not detailed enough for the complexity of the change and the associated service impact;
  • Production Management felt that the testing was successful, given that the test infrastructure does not have an active O365 feed to the Test Student Mail system and ITI has no test system for mail. There was an increased criticality associated with getting valid test cases and data in integration testing and, although this was recognised in planning  for COM033, the full impact was found to be greater than expected:
    • The test data was felt to be insufficient to provide confidence that live data would give the equivalent configuration on the Mail Relays once the code was deployed;
    • The ITI view was that, more time should have been spent performing requirements analysis for the email alias data.  The project tried to mitigate this by recreating the legacy database in IDM, resulting in multiple changes late in the project when requirements surfaced in an ad-hoc manner.

  • At the change-over for the project the PM taking on the project was new to the service and, no-matter how good the resource is, there is a learning curve associated with bringing the resource online.

 

Outstanding Issues

The last JIRA requiring a fix was JIRA COM033-30 which deployed to Live on 17th Jan.

During development and delivery there were four JIRA identified that were agreed  to be beyond the scope of COM033 or not tied to the changes in COM033. These should be picked up as requirements for project DTI038 or the subsequent one. These JIRA can be contained as "known incidents" pending deployment of the solution that will resolve them in DTI038 or similar. These are as follows:

 

 

 

Project Info

Project
Personalised Email for Students (Options and Implementation)
Code
COM033
Programme
Digital Transformation - Integrated Identities (DTIP09)
Management Office
ISG PMO
Project Manager
Don MacIver
Project Sponsor
Alex Carter
Current Stage
Close
Status
Closed
Start Date
26-Oct-2016
Close Date
09-Feb-2018
Programme Priority
3
Overall Priority
Normal
Category
Discretionary