Closure Report
Project Summary
The University has been issued with an Improvement Notice (currently appealed and suspended) by the Health & Safety Executive (HSE) with regards to our safety management system in the University including the retention of particular types of staff/student records under the Control of Substances Hazardous to Health Regulations (COSHH). These regulations require the University to be able to demonstrate compliance with COSHH health records requirements in order to protect staff/student health. The University does currently comply with these regulations, but this is difficult to effectively demonstrate, as the data is stored in a variety of different sources at central and local School level and in different formats. This means that collating a full COSHH health record for an individual requires the manual extraction of data from systems such as the Occupational Health Unit's OPAS record management system, corporate Health and Safety Department's Face-fit Testing database, and various other data sources, such as School records.
Access to certain labs & animal facilities requires health surveillance to be conducted prior to admittance. Lab Managers are currently unable to easily check these records. There is therefore a risk of allowing admittance to people who may not have received all of the required health checks, or had suitable assessment and training for respiratory protective equipment, and who may therefore be at increased risk of experiencing health issues in the future.
This project sought to develop a mechanism to collate existing data, from various University sources, to provide a consolidated Health Record for those members of the University community who may encounter hazardous substances that are subject to health surveillance, particularly laboratory animal allergens.
The resulting database will enable the University to provide, in an efficient manner, the data required by the Health & Safety Executive's Control of Substances Hazardous to Health Regulations (COSHH), and the Home Office's Personal Licence (PIL) requirements.
The project will also deliver an application that will support multi-user access within the University, to maintain the database. The application will also include restricted-view reports, and possibly notifications, to authorised personnel (e.g. Lab Managers), to help them ensure that only approved people can access their facilities.
Utilising the agile iterative feedback and incremental delivery cycles the project at the request and fully funded by the Sponsor was increased from its original deliverables and scope, this is recorded in the report below.
Objectives & Deliverables
Priority – M = Must Have; S = Should Have; C = Could Have; W = Won't Have
- M = has to be satisfied for the final solution to be acceptable in terms of delivery dates, compliance, viability etc.
- S = high-priority requirement that should be included if possible -workarounds may be available
- C = a nice-to-have requirement
- W = will not be part of this project
O = Objective D = Deliverable AD = Additional Deliverable as a result of Project Sponsor funded scope increase
| Ref. | Objectives & Deliverables | Priority | Achieved? |
| O1 |
To develop a mechanism to collate the data from the various University sources, in order to provide a COSHH-compliant health record for affected personnel. The delivered mechanism must: - satisfy the Health & Safety Executive's Control of Substances Hazardous to Health Regulations (COSHH) requirements - satisfy the Home Office's Personal Licence (PIL) requirements, for handling animals - be suitable for multi user access within the University |
||
| D1 |
A database that will include all data fields that are required to meet the legislative reporting requirements for COSHH and PIL. The database must include:
|
|
|
| D2 | A means of transferring data from the current diverse data repositories, into the new database |
|
|
| O2 |
To provide a restricted view of the collated data to authorised personnel (e.g. Lab Managers), so that they can ensure that only approved people can access their facilities. - e.g. a facility manager's dashboard, to include a list of people whose record has significantly changed (timeframe tbc) |
||
| D3 |
An application, via which users throughout the university will be able to maintain the data in the database. The application must be:
|
|
|
| AD1 | Create a fully electronic facility application / approval process for both Staff & Students that is fully audited |
|
|
| O3 | To reduce the need for individual schools to maintain separate databases of similar information | ||
| D4 | A range of reports, against the new database, that will meet the legislative reporting requirements. The preferred delivery method for these reports is from within the application |
|
|
| O4 | To maintain a single record for each identified individual, as s/he moves around the University | ||
| D5 | A means by which authorised personnel may view, or report against, a restricted view of the database. The preferred delivery method for these reports is from within the application |
|
|
| D6 | A means by which the application may alert facilities managers to significant changes in users' status |
|
|
Scope
| No. | Description | Project stayed within scope? (Yes/No); Reason if not. |
|---|---|---|
| 1 | The project will consolidate all relevant data, from the currently dispersed data sources, into a single data repository. This repository will be able to provide a COSHH-compliant and PIL-compliant health record for affected personnel. | Yes |
| 2 |
The project will provide an application that will be used to maintain the data via the use of dashboards. |
Yes |
| 3 |
The application will provide a number of reports, which will be downloadable in the form of lists and/or csvs. The reports will run from a search facility, with specific selection criteria. Commonly-used reports are expected to include full details for individual users, and a list of users who have incomplete checks and should therefore be denied access to a specific facility. |
Yes |
| 4 |
The application will be EASE-enabled. In addition, authorisation to specific areas of the application's functionality will be controlled for specific groups and/or roles. |
Yes |
The following scope items were added to the project after iterative feedback during the life cycle of this agile project and at the request and fully funded by the Sponsor:
| No. | Description | Project stayed within scope? (Yes/No); Reason if not. |
|---|---|---|
| 1 |
The Project Sponsor provided additional budget to improve the User interface, dashboards and notifications based on feedback after an initial pilot. |
Yes |
| 2 |
Create a fully electronic facility application / approval process for both Staff & Students that is fully audited |
Yes |
Out of scope:
-
BI reporting
- Decommissioning of any software this project may replace (although this will be reviewed at the end of the analysis stage)
Benefits
| No. | Description | Achieved? |
| 1 | Improved sharing of information across the organisation | Yes |
| 2 | Improved access to real-time information, for the managers of animal and other relevant facilities. This will enable them to manage access to their facilities in a more timely manner, achieved via RAG dashboards | Yes |
| 3 | Better management of information about staff & students who may encounter hazardous substances subject to health surveillance, particularly laboratory animal allergens | Yes |
| 4 | Provision of a personal health record for staff & students, who would then be able to take that record to subsequent employers, covering an individuals complete life cycle at the University | Yes |
| 5 | More efficient means of complying with COSHH Regulations. Less time-consuming for staff involved, paper work removed via the application / approval process | Yes |
| 6 | The risk of Enforcement action from the Health and Safety Executive, such as Improvement Notices, minimised and hence reduction of risk of prosecution | Yes |
| 7 | Full electronic application / approval process for the managed facilities now in place, allowing simple RAG dashboard views of staff / student health statuses | Yes |
Success Criteria
| No. | Description | Achieved? |
| 1 | The data from the currently diverse University sources has been collated into a single point of access | Yes |
| 2 | Appropriately authorised colleagues within Health & Safety can maintain the data via an application | Yes |
| 3 | Appropriately authorised colleagues across the University have restricted access to the collated data, and can run and download selected reports | Yes |
| 4 | Appropriately authorised Facilities Managers are notified of significant changes to users' status, to enable them to quickly adjust users' access to their facilities | Yes |
| 5 | A COSHH-compliant health record for affected personnel can be quickly generated | Yes |
| 6 | A PIL-compliant health record for affected personnel can be quickly generated | N/A. It was deemed by HAS and the Project Sponsor that this was no longer applicable for COSHH |
| 7 | A personal health record can be quickly generated, on request, for individual staff & students | Yes |
Schedule
Analysis of Resource Usage:
Staff Usage Estimate: 280 days
Staff Usage Actual: 279 days
Staff Usage Variance: 0%
Explanation of the increase to budget over the life cycle of the project:
Two PICCL were raised during the life cycle of this project at the request of the Project Sponsor in order to deliver additional development works to cover some of the should have stories.
Monday 14th August 2017 -
Original Budget = 200 days
Revised Budget = 240 days
Additional Budget Requested = 40 days
The additional estimation of 40 days was to complete 2 additional sprints, at 18 days each, as well as 4 extra days planning / preparation and management activities
Wednesday 27th September 2017 -
Agreed Budget = 240 days
Revised Agreed Budget = 280 days
Additional Budget Requested = 40 days
The additional estimation of 40 days was to complete 2 additional sprints, at 20 days each, that has been agreed with and was funded by the Project Sponsor
Explanation for variance:
N/A
Key Learning Points:
Agile - Utilising the agile iterative feedback and incremental delivery cycles worked extremely well for the project and all Team Members, including the Business fully bought into it. Through its use the COSHH system was successfully developed, adapted and made suitable for purpose, to the extent that the Project Sponsor (HAS) were willing / had the confidence to fund an additional 80 days towards the Project. Agile also allowed the project to adapt despite a number of challenges, notably the conflict for the lead developers time with another project, reported under ISSUE #3.
Communication - The Project ran well by getting all of the basics correct. The use of the tool sets available, such as HipChat between the technical Team members, JIRA and regular Project meetings, allowed for good open communication channels which at no point saw the project stall once it was up and running. This led to great Team work throughout and it is commended the amount that the Business in particular undertook testing and provided swift feedback to any questions posed in a prompt and thorough manner.
Resourcing - If a person is signed off long term sick then the Project and Programme Teams should review the issue immediately and consider the options either to delay or find an alternative resource. The plan should be agreed with the Team, including Resource Managers, and implemented. If required the plan should include check points to ensure that the decision remains the best approach, i.e. in the case of a decision to delay the project.
Testing - Testing of features related to user roles and authorisation was very difficult (for example obtaining a student id, logging in with that via test-EASE and verifying what that user can and cannot do in the app). There are many barriers to doing these sorts of tests, from the authentication used in pre-production systems, to the identity sources used to obtain user attributes and the way we interact with them in pre-production systems, to the very identity data that they contain and our ability to both modify that data to generate scenarios and provide an assurance of consistency required for repeatability of test scenarios. These difficulties meant that it was near-impossible to automate tests and, as a result, regression test coverage for this application is uncomfortably low. Ii is felt that the most significant barrier is EASE authentication - the other challenges are resolvable via techniques such as mocking interfaces, if one takes a more flexible approach to authentication in pre-production environments. It must be noted though that using the 'generic test accounts' is difficult as when you are logged in as one it is hard to distinguish within the application which one you are logged in as. A Post Project Action was agreed that the Development Team were to discuss options/ways forward for how to more readily do testing that needs someone of certain categories, statuses, classes, etc, with a particular focus on how that kind of testing can be done in an automated, repeatable non-brittle way.
Samba - Scheduling times for server restarts need to be appropriately determined when using file storage
Adoption of New Technology - By adopting the new technologies Python, Django and GIT, despite the initial learning curve that the Technical Team members were required to make, in the long term reaped benefits, in the case of this project, as coding became more efficient / rationalised and deployment became easier to manage.
JIRA - Use of consistent, agreed, naming conventions set up right at the start of the project would have made things clearer in the long term. Also related to resourcing a change to (loss of) the Business Analyst early in the project also saw the creation of multiple User Stories in JIRA that effectively were either duplicate, or very similar. This would have been lessened had that expertise been retained between the requirements gathering and the quality control phases.
Outstanding issues:
There are no outstanding issues in terms of Must Have stories. All Must Have User stories were delivered within the agreed / revised boundaries of this Project, which successfully employed the Agile methodology in order to meet the Customers prime objectives. For reference there are 11 Should Have, 6 Could Have and 5 Wont Have User Stories remaining, but it was agreed that these would not be developed / delivered and they were captured during the Agile Process and it was agreed that these be left for future consideration should any further works be considered against the application. These JIRA are listed below for reference only:
| HAS001-168 | As Health and Safety I need a dashboard picker added to my dashboard | Should Have |
| HAS001-201 | Multiple User Allocation on Upload of Generic Documents | Should Have |
| HAS001-59 | Accident reference number | Should Have |
| HAS001-60 | Occupational Hygiene Report Reference Number | Should Have |
| HAS001-56 | Risk Assessment reference numbers | Should Have |
| HAS001-204 | Facility Managers for any facility can see checklists for all facilities | Should Have |
| HAS001-98 | Filter on records | Should Have |
| HAS001-34 | Access to relevant risk assessments | Should Have |
| HAS001-91 | Record role-specific training | Should Have |
| HAS001-37 | Interface with Occ Health system | Should Have |
| HAS001-196 | As an PI I need to bulk set User's Statuses to Suspended / Un-suspended | Should Have |
| HAS001-147 | change the wording when a search is forbidden | Could Have |
| HAS001-121 | Automatically Scrape Data from the Fit Note into COSHH as the Health Surveillance Data Entry role | Could Have |
| HAS001-70 | Irradiator authorisation | Could Have |
| HAS001-96 | Interface with Card Access systems | Could Have |
| HAS001-93 | Interface with PIL licence admin DB | Could Have |
| HAS001-197 | Create an Application Process Rejection History | Could Have |
| HAS001-107 | As a Health & Safety Admin I need an audit trail for viewing data updates/amendments | Wont Have |
| HAS001-77 | Accident / Incident detail | Wont Have |
| HAS001-74 | Record and access Risk Assessment Reference Number | Wont Have |
| HAS001-64 | Exposure Type | Wont Have |
| HAS001-55 | Frequency of exposure for an individual | Wont Have |