Closure Report

 

Project Summary

This project sought to develop a bulk way to create computing accounts for visitors and to assign services to those accounts. As noted in the brief there were risks considered about the achievability of this within a reasonable budget.

The project initially had the brief drafted, articulating that the computing accounts would be achieved through a bulk mechanism with the current VRS system. The Head of Service Management requested that this explicit design route be removed and that the actual goal - computing accounts - should be the stated scope of the brief. (See change control 1)

During the development and approval of the brief, and in the initial weeks post Brief approval, some business analysis and initial systems analysis options were discussed but it became apparent that the different options would require investment of a level - circa 150 days - that could not be justified at this time with the priorities resulting from Covid-19.

The decision has therefore been taken by the project sponsor to withdraw the project.

Scope as defined in the Brief:

  • The ability to bulk create visitors' computing accounts, assign services to those accounts and to issue credentials are all in scope. This project's scope is to be delivered in as simple a solution as possible and in as short a timescale as resources permit. Therefore the analysis and design will look at the most basic solution that sufficiently satisfies the scope.

The scope was kept to in the initial analysis completed.

 

Objectives And Deliverables as defined in the Brief:

No Description Priority Achieved?
O1 Ability to bulk create Visitors' computing accounts MUST No
O1D1 Analysis to identify range of use cases for Bulk creation MUST Partial analysis completed
O1D2 System analysis and design of bulk creation mechanism MUST Initial options analysis completed
O1D3 Build, testing and delivery of ability to bulk create Visitors' computing accounts MUST No
O2 Perform analysis for requested accounts  MUST No
O2D1 Mechanism to check if repeat visitor MUST No
O2D2 Mechanism to check if overlapping or duplicate visit MUST No
O2D3 Mechanism to check if already identity with University, eg CESAR account for COL students and to assign this as the identity SHOULD No
O2D4 Process for managing exceptions when creating bulk accounts (eg emailing requester to advise of repeat visitor) MUST No
O3 Ability to bulk assign services to be provided to Visitors' computing accounts MUST No
O3D1 Mechanism to define what services the account is to be assigned on creation MUST No
O3D2 Guidance to be communicated to those needing to bulk create accounts on what services can be assigned (updating current guidance to reflect bulk creation) MUST No
O4 Process for issuing credentials MUST No
O4D1 Process to be defined for requester to know when account and services are available (eg in format that enables mail merge) MUST No
O4D2 Process to be defined to inform visitor when account and services are available (eg automated mail merge) MUST No
O5 Ensure that process for ending visit and deprovisioning services is fully in place MUST No
O5D1 Process to be defined to ensure that visitor's services are deprovisioned at the end of the visit (this should already exist but need to ensure bulk creation doesn't interfere with deprovisioning processes) MUST No

As noted above only initial analysis was completed before the decision to withdraw was taken.

 

Benefits as defined in the Brief:

Benefit Owner Realisation timescale Achieved?
Reduction of risk of error by removing manual effort School creating accounts Immediate on delivery No
Reduction in time needed to create accounts School creating accounts Immediate on delivery No
Quicker access to services - staff effective earlier School creating accounts Immediate on delivery No
Improved visitor experience by having access to services from day one VRS account holder Immediate on delivery No

The project did not deliver so therefore the stated benefits were not achieved. However, the analysis completed did provide valuable insight into the level of work and risk that would be involved for any future development. It has also raised the possibility of using Robotic Process Automation (RPA) in future work.

 

Success Criteria as defined in the Brief:

  • Schools/Colleges can bulk create Visitors' computing accounts
  • Bulk process assigns services to Visitors' computing accounts

The project's success criteria were not achieved due to the decision to withdraw shortly after completion of the Brief.

 

 

Analysis of Resource Usage:

Staff Usage Estimate: 20 days

Staff Usage Actual: 19.5 days

 

Explanation for Variance

Although there does not appear to be any meaningful variance from the proposal estimate of 20 days and actual effort of 19.5 days, it is worth noting that at Brief stage, the project's budget was increased from 20 days to 40 days (see change control 3) and this was only to cover to the end of the Business and Systems Analysis and Design work. There would have been a further ~150 days required to implement a solution.

Outcome

Initial systems analysis and associated estimated implementation costs led to the decision to withdraw the project.

Key Learning Points

Ref Date Title Impact Theme Stage
1 20-May-2020 VRS related development is expensive and high risk and should therefore be avoided Should implement as good practice Architecture Analyse

Outstanding Issues

None

 

Project Info

Project
Visitor Registration System (VRS) bulk upload and creation
Code
HSS034
Programme
CAHSS Portfolio Projects
Management Office
ISG PMO
Project Manager
Susan Ridder-Patrick
Project Sponsor
Fraser Muir
Current Stage
Close
Status
Withdrawn
Project Classification
Grow
Start Date
07-Feb-2020
Planning Date
24-Apr-2020
Delivery Date
09-Oct-2020
Close Date
29-May-2020
Overall Priority
Normal
Category
Discretionary

Documentation

Close