Closure Review

Project Summary:

The key objectives of this project, as a first phase of implementing an Estates Purchase to Pay solution, were to:

• Deliver an integrated purchase order solution for Estates incorporating the University’s preferred e-procurement (purchase ordering) system
• Undertake testing to ensure each element of the purchase to pay process, including the elements which are not changing, meet specified acceptance criteria
• Deliver training to end users of the purchase order solution, and deploy the new solution

While the project delivered working prototypes of new purchase order modules developed within Archibus Web Central, the Project Board decided that full implementation of the first phase would not be taken forward at this point following concerns raised by Procurement regarding the phased implementation approach, the timing and the wider SciQuest migration project.  In addition, the Board also acknowledged that there were capacity and resource availability challenges within the Estates Department which would impact rollout within the original agreed timescales. 

The Board agreed that a renewed strategy to roll out this first phase along with the subsequent phase (incorporating receipting, payments and stock management) should be explored as the development work for the subsequent phase is scheduled to start in academic year 16-17.  To support this, a revised implementation plan has been drafted and will be shared with the project sponsor, with the renewed approach based on setting up an expanded project team containing some new, key project roles, which should address management of existing issues and enable the project to deliver a new, fully integrated, purchase to pay process.

This project has delivered the working prototypes of new purchase order modules developed within Archibus Web Central, with positive feedback received from key stakeholders in Estates which will provide a firm foundation for the follow-on 'Purchase to Pay' project.

Analysis of Resource Usage:

Staff Usage Estimate: 200 days

Staff Usage Actual: 394.2 days

Staff Usage Variance: +97%

Other Resource Estimate: 0 days

Other Resource Actual: 0 days

Other Resource Variance: 0%

Explanation for variance:

Not all days have been used as the project did not complete a deployment and go-live for purchase ordering, as detailed in the decision/issue log.

The breakdown was:

The estimate change history was:

Start of project (01/11/2014) - estimated at 200d

17/09/2015 - estimate increased to 269d (+69)

Having completed the System Design, the project was re-estimated following a clearer definition of requirements.

16/12/2015 - estimate increased to 294d (+25)

This was to cover 4 unplanned days of effort already used during the Design stage to complete an ADA following a request from the IS Applications Enterprise Architect, and a re-estimation of the effort needed to complete the Build stage, representing an additional 21 days of effort.  The reason for the re-estimate was that the Lead Developer encountered a number of technical queries which require prior knowledge of the system (which we don't have) or consultation of help guides, both resulting in additional effort to address the queries.

04/02/2016 - estimate increased to 314d (+20)

The project estimate was anticipated to be exceeded with an additional system development resource due to work on the project in February and additional project management effort used to help co-ordinate the supplier enablement work-stream.

29/03/2016 – estimate increase to 402d (+88)

This increase was due to a revised software development estimate and additional project management and business analysis effort estimated due to the lack of a Business Lead.

The original development estimate was 104d out of 200d.

The development estimate then increased at each approved budget increase to the following:

143d out of 269d (estimate + 39d related to Design)

168d out of 294d (estimate +25d related to Design and Build)

178d out of 314d (estimate +10d related to Build)

240d out of 402d (actual +62d related to Build)

The original estimate v actual effort by team is shown below:

Key Learning Points:

• The lack of an overall Business Lead in Estates led to challenges in decision making and drive within Estates.  Indeed, the PM/BA in IS Applications effecticely had to cover this missing role in Estates.  The impact on IS Applications was an increase in budget to pay for additional project manager/business analyst time.  The learning point acknowledged by the senior supplier was to stop the project rather than continue for so long without a Business Lead being put forward by Estates.
• There was a lack of availability of key senior staff in Estates (particularly within Estates Finance and on the supplier management side) to engage with this project, in part due to the organisational change they were going through at the time.  The learning point, as above, was to stop or suspend the project rather than continue without these key people having availability or the key roles being resourced.
• Not enough budget was allowed for business analysis, as evidenced by the number of queries arose from the system developer where an answer had to be sought 'on demand' from Estates colleagues.  This was particularly evident in the clarifications required around the Estates budgeting process.  The learning point is to allow sufficient budget for the analysis and sufficient time before signing off the analysis phase.
• The next phase should appoint a Business Analyst to act in a separate role to the Project Manager to enable sufficient focus on both disciplines due to the complexity and size of the project.  The learning point on this project was that it would have been better not to combine these roles given the complexity and engagement challenges faced.
• The Procurement Office acknowledged that they did not sufficiently escalate their concerns about the SciQuest delivery early enough in the project.  The learning point for the Procurement Office is to ensure they communicate adequately through the Project Board structure.  The follow-on project will consider the Board Membership closely.
• There was a lack of representation of the Central Finance Department on the project team - this was in part due to the revised scope only taking us up to the purchase order modules development.  Again, the follow-up project will look to address this.
• The actual development cost exceeded the development estimates, the root cause of this being the fact that we were new to developing in Archibus Web Central which we found imposed a very rigid framework for development; some of this only became apparent as we made our way further through the development.
• Towards the latter stages of the project, Estates prioritised another project delivery (EST080: Estates Helpdesk).  This resulted in some key resources in Estates being diverted.  The learning point is to fully assess the impact of the prioritisation and challenge the feasibility of running two large (calling on similar resources) alongside each other.
• There were some dependencies on the same Archibus database between this project and another project (EST080: Estates Helpdesk) - it would have been useful to convene a working group or virtual team of IS Apps personnel to have visibility over the use of the database for both projects to ensure no overlaps or issues.  The next project could consider a virtual team or chat room to help with communications and visibility of this.

• it was at times difficult to secure developer resource with Estates/Archibus knowledge and the recommendation is that more developers are given the opportunity to train in Archibus and participate in future projects.

• Bringing in an external contractor to work with our software developers worked well, but it did still rely on our developers working closely with the contractor.

Outstanding issues:

• Ensure any solutions taken forward for capital programme management are developed in line with this project and review any opportunities for linking systems to deliver actual cost data within the capital system;

• Review composition of the Project Board to ensure key stakeholder representation and shared knowledge across corporate services boundaries (note, a new project sponsor has been identified but there will be other key roles to fill, particularly a business lead and key contacts in Finance and Procurement as well as Estates).
• There is an improvement we could make with the Web Central/SciQuest integration, which is to implement a listening web service on Web Central, instead of using a scheduled poll to retrieve PO data. This was de-prioritised in EST083 because the polling is a working solution, but the web service would be an better solution and we’d be looking to take this forward in the next phase.
• Peer testing revealed some minor bugs which will be taken forward into the follow-on project, these have been documented in the Build Test Document.
• Recommended to use automated deployment software (Bamboo) in next project, this will be factored into planning and estimates
• Compile a 'change difference report' against the existing code to confirm changes required to new coding