Were the project goals met? Were the project deliverables fully or partially accomplished?
The objectives of this project were:
- When a meeting is set up, enable the participants to add the meeting to their electronic diary
- Enable students to add a meeting to Office365 as their electronic diary of choice
The scope of this project was to:
- Where relevant include an electronic copy of the appointment which when opened (or automatically handled by email client/server) will put a slot in the users electronic calendar.
- This will be in the form of ICS/Ical attachments added to emails already sent by the system
The above objectives and scope have been delivered, and the personal tutor meetings are now able to be added to staff and student calendars, including Office365.
Did the project deliver a solution to the problems being addressed? Have the desired operational results been achieved?
The success criteria were that the project will be successful if:
- Students can add the scheduled meetings to their calendar (Office365).
- Staff can add the scheduled meetings to their electronic calendar of choice.
The above success criteria have been delivered, and the personal tutor meetings are now able to be added to staff and student calendars, including Office365 so the operational results have been achieved.
Were additional results achieved besides the original success criteria? Were there any unforeseen benefits delivered by this project?
In addition to the original success criteria the project:
- Delivered cancellation functionality to enable staff to cancel a meeting and have it removed from the students' calendars.
A number of academics do not use an electronic calendar, this project is seen as encouraging them to view the electronic calendar as a positive and useful tool that they may choose to use if they wish, as students are likely to make increasing use of their Office365 calendar in future when their timetable will be made available through it.
Does the Project Sponsor agree that this project can be closed at this time?
Yes, the Project Sponsor comments:
"This new function has significant potential for both students and staff to more effectively arrange and manage their scheduled meetings and is likely to increase in importance and usage once electronic timetabling goes 'live'.
The design and implementation of this particular function is impressive, simple to use and should encourage both students and staff to productively use their eCalendars."
Analysis of Resource Usage:
Staff Usage Estimate: 20 days
Staff Usage Actual: 34 days
Staff Usage Variance: 70%
Other Resource Estimate: 0 days
Other Resource Actual: 0 days
Other Resource Variance: 0%
Explanation for variance:
The last estimate as of 23-Jan-13 was 34d total; the actual effort is in line with this revised estimate.
Estimate at brief (d)
12 – 14
IS Apps Total
The variance between project brief and actual is largely in relation to the development effort, this was due to a number of reasons:
- The code was originally developed as part of SSG001, on which the technical lead worked as a lone developer, and that development was subject to constant change throughout. This led to a lack of cohesion, some parts are consistent while in others there were a number of fixes to reach the very tight deadlines. The intent was to reduce the risk to the ESS Programme by having another developer able to understand and develop the code, which took time from both the technical lead and new developer. In addition the code has a number of complex programming ideas (e.g. hibernate, bootstrap, mach-ii), and each of these frameworks take time for new developers to learn.
- There was concurrent development with SSG004 and SSG007, which meant that the development of the code had to be versioned and work was involved in tracking and harmonising these for release, considering the fixes and deadlines.
- The expectation was that Office365 and Outlook would work in the same way in relation to the calendar functions from external applications, but development took longer to accommodate both Outlook and Office 365 as they were not the same.
- Cancellation functionality was included as it was expected to be simple and without significant additional effort, but took a little to fully work.
- The 'testing loop' took time, as once a bug is identified there are 4 people involved in agreeing, fixing, promoting and re-testing the work, which expands the elapsed time for fixes.
- There were difficulties finalising requirements, as technical constraints limited what could be achieved, and so requirements were flexed in relation to the solutions possible.
- In relation to the SACS effort for testing, some of the effort was due to the development of skills for a new tester, which was not coded against this project (estimated 30-40% of the time).
Key Learning Points:
- The initial development of Personal Tutors code was completed to a very tight deadline, so the code is not ideally written and is in some places very complex. This means that some sections of the code are particularly difficult for others to work on. While it is highly desirable for multiple people to be able to work on the Personal Tutors code, it does mean that development estimates need to be revised upward for future projects to take this into account.
- The 'testing loop' is not quick in practice in relation to elapsed time, even though the individual tasks may be small. Documenting the simple process between SACS and IS Applications for
- validating requirements/fixes (BA & Tester)
- completing a fix (whether SSP Config or Dev Team)
- promoting the fix to TEST (SSP Config or Dev Tech - note SSP Config is much quicker)
- re-testing (Tester)
- and ideally agreeing turnaround times would be helpful for future projects of this nature. In addition defining the test criteria and scripts before development to allow the developers to test against the expected criteria would be preferable to reduce the number of fixes that enter the 'testing loop'.
There are no outstanding issues in jira. There was an issue that related to blank emails that was not possible for SACS to replicate. The Project Sponsor and SACS have agreed that is recorded as a known error which is not further investigated in the project nor support.