Completion Report

Project Summary:

This was the annual project to upgrade the Central Wiki service to the latest version. This year the project had a wider scope to include replacing obsolete application tier hardware as well as moving the DB over to the new DB infrastructure running Oracle 12C. This work was scheduled for 2016/17 however, the project team identified an opportunity to deliver this earlier.

The scope agreed at planning was:

1. A review of all open Atlassian JIRA tickets - checking any bugs or issues affecting v5.9 - including check of plug in compatibility - COMPLETED
2. A refresh of the DEV and TEST DB environments with the latest production data - COMPLETED
3. Installing the latest version of Confluence on the existing DEV servers - COMPLETED
4. Conducting functional testing of the upgraded wiki service - COMPLETED
5. Migration of data on DEV database (Oracle 11g) to new (Oracle 12c) DEV database infrastructure provided by project INF110 - COMPLETED
6. Cloning of data on new DEV database (Oracle 12c) to new (Oracle 12c) TEST database infrastructure provided by project INF110 - COMPLETED
7. Build of new DEV, TEST and LIVE servers including deploying the newest version of Confluence to DEV, TEST & LIVE - COMPLETED
8. Migration of Data from LIVE (Oracle 11g) database to new (Oracle 12c) LIVE database infrastructure provided by project INF110 - COMPLETED
9. Repointing of Live URL to new LIVE infrastructure - COMPLETED
10. User acceptance testing of the upgraded Wiki - COMPLETED
11. Handover and documentation with Production Management - COMPLETED
12. Recoding of the IDM connector - COMPLETED
13. Creating a separate TEST and LIVE environment of the WIKI, including separate URL's for Genomics (TEST & LIVE) - COMPLETED

Analysis of Resource Usage:

Staff Usage Estimate: 80 days

Staff Usage Actual: 120 days

Staff Usage Variance: 50%

Other Resource Estimate: 0 days

Other Resource Actual: 0 days

Other Resource Variance: 0%

Explanation for variance:

The project has spent 120 days against the original estimate of 80 days. The break down of spend against estimate is presented in the table below.

COM026 Effort breakdown by project team and phase

From the above data it is clear that the phases from integration to deliver were underestimated, specifically for delivery they were most inaccurate. The reason for this can be attributed to the technical complexity of the work involved. There was some unplanned out of hours work during the acceptance phase which was taken as time off in lieu after deployment. It was only during acceptance that the implementation strategy was finalised. The implementation plan was created for TEST however, some issues after TEST was completed resulted in changes for the LIVE deployment.

Key Learning Points:

The majority of responses to the closure survey indicated that the project achieved it's objectives and confirmed that the business requirements had been met. Survey responses all complimented the project team on working well and effectively together. Particular thanks should be noted to Ewan Scott and Alain Forrester involved in the deployment to LIVE. This was completed over two weekends involving extended working hours. 

Despite being in regular dialogue with Atlassian throughout the project, some issues with our configuration files did not materialise until we opened a high priority support call with the vendor for the post upgrade performance issues. Although Atlassian did review the configuration files prior to the upgrade, in future we should ensure that this review is more thorough for example by the vendor's third level support prior to deployment. This would not only reduce the risk of post upgrade issues but also save the time required to investigate, tweak and fix configuration issues. 

It is worth noting that TEST and LIVE ended up with a clean v5.7.5 install before upgrading to v5.9 due to the erroneous CLUSTER install type which had gone in at some time in the past. This did not seem to be an issue in DEV and there was no need to redo the install on DEV, however this was an additional factor in time and cost. 

Another learning point was the need to try to avoid a complex upgrade of this nature so close to the start of term. With this in mind the upgrade project for 2016/17 has been scheduled to start earlier, after the Christmas break. Where another upgrade project comprises of so many factors this would be planned to start even earlier. 

Further feedback though the CCPAG, is the request from Schools to have one or two months for User Acceptance Testing. The practicalities of this will be investigated during the planning phase of this year's project, however it should be noted that where a longer period for UAT is scheduled this does need to be utilised in its entirety. 

Outstanding issues:

Several issues were encountered post deployment. These have now been resolved or will be picked up as Service activity. . 

• An issue with anchor links were not working in a particular theme was resolved by Service Management post deployment.

Resolved issues no longer outstanding

• Post deployment DB locks occurred resulting in the service restarting, rendering it unstable. After investigation with the vendor these were eventually resolved. 
• Email addresses missing from some profiles. This issue was not caused by the upgrade but was highlighted after. A decision was made between Production and Service Management not to auto populate email addresses but add these to profiles as and when required. It was felt that doing so would generate thousands of page update notifications for those who were watching pages but currently not receiving mails