Completion Report

Project Summary:

• Online solution for submission and management of accident/incident reports
• Including public access to reporting accident / incidents
• Authenticated access via EASE to report accident / incidents
• Incident management by Health and Safety Department and School Safety Advisors
• Reporting capabilities via Business Objects

Analysis of Resource Usage:

Staff Usage Estimate: 120 days

Staff Usage Actual: 185.5 days

Staff Usage Variance: 55%

Other Resource Estimate: 0 days

Other Resource Actual: 0 days

Other Resource Variance: 0%

Explanation for variance:

Variance explanation:

• Annual planning 13/14 budget allocation 100 (20 days contingency) = 120 days, this being a funded project
• Pre-project commencement the seniior developer estimated 143- 220 resource days with most likely = 160 days
• Agreed at project outset, a re-estimation would take place following user stories workshop / prioritisation, this was noted within the project brief https://www.projects.ed.ac.uk/project/csg002-0/brief-1 and risk https://www.projects.ed.ac.uk/project/csg002-0/risks/1
• The original budget of 120 day would only cover: project start, foundations and 6 x 1 week iterations and provide a basic application. This was deemed not acceptable by product owners who advised additional funding available to create a more robust application.
• Budget to fund a further 3 x1 weekly iterations c. 45 days would provide sufficient budget, with effective prioritisation of user stories, business users would be provided with a more worthwhile application. The original budget would not provide business users with MI reporting. As this was a compliance project it was important for the project team that we ensured regulatory reporting was a key deliverable for the project. Increase in budget of 45 days approved https://www.projects.ed.ac.uk/project/csg002/issues/3 budget  = 165 days
• Further 2 requests were received from Product owners:
  • An additional development iteration to accommodate some final stories then business users deemed as required for live implementation. They agreed funding for an additional 1 week's development of 11 days together with an overspend attributed to developers familiarisation of software, impact of 503 errors on development activity/investigations and 3 resource on project who were new to agile impacting budget (5 days). https://www.projects.ed.ac.uk/project/csg002/issues/9 and also
  • Product Owners advise that following further review of the application they identified 3 changes required before they could launch for use by pilot users (2 deemed as critical). An additional of 2 days to existing budget  https://www.projects.ed.ac.uk/project/csg002/issues/11 Total budget approved 183 days
• Some additional resource costs 2 days due to delay in final deployment of Business Objects resulting in project management costs to close down projects

If project variance is based on the original annual planning budget / project brief = 120 days (55% variance)

If project is based on developer initial estimation pre-project commencement although not formally noted = 160 days (15% variance)

Key Learning Points:

Recommendations:

1.     When the majority of the core project team are new to Agile methodology it would be useful to allocate the lead developer with 60% development time and 20% Agile coach time, to allow them to proactively manage any tasks which are impacting project due to limited knowledge within the remainder of the project team.

2.     Review the use of weekly development iterations instead of the standard 2 weekly iterations - the senior developer felt, as there were 3 developers allocated to this project, then 1weekly iterations would be a suitable approach for this size of project. However for future projects consideration of the size of the development team and project scope may not always work for the project to turnaround the development of users’ stories particularly when more functionality is added and more testing is required in later iterations.

3.     Ensure additional time allocated to include Equality Impact Assessment and involvement of Viki Galt to complete accessibility testing as Project Manager not previously aware of this activity as part of the project.

4.    The guidance for agile projects should clarify that a high-level estimate should be completed during the planning phase and submitted with the brief.  The guidance should explain the relation between this necessarily rough estimate, the earlier pro-forma annual planning estimate, and the more detailed process tracking that the agile methodology will allow once development is under way

Successes

   1.   The Core team, although the majority were new to Agile, found as a project team they worked and communicated well and they are looking forward to working on their next Agile project

2.    The use of Hipchat to actively communicate with the core project team proved extremely useful and saved time arranging meetings to discuss and resolve any issues / concerns which surfaced during the project.

3.    The product owners noted how good it was to visualise the new application when the developers transferred their user stories, gathered at the workshop, and were ‘brought to life’ on to balsamic mock-up designs.

Areas for Improvement

1.     The Core team agreed that more time should be allocated to completing and understanding the conditions of satisfaction ahead of development iteration schedule starting, to fully understand the product owners requirements.

2.     The Product owners highlighted it would be really useful if they were able to buy some additional time which could be scheduled for a later date, for example 8-12 weeks after the end of the project, in order to allow us to involve more users in testing the AIR system.  The agile method has many advantages to other ways of working, but one of the drawbacks is the lack of time available to get user testing and feedback, particularly towards the end of the project when they're taking the completed system to them, but there's very little opportunity to get many changes made, other than what is agreed via the SLA and any mop-up time remaining.  This might have been useful on the RETAIN project as well and might be something for the IS team to consider as an option for other agile projects.

3.     The project encountered a number of incidences whereby they were unable to complete testing due to 503 errors being encountered on both the Development & BETA environment this also impacted code builds and delays resulting in the developers having to quarantine tests to promote code. This was not isolated to this project all agile projects were being impacted. This was raised to WIS https://www.projects.ed.ac.uk/project/csg002/issues/5 as it had the potential to affect future Agile Projects especially if it is a large development project and it will need possible further infrastructure investigations to ensure enough capacity available for multiple agile code deployments.

Outstanding issues:

Post deployment tasks completed by Health and Safety are as follows:

• Set up Areas of Responsibility - Complete
• Set up Users - Complete
• Update wiki page for help information - Complete
• Update website with link to new application - Complete
• Rollout pilot to 10 key users - Complete
• Rollout to remaining SSAs - Complete
• H &S are manually rekeying submitted reports from Oct 2013 (approx 200) which will allow them to complete current year reporting from the new AIR application and will allow existing system to be changed to ‘read only’ status in shorter timescales. Expected completion timescales for this manual activity to be in place by early April. Now complete

Future development

• H & S will be looking for a future development to be completed to attach documents to their application, this has been given a high level estimate to be taken forward later in the year. Having reviewed this with Jamie Thin and Craig Midlemass who are using the same development team on HSS project,  it looks like the earliest that any additional work for AIR could be completed is the beginning of August 2014. The HSS project is expecting to take a break / reflection on development iteration around 25/07 so developer resource could be available over a four week period to complete further work on AIR. This would mean a small project for H & S Dept in the new financial year 2014/15 to be confirmed.