Closure Report
Project Summary
The key objective of this project was to create two new GDPR request type categories within Request Handling Monitor of the FOI database.
The project was initiated in order to upgrade the existing Freedom of Information database with the necessary GDPR categories that would allow the Records Management Team to respond to subject access requests (GDPR SAR) for personal information and GDPR Right to correct/erase/object/restrict data that is held by the University of Edinburgh holds, pertaining to them.
Background
This project addressed the need to implement changes to the Freedom of Information(FOI) Publication Scheme Database to ensure compliance of GDPR. The element of change pertains to the Request Handling Monitor functionality in relation to how this information is requested, logged, monitored and managed.
In order to accommodate GDPR Subject (subject can be described as anyone, either internal to the organisation, a previous student or anyone who believes that Edinburgh University have any personal information about them) Access Requests, and GDPR Right to request/correct/erase/object/restrict data requests, the changes involved the creation of two new request types and the redundancy of two existing request types within the Request Handling Monitor.
This project was initiated to upgrade the FOI database to accommodate the GDPR legislation.
Scope
The scope of this project was to:
- Introduction of two request type categories for GDPR by 25th May 2018
- Facility to maintain existing categories and new categories for a two week period during 'cutover' to accommodate 'delayed' requests, until 8th June
- Redundancy of two of the existing request type categories 8th June 2018
- 'Search request ONLY 'functionality for the two categories that GDPR will replace, for historical and auditory purposes
- Some guidance to Record Management team in support of their UAT for each deliverable.
Objectives, Deliverables
No | Description |
Priority (MoSCoW |
Complete |
---|---|---|---|
O1 | To ensure compliance of GDPR Subject Access Requests and 'GDPR right to correct/erase/object/restrict data, within Freedom of Information(FOI) Publication Scheme Database, for the Records management team by 25th May2018. | Must | |
O1D1 | Add New GDPR Subject access requests type Option, within Freedom of Information(FOI) Publication Scheme Database, allowing for calendar days and working days. | Must | YES |
O1D2 | Add NEW GDPR functionality request type - GDPR right to correct/erase/object/restrict data, within Freedom of Information(FOI) Publication Scheme Database. | Must | YES |
O1D3 | To provide the administrative option to control whether the period is calendar or working days. | ||
O1D4 | Support Records management team with UAT that will incorporate the new functionality and phases. | Must | YES |
O2 | To ensure pre-GDPR categories can be searched and reported on enable for redundant requests in support of management Reporting and auditory purposes. | Must | |
O2D1 |
To Provide facility to search and report facility on non GDPR categories. |
Must | YES |
ADDITIONAL DELIVERABLES - investigations in case existing reports did not work with new categories: not required in the end |
|||
Set up new categories on the BI | Must | N/A | |
Set up new calculations for the new categories | Must | N/A |
Outcome
The changes to the Freedom of Information Database went LIVE on 26th April, without issues.
Benefits
The planned benefits from this project were all achieved:
- Compliance with the General Data Protection Regulation (GDPR) (Regulation (EU) 2016/679) wrt to recording of new request types
- Edinburgh University remaining as a GDPR compliant organisation.
- The Records management team able to demonstrate compliance to the requesting subjects and regulator bodies.
Additional Benefits
- Project team and business testers successful use of Testrail in a project environment, enabling this technology to be used for further projects
- Business Analyst gained considerable insight into work of the records management tea, which is knowledge already proving useful for new projects ( eg STU263)
Success Criteria
The planned success criteria for this project were all achieved,
- The Records management team can respond to the subject's GDPR requests.
- Add New GDPR Subject access requests within Freedom of Information(FOI) Publication Scheme Database, for the Records management team, with option for Business to select option for response times in calendar days or working days.
- All categories can be selected as active or inactive, are searchable and can be reported by the Records management Team.
Analysis of Resource Usage:
Staff Usage Estimate: 30 days Additional days approved by STU programme and WIS, increased to 59 days
Staff Usage Actual: 50 days
Staff Usage Variance: 67%
Explanation for variance
- The original project plan approved at the planning stage anticipated for the project to be closed by the 18th May 2018 however due to an increase within project scope to cover reporting, and delays due to the need to clarify of the GDPR calculation (that had to be redressed with the ICO), the budget was increased to 59 days.
-
During planning it was not clear how the request-type target date would be calculated. The business was not in a position to confirm how the target date ought to be calculated as this required guidance from an external party (Information Commissioner's Office) .
-
In order to ensure that a solution was available by 25th May, the approach agreed was to provide an additional ‘calendar days’ option in addition to the ‘working days’ option that already existed in the system. The project team and business accepted the risk that the project might carry out development which would not ultimately be required. However when firm guidance was eventually provided to the business, it was that the target date was to be based on ‘calendar month’ rather than 'calendar days. At that point the relevant sections of the BRD were updated and the design adjusted to reflect this.
-
The business considered that the project team did not understand that they were not in a position to confirm the target-date requirement: however from the planning stage the project team attempted to ensure delivery by 25th May by ensuring that more than one means of calculating the target date could be selected by the business after delivery. This is because the business was unable to say when the target-date requirement would be confirmed and the project team considered it was too risky to wait until the target-date requirement was confirmed, in case this was not delivered until too late or when resources were not available.
-
Delays due to Industrial Strike action increased project costs
- The project team and the business testers were all new to Testrail therefore additional effort was required to understand how to use this for testing.
- As the Records Management Section is a small team, the project team carried out more testing in-house than had been anticipated.
- The project manager noted that the Business Analyst took a crucial leadership role in gathering requirements and in planning and directing testing.
- The BI reporting element changes were not as significant as had been anticipated, so fewer days were required than had been estimated in the change of scope
- 17 days days were subsequently returned to STU Programme.
Key Learning Points
- Great communications between the Records Management Section, the development resource and business analyst proved to be successful in the upgrade to the FOI database.
- Early planning of UAT and scripting with the Records Management resource and BA, allowing the Records Management Section to understand their role and the tools such as JIRA and Testrail in signing-off the UAT
- The project team found that Testrail was a useful tool in monitoring testing progress.
- The Business also found that Testrail was easy to use and noted that the Business Analyst planned and managed the testing process very well.
- Where an existing spreadsheet of tests exists, it would likely save effort to upload this into testrail - a template for uploading into Testrail would be useful.
- RISK management ensured control throughout the Project.
- The JIRA board was not set up in time for this integration testing, therefore it was not used to record any of the bugs identified in integration testing.
- The partnership between a project manager new to IS and a very experienced Business Analyst worked very well, as the BA was able to provide a great deal of support and information ot the PM.
Outstanding Issues
None