To undertake all development changes required to meet the requirement changes specified by HESA.
Please see HESA requirements.
Provide supporting changes to HR database, application, and extracts
Provide supporting changes to HESA and HESA Archive database, application, extracts, and BOXI universes
Provide supporting changes in eRecruitment database, application, extract, and BOXI universe
Provide supporting changes in PPIPMI database and BOXI universe
To support the submission of the 2012/13 HESA return.
Update HESA extract facility for required final return functionality
Update the submission method:
change the Staff flat file structure to use XML
change the Contract flat file structure to use XML
remove the Grade file
Accepted HESA return for 2012/13 period
Analysis of Resource Usage:
Staff Usage Estimate: 263 days
Staff Usage Actual: 278 days
Staff Usage Variance: 6%
Other Resource Estimate: 0 days
Other Resource Actual: 0 days
Other Resource Variance: 0%
Explanation for variance:
The project budget increased due to;
- 6 days were alloacted to the project to cover additional scope to provide HESA IDs for REF'able staff that are employed outwith the HESA year.
- 9 days were required to cover additional work required to support HR and to make further changes post 1st August to meet the HESA requirements.
Key Learning Points:
- The IS Applications Business Analyst rather than the HR Business Lead reviewed the HESA requiremenst and drafted the Business Requirements documentation. Consequently, much of the business requirements document was compiled from the HESA website, and a key business requirement for ECA colleagues was not identified until the day of the UAT sign-off review meeting. Post 1st August further mismatching between the HESA requirements and the project requirements or design were identified. It is not clear if these were missed requirements from the initial review of the HESA documentation or if HESA changed their requirements without updating the audit information. It is suggested that;
- Roles and Responsibilities must be discussed with the projec team at the earliest opportunity to agree who will draft, review or approve key project documentation or deliverables. Input from the key parties needs to be included and agreed in the project plan.
- For future HESA projects, it is recommended that the business area assess the HESA guidelines, and then work with the business analyst to specify the requirements. This would add crucial business area knowledge to the business analysis.
- The full or a sample data set is obtained as early as possible in the project, and before 1st August if possible, to run this set through the HESA validation kit. This would highlight any mismatch between the data outputs and the HESA requirements either indicating a need to update the data or the underlying code at an early date.
- The final week of UAT testing should be reserved for re-testing addressed feedback from earlier in the UAT stage. However, new issues were still being raised on the day of the UAT sign-off review meeting. Consequently, the stage milestone could not be met, and the deployment to Live had to be rescheduled for a later date.
- For future projects, it is recommended that the UAT testing stage be split into two discreet segments. The initial UAT testing should have its own milestone, to be agreed with and met by the business area testers. A second, UAT re-testing stage should be scheduled to follow the UAT testing milestone, and should not include any new testing.
- HESA projects are so reliant on accurate data that consideration of the value of testing on TEST needs to be considered. Either the TEST and DEV environments need to be refreshed from LIVE just before UAT or the code is quickly progressed to LIVE and testing undertaken with the LIVE data. The later may need further consideration of how this can be accommodated as the LIVE archive can currenty only be run after 1st June of that HESA year.
- Multiple issues were identified after 1st August as this was the first time the LIVE extract had been run through the validation kit. The full business process needs to be clearly understood so the risks involved in this can be understood. In this case, if it was fully known that there would be no testing of the data outputs before 1st August then additional resource would be have carried over to 13/14 with appropriate bookings in place to ensure to mitigate this risk.
- The project plan should take account of all project activities not just the technical tasks.
- Consideration should be made as to how development and testing for HESA type projects should be progressed as the waterfall approach does not fit these types of projects.
- A full risk assessment should be undertaken to review all aspects of the plan to identify any risks and agree appropriate mitigation.
- Risk should be reviewed, as a minimum, at stage sign off meetings.
- The data collection and input of the required additional HESA data was undertaken out with the project. This in itself was not an issue but as the required ACTSOC data was not input in to the Oracle system until late in the project this reduced the projects ability to test and review this essential data. In this case the ACTSOC data was key to the correct allocation of many other data fields so these aspects of the code were not fully tested till after 1st August.
- The plan for any data collection essential for project delivery should be agreed as part of the project and the interdependencies understood.
- The risks of any delays to this plan or the impact of not having the data input in to Oracle by an agreed date understood, this would have allowed for a discussion over alternatives for testing purposes, e.g. input of a subset or dummy data to Oracle DEV or TEST ahead of the business input dates.
- HESA requirements may change and these will not always be highlighted on the HESA website or vie email from HESA. A sample of 100 records was used for IS Apps testing purposes but this was since identified as not truely representative of the final data set. This importance of quality data represenative of the final live data must be understood for all HESA projects.
- A sample XML or suitably representative subset of the full data could be generated from TEST or LIVE to run through the validation kit regularly through the project and before 1st August. If carefully constructed this would have allowed for many of the schema or business rules errors that were not identified until September to be dealt with before the crucial deadline approached.
- Changes that were applied direct to the data (as it was not possible to rerun the extract without impacted HR manual updates) have been retrospectively updated in the extract code on DEV. At the deployment sign off meeting it was discussed whether this should be applied to TEST and LIVE but agreed that, although there was low risk, the changes should only be applied to DEV and TEST so that these are not lost or forgotten before changes are made for 13/14. The code is to be checked in to SVN and the Annual Maintenance project will take the action to reapply these changes to DEV and TEST following the LIVE clones.
The following items were either manually resolved, coded in to the XML or the data updated in the HESA tables for 12/13. These will need to be reviewed, and if required, the code updated for the 13/14 submission;
APEX - There is a change required on the APEX system created this year for HESA. The issue encountered resulted in a person being both typical and atypical in the same year resulting in the same assignment qualifying for inclusion in the hesa return under two different categories in the same year. This should be reviewed to confirm if this situation needs to be coded or can be manually handled.
LOCLEAVE - this was not collected for casual staff for 12/13 but there is a requirement to return this feild. If this data is not to be collected then the business rule for how this should be returned need to be agreed.
- Current Academic Discipline not updating for all records (see JIRA https://www.jira.is.ed.ac.uk/jira/browse/HRS071-125)
- The following fields resulted in errors and the data was updated directly in the HESA code. The business rules as to how the data is to be manipulated to meet HESA requirements needs to be defined for;