Completion Report

Project Summary

This project aimed to deliver a method for staff on the main payroll to receive electronic payslips and P60s, while enabling certain staff to receive paper payslips and P60s if required. 

The project delivered these requirements, however the original budget and the  duration of the project were considerably exceeded.

The business has received many expressions of satisfaction from staff who appreciate online payslips and P60s, and only one objection to the introduction of online payslips.

Project Deliverables: 

Success Criteria: 

The following success criteria were achieved:

• Staff on main monthly payroll  able to access payslips online. 
• Paper payslips delivered  to staff and pensioners in certain categories (such as staff on the main monthly  payroll leaving university employment)
• Paper payslips or P60s  delivered to staff or pensioners who have agreed this with HR/Payroll.
• Online payslips  and P60s  are accessed via EASE.
• Staff passwords can be reset with minimum effort.
• New members of staff on main monthly payroll  and new pensioners on pensioner payroll  to be set up to receive online payslips by default.
• Paper payslips and P60s continue to be delivered  to staff on payments payroll.
• Paper payslips are not produced for staff  on main monthly payroll who should receive online payslips only.
• Paper P60s are not produced for staff who should receive online P60s only.

Partially achieved:

HR database contains:

• up-to-date record of UUN
• up-to-date email address for staff on main monthly payroll, where staff members have an address registered in EDDIR.
• derived email address for staff members who do not have an address registered in EDDIR

Not achieved:

• No adverse effect on performance of Oracle. 
  • Poor performance on the LIVE service was experienced upon  announcing the release of online payslips 
  • The performance improved after configuration changes were tested by HR, Payroll and IS users and applied to LIVE
  • Future management of communications is needed in order to ensure no degradation of response in LIVE

(See outstanding issues below)

Analysis of Resource Usage:

Staff Usage Estimate: 118 days

Staff Usage Actual:310

Staff Usage Variance: 262%

Other Resource Estimate: 0  

Other Resource Actual: £25000

Other Resource Variance: £25000

Explanation for variance:

1. Summary of estimate changes

The project was re-estimated several times:

28 May  2015: estimate increased to 145 days

- due to additional effort to complete the build of  the e-recruitment and password reset deliverables

- for extra PM time due to extended duration of project

9 September 2015 and 9 October 2015  estimate increased to 202 days

- additional effort required to deliver replacement for PAY29 report for paper payslip

-  to redeploy and re-test changes in HRDEV and HRTEST which were wiped out by the cloning of those environments and to cover the extended duration of the project

- for extra PM time due to extended duration of project

 18 May 2016 the budget was confirmed at 276 days

- to restart project after it had been suspended

- to introduce 2 new contractors to project

-  to complete  report for  paper payslip

- for extra deployment effort due to splitting delivery of project to deliver password reset, UUN/email and e-recruitment deliverables into LIVE

- for extra PM time due to extended duration of project

29 March 2017 the budget was increased  to 305 days

- to resolve post-deployment issues with the online payslip

- to resolve poor performance in LIVE

- for extra PM time due to extended duration of project

2. Summary of reasons for increases in effort

Loss of senior development resource: 

• loss of the senior developer resulted in increased effort to deliver the PAY29 report (which required to be changed for users who would still require paper payslips) as the remaining resources had less experience.
• loss of the second  developer resulted in the recruitment of  contractor resources  to whom handover was required  
• the specialist contractor suggested the use of new technology which was used to deliver the new PAY31 report which replaced the PAY29 report

Extended duration of the project:

• unavailability  of resources in the business due to higher priority work extended the duration of the project adding to overheads and resulted eventually in the suspension of the project for several months
• unavailability  of resources in IS due loss of senior resource and to higher priority project work conflicting for resources extended the duration of the project adding to overheads

Changes in project scope

• creation of new PAY31 report

      -  required due to the extended duration of the project, this users newer, more supportable technology and contained improvements compared to the previous PAY29 report 

• creation of online payslip

      - it had been assumed by the project team that the business would be able to deliver this using existing Oracle functionality but due to the length of time before  the project was ready to deliver, a different option was available to the business, requiring the use of the contractor

• addition of link to UKVI letter added to online payslip section in oracle self-service
• additional compliance changes to the paper payslips emerging after delivery

Rework required due to extended duration of the project: 

•        redeployment  and retesting of work in DEV and TEST after the HR system was cloned from LIVE
•        redeployment and retesting of work withdrawn during suspension of project

Post-deployment issues encountered during parallel run period:

•  several issues not identified in testing were reported in LIVE and additional resource was required to resolve these.

Performance issues identified in LIVE

• The LIVE user experience was poor when online payslips were advertised to users.
• Significant effort was required to investigate and resolve this, including the assistance of IS, Payroll and HR users in testing.

3. Other cost increase

Requirement to buy additional oracle licences

As Oracle Self-Service was already in use it was assumed that the university had already paid for the licences needed to allow all users on the main payroll to access online payslips. This was not the case.  Only 6,500 licences had previously been bought and so additional self-service licences were required. An additional 8500 were bought at a cost of (approximately) £25000.

Key Learning Points:

• Paper Payslip  - Delivery of the paper payslip took more effort than expected, this was in part due to the loss of experienced IS resources early in the project and the lack of IS experience with working with the complex payroll data and functions. Initially the PAY29 report was to be repurposed as this was considered the most efficient option to deliver the requirements. This turned out not to be the case.

  • More consideration should have been made to the risks involved in rewriting very old code where little documentation still existed
  • In hindsight, engaging specialist training or technical skills earlier in the project would have reduced the overall duration and effort 
  • The new PAY31 report delivered by the project, uses  a newer,  more supportable technology (XML)   and is therefore more supportable than the PAY29 report which it replaced

• Replacement of key resources - The experience and knowledge lost by the departure of key resources during this project have not been replaced by UoE staff, partly due to a lack of appointable candidates to a recruitment and latterly due to the minimal demand for specialist skills in the current 3 year plan and awaiting the direction and of service excellence.

  • The use of contract staff has worked extremely well to cover this gap and should be considered in the future if specialist knowledge is required short term.
  • The recruitment of a specialist contractor to deliver the paper payslips could have been considered earlier

• Change of use

  • Where a project aims to greatly increase user access to a service,  and where automated testing is difficult or costly, efforts must be made to test with user volunteers in order to gain an understanding of how increased usage will affect performance and the live user experience.

• Suspending project if resource availability changes

  • The project experienced significant delays due to the unavailability of business and IS resources.
  • Keeping the project open for an extended period while little progress was made  had significant implications for the project budget

• Post-deployment changes and costs

  • Where a project is to remain open for an extended period after delivery, sufficient budget should be retained to enable changes to be developed and deployed after the initial delivery
  • Alternatively, a project may agree to hand over certain deliverables to support before closure

• Gaps in understanding of licence costs

  • The additional costs of licences was misunderstood at the proposal stage and so the cost savings to the business were miscalculated at the proposal stage
  • Although the purchase of new licences was approved, the cost benefits could have been reassessed at the analysis stage

• User Communications

  • The meetings  and workshops held by the business with user representatives worked well, in particular ensuring that concerns about staff without access to the Internet were addressed. Methods used included:
    • Roadshows at several sites
    • Posters advertising the change
    • Emails to staff
    • Meeting with union representatives
    • regular updates to CMG
  • Some senior management raised concerns that the change had not been adequately publicised, however no improvements  in the comms plan were  identified

• Delivery  approach 

  • A phased roll-out of online payslips could have allowed the performance issues to be identified while affecting only a subset of users. This was discussed by the project team (for example by  rolling out to IS staff only) but not felt to be appropriate. It may be worth considering phased introduction of services (where possible and appropriate) even if this delays full delivery.

• Recording of Scope changes

  • ​Delivering load testing was ruled out early in the project due to the cost of delivery and the fact that Oracle Self-Service was an existing application which had already been tested. However the business leads were under the impression that it had been done and as the project manager had not recorded the scope change in the project records. This  underlines the importance of recording such decisions in order that such misunderstandings do not occur.

​

• Extended duration may have benefited from an annual review  - the project took more than two years longer to deliver than expected and experienced the loss and replacement of several key team members . This led to lack of momentum, loss of knowledge and some miscommunication between team members. The project manager will discuss with project services colleagues whether a project in such circumstances might benefit from an annual review  and restatement of scope, objectives, deliverables,  and benefits in order to give the project team time and space to re-evaluate progress 

Outstanding issues: Performance 

• Communications with users must be managed in order not to drive significant numbers of users to access the self-service functionality at the same time
• Should the service fail during a period of busy usage of self-service Production may restart the service but will take no other actions
• IS Apps will discuss future measures to resolve the performance issue and future use of self-service outwith this project