Completion Report

Project Summary:

The Project was started in October 2014.  Despite the lack of an approved Brief, the project proceeded to the Build, and even Integration stages.  (See Scope section below, which shows which PURE versions had been applied in Dev/Test by the time the Brief was agreed.)  However, the Project Brief was not completed or approved until June 2015.  The target versus delivery dates recorded in this report are therefore not entirely reflective of the project's performance.

The original scope was to deliver the Java upgrade by Januaary 2015.  However, the Java version failed testing, so a decision was taken to wait for the next version.  That next version also required a Tomcat upgrade.  Both the Tomcat version and the subsequent patch also failed, so a further upgrade had to be applied.

Overview, from Project Brief:

This project is being undertaken to upgrade the PURE system to the latest versions of the software and the underlying Java to version 1.8, and Tomcat Technology to version 8.

The PURE system delivers a functional and usable research management information system, designed for researchers, administrators, and managers across the University.

The PURE system has been in place in an operational capacity since summer 2011.  Regular upgrades to the software are normally undertaken by IS Production Management as part of the agreed support arrangements. These particular upgrades were more complicated so have been raised as a project.

Scope:

When the Brief was completed, the following PURE versions, with supporting technology upgrades, had been applied in Dev.

The Brief therefore confirmed that the scope of the project was to manage and deliver the upgrade of Java to version 1.8, the upgrade of Tomcat to version 8, and the upgrade of PURE to the version that passed business UAT testing in the Dev environment.

No change to scope since Brief approval.

Objectives and Deliverables:

Schedule:

Analysis of Resource Usage:

Staff Usage Estimate: 76 days

Staff Usage Actual: 60 days

Staff Usage Variance: -21%

Other Resource Estimate: 0 days

Other Resource Actual: 0 days

Other Resource Variance: 0%

Explanation for variance:

Key Learning Points:

1.  Resource churn

It is always preferred that the membership of a project team should remain stable.  Unfortunately, this project has experienced an unusually high level of turnover, with resource changes from three of its four key IS Applications teams, due to reorganisation, to illness, and to the requirements of the University's Priority 1 projects.  This has impacted the project's elapsed times and cost, due first to the losses, and then to the number of handovers / learning curves required. 

While the project's resource losses could not have been avoided, it has been recommended that if future projects experience similarly high levels of turnover, then the Project Manager should escalate this as an issue, for discussion with the Programme, Portfolio, and affected Team managers, to agree a resolution for the project.

2.  Faulty software releases

The software provider released five PURE versions, all of which contained "show-stopper" faults, before the sixth version could be accepted for further deployment. 

While this issue also could not have been avoided, it has been recommended that future similar projects might use a more flexible project model for software updates of this type.  This model would allow for a number of iterations through the process, until sign-off is confirmed in the Development environment. 

3.  Cost of project

Both the Business Lead and the Applications Management representative have expressed concern about the high estimates, and the current and historical cost of project-based upgrades, in comparison with the time required for the regular upgrades that are managed within Applications Management.  There are a number of contributing factors to the estimates, for example:

• The resource churn mentioned in item 1, above.
• The software churn, mentioned in item 2, above.
• The lack of familiarity with, and documentation for, PURE upgrades in Development Technology.
• The following of the project methodology, with its standard stage sign-offs and appropriate maintenance of technical documentation.  
• The need to re-estimate and re-plan the project each time a software version proved to be faulty.
• The repeated securing of the Development Technology analyst at Atira's request, although Atira subsequently failed to make the requested contact. 

It was suggested that the Development Technology and Applications Management leaders might take this forward for further discussion. 

• A number of suggestions were offered as input to this discussion:
  • On a project-by-project basis, consider whether an arrangement might be agreed to support a (partial?) secondment of the Applications Management specialist to Development Technology.
  • Where an upgrade requires both PURE upgrades and underlying software upgrades, the PURE upgrades might remain solely the responsibility of Applications Management, with Development Technology performing only the upgrades to the underlying software. 
    • Alternatively, those PURE upgrades that involve underlying software upgrades might be performed by Development Technology, while those intermediate patches/corrections that do not require underlying software upgrades might be performed by Applications Management.
  • Applications Management should maintain a single master copy of the PURE upgrade procedure.  This procedure should be detailed enough to be run by a new technical specialist, and should be stored on the Technical Collaboration wiki.
• The Business Lead has also indicated that there may be an opportunity for Atira to perform the upgrades remotely.  (This would require the University to agree to, and to arrange, acceess to the shared infrastructure.)
• The Business Lead does not want future upgrade projects to be managed by Project Services, or to use the full Project Methodology.  IS Applications team and resource managers are requested to identify an alternative means of managing upgrade projects.  For example, small, purely infrastructure projects, have in the past been managed within Development Technology.

Outstanding issues:

The project has no outstanding issues.  However, the Business Lead has asked that the following Actions be carried forward, to be addressed at a Research Programme level:

1. Programme Manager to take forward a note that the Business Lead does not want the full project methodology used for future upgrades.
2. Development Technology and Applications Management leaders to take the concerns and suggestions expressed in Learning Point 3, above, forward for further discussion.  Any resulting proposal should be discussed and agreed with the Business Lead.