Closure Report
Project Summary
Scope
This project will deliver updates to existing process documentation to meet current and future requirements for standalone API development and manage delivery of small APIs and improvements to existing APIs. Requests for small APIs and improvements to existing APIs will be approved and prioritised by a combination of service work, the Programme Steering Group and the DTI013 project.
The project team will offer guidance on decommissioning of APIs.
Out of Scope
Delivery of larger APIs - these will be delivered by projects dedicated to the specific APIs. Decommissioning of APIs is outwith the scope of the project.
Objectives & Deliverables
No. | Description | Prioirty | Achived (yes / no) |
---|---|---|---|
O1 | Review and optimise documentation set | ||
D1 | Deliver reduced deployment checklist template - D1 Checklist Template | Must have | Yes |
D2 | Deliver reduced system description document template - D2 System Description document | Must have | Yes |
D3 | Delivery Updated TAD template | Must have | No (Descoped) Note 1 below |
D4 | Deliver Updated RACI matrix and roles and responsibilities - D4 - RACI matrix | Must have | Yes |
O2 | Manage delivery of small APIs and improvements to existing APIs | ||
D5 | Deliver blueprints for technical platform | Must have | Yes |
D6 | Release 1 - delivery of small API improvement | Must have | No |
D7 | Release 2 - delivery of small API improvement | Must have | No |
D8 |
Release 3 - delivery of small API improvement |
Must have |
No |
UniDesk API |
Should have | Yes | |
PURE Id Resolver API | Should have | Yes | |
EDW Person Resolver ID API | Should have | Partial |
Note 1 - Deliverable D3 descoped from project. This was agreed at a meeting on 23/8/17, see DTI018 Issue 6.
Analysis of Resource Usage:
Staff Usage Estimate: 330 days
Staff Usage Actual: 390 days
Other Resource Variance: 119%
Outcome
Good progress was made during the initial phase of the project, particularly with regards the documentation which was delivered as scheduled by the project.
In contrast due to a combination of the following reasons progress with regards API development was disappointing:
- Support infrastructure and service was not in place.
- Resource conflict with SEP and UCP
- Loss of Business Analyst for user stories
- Focus on infrastructure – and subsequent change of technology as agreed by the board
It was decided to suspend the project for a number of months. When the project was un-suspended the majority of the infrastructure was still in development and the Target Operating Model for the future development and management was still being defined. Again momentum with regards the creation of APIs was lost. A new Programme Manager brought a change of focus to review the programme holistically and make assessments on the audience and purpose. In response the steering group revised the scope and reprioritised the APIs to be delivered, concentrating efforts on the UniDesk API, the PURE Id resolver API and the EDW Person Resolver ID API. Of these the UniDesk API and PURE APIs were successfully delivered.
Benefits
This project will support the Service Excellence Programme and other digitalisation and transformation Programmes across the University. The APIs delivered by the project have been made available to the user community via WSO2. Realisation of the benefits provided by these will only be achieved by the incorporation of the API's into business as usual processes.
The benefit provided by the revised documentation will be integral to the API service which was delivered as part of project DTI029 - Maturing the API Service. The realisation of the benefits will only be achieved once the API service has becomes live and the service becomes integrated within the IS development and enhancement environment.
Explanation for Variance
There were a number of issues that added to the overall project variance:
- As reported in the Outcome section there were a number of issues which hindered the development of APIs. This led to the project having a stop start nature.
- We were learning and re-learning on the job due to a lack of resource continuity.
- The change in Project Manager and loss of Programme Manager exacerbated this loss of momentum and lack of continuity across the API development thread.
Key Learning Points
It is possible that the development element of the project started too early and should have been raised as a separate project to be commenced once the support infrastructure was in place. This would have greatly reduced the amount of time spent discussing and prioritising APIs without the environment available to host them. Resulting in a shorter more focused project which by successfully developing a number of APIs would have provided an initial development model for the API service.
Considerable knowledge has been gained regarding the development, testing and signing off of individual APIs. Utilising this knowledge in the API service will provide an ongoing benefit from the project.
Lack of understanding regarding customer expectation management led to conflict and rework as the customer expectations were not met. Individual scope or requirement documents should be considered when developing stand alone APIs in the future so that expectations can be agreed and achieved.
Outstanding Issues
The UniDesk API was to provide an API for use by all institutions using the UniDesk service. Although the UniDesk API has recently been signed off in has not been tested externally and has not been made available to external institutions. The UniDesk product will be upgraded between now and the end of the year with the upgraded version being rolled out to the various institutions on an individual basis over the next few months. It is thought that the upgrade includes functionality similar to the developed API. This is under investigation and if it is confirmed there would be no requirement to provide an external API service. Should this not be the case the API will require to be updated to work with the upgraded version of UniDesk.
The EDW resolver ID API has not been completed within the timescales of the project. This was a result of the API being identified as having the least priority and the key developer being assigned to higher priority projects. The result of this was that although good headway has been made with the API it has not been signed off. Should this be required it will have to be raised outside the confines of this project.