Completion Report

Project Summary:

Background

This project delivered;

• All required HMRC tax patches issued by Oracle
• All relevant Oracle security patches

Two other proposals were also included in this 2015/16 Annual Maintenance project

• Pensions re-enrolment (AP56-018)
• End of Contracting out (AP56-019)

Scope

This project progressed the work required to meet the University's legislative obligations and applied Tax and/or other annual compliance updates for Oracle HR & Payroll. This is a standard recurring event to meet HM Revenue & Customs requirements.  A significant IS and Business Partner input was needed, to ensure the HMRC application was updated to the appropriate legislative status, and to complete the actual Tax Year End and Tax Year Start for 2015/16 Tax year.

In addition, Oracle required that the appropriate patches (RUP 8) had to be applied in Phase 1 before the Legislative Patches in Phase 2.

The scope of the project included and has been delivered;

• RUP 8
• Re-enrolment for Pensions
• The HMRC tax patches issued by Oracle for tax year end and tax year start
• Up to date Oracle security patches
• End of Contracting Out for Pensions Schemes
• Updates to P60’s
• Any Legislative updates required by the March 2016 Budget

Objectives

• To ensure that the University remains compliant with UK legislation by March 2016
• Ensure that all agreed security patches are applied to Oracle HR & Payroll DEV, TEST and LIVE by end May 2016.
• To include the patches required for re-enrolment for pensions to be Live by Feb 2016
• To include the patches required for 'end of contracting out' by April 2016
• Enable the University to issue P60's to all staff and pensioners by end April 2016, before May 2016 (if required).
• Comply with any Legislative change resulting from the budget announcements in March 2016 (if required)

Deliverables

This project will deliver;

Benefits

• The University is compliant with the HMRC changes for 15/16
• Oracle HR & Payroll system has been patched to cover any security updates provided by Oracle which reduced the chance of any breaches of security of sensitive data.
• University issued P60s to staff and pensioners.
• Remained compliant for 2016/17 - start of year

Success Criteria

Analysis of Resource Usage:

Staff Usage Estimate: 150 days

Staff Usage Actual: 134 days

Staff Usage Variance: -11%

Other Resource Estimate: 0 days

Other Resource Actual: 0 days

Other Resource Variance: 0%

Explanation for variance:

Phase 1

• At the start of the project the Test Clone was completed before the Dev Clone. This caused significant rework, applying patches involving 4 projects, to ensure the environments were kept in sync before the Test Clone was redone and the RUP 8 work could start in October
• Dev had so many issues that the Go Live date had to be changed 4 times ( between Oct and Feb)
• During Phase 1 we had early indications that the amount of RUP 8 + Re-enrolment patches and HR Global runs that the downtime was significant even before other patches were incorporated before P1 Go Live

Benefit with the above delays, that October Live date was re-used for:

•  IE11, Security patch and Rapid Clone Patching (PPP007 work moved from October downtime, due to length of estimated downtime).

Phase 2

Oracle released huge numbers of patches in this project and even when the initial patches were complete, more arrived.

Expected patches for TYE work for start of March, followed by additional security patches a well as RTI and Re-enrolment for April, followed by further work in May (P3) 

P60 also had further patches released by Oracle after the initial P60 worked.

P60

There was an issue with the coding for the P60's :

• this resulted in not producing output for multi-assignment employees (approx. 1000).
• this was not picked up from Payroll's testing.

Payroll successfully identified those affected and produced their P60's via an assignment set, as Live had been updated with a patch which overwrote the previous code change.

The issue with the P60 was because of another Oracle bug.

Phase 3

Further RTI and Re-enrolment patches continued to arrive in May for the May payroll with extremely little notice (1 week).

• Had to move through Dev, Test  and Live between 12-16 May.
• This was successfully managed working with PPP004 Migrate Oracle HR Payroll and Pensions Application project

Summary

Although a large number of un-expected and unplanned patches have been required and have been successfully applied, this project has been more similar to a support project where there is constant change with little planning possible. This can be tricky given the urgent resourcing requirements.

The budget allowed for this largely patched project

However the continued running of this project has required duplicate work for the PPP004, Migrate Oracle HR Payroll and Pensions Application project, where the patches had to be applied and re-applied a number of times.

• A number of security patches had to be held over until after the migration of the application tier.
• The database tier was fully patched, but not the application tier. This was agreed and catered for under PPP004 Migrate Oracle HR Payroll and Pensions Application project

General Comment for PPP007

• Nothing has been straight forward in this project.
• Bad service from Oracle.
  • Had Oracle tested the work before it was released?
• The amount of bug fix patches released by Oracle was really concerning. Some of the failed patches were UK legislation. The impact on UAT created a risk to the project-time and resourcing
• Huge thanks to the IS developers/database administrators for managing and applying all the patches at short notice-much appreciated. (Payroll Business Lead)

Key Learning Points:

Security Patches

Can be difficult to accommodate the security patches in the TYE project. Maybe other options should be considered? Options:

• fit the security patches in each phase
• complete the security patches earlier
• split the patches up between P1 and P2
• remove security patches from TYE
  •  Apps Supp take them on as Support with Dev Tech completing the work
  • Tech Man handle the patches when they are released, 4 times a year
  • As  the work is usually than 5 days, to go through Dev, Test  Live, they are within a project

• However, in summary, whichever the option selected, all options require downtime whoever does the work. One option suggested at closure bu Dev Tech was to separate the security patches to September (still once a year)
• The Payroll Business Lead commented that the current IS approach of saving up security patches for deployment in PPP007 is a high risk to the PPP007 project. Some of the legislative patches were delayed while issues with security patches were resolved. Request that the current IS approach to applying security patches is reviewed?

Change Control

Consider creating separate activities for any significant bits of work which are done during the year.

For example, activities for RUP 8, TYE, security patching etc

• The will enable a process for identifying individual pieces of work and when they were implemented (whereas if the same change control is used for the whole project it is harder to see.

For example, this has been done on PPP004, Migrate Oracle HR Payroll and Pensions Application, see C1510-095

Multiple Projects

Running multiple projects on 2 environments is extremely challenging and puts projects at risk. There is a new environment called CONF (can we change this name to Payroll Sandpit please?) however there were issues accessing this environment throughout the project which meant that we couldn't progress functional projects because all the other environments were being patched/down.

• Can IS please advise what the status is with this environment, arrange a refresh from HR-Live and release?

Outstanding issues:

Considerations for the Annual Maintenance project and how environments and security patches should be handled:

Can be difficult to accommodate the security patches in the TYE project.

• However, in summary, whichever the option selected, all options require downtime whoever does the work. One option suggested at closure by Dev Tech was to separate the security patches to September (still once a year)
• The Payroll Business Lead commented that the current IS approach of saving up security patches for deployment in PPP007 is a high risk to the PPP007 project. Some of the legislative patches were delayed while issues with security patches were resolved. Request that the current IS approach to applying security patches is reviewed?

Running multiple projects on 2 environments is extremely challenging and puts projects at risk. There is a new environment called CONF (can we change this name to Payroll Sandpit please?) however there were issues accessing this environment throughout the project which meant that we couldn't progress functional projects because all the other environments were being patched/down.

• Can IS please advise what the status is with this environment, arrange a refresh from HR-Live and release?
• This relates to PPP004 'Migrate Oracle HR Payroll and Pensions Application' however with the cross over it is useful to include here as well