Closure Review
Project Summary:
A project of this magnitude and complexity will always face challenges and risks, the project team worked extremely well together, embraced and adapted the agile project methodology to suit the changing needs of the project along the way.
This has been a very successful project.
The purpose of this project was to develop a Drupal based CMS, EdWeb, that meets the University’s requirements for Web content management. EdWeb needed fulfil some key high level requirements:
- to support mobile devices;
- offer content producers an easier and more adaptable system with which to work;
- be built using a future proof technology
Early on in the project is was decided to run the migration planning, development and migration itself as a separate project. Although some of the resources working on the migration also had an important part in the development project, running the migration as an autonomous piece of work the served the need to ensure development work and communication for each strand were handled independently of each other.
The objectives and deliverables have been successfully met. Where some lower level functionality (i.e. user stories) were not prioritised and therefor not developed, a work around to achieve the desired outcome is available.
In the closure questionnaire responses here was unanimous agreement that the new system is a huge improvement and will enhance the University’s web presence and reputation.
Objectives, Deliverables and Success Criteria
No | Description | Success Criteria | Priority | Achieved |
| Development | ||||
O1 | To deliver a new University-wide CMS that meets the needs of the user community based on the User stories as prioritised by UWP. The new CMS will provide better support for mobile devices and offer content producers an easier, more adaptable system, while also providing at least the equivalent level of functionality of Polopoly. |
| M | YES |
D 1.1 | a. Deliver a new and improved CMS that allows the current devolved publishing model to continue functioning as outlined in the user stories (business requirements). The CMS must be easy to use by non-specialist and occasional editors. b. The website delivered by new CMS must include a responsive design supporting mobile devices and provide an improved web experience for the website visitor. | a.
b.
| M | YES |
| D 1.2 | Implementation of new CMS to DEV, TEST, STAGING, TRAIN and LIVE environments. The new CMS infrastructure must support the service in a performant, scalable and resilient manner. |
| M | YES |
| D 1.3 | Develop technical support materials and handover system support to Production Management |
| M | YES |
| Content Migration | ||||
O2 | To migrate current LIVE content from Polopoly to the new Drupal based CMS. Also, to create a manageable/realistic transition plan that can be achieved with the resources available and within the timescales agreed |
| ||
| D 2.1 | Engage and consult with all units/schools using old CMS, so they understand steps involved and are prepared for the transition/migration when their turn comes. |
| M | YES |
D 2.1 | Complete a full audit of all current websites and their content – activities to included quantify number of individual websites, their size, number of editors involved, etc. |
| M | YES |
D 2.2 | Initial editorial migration – following technical migration, review content to check that automated migration has worked properly, quantify the type and range of editorial activities required to make content fit the new site structure, content layouts and CMS editorial functionality. |
| M | YES |
| D 2.3 | Produce a robust and manageable migration process that can be tailored and repeated for all units currently publishing in old CMS/Polopoly. |
| M | YES |
| D 2.4 | Rollout of migration process/activity – following the successful initial migration (both technical and editorial), work with each unit/school to successfully move content from the old CMS to the new CMS. |
| M | YES |
| D 2.5 | Decommission Polopoly |
| M | No (migration still in progress) |
| Training and Support | ||||
| O3 | To provide the required training and support infrastructure to allow UWP to support the new service and ensure that users are trained to publish content to the new CMS and that the new service is suitable for all levels of users. | |||
| D 3.1 | Interface usability, design and development – to ensure interfaces are kept easy to use so that the training overhead is kept to a minimum. |
| M | YES |
| D 3.2 | Develop training and support materials and train initial users involved in the initial migration |
| M | YES |
| D 3.4 | Initial training delivery – support staff and initial users |
| M | YES |
| D 3.5 | Rollout training delivery – regular training for all staff as each unit’s website is transferred from old to new CMS |
| M | YES |
| D 3.6 | Deliver familiarisation/training for support staff to support service transition management |
| M | YES |
| D 3.7 | Develop SLA and OLAs for the new Drupal Service |
| M | YES |
| Change Advisory Board | ||||
| O4 | Establish a Change Advisory Board (CAB) to enable ongoing management and development of the core CMS whilst enabling local development contributions. | |||
| D 4.1 |
|
| M | YES |
| CMS Service | ||||
| O5 | To increase the number of units/schools engaging with the central CMS service either directly or indirectly. In order to achieve this the new service should offer different levels of service and support according to the varying needs of different units/schools | |||
| D 5.1 | The project should provide a core profile of Drupal modules that may be used and modified or further developed by units/schools out with the central service. Appropriate levels of support available from the central CMS will be defined. |
| M | YES |
| D 5.2 | Where possible liaison with other HE institutions using Drupal. |
| D | Partially Achieved |
Scope
The scope of the project as agreed in the terms of reference were:
"The scope of the project is to deliver a University-wide CMS using Drupal Open Source software, migrate the current LIVE content from Polopoly to Drupal and provide training materials and associated support related documentation for the new service. This project will be delivered over two years, however, the it is planned to go live with an initial site in July 2014 and continue development and migration throughout 2014/15. While the main focus of the migration will be from Polopoly, it is expected that some non Polopoly content will be migrated. Plans for migrating this non-Polopoly content will be made when details of the source system and content are made available by content owners."
The project remained in scope.
Schedule
This was a two-year development project which started in August 2013. As an Agile project, the development was completed in a series of iterations. In total, the project delivered 5 releases. The first release was broken up into 4 development phases. In release 1, each phase covered specific areas of development with the delivery of the beta at the end of development phase 4. Release 2 was the minimum viable product (MVP). Each of the subsequent releases 3, 4 and 5 contained features required for the following batch of sites migrated to EdWeb.
Analysis of Resource Usage:
Staff Usage Estimate: 1336 days
Staff Usage Actual: 1750 days
Staff Usage Variance: 31%
Other Resource Estimate: 30000 days
Other Resource Actual: 15000 days
Other Resource Variance: -50%
Explanation for variance:
The variance of 414 days against ToR can be attributed vast amount of user stories and customisation required to meet the business needs. This resulted the agreement for additional development iterations.
The project team did not record their time against individual tasks but had bookings for development phases/releases. This makes retrospectively identifying the cost of specific tasks impossible. However, the initial infrastructure issues (noted below) accounted for some 15/20 days effort. Also, the distribution took much longer to develop than originally anticipated. This work was not specifically estimated or recorded in ASTA but at least one developer worked mainly on the distribution for several iterations over the course of the project.
Key Learning Points:
This was an extremely complex project using a technology to a level that we had not undertaken before. As such there were unexpected issues of both a technical and non-techncial nature along the way. A number of lessons learned have been identified, these can be used in future projects within UWP and further afield.
The key lessons learned are listed below, all closure questionnaire responses are here: UWP006 Completed Closure Questionnaire.
Agile
The chosen project methodology is an area where lessons can and have been learnt. Although everyone involved in the project agreed that Agile was the best approach, some concern was raised at the outset about the Agile experience within the project team. To mitigate this concern and to familiarise the team with Agile as a project methodology, a two-day Agile course was held for the core members of the project team. The project team did adapt the Agile processes as the project progressed for example with the inclusion of UX testing. The whole project team agree that the methodology worked very well for the project. At the time of writing January 2016, Agile projects are now more common within Applications, our flavour of Agile project management has developed and matured since 2013, some of these improvements are a direct result of how this project was managed and implemented.
During the development iterations, the Apps team co-located to UWP offices. This was a significant factor in the project success and is recommended for future projects of this nature.
As the project progressed, changes were made to the user story development process. By changing and adding to the iteration meeting structure, allowing a certain group to review feedback, issues and potential new user stories, the backlog maintenance and story creation was made much more efficient.
There were changes to some roles during the project. The business analyst role had three different incumbents. When the initial BA was on long term sick leave, a replacement was found. However, at the start of 2015, she left the division and the project manager picked up the role for the remainder of the project. The second switch did not have a detrimental effect on the project but the initial change did come at a cost, while the BA was brought up to speed with the project.
One of the key roles in the Agile methodology is the role of Product Owner. The role was also changed mid-project with the UX lead and Product Owner swapping these roles. This did have a very positive impact on the project, allowing expertise to be applied more effectively and enhance the decision making process.
With hindsight, another area that could have been better defined at the outset of the project, was that of Graphic Design representative. With the work completed in previous projects it was not clear at the outset the commitment which was required. This should have been a clearly defined role (as opposed to a representative). This resulted in the effort required being underestimated, leading to conflict for resource and availability in the project. However, it should be noted that a significant amount of good work was completed.
Prior to the development project commencing an extensive backlog of user stories were developed in a previous project. A large number of these were then discarded during the development, it would be useful for future projects to consider how the business analysis and foundation phase can be more efficient, to reduce the creation of user stories that are later discarded.
Infrastructure
Another key lesson learned early on in the project concerned the infrastructure. The development started before all environments were completely available. This should have been completed in the foundation phase (iteration 0). There was a certain amount of pressure not to delay the start of development but in retrospect it would have been more effective to have delayed the development until the infrastructure was completely finished. The infrastructure setup/configuration was not completed by the project team but ITI Unix, over whose schedule we did not have any significant influence. This would almost certainly have resulted in a significant delay with the knock on effect this has on both the project/programme but also other planned work across IS Applications.
A second significant infrastructure issue was the withdrawal of the file resilient storage. Due to on-going technical issues this was withdrawn by ITI in July/August 2014. The cost of the rework was approximately 20 days and the service now has some storage related issues with the SAN infrastructure which is in use.
The complexity of the Drupal infrastructure is a perfect example of why configuration management is needed to be used in Apps. For future large in house hosted projects, for example the Drupal 8 upgrade, it is strongly recommended to use Enterprise Linux 7 hosts and the “Puppetisation” of the service.
DrupalCon and Consultancy
Some of the project team were able to attend DrupalCon, the annual conference for the open source Drupal community. This was extremely beneficial and allowed attendees to gain knowledge and experience from a technical, functional and management level. DrupalCon gave the team members the opportunity to research and validate decisions that were being taken along the way.
Unfortunately, colleagues from UWP were not able to attend DrupalCon in 2013, which doubled as an excellent team building opportunity.
DrupalCon attendance provided valuable background and technical lessons in the best practice of configuring Drupal. At the first DrupalCon research was completed which led to the engagement of Wunderroot as consultants. Wunderroot completed the following work:
- Initial analysis of the technical architecture
- Review of code base during the first year of development
- Content type theming
- Valuable troubleshooting
- Final code audit
Outstanding issues:
- The implementation of the rollback has not yet been completely tested and enabled on LIVE. This will be completed in the next development project UWP011.
- The project board will continue to meet until the migration is complete and to advise where required on future development.
- There are some known issues are the current SAN storage, work-arounds are in place to deal with these. The implementation of the resilient file storage will be handled by a future as yet undefined project.