Closure Report
Project Summary
Background
The October 2017 update of Google Chrome (release 62) will change treatment of websites served over HTTP. Where there is a text input field on a webpage, the page must be served over HTTPS. A failure to do so could result in a ‘Not secure’ warning in the browser bar.
Google indicated in late April that this change was in relation to personal data but have recently extended it to any text input on a website, including website search. Equally, the Chrome browser in ‘Incognito’ mode will flag all HTTP sites as ‘not secure’.
Chrome is the world's most popular browser and currently Chrome accounts for 47% of browser usage of the University website with more than 80% on the latest version.
Generally the popular uptake of a new release is 2-6 weeks post release. and post that will tend to become the defacto version.
A project of this type and complexity always faces risks and challenges, it also had a very tight timescale due to the impending release of the Chrome upgrade.
The project team comprised technical expertise from various ISG - Applications teams as well as close cooperation with the UWP team. Despite the diverse nature of the project team worked very well together and adapted methodologies to suit the needs of the project delivery along the way, including delivering a communications strategy to keep the business well informed.
The project was successful in delivering in a very short time frame so as to meet the needs of the University.
The purpose of this project was to update HTTP text fields to only accept HTTPS.
This was to support:
- Upcoming Google Chrome upgrade.
- Protect the reputation of the University.
Scope
The scope of the project as agreed in the Project Brief were:
Until now the website has accepted HTTP input fields and the integrity has been maintained within the current system. The scope of this project is to ensure that the product remains compliant with the changes that Google is making to the Chrome browser.
The project also intends to protect the reputation of the university in that users will not question whether the site is secure, something that could happen should users spot the not secure comment in their browser bar.
The project remained in scope up to and including the delivery milestone.
The project was set up to deliver a solution that avoided this situation:
This situation could have possibly damaged the University's reputation as visitors to the site may have deemed that their information was insecure
After the delivery of the solution :
CMS Login was also made secure
Objectives, Deliverables and Success Criteria
As noted in the project brief:
The objective of this project was to ensure that users who utilise Chrome as their browser will not experience a 'not secure' flag in their browser bar, secure public website with HTTPS. The University Website is not currently HTTPS but this project will implement SSL across www.ed.ac.uk to ensure full compliance.
|
No |
Description |
Success Criteria |
Priority | Achieved | |
| Development | |||||
|
O 1 |
To ensure that those who utilise Chrome as their browser do not experience a not secure flag |
No not secure flags |
M | YES | |
|
D 1 |
Present options for solution to business |
Identify benefits, risks and costs |
M | YES | |
| O 2 | Communications strategy | A communications strategy was devised and Published | M | YES | |
| D 2 | Delivery of a communications plan to business | Business kept well informed of the reasons for upgrade and delivery of final solution | M | YES | |
| O 3 | No changes to workflow or loss of service | Business notices no change or downgrade to service | M | YES | |
| D 3 |
|
||||
| Training and Support | Training website updated to mirror Live | www.Train.ed.ac.uk now same as live | M | YES |
Schedule
This was a short 6 week project which started in mid- September 2017. The project was delivered to LIVE in a single release in mid-October and then updated the TRAIN website post LIVE deployment.
Analysis of Resource Usage:
Staff Usage Estimate: 60 days
Staff Usage Actual: 49.4 days
Staff Usage Variance: -17%
Other Resource Estimate: n/a
Other Resource Actual: n/a
Other Resource Variance: n/a
Explanation for variance:
The project delivered some 10 days under the original 60 day budget.This is possibly for two reasons:
- The team worked exceptionally well together and able to deliver within original timescales.
- Project over estimated during planning.
Outcome
The project delivered the solution on 12th October 2017 as planned.
Target Date |
Previous Date | Title | Stage |
|---|---|---|---|
| 18-Sep-2017 | No date available | Planning Review | Plan |
| 29-Sep-2017 | No date available | Build Review | Build |
| 03-Oct-2017 | No date available | Acceptance Review | Accept |
| 12-Oct-2017 | No date available | Delivery | Deliver |
| 02-Nov-2017 | 16-Oct-2017 | Deployment Review | Deliver |
| 16-Nov-2017 | 27-Oct-2017 | Closure review | Close |
Explanation for variance
The only variances being the Deployment review and closure report, which were originally scheduled too close to the delivery date.
Key Learning Points
- The project was completed, albeit successfully, to an extremely tight schedule. This put more pressure on the project team and the resources assigned. perhaps for future upgrades of this nature more project time should be allowed, thus reducing the pressure on all resources available.
- A daily stand-up improved communications between the teams and focused all on the delivery points of that day
- This allowed the team to deliver on the urgent timescales.
Outstanding Issues
Occasional Images not showing.
- The project highlighted an issue already present, but not caused by the project.
- This error will be resolved with a code upgrade in December 2017.