Completion Report

Project Summary:

This project was not successful.

The aim of the project was to enhance the Simulated Patients Database used in the Centre for Medical Education.  The key enhancements, as documented in the brief, were to add:

• Calendar View as seen in EPPSAT database (number one crucial enhancement)
• Need to balance Simulated Patient scheduling between two or more users
• Alert system to remind the user to raise invoices (this is done in eFinancials)
• Requirement to show which scheduled activities are Under- or Post-Grad
• Basic reports to show a breakdown of Exams and Skills, by SP’s across different venues and the time spent in each discipline over the year
• Basic mailmerge letters – these all exist already and are set up for each venue and activity, so should be easy to incorporate into the database.

The system delivered did not pass UAT, even after extra effort was expended, and did not meet the expectations of the business.   The project sponsors were not willing to fund extra effort.  All parties agreed that as the system was not fit for purpose, the project should be closed.   Applications Division refunded all payments.

Analysis of Resource Usage:

Staff Usage Estimate: 25 days

Staff Usage Actual: 38 days

Staff Usage Variance: 52%

Other Resource Estimate: 0 days

Other Resource Actual: 0 days

Other Resource Variance: 0%

Explanation for variance:

The overall problems with this project are reported in the lessons learned section, below. The increase in the estimate over time was documented in the issue log, with particular issues noted as follows:

As documented in issue 7, three days were added to the budget to allow handover from one developer to the next.

Three more days were allocated for rework to cover mistakes in the original release, as documented in issue 8 .

Problems found during UAT led to further increases, documented in issue 11 .

Applications Division absorbed six days of the increase, to allow for the handover (issue 7) and rework (issue 8).  The MVM college budget provided a further three days of the increase.

The effort recorded in excess of the final agreed budget was spent determining the way forward and also on normal project reports during this period.

Key Learning Points:

1. Lightweight software development projects, such as this aspired to be, require either (i) a precise definition of requirements and design and what will be signed off, or (ii) a close working relationship between the project sponsor and the developer over a concentrated period of time.

Neither approach held in this project.  Several months passed following meetings to discuss requirements before software was delivered, and several months passed between delivery of the software and this software being tested.  There were frequent misunderstandings regarding what was expected.  Project staff left over the period of the project, which entailed increase effort for handover; a quicker project would have avoided this. The Project Sponsor confirms this last paragraph as the key lesson to be learned.

2. Software development projects should clearly prioritise requirements. The developer should build these in a phased or iterative fashion, in order to demonstrate progress, and the business lead should test these releases to check the direction taken.

Whilst lightweight software development projects should have light touch project management, the need to maintain rigour, particularly around tracking actual time spent vs estimate, needs to be emphasized and checked weekly.  Project Sponsors should be provided with this information regularly to make informed decisions on whether to proceed with the current plan or to adjust scope or budget accordingly.

3. The implications of funding and support arrangements must be absolutely clear and understood.   This includes what will happen if a project fails to deliver within the original estimate, and what will happen if issues arise during use and/or on particular PCs. 

4. MS Access is sensitive to the environment on which it is installed, especially if linking to a shared backend and/or other tools such as MS Outlook.  Projects using MS Access need to take extra care to ensure that development uses environments that match the production environment, and to control changes in the production environment.  Adequate support arrangements need to be in place.

Outstanding issues: