Completion Report
Project Summary:
Were the project goals met? Yes
The goals of the projects were:
Deliver incoming interfaces to Timetabling business users which are simplified, more stable, more consistent, and run in a timelier manner. This will reduce IS support costs related to support issues at the start of semester 1 with the Timetable Service.
For the past two years IS Apps Management has experienced support issues at the start of semester 1 with the Timetable Service. As a result, much staff time has been spent to support related processes.
For the start of term processing in 2014 a large proportion of the time outlined below was spent keeping the incoming interfaces running, including supporting the SPDA component failure. 4 days allocated per month. Expenditure on the first few months in 14/15 is outlined in the table below (estimated that 90% of those are related to data issues):
Month/Year | Support effort spent (days) |
Aug 2014 | 26.7 |
Sep 2014 | 34 |
Oct 2014 | 22.9 |
Total | 83.6 |
Were the project deliverables fully or partially accomplished? fully
The following deliverables were achieved (from project brief):
Deliverables
Reference | Related Objective(s) | Deliverable Details | Priority | Achieved |
D1 | Enhancement to current changed based process of the incoming interfaces | The information set is currently presented to Timetabling by taking a difference between the last and current runs. A switch to change based processing is seen as taking the difference from the RDB (Timetabling) to EUGEX (student) databases. Benefits are: - In the event of a failure we could restart. Currently establishing what has been processed and getting the next run ready to process has been labour intensive. - We have seen changes to enrolments/movement between courses (enrol/un-enrol/enrol). We could potentially take the final state of the enrolment without the previous enrolment and un-enrolment. - If referencing the RDB, one year’s enrolments would be referenced rather than all enrolments from EUGEX. | Must | Yes |
D2 | A new reference view in EUGEX to show future student course enrolments. Enrolments would be visible to Timetabling Unit immediately rather than a high volume at one time when they are active. | Use a new view in EUGEX and a change to the staging tables in Timetabling (SATSTAGE) would present continuing and new student information as soon as it is available in EUCLID. EUGEX is the gold master source for IDM, so it is logically impossible for IDM to be a better data source than EUGEX for student only data. Expected to remove duplicate records or missing information. | Must | Yes |
D3 | Remove the non-academic SPDA. | Moving to one Syllabus Plus Data Adaptor (SPDA). Currently having two SPDA, if one feed fails and the other succeeds we have seen the creation of duplicate records.
| Must | Yes |
D4 | Remove the non-academic SPDA. | Decommission IDM Service Entitlement in Dev, Test, Live. Tidy up entitlements by Service Management. | Must | Yes |
D5 | If the change based process Is implemented, there is a risk that changes to the Org Hierarchy will result in automatic deletion of activities in Timetable. Investigate whether we can remove the Org Hierarchy as a data source. | Recommendation whether SATSTAGE can be designed without the Org Hierarchy as a data source. Timetabling Unit would manage the departments manually. If estimated as short, this could be implemented in this project. | Should | Yes |
The following deliverables were not described in the brief but were delivered by the implementation part of the project:
A number of pre-existing data issues were identified and resolved. Theyt have improved the quality and completeness of the data being loaded from the data source.
Not Delivered: N/A
Did the project deliver a solution to the problems being addressed? Yes,
What are the benefits for the business?
1. Fewer system downtime and fewer project effort during Timetabling roll forward
We now have a synchronisation between timetabling and the source system. It is much easier to recover from issues with the SPDA. This year we rolled forward without any system downtime (normally 1-2 days).
As well as improving the SPDA roll forward, it will remove the manual load of students/courses in July, by making the data available in Timetabling as soon as it is uploaded in EUCLID.
2. Reduction in support time
While we won't be able to say for sure until a period of time has passed, but based on initial results the prospects look good. Wehave already saved a significant amount of effort over the usual annual rollforward issues we have faced in the past.
The single SPDA seems to be much more stable than running two.
Does the Project Sponsor agree that this project can be closed at this time? yes.
Link to the closing questionnaire https://www.projects.ed.ac.uk/project/ttu011/page-1
| Cost Summary | ||||||||||
|
.
Analysis of Resource Usage:
Staff Usage Estimate: 75 days
Staff Usage Actual: 149 days
Staff Usage Variance: 99%
Other Resource Estimate: 1 days
Other Resource Actual: 1 days
Other Resource Variance: 0%
Explanation for variance:
Delivery date and budget
While the project delivered the synchronisation with 2 weeks delay from original day, there were additional effort to address the post live data issues and the decommissioning.
Because of resource conflicts with compliance work, the remaining post live issues and decommissioning were completed only in June.
Budget variances were tracked in project issues:
-during build +6d https://www.projects.ed.ac.uk/project/ttu011/issues/4
- end of acceptance +17d https://www.projects.ed.ac.uk/project/ttu011/issues/7
- Addressing Live data issues https://www.projects.ed.ac.uk/project/ttu011/issues/8 and revised estimates post deployment https://www.projects.ed.ac.uk/project/ttu011/issues/9 +37d
Key Learning Points:
1. What went well:
- Delivered all objectives mentioned in the project brief, delivered benefits to the business (see above) and addressed existing data issues
- Working together as a team to resolve quite complex issues inside Timetabling and outside Timetabling to get the best result for the Customers. Communication between development and production was not always easy at the beginning of the project. Overtime we have in fact developed a much better working relationship here as we have begun to work much more closely and focus on delivering a good service rather than the semantics of project vs support
- Automated deployment and testing of the application and it's configuration have made ongoing development and support much less costly. We actually introduced a more thorough set of tests than we have ever had for the satstage process and a number of these scenarios are now automated. The solution that was delivered is far superior than the old change based system.
2. What did not go so well?
- Resources were not available to commit to running the project in an agile fashion due to conflicts with other work. While the individuals involved worked effectively on the project it was originally envisaged that two developers would work in parallel to deliver the solution together. Other commitments, paternity leave and conflicts with other TTU work meant that this proved impossible. The project would have run well under the agile methodology but the resourcing conflicts meant that it was impossible to deliver it using agile, we started off agile but were not able to carry on working in that way.
- What we did suffer from was understanding the end to end process and all the variations contained within that well enough to create tests for every scenario. That sort of overview of the scenario testing needs to also come from the business and from support who understand the data issues we see so that we can test for them. As a result data issues were only found once we went live.
- We identified a number of pre-existing live data issues but these were treated as issue with the new implementation rather than fixes for existing issues. While recognising that the project was best placed to resolve these, it reflected badly on the project as having caused these issues, or not having tested thoroughly enough, when in fact they were issues which had existed for years but had never been identified. The complexity of the interfaces involved meant such data was difficult to obtain.
3. What would you change if you had a similar project?
- Need to have broader UAT to include particular scenarios (like student with more than one programme SCJ record, student with several Course enrolment SCE record). Those scenarios need to be detailed enough so that they can be set by SSP and run through in EUGEX/Timetabling . Could be done as regression tests. Timetabling would identify those scenarios with Apps Man support.
More time should be spent on finalising user stories for Agile project, at foundation or at the beginning of the iteration, with emphasis on the User Stories' Conditions of Satisfaction, which will form the test criteria. If not there is a risk of a lack of understanding of what actually should be tested. The whole project team - not only business and production- should agree on them.
- We should require the same resources throughout the project.
Outstanding issues:
1. Log rotation to be documented in the TAD update currently being done underTTU012 and implemented at the next rollover project
This is about deleting the log files as per an agreed retention period.
We typically have an automated job in place to do this for log files but we agreed a reasonable alternative in this instance was for the task to be completed manually during the rollover project.
2.Outstanding Jiras
There were jiras not done as part of this project for budget/ priority reasons. They have been reviewed and prioritised for future project:
