Completion Report

Project Summary:

The scope, objectives and deliverables defined at the outset of the project were as follows:

Scope and Objectives

To establish an enterprise production-quality Python web development platform:

• Suitable for use as a replacement for our existing ColdFusion web development platform
• Which is in step with our Division’s automation strategy

To ensure we have a solid core of trained staff who can:

• Create and maintain the infrastructure quality, reliability and availability.
• Design, develop and support the software and services hosted on the infrastructure.
• Incorporate source control and automated deployment solutions.
• Act as change agents to spread enthusiasm, knowledge and experience more widely across the Division.

Notes from Closure Review meeting:

It was agreed that the project achieved its main objective to establish an enterprise production-quality Python web development platform.  However, it was noted that training for IS Apps staff will take place out-with this project.  Training has been arranged for Python (4 days mid-September), and Django (3-5 October).  Note that this will not prevent Python projects from being initiated - we have several which are ready to start.

Deliverables

• Infrastructure components. Completed
• Software (including the Django framework) and deployment components. Completed
• Establishment of DR and resilience (Completed) , patching and End of Life (EOL) characteristics (see note below)
• Establishment of any ongoing licensing and server costs. Completed
• User Training (not completed - see note above)
• Proof of concept / demonstrator to confirm that the new platform is operational (Completed).

The product backlog which lists the user stories are recorded in the JIRA website.  Delivery of release 1 will achieve the minimum viable product:

Notes from Closure Review meeting:

• Patching and EOL characteristics: It was agreed that work will continue with our strategy for patching and EOL, as well as software collections.  The follow-on INF python project in the 16/17 programme will finalise the strategy, and as we will have real Python applications in use, we will be in a better position to understand the requirements for patching and EOL.
• It was noted that some user stories did not get completed as part of Release 1.  These will be included in Release 2 as part of the 16/17 Python project (see final section for what's in Release 2).

Feedback from Closure Questionnaire

Analysis of Resource Usage:

Staff Usage Estimate: 100 days

Staff Usage Actual: 161 days

Staff Usage Variance: 61%

Other Resource Estimate: 0 days

Other Resource Actual: 0 days

Other Resource Variance: 0%

Explanation for variance:

The budget for the project was increased on two occasions during the project.  The original budget was set at 100 days, and increased to 162 days with agreement from the Programme Manager and Project Sponsor.

1 - PICCL item 4

2 - PICCL item 5

Key Learning Points:

The following successes were noted from the closure questionnaire, and feedback at the closure review meeting:

• It feels very satisfying to be part of the team which has delivered such a large and important piece of work. Working with the rest of the team has been a real pleasure.
• Really good team work!
• We really needed a much higher % booking from both John and Riky which proved impossible to get. There was no way round that issue other than not using John and Riky - which wasn't an option either. Given all of that, John and Riky did a fantastic job.

The following areas for improvement / lessons learned were noted from the closure questionnaire, and feedback at the closure review meeting:

• To run this effectively as an agile project you would need to fix the resource FTE across iterations - otherwise you never know whether you will achieve your backlog. (can't predict velocity). In this project we had unpredictable resource allocation from week to week which was not good.
• It was interesting to have the project work in an Agile manner. While, in hindsight, it was a little clunky (it perhaps should have been a bit more Kanban and a bit less Scrum), it was useful to capture the requirements as user stories, be able to pass them between resources, and monitor their progress easily.
• Was run pseudo agile which was not as effective as running agile.
• Resource commitment was an issue that had no obvious resolution.
• The original budget was way too small but as this was something completely new we had no way of suggesting something more realistic.
• Normally in a project we are not the customer so the tasks and activities of the customer do not appear in our budgeting/estimation. On this occasion we were the customer (Bill was the Product Owner) and therefore the budget was never going to stretch as far as we would like because we also had to account for the customer role.
• A product owner is expected to contribute 40% of their effort to an agile project - our budget could never "afford" this amount and consequently Bill was always under pressure to do less so that more could be spent on development. This meant that there were compromises in the product owner role that would have been better avoided.
• Although Production Management contributed to the project, it was felt that they should have been more involved during the weekly review meetings.

Outstanding issues:

There are no outstanding issues to report. 

For information, the following is a list of features which will be delivered by the 16/17 INF Python project:

INFRASTRUCTURE:

• Introduce containerisation into the infrastructure to provide fully isolated, reproducible application environments. (Python story numbers: #120, #25, #13, #26)  

• Allow applications to deploy gracefully to severs (Python stories #99, #100, #110)

• Provide a more modern and easier to follow job scheduler than CRON (Python story #29)

DEVELOPMENT CAPABILITY:

• Provide support for LDAP integration in the Django Starter Application (Python Story #3)  

• Have guidance on how to export information to PDF, Excel or CSV formats by adding to starter app (Python Story #28)  
• Provide the capability to pull shared versions of internal libraries/resources/assets from a repository (e.g. Maven) so that they are pulled into the deployment process as dependant artifacts and we are not relying on single shared resources on the servers. (Python Story #6)  
• Enhance the healthcheck functionality to provide a healthcheck which is deployed in a standard manner and checks as much of the stack as we want so that load balancer configuration is simplified and application issues can be caught and diagnosed. (Python Story #17).  
• Make use of all of the application configuration items and see them as a whole so that we can get a good overview of all the dependencies across our whole python infrastructure, and be able to assess the impact of change (Python Story #22).  
• Provide the capability of choosing which version of Python is built during the deployment so that upgrades can be achieved with little or no cost, and to allow variances in supportable versions (Python Story #7).