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



Success Criteria



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.



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.


  • Delivery of priority use cases; must deliver at least the equivalent functionality available in Polopoly.
  • Testing with CMS users throughout the development process


  • Delivery of a responsive design for a range of devices.
  • Testing with representative website users throughout the development process
D 1.2Implementation 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.
  • New CMS is deployed to all environments using established continuous integration processes
  • The infrastructure meets the requirements in terms of performance, scalability and resilience.
D 1.3Develop technical support materials and handover system support to Production Management
  • Support materials are documented and reviewed by all relevant support teams
Content Migration    


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.1Engage 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. 
  • Units/schools informed of developments/timescales
  • Remedial work on content has been completed

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.

  • Full audit complete to inform full migration plan

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.
  • Editorial migration is tested with changes to processes/tasks documented and reviewed
D 2.3Produce a robust and manageable migration process that can be tailored and repeated for all units currently publishing in old CMS/Polopoly.
  • Plan for 14/15 wide scale migration is delivered (based on experiences during initial migration)
D 2.4Rollout 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.
  • Implement migration plan to move schools and units to new CMS
D 2.5Decommission Polopoly
  • Polopoly to be moved to a read only state by Summer 2015
MNo (migration still in progress)
Training and Support    
O3To 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.1Interface usability, design and development – to ensure interfaces are kept easy to use so that the training overhead is kept to a minimum.
  • CMS design pattern library in use as an ongoing working document .

  • UX techniques formalised/embedded in development processes

D 3.2Develop training and support materials and train initial users involved in the initial migration
  • Must be at least the same as existing Polopoly service
D 3.4Initial training delivery – support staff and initial users
  • Training framework in in place and users trained at appropriate point in the engagement process
D 3.5Rollout training delivery – regular training for all staff as each unit’s website is transferred from old to new CMS
  • Training plan is in place to ensure that users can publish and edit content as with the new CMS
D 3.6Deliver familiarisation/training for support staff to support service transition management
  • Support officers are training and familiar with new CMS
D 3.7Develop SLA and OLAs for the new Drupal Service
  • SLA and OLA for new service have been agreed
Change Advisory Board    
O4Establish a Change Advisory Board (CAB) to enable ongoing management and development of the core CMS whilst enabling local development contributions.   
D 4.1
  • Initiate CAB
  • Appoint chairperson
  • Assist CAB chairperson in appointing CAB members
  • Agreed terms of reference
  • Develop CAB processes including defining processes for technical peer group/UoE Open Source community to feed into the CAB decision making process
  • Agree frequency of meetings and assist CAB chairperson in scheduling initial meetings
  • CAB is set up
  • CAB members appointed
  • CAB members agree to terms of reference
  • CAB processes are confirmed
  • CAB engages with user community and discussions with local developers


CMS Service    
O5To 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.1The 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.
  • Suitable service options are available for central supported units, non-core units/schools etc
  • There is a mechanism though the CAB for non-core units/schools to feedback their development for potential inclusion into the core profile
D 5.2Where possible liaison with other HE institutions using Drupal.
  • Engagement with other HE institutions in the UK and further afield to establish areas of common interest.
DPartially Achieved


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.


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.  


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.


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.

Project Info

New University-wide Web CMS
Z. ISG - University Website (UWP) (Closed)
Project Manager
Tim Gray
Project Sponsor
Dawn Ellis
Current Stage
Start Date
Planning Date
Delivery Date
Close Date