Completion Report

Project Summary:

Performance against objectives

The following objectives were identified in the Project Brief: -

• To provide a University-wide solution to eFinancials stores requisitioning
• To provide automatic uploading of stock information for all University stores
• To incorporate barcode scanning of stock products and issues into eStores
• To develop the systems infrastructure to support this

All of these objectives have been achieved and in many areas exceeded.  Not only has the project delivered product barcode scanning via eStores Mobile on newly procured handheld scanning devices, but it has also introduced additional key functionality for the online Stores, such as 'item back in stock' notifications, enhanced multi-store functionality for users who shop at more than one Store, and enhanced stock reporting facilities.

Performance against success criteria

The following success criteria were identified in the Project Brief: -

• FIS no longer receive manual stock files for loading into eFinancials
• Stores are able to effectively and efficiently issue stock for both 'in-store' and 'online' shoppers
• eStores accurately reflects the stock in the Stores and keeps eFinancials in line.

All of these success criteria have been met.  5 additional Stores are now on the system (3 barcoded Stores and 2 online Stores).  The system is also set-up ready for the 2 remaining online Stores (SCRM and Roslin) to come onto the system in the New Year.

Delivery schedule

The project delivered 3 discreet Releases.  Barcode scanning functionality and ID card production were delivered in Release 1, with further enhancements delivered in Releases 2 and 3.  Details of the deliverables in each release can be accessed via the links in the table below.

Analysis of Resource Usage:

Staff Usage Estimate: 117 days

Staff Usage Actual: 128 days

Staff Usage Variance: 9%

Other Resource Estimate: days

Other Resource Actual: days

Other Resource Variance: 0%

Explanation for variance:

• The Project Team provided on-site and remote support during the go-live of each Store to ensure a smooth transition onto the new system for both the Stores staff and their customers.
• A development break was taken between Release 2 and 3 to allow sufficient time for the new Stores to give reallife usage feedback.  During this time the Project Team gave advice and support whilst the users became accustomed to the new technology.
• The Project Team gave support and advice during the procurement of the new barcode scanners.
• Internal Audit undertook an audit of the HGU/eStores transactions.  No eStores-related issues were indentified, but the Project Team had to take time to answer the auditors queries.

Key Learning Points:

What went well

• User engagement - the Stores reps were extremely engaged with the Agile process, actively participating is producing User Stories, User Groups and Prioritisation meetings and giving feedback on the Live product.  The Team have had excellent feedback from the Stores users on both the process and the end product.
• Product Owner role - the Product Owner is now more familiar with the Agile process and the role of the Product Owner so was able to effectively guide the development of the product.  The Product Owner also successfully managed the relationship with the Project Sponsor.
• Team flexibility (Agility?) - the Project Team were able to modify their approach/plans as events changed e.g. when the scanner delivery was delayed, when the Prioritisation Group needed adjusting etc.
• Matthew Bunn (eAuthorisations changes) - several of the User Stories required changes to eAuthorisations.  Matthew was extremely receptive to our requests and delivered all of the relevant changes promptly and effectively.
• Improved process - compared to the previous Agile project, the Agile process worked much more smoothly within the framework of IS Apps processes.
• Continuous integration - the Bamboo product and the continuous integration process worked very smoothly and allowed the team to concentrate on developments rather than routine installation tasks.
• Feedback from Live - the Team received valuable feedback from Live usage of the product, which was then able to be fed into the final release, resulting in an improved end product.  The Team noted that that users in a realife situation used the application in a different manner to when being used in a test situation.
• Dual developers - as for the previous eStores project, having 2 developers resulted in a high quality delivery.
• Development Spike - using this timeboxed approach allowed the Team to effectively manage the risk of introducing new technology and a new development language.
• Teamwork - The Team worked together very effectively.  The increased % resource booking helped to embed Dev Tech within the team, which worked much better than on previous Agile projects.

 What didn't go so well

• Make-up of Prioritisation Group - the make-up of the Prioritisation Group didn't seem to accurately reflect the breadth of end-users.  This was addressed in Release 3 by inviting a wider group of Stores representatives.
• Apps Management team involvement - the Apps Mgmnt reps didn't seem to be embedded within the team or to become fully engaged with the eStores product.  This was highlighted as a concern on the previous Agile project and an attempt was made to improve on this by increasing the % allocation and including Apps Mgmnt in weekly team meetings, but this doesn't seem to have had the desired effect. Apps Mgmnt rotated the role between 3 individuals in an attempt to share the knowledge around their team, but this seems to have diluted the engagement further as some of the continuity was lost.
• Beta environment - the Team didn't make much use of the Beta environment for QA, which instead took place on the Test enviornment.  This was partly because there is no accessible Dev eAuthorisations, so sample users were difficult to set up, and partly because the stores/product data on Dev eFinancials was insufficient for testing.
• Cron script re-write - Apps Mgmnt undertook a rewrite of one section of the overnight interface (the cron job activation).  This requirement should have been raised at the team meetings as a User Story e.g. "As a support provider I need a more effective method of activating the overnight interface so that I don't waste time/effort rewriting the script everytime a new Store comes online".  This story would then have then have been discussed and prioritised alongside other work.

What we would do differently next time

• Improve UAT - due to their geographic distribution & their usual day-to-day jobs, end user testing was very limited.  The role of UAT was undertaken by the team.ideally users would be able to allocate time to undertake user testing, but in the University environment this is difficult to achieve as end-users already have fulltime roles and are geographically spread across the city.  Better use could be made of collaborative tools such as 'Collaborate' and video recording to allow users to feedback on new features as they're developed.
• Post release  & break resource - a % of resource should be allocated for post-release support to allow for investigating/resolving issues encountered in the final release.  If the project plans to take a break between iterations then a % of resource should also be allowed for this.
• Shorter iterations - because of the new technology/language involved on this particular project, it would have been better to have used shorter iterations (1 week in duration rather than 2).  This would have improved the monitoring & feedback cycle and allowed us to spot sooner the drift that we experienced in iteration 1.
• Get equipment delivered earlier (or start development later) - the late delivery of the scanners had a significant effect on Release 1 of the project.  In future we would allow a much longer period to allow for late delivery.

Outstanding issues:

• Dev version of eAuthorisations  - eAuthorisations has no Dev environment and no data syncing, which makes development of linked products such as eStores more complex. There is also concern about how linked System Admin roles will be assigned, as FIS should not be allocating system admin roles for these systems.  A project proposal for this is being considered as part of Annual Planning and this project should include these areas of concern.
• WiFi connectivity issues on the barcode scanners - the new barcode scanning devices (Datalogic Elf) are intermittently losing their WiFi connection.  The procurement and support of these devices was outside the direct scope of this project, but the eStores product is impacted by this issue.  The Team has supplied a workaround to the Stores. The procurement manager at Chemistry is in direct communication with the supplier to resolve this issue.
• Documention of the revised cron script - the rewrite of this script was outside the scope of the project and it is currently not installed in the Live environment, but once it is then Apps Mgment may want to consider including it in the SDD or other support documentation.
• Upgrade remaining barcode scanners - the scanners at Swann stores are still on the previous version of eStores mobile.  This will continue to work ok but the newer version contains more error handling.  As soon as the Stores pcs are upgraded to Windows 7 then the upgrade can be carried out by Stores staff, with support from Finance.  Instructions for the upgrade are in the User Guide.
• Bamboo training for Apps Management - as for the previous Agile projects, Bamboo training is still to be arranged for Apps Management staff, until this is done then fixes will need to be deployed to live by Dev Team.
• Invalid finance code combinations - a small handful of MVM users (<5 out of several hundred) are unable to use eStores because their grant codes are considered invalid by the validation web service (used by eAuthorisations and eStores).  This is being progressed with ABS by Finance to see if they will make their internal eFin validation service available.  If ABS agree to this then a small change may need to be made to eStores (under support arrangements) to point to the alternative validation service. The workaround for the Stores is to raise orders for these users directly in eFin stock module.

User stores to be considered for future development

• A number of User Stories were not selected for development by the Prioritisation Group, these are documented in the Unused User Stories section of this Wiki.  A number of them should be considered for future development.
• The Product Owner has been requested to consider the introduction of a reporting tool such as BOXI to allow for end-to-end reporting between eStores and eFin stock module.
• The Product Owner has been requested to consider whether all of the interface emails are still required, as some of these appear to be of limited use.  A monitor dashboard (for Admin use only) or BOXI report may prove to be more useful.