Closure Review

Project Summary:

Contributors

Scope, Objectives and Deliverables

The eTime application was created, under project FIN072, to meet two distinct needs:

•  to meet legislative compliance requirements for researchers working on EU funded research grants
•  to replace an existing, labour-intensive, paper-based process for submitting and approving timesheets for Hours to be Notified staff

When the budget for the original project was reached, the remaining business requirements were collected into the Phase 3 Requirements Document. 

In the months between eTime's initial release and the intitiation of the current project, a number of recurring issues were reported.  

This project assessed and prioritised the carried forward requirements along with the recurring issues.  Its plan was then to iteratively release system enhancements, in batches, according to the agreed priorities, until the budget of 157 ISA days was reached.

Schedule

Analysis of Resource Usage:

Staff Usage Estimate: 157 days

Staff Usage Actual: 216 days

Staff Usage Variance: 38%

Other Resource Estimate: 0 days

Other Resource Actual: 0 days

Other Resource Variance: 0%

Explanation for variance:

HSS provided direct funding for a number of additional enhancements. 

Finance were unable to identify business stakeholders or provide business requirements for the high priority Batch Processing requirement. 

The continuing absence of Batch requirements caused the project's priority to be downgraded from 1 to 2.  This impacted the project's ability to retain its resources.

While waiting for requirements, the project team had to choose between either suspending, or continuing to deliver batches of lower priority requirements.  The latter option was selected, because the Designer - who was key to the project's success - would not have been reassigned to the project following a suspension.  As a result, only one lower priority requirement remained to be de-scoped when the Designer's proposal for Batch Processing was approved.

The complexity of Batch Processing, combined with the low availability of the Designer and the inexperience of the replacement Developer, caused several increases to the Build estimate. 

The IS Applications Software Development section re-organised in August-September 2013.  This resulted in the loss (apart from a 10% advisory role) of the project's Designer, and in the complete loss of the original Developer, and gave rise to impacts for:

• the learning curve required by the replacement Developer
• the delayed start date of the replacement Developer, due to commitments to higher priority Finance project and support tasks
• the subsequent reduced availability of the replacement Developer, due to commitments to higher priority Finance project and support tasks
• the reduced availability of the Designer, due to her assignment to a non-CSG team and to a high priority agile project within the new team

Key Learning Points:

        Recommendations:

1. Resource stability within a project team is an important indicator of project success and should be highly prioritised by IS Applications (ISA).
2. Both ISA Project Management and Business Area Management should have a dedicated, stable resource, committed to the project at a level to be agreed during the Planning stage, taking key project responsibilities into consideration.
3. Continuing support from the System Designer should maintained throughout the remainder of a project, at a level to be assessed based on the complexity of the Design.
4. High priority business requirements should be accompanied by a high level of business commitment, for the specification of requirements, and for their subsequent support and testing.
5. A key business decision-maker should be identified by the Project Sponsor at the start of the project.  This resource should be responsible for attending all project meetings, and should both feel and be empowered to make key project decisions.  If  any stakeholder (ISA or business) knows ahead of a meeting that a decision will be needed, then s/he should inform all stakeholders of this, so that they can discuss it with appropriate colleagues/managers ahead of time, and bring their answers to the meeting.
6. For substantial development projects, weekly or fortnightly project meetings should be scheduled, and should include key development and key stakeholder representatives.
7. The level of business stakeholder commitment expected by the project should be clearly communicated and agreed by all parties at the start of a project.  If any stakeholder is unable to make the required commitment, then the Project Sponsor / Programme Manager should identify a suitable replacement.  Caveat:  this could, however, risk losing good people before a project gets off the ground.
8. The Business Area Manager should invite representatives from the FIS Help Desk to attend key project team meeetings, e.g. for system demos given when functionality is about to be released for UAT.  This option might also be considered by other business stakeholders, and by ISA.

        Successes: 

The key stakeholders are delighted with the eTime application, and report that users across the University find it to be "user-friendly", with little or no need for training. 

The Project Sponsor has communicated to the University her target of completing the transfer from paper-based time recording to eTime by the beginning of August.  In support of this target, business presentations of eTime are being offered to potential new users, across the University.  Reports back from these presentations are that they're being enthusiastically received.

The project benefited greatly from the high levels of expertise and commitment of the key business stakeholder group and the System Designer.  The relentless encouragement and support of the HSS stakeholder group were fundamental to the project's success.

Both stakeholder groups have provided onward training to users in their areas.

The continuity of both the key business stakeholders and key ISA team members from the earlier eTime project (FIN072) was also of great value to the project.

The weekly project meetings, though demanding of people's time, have made an important contribution to the project's success, by ensuring:

• continuous communication and a very positive working relationship between the ISA team and the key business stakeholders
• increased engagement with the project (at least, for those invitees who chose to attend)
• the ongoing ability to question, further refine, and therefore better understand business requirements
• a ready-made forum in which to demonstrate each batch of enhancements, ahead of their release for UAT
• the ability to discuss, and therefore to better understand, any testing issues raised

The model of the Designer continuing to support the Developer throughout the project was for the most part successful, though the Development Team reorganisation and the relocation of the Designer for three days each week challenged the model somewhat. 

The project delivered a series of small enhancement batches, some with very quick turn-around.  The deployment process was standardised, and each batch required only a small amount of deployment effort.  A low-fte resource booking was in place throughout the project, for the Development Technology analyst to support deployments as required.  This analyst's skill and support were of great value to the project, allowing the many enhancement releases to flow smoothly though the testing and delivery process.

This is a very complex application, but the project has provided a wealth of systems documentation, as well as a comprehensive Peer Test plan, to pass to future enhancement projects.  In addition, the Designer has provided business process and technical system presentations to Applications Management colleagues.

        Areas for Improvement:

It was unfortunate that the ISA reorganisation removed the original Developer from the project, and reduced the Designer's available project time, just before Build work started on the extremely complex Batch Processing functionality.  The project suffered from the handover, and from the late start and comparatively low fte that was initially available for the replacement Developer.  Further, the limit of half a day a week of Designer support often proved inadequate, and was supplemented at the Designer's own expense.  (See recommendations 1 & 3.)

The Business Area Manager's dedication to the project could not be faulted, but conflicting work commitments (e.g. Payroll projects, interviewing panels) made it very difficult for him to support the project to the level it required.  (See recommendation 2.)

It was unfortunate that no stakeholders could be found to provide business requirements for the Batch Processing functionality.  The Designer presented a proposal for this functionality in mid-April, and the Project manager had set a hard deadline for requirement confirmation of the end of June.  However, it was not until early September that the Designer's proposal was approved.  By that time, the remaining project budget and timelines were inadequate to deliver the extremely complex Batch Processing functionality.  Additional budget and extended milestones were therefore required.  (See recommendation 4.)

On the rare occasions where a disagreement arose in identifying business requirements, it was not always easy to determine which view should prevail.  This could result in a delay of a week, or of several weeks, as the Business Area Manager sought a decision from the Project Sponsor.  (See recommendation 5.)

Outstanding issues:

There are no outstanding project issues.

There is one outstanding project delivery.  The Business Area Manager has still to update Finance's User Guidance Documents to reflect the enhancements delivered by the project.  (This delivery has always been outwith ISA's project scope.)

Two further sets of potential requirement changes have been mentioned.  These are outwith the project's scope, and will be taken forward by future project(s):

Research Grants section has indicated that the EU Grants authority plans to introduce new time recording requirements, while retaining the existing requirements for current grants.  The Research Grants stakeholder has communicated this to the Project Sponsor.  Full details of requirements have not yet been received from the European Commission.

Human Resources have indicated that changes will be required to support the removal of zero hours contracts.  Human Resources have plans to take this forward as a separate project.  Detailed requirements have not been received from HR.