Completion Report
Project Summary:
The University has ceased HTBN (Hours To Be Notified) contracts under the Enhancing Employment programme of work. HTBN employees have been moved, predominantly, onto Guaranteed Hours contracts. Other atypical alternative employment arrangements are used in the University, eg Annualised Hours, although are not widely used potentially because administrative processes and systems are not in place to support.
There is a large administrative overhead for the management and reporting on the GH contracts in the devolved HR teams and business areas created in part by the manual nature of the process. The UHRS Systems team is also impacted by the inability of devolved areas to access the information they require and by the challenges of current reporting capacity.
This analysis will feed into the design and technical implementation project, which will deliver a method for recording guaranteed hours that have been offered for the specified period, and a method for managers to report on Guaranteed Hours employees e.g. to identify the imminent end of the specified period. Currently, Guaranteed Hours are being managed locally in a variety of different ways all resulting in significant and manual transfer of data to spreadsheets for final reconciliation and production of documentation in local HR teams.
Reasons for taking this project forward
The Principal has made a strong and public commitment to the removal of HTBN contacts.There is also a need to ensure that appropriate business processes, supported by technical solutions, are in place to manage Guaranteed Hours contracts.
· The systems will comply with the University’s change to GH contracts and will help the management of Guaranteed Hours contracts.
· Ensure that employees on Guaranteed Hours contract types continue to be paid and contribute to pensions correctly.
· Provide MI on use and management of the contract types. This will include information to support the Business in estimating the level of hours which should be guaranteed in each contract.
· If systems are not brought in line with policy and processes then the manual overheads to the University are estimated as large impact.
· Provide a robust system to manage hours to ensure that there is visibility on how many hours have been guaranteed and for what specified period, and the difference between hours guaranteed and hours worked for individual employees. For particular business areas, including ultimately across the University, the requirement to have the capacity to track hours guaranteed, offered and worked (including when the hours were worked) is important.
Were the project goals met? yes
Were the project deliverables fully or partially accomplished? The project deliverables were fully accomplished.
The goals of the project were:
The Enhancing Employment Analysis project will determine the specific requirements for implementing, as a separate technical project, a management and reporting solution for Guaranteed Hours only. The aim of the analysis project is to identify all GH employment arrangements, and articulate the business processes for managing them. This will be achieved by consulting key stakeholders.
The objectives of the project were:
Articulate the business requirements needed to support the management and reporting on the Guaranteed Hours contract and focus on:
1. Improve efficiency of the current method of
The following deliverables were achieved (from project brief)
ref | Deliverable | priorities | delivered? |
1 | Suite of clearly defined business requirements documented in a Business Requirement Document (BRD) detailing the current business processes and addressing the following questions: · How are Guaranteed Hours being used and managed by the different stakeholders? · What are the recording and reporting requirements (including exception reports)? · What are the current data sources; the data required, required feed and compatibility of data? · Are there legal requirements? · Are there financial regulations, eg Working Time Directive?
| mandatory | Yes The requirements have been delivered not in the form of a traditional BRD but as: - current processes detailed - processes to be detailed - a set of requirements detailed as user stories and prioritised as per level of internal and external compliance. The final signed off version details the must requirements. |
2 | Authorisation rules for who can - Manage an employee’s contract - Make and record offers against contracts. These would then be incorporated in the system build in the technical project scheduled for 15/16 | mandatory | yes Process to be and detailed as user stories |
3 | Authorisation for who can see an employee’s contracts and view/report on work against contracts. These would then be incorporated in the system build in the technical project scheduled for 15/16 | mandatory | yes Process to be and detailed as user stories |
4 | Ability to view/report on GH contracts within the university at an individual and wider level. Line managers, department, division, university level reporting to be easily accessible. | mandatory | Yes Detailed as user stories for reporting |
5 | 1.Ability to communicate to employees the details of the GH: the numbers of hours he/she is getting paid for, the hourly rate and annual leave payments. 2.The BRD will identify the information required to extract the GH data to be communicated to employees for processes including the automated generation of contracts to employees. | mandatory
| Yes 1.Detailed as user stories for payslip 2.Detailed as user stories for new GH staff and refresh |
6 | Ability for employee to view information on their own GH contracts. Display hours guaranteed/offered/hours worked/hours paid and balance of GH hours for the specified period. | Highly desirable | no requirements were deemed to be lower priorities |
7 | Ability to differentiate between a greater number of activities e.g. preparation, marking, staff development, than currently able to (with E-Time at least) to improve communication and monitoring. | Highly desirable | yes, detailed as user stories for timesheet |
The following deliverables were not described in the Brief but were delivered:
- short evaluation of the current use of the multiplier across the University (and the discrepancy of it) recorded as new scope
- assessement of the cost for annual planning of the follow up implementation project and business case for key processes
- additional paid leaves (paternity, maternity, sickness, jury duty, bereavement, parental leaves); there were no consistent current processes across schools and support groups. Effort was spent to help document the whole process, though the scope of the project was to focus on GH hours.
Not Delivered:
lower priority deliverable 6, as detailed above
Did the project deliver a solution to the problems being addressed? yes
1. mapping of current processes across the university
2. mapping of processes to be
3. prioritised user stories as per internal and external compliance
4. detailed conditions of satisfactions
Does the Project Sponsor agree that this project can be closed at this time?
Yes.
What are the benefits for the business?
-the business have all the processes detailed they can refer to.
- an awareness of existing variances: additional paid leaves, use of multipliers or the TAP (Temporary Additional Payments)
Cost/Delivery date Summary | ||||||||||
|
Analysis of Resource Usage:
Staff Usage Estimate: 35 days
Staff Usage Actual: 73 days
Staff Usage Variance: 109%
Other Resource Estimate: 0 days
Other Resource Actual: 0 days
Other Resource Variance: 0%
Explanation for variance:
Variance of budget
This has been managed by project issues as follows:
- issue 9: additional 20 days
An initial budget of 35d was set at planning. There were a few assumptions made at planning and there are reasons for increased efforts:
- at planning we were expecting a resource within HR to support the administration of the project, eg arranging devolved analysis sessions. Unfortunately that HR person left early on, and the BA/PM have been doing this admin work.
- we would work with 2 groups of users: we actually worked with 4 groups of users (Central HR, College HR, Devolved School groups, Devolved Support groups) with the numbers of users to be consulted increasing to nearly 40 users. The number of stakeholders being consulted increased , and differences between the way devolved groups are managing Guaranteed Hours emerged.
- we would have one meeting with each group to review the current process workflows: we actually required 2 sets of meetings for each of the 4 user groups.
- we would need 2 meetings with all user groups to cover the new requirements: some of the engagements with users have not been as good as expected and required additional 1:1 meetings and follow up meetings (issue 6). We needed additional meeting to clarify the other leaves workflow process (maternity, sickness, jury), as the detailed process did not exist prior to that project.
- we were planning 2 meetings with Senior Users to review the overall list of requirements and priority. We actually needed 3 meetings, and additional meetings to follow up with some Senior Users to resolve issues/agree terminology between separate groups/clarify some details. BA also needed more time to merge all requirements into one single document for presentation to Senior Users.
-Issue 13: additional 10 days (Aug 2015):
- Business requirements sign off: we initially planned 2 meetings in July to review the details of the prioritised requirements and seek sign off by emails. However, looking at some of the details has raised business issues which could not be solved at the sign off meeting. There are still other requirements to review. Due to lack of engagment from users at previous meetings, more meetings are required with all stakeholders for sign off.
Additionally paid leaves processes for sickness and maternity guaranteed hours contracts are new to the university and there is not a set process across the university. This has required more meetings with Business Lead to write the process to be. This now needs to be reviewed by the whole group. The approach is to sign off the business requirements at 3 separate meetings (Sept and Nov) with all user reps and senior stakeholders.
- Issue 15: additional 10 days following the consultation meeting with senior users/stakeholders:
- New scope: investigate multiplier and its inconsistent use across schools-Business case for timesheet
- Compile business case for key processes
- Prioritise as per compliance level
Variance of time
The above reasons will explain the revised milestones. The revised dates were captured by project issues:
- Delay in signing off the brief : issue 1 and issue 2
- Revised date for signing off current process issue 3
- Revised date for delivering requirements issue 7 and issue 12,
- Revised date for signing off requirements issue 16 and issue 17
As a summary, a combination of factors contributed to the delay of the completion and sign off of the requirements:
- Size of the user groups
- Additional times: size and complexity of the requirements
- Conflicting Views and open issues requiring separate senior stakeholders review meetings
- Some additional scope
- Key stakeholders' role and responsibilities not clear at outset. The effort and commitment from the business lead and senior school user was greater than expected.
- Working pattern of key stakeholder (i.e part time) reduces the availabilty for consultation with wider group.
Key Learning Points:
Approach taken for consulting users:
1.Users representatives were split over 4 groups as per business responsibilities and roles: UHRS, Devolved HR, School Business Group, Support Business Group
2. The first consultation objective was to establish the current processes. This enabled to bring all user reps from each group around the table to document the current processes. It highlighted differences between each groups, and little or no awareness of the other groups, which were able to be discussed. It also highlighted missing current processes for paid leave types (Maternity, Adoption, Paternity, Sickness, Bereavement and Jury Duty) for GH employees as there was inconsistent embedded processes in place.
3.Once the current processes were established, users reps were able to identify the processes/gaps/issues that were missing, document them as user stories and discuss. A first attempt to prioritise them was carried out.
4. User stories were written by user represenatives of each group for each process areas. They were written in plain English emphasing on the role of the user, what it will do and why it was required (i.e. as a School or SG Admin/DOP/HR Admin I want to access details of GH staff added to the system plus their Staff No on a real time basis so that I can process new GH staff and ensure the individual does not exceed their UKVI working restrictions) . They were then collated into a spreadsheet so that they could be fedback to the groups. This allowed us to combine the requirements from 4 groups into a single set of requirements.
5. The user stories were enhanced with the conditions of satisfaction which define what must be true for that user story to be set to completed, this is important for clarifying the steps/validations, which will then be picked up during the next implementation project. Capturing the requirements in an agile spreadsheet format is not always easy to read and interpret. However volumes of requirements and the amount of change involved was easier to track in spreadsheet format.
6. The user stories were further prioritised by stakeholders/senior users representing the 4 groups over several meetings as per their level of compliance (external and internal), and the existence of workarounds. They were finally reviewed and signed off by seniuor stakeholders.
What went well?
- To-be processes have been mapped out for some of the inconsistent paid leaves: Maternity and Adoption and for Sickness, Bereavement and Jury Duty. These have been reviewed by the senior user group and requirements captured.
-The scope and the prioritised requirements were used as part of the IS planning process to estimate the technical implementation, and make a business case for additional funding.
- Managing several user groups, several processes/requirements and achieving one set of prioritised requirements.
What didn’t go so well?
- See the issues already raised above under the explanantion for time and budget variances
- User engagement was difficult at times. The aim of the project was to relate to business requirements without referring to current systems solutions. Some users expected they would have been shown alternatives to current systems and processes. However the project aim was to focus on capturing the business requirements.
- Some of the issues raised could not find a solution straight away. Conflicting views emerged across user groups. They required additional meetings and more senior stakeholders involvement than what was expected.
- The senior school user group was not comfortable with her workload and with a lack of representation from the other colleges. As a result, 2 additional users from other 2 colleges were brought in to review some user stories.
If you had a project like this again, what would you improve?
- On the consultation with schools and support group user reps: could we have picked up a smaller group? There would have been a risk that a smaller group would not be able to provide cover for all areas and find out about all the process variations.A suggestion would have been to assign the senior user rep at an earlier stage for them to keep checking back with the sub group that they were representing. Issue with this would have been someone to fill in that role. It appeared from early stage that schools/support groups work independently with little awareness of how their processes compared.
- Have a senior user from each college and support group from the start of the consultation. For them to take a role about finding missing information and confirming understanding/interpret the emerging user stories.
- Allow more time to assess and structure the information gathered following the requirement sessions, while reducing time spent on requirements that are low priority.
- Prioritise requirements earlier so that the user group focuses their energy and time on the mandatory ones only.
- Opportunity to see the systems (local spreadsheets, etime) would have been helpful, that was discussed but it was thought not necessary.
- Discuss roles and responsibilities of business lead and senior stakeholder from outset, and the required effort expected. It would have been beneficial to have more than one business lead to represent the 4 groups and split the roles and responsibilities accordingly.
Outstanding issues:
No outstanding issues