Completion Report
Project Summary:
Project Review
In 2013/14 development work has commenced on the new Drupal CMS (UWP006). As part of the transition, a content audit and large scale migration of content, structures, users and workflow is required from Polopoly to the new CMS. In preparation for the migration of content from Polopoly to Drupal several activities have been ongoing simultaneously. The project UWP009 is investigating the content and data structures in Polopoly to feed into the development project UWP006. This focus of this project was to gather information about how the current CMS is used in terms of peak traffic times, relationship between groups and users, workflow and provide information on shared content.
The project planning was completed in September 2013, although the project started in July, high priority work meant that the planning was pushed out slightly. During planning it was decided to deliver the project using the Business Objects (BO) platform. In November, due to scheduling challenges within UWP, the project was split into 2 phases so that the deliverables 1 and 3 could be put LIVE earlier. However, due to issues deploying to DEV the phases were rescheduled together one month later when all objectives were deployed to DEV and TEST. A further delay was encountered due to an ongoing BO upgrade project. As a result the LIVE deployment was moved out to mid-February. Some issues arose after deployment these were fixed but did encounter a delay due to the PM's absence.
In summary the project has delivered valuable information for the migration to Drupal. The implementation could also be used in future, as a mechanism to generate new reports should these be required.
Objectives and Deliverables
| Objective | Deliverable | Success Criteria | Delivered |
|---|---|---|---|
| 1. To audit the structure and metadata of the CMS content in preparation for migration to the new CMS and export this audit in csv file format | A means of auditing the CMS Structure and metadata which produces:
| Scripts which can be run by either run by CMS Managers or run at their request through a support call. The output is in the form or a csv file.
| YES |
2. To express the relationship between users, groups, workflow and permissions on sections to allow CMS managers to compare this with the CMS structure and metadata. This will inform and simplify the recreation of workflows in the new CMS. | A means of auditing the CMS group permissions, workflow associations which produces :
| Scripts which can be run by either run by CMS Managers or run at their request through a support call. The output is in the form or a csv file.
| YES |
| 3. To have the information on shared content references within the CMS in order to rebuild these references within the new CMS. | A bug fix for the reference tab and additional functionality:
| All historical inbound references appear correctly within the references tab. | YES |
| 4.To ascertain the CMS usage at normal and peak times in order to assist capacity planning for the new CMS. | A means of auditing CMS usage as follows:
| A report that details correct information on CMS usage:
| YES |
Scope
The project remained in scope throughout.
Analysis of Resource Usage:
Staff Usage Estimate: 80 days
Staff Usage Actual: 79 days
Staff Usage Variance: -1%
Other Resource Estimate: 0 days
Other Resource Actual: 0 days
Other Resource Variance: 0%
Explanation for variance:
Despite some delays the project has delivered to within the budget estimates during planning.
Key Learning Points:
There are four main lessons that can be learned from this project, most of these around the deployment to LIVE.
Nr | Issue | Leason Learned |
|---|---|---|
1 | During the Acceptance Review it was agreed to make a minor change to one of the reports, this did cause an issue during the deployment. After this change was backed out, the deployment script completed successfully. | No code changes should to made after UAT is completed, unless these changes are rigorously tested |
2 | After the deployment, business users did not have access to the LIVE environment. This appears to have arisen because there is a general lack of understanding/clarity about the procedures related to Business Objects reporting and deployments. | Clear guidelines on implementing BO projects, especially around users and permissions should be made available. |
3 | The reports on LIVE had lost their connection to the corresponding BOXI universe. This possibly due to work on ITS092 between the time the reports were tested on TEST and deployment to LIVE. | Better communication between projects working on the same infrastructure or with the same service. |
4 | End users were not aware that the existing content in the reports were from the last time they were saved - which is this case was on TEST just before deployment. This lead to a complaint that they were seeing TEST data from the LIVE reports. The solution was to refresh the reports and save them on LIVE | Improved training should be completed for business users with no previous BO experience. |
Outstanding issues:
There is one outstanding issue. There is no monitoring in place to ensure that the materialized views are being refreshed. The monitoring of this materialized views should be some standard to be delivered by the project, this was raised after deployment. Production Management has agreed to pick this up as KSR.