Completion Report
Project Summary:
This project set out to enhance the student experience by accurately reflecting the status of their fees invoices in the student finance channel. This in turn would reduce the number of student queries to Finance and Registry regarding fees, particularly around graduation time when unpaid fees become a priority.
For SAAS, the larger of the FPAs, this has been achieved and the large January SAAS payment details have been successfully loaded into eFinancials and are showing the student finance channel.
One unexpected benefit of the project is that the end-to-end process is now better understood by the different departments involved.
The success criteria listed in the table below were identified at the beginning of the project and all have been achieved.
| Criteria | Achieved? |
|---|---|
SAAS and SLC payments are able to be correctly matched against the corresponding student invoice in eFinancials | Yes (not SLC - de-scoped by agreement) |
An individual invoice line can be reversed without the need for reversing other invoices | Yes |
Invoices for which payment has been received are correctly shown as paid in the student finance channel | Yes |
FSS and eFIn SAAS/SLC payment details be reconciled | Yes (not SLC - de-scoped by agreement) |
Other parts of eFin are not detrementially affected | Yes |
Analysis of Resource Usage:
Staff Usage Estimate: 150 days
Staff Usage Actual: 108 days
Staff Usage Variance: -28%
Other Resource Estimate: 0 days
Other Resource Actual: 0 days
Other Resource Variance: 0%
Explanation for variance:
It was originally anticipated that the JAMS application would be used to completely automate the loading of payment details into eFin with no manual intervention, but the Project Sponsor wanted to retain an element of human intervention to ensure that appropriate financial checks took place and so this automation was de-scoped and the budget reduced.
SLC payments were also de-scoped from the project by agreement with the key stakeholders as financial process for this FPA had improved significantly since the audit report was done so the benefits were not as great. The SLC payments are also more complicated so it was agreed to focus on SAAS only.
Key Learning Points:
What went well?
- the project successfully achieved what it set out to deliver and has been able to deliver benefits to the students
- the end-to-end process is now better understood by the different teams involved
- FSS were able to turn around requests for test data quickly and efficiently
What didn't go so well?
- Difficulties uncovering the current process - a lot of time (5 months) was spent in the planning & analysis stages as it was difficult to find out how the current process fitted together and what teams were involved
- Loss of key team member - the key finance stakeholder retired part-way through the project. This left a large gap inthe knowledge of the project team which took time to fill.
- Late discovery of issues with large files - the testing predominantly focussed on the accuracy of the interface so the issue with large files was not discovered until just before the planning go-live, by which time the project was nearing its end and the developer needed to move onto other priority project work.
- Difficulties obtaining sufficient test data - as the Dev/Test eFin data was out-of-date it was a manually intensive process to get appropriate test data. Fortunately the RMAS project undertook a database refresh of the Test database later in the project and FSS were able to provide corresponding SAAS payment data for the final stages of UAT. We also had to avoid processing large amounts of data early in the testing as this would have reduced the amount of test data remaining to us for subsequent tests (as the process will only run on unpaid invoices).
- Late small changes to requirements - there were a number of small changes requested quite late in the testing phase (e.g. prefixing 'our ref', swapping 'our ref' & 'their ref' ) which appeared to be small changes but resulted in larger knock-on impacts.
What would we do differently next time?
- Load Testing - ensure that realistic volumes of data are included in build/peer tests as this would have uncovered the issue with large files earlier in the project when it still might been possible to resolve. We did undertake testing of files with 1000+ records but not the 10,000 records that can occur on live. Although this data would have been difficut to accumulate it would have uncovered the limitations of the application design earlier in the project.
Outstanding issues:
- There is an outstanding issue with loading large files (over 1000 records) which causes the application to time-out. The Project Sponsor has confirmed that as there are only a handful of files per year then the business will work around this in the short-term manually by chopping up the files into smaller chunks. The Project Sponsor has offered to speak to her teams to see what assistance they can offer FSS with this manual task. A project proposal will be put into the next planning round for a more permanent solution. This proposal will also include the areas de-scoped from this project i.e. credit notes and clawbacks, plus processing for other Fee Paying Authorities (FPAs).
- Potential issue with old payments (i.e. not the current academic year). This must be verified before the project can close. - fix deployed to live 28/07/15 signed-off by business rep 29/07/15