Completion Report
Project Summary:
The project was to deliver an online questionnaire accessed from the Student Recruitment and Admission website. This questionnaire accesses the existing Widening Participate calculation to provide an indication to the applicant regarding their eligibility for a contextual offer from the University of Edinburgh. The site also provides applicants with supporting information on how contextual admissions operate.
Analysis of Resource Usage:
| IS Apps Staff Resources Estimated on Project Brief (Days | 46 days IS Apps resource |
| Actual IS Apps Staff Resources Used (% Variance) |
83 Days IS resource (+80%) |
| SSP non IS Staff Resources Estimated on Project Brief (Days) | 45 Days |
| Actual SSP non IS Staff Resources (days) | 39.5 Days |
| Other Resources Estimated on Project Brief | |
| Planned Delivery Date (goLive) from Project Brief | 26th September |
| Actual Delivery Date (go live) |
18th October |
Explanation for variance:
This project utilised an external consultant who was unfamiliar with the chosen technology. The decision to implement using Python rather than the planned use of PHP caused some issues in this developer being able to complete the work. The decision to use Python was done so against the express recommendation of the Software Development team and given the timescales and there being no other available resources it was seen as an acceptable risk to allow the contractor to do this work. This was not communicated to the PM.
The timing was also such that the core members of the development team responsible for developing our Python capability were on annual leave at the time the contractor was expected to use the new infrastructure. This left him with no support until they returned. Peer testing and assistance at the end of the build stage highlighted some concerns with the consultants approach to coding the application which led to additional time being required both for the support needed and in extra time to complete a more thorough peer review. This led to some rewriting of the original work.
At this time the consultants contract came to an end and the final element of the changes were passed to an internal member of staff who was leaving the organisation. It was felt that the remaining work was minor and could be completed within his available time but this proved not to be the case with some ongoing bugs being detected. Another temporary resource was assigned to the bug fixing but again he completed his time without completing the work required and finally a third internal resource was applied who stayed with the project to the end. The peer reviewer was also involved throughout this time to support the developers who were new to the application.
In addition the resource allocation for the acceptance and closure stage of this project was underestimated due to the lack of knowledge of the new PM who was unaware of quite the involvement form several departments in this stage via ASOR and DSOR meeting and technical handovers.
Key Learning Points:
PM has a better understanding of the time involved in Projects from other departments. Also, the schedule of tasks which are agreed often seem to take longer so the actual process of user testing and going live need to be tightly managed to ensure that deadlines can be met.
Whilst contractors skills will be known and matched to the requirements of the project, if there is a change of scope affecting the technical requirements there needs to be a reassessment of the resources being used. The decision on the most appropriate technology when designing a solution should be agreed by the development team. On this occassion the decision to use Python was thought by the development team to be poorly conceived for this project, given the available resources and the fact that INF115 had not yet completed. Such risks should becommunicated to the Project Manager, assigned and managed to ensure that there won't be a negative impact on the project, particularly as this was one of the first project utilisting this technology.
With regard the use of contractors and managing the development; progress and quality were compromised by the consultant working off site . Off site working should be flagged as a risk and a technical resource assigned to manage this risk. This person should have regular communication with the consultant and monitor the development as it progresses so that peer review is not identifying significant issues. It is imperative that the PM has regular updates regarding such progress and any changes to the risk to ensure that the project can be managed and time delays understood.
The allocation of resources should also have been identified as a risk when the project team were unable to resource a developer to take over the work. If this was flagged as a risk which was managed and reassessed then management could have been made aware through the changing RAG status when issues occurred.
Outstanding issues:
None