Website Architecture Refresh Project

19916 Page 1 of 19

A7

The Royal Borough of Kensington and Chelsea

PROJECT INITIATION DOCUMENT

Website Architecture Refresh Project

Author: Rachel Circus

Project Initiation Document History

Document Location

This document is only valid on the day it was printed.

The document will be saved in the Project Folder on the Intranet

Revision History

date

Version Summary of Changes Changes

19916 Page 2 of 19

Approvals

This document requires approvals from the following:

Name Signature Title Date of

Issue

Version

David Tidey Head of Information

Systems

Trevor Ridley E-Manager

Derek Fenwick Service Manager Business

Support

Janette White Head Of Business Support

Martin Fitzpatrick Head of Media and Communication

Distribution List

Name Title Date of Issue Version

David Tidey Head of Information Systems Trevor Ridley eManager

Derek Fenwick Service Manager Business Support

Janette White Head Of Business Support Martin Fitzpatrick Head of Media and

Communication

Steven Evans Head Of Customer Services And Revenues

Rebecca Kitchen Secretary

James O’Malley Senior Internet Support Officer Andrew Smith ICT for ICE Project Manager Alan Koeninger Web Design Officer

Maureen Kerr Internet Editor Cllr Campion Councillor

Shirley Wechsler Deputy Head of Media and Communications

Vijay Parbat Solicitor

Andrew Smart Senior Finance Officer

Paul McDonald Information Systems Strategist Melanie Marshman Research & Consultation Manager

19916 Page 3 of 19

Karen Sale TMP

Matt Graves iDox

Mark Laridon Bucksnet ISD Management Team

Contents

5. Project Definitions: Objectives and Scope, Inclusions/Exclusions 6. Method of Approach

7. Project Stages and Key Deliverables 8. Constraints and Interfaces

9. Business Case: Reasons, Benefits, Costs, 10. Project Quality Plan

11. Brief Equalities Impact Assessment 12. Project Controls

13. Communication Plan 14. Contingency Plans 15. Project filing structure 16. Project Organisation 17. Initial Risk Log 18. The Project plan 19. Glossary

19916 Page 4 of 19

Purpose of Document

The purpose of this document is to define the project, to form the basis for its management and the assessment of overall success.

The PID addresses the following fundamental aspects of the project: • What is the project aiming to achieve

• Why it is important to achieve the stated aims

• Who will be involved in managing the project and what are their roles and responsibilities

• How quality will be maintained

• How and when the arrangements discussed in this PID will be put into effect When approved by the Project Board this PID will provide the “Baseline” for the project and will become “frozen”. It will be referred to whenever a major decision is taken about the project and used at the conclusion of the project to measure whether the project was managed successfully and delivered an acceptable outcome for the sponsor/user/customer.

Project Background

The website architecture has been in place for five years. it is used by over 80,000 people a month and provides details on all the Council's services.

The Society of IT Managers (SOCITM) has ranked the RBKC website in the top twenty in the country for the past four years.

Since implementation the volume of information published has grown significantly necessitating several revisions to the architecture of the site.

The requirements of the public have also changed, with more and more people using websites to access council services thereby increasing the importance of a clear and informative website.

The council's branding requirements have changed over the years, with these changes reflected on the website to match other council communications.

Accessibility standards that are updated on a regular basis must be achieved in order to maintain our excellent standards - the RBKC website is one of only three LGA websites with 'AA' compliance. We also hold an Internet Crystal Mark for use of Plain English.

However, the web architecture has reached the end of its life and must be replaced to reduce the risk of the Website losing its 'Excellent' rating.

19916 Page 5 of 19

Project Definition

The high-level goal of this project is to overhaul the RBKC website architecture in four key areas:

• Interface design

• Content management system • Search engine

• Information architecture

In line with the Borough's Aims, the specific objectives of this project are: • Really good services

o _{Enabling greater quantities of information to be published.} o _{Enabling different types of information to be published.} o _{Improving the overall usability.}

o _{Providing Content Authors with greater structure for their content.}

o _{Automatic categorisation of content using IPSV (Integrated Public Sector}

Vocabulary).

o _{Reducing the Content Editors workload through the use of templates.} o _{Reducing the time and work involved from content creation to publishing by}

streamlining the authoring process.

o _{Devolving content authoring to the business.}

o _{Reducing the maintenance overhead by allowing for global updates to the site.}

• Renewing the legacy

o _{A future-proof platform to build on.}

o _{Reducing the time and manual effort involved to achieve required accessibility}

and other standards. • Responding to residents

o _{Improving communication between RBKC and the public}

o _{Improving the consistency of branding between the different types of council}

communication.

o _{Improving consistency of content placement, thereby enabling the user to}

quickly locate the information they're looking for.

o _{Improving the categorisation of information again helping the user to locate}

what they're looking for.

o _{Improving the search facility.}

Project Scope:

The project will involve a review of the full website architecture and will consist of four workstreams:

19916 Page 6 of 19

• Information Architecture Redesign - Review of RBKC published information. Including the identification of types of information published (e.g. events, reports), development of rules and information templates to assist content authors in the generation of content.

• Website Redesign - The redesign and rebranding of the RBKC website, the presentation of the family of RBKC microsites, the adoption of current best practice and the creation of design templates.

• Content Management System Replacement - Replacement of the current CMS, this will include participation in the Microsoft Office 2007 Technology Adopt Program (TAP). The expectation is for enhanced functionality not like-for-like replacement.

• Search Engine Replacement - To provide a search facility with enhanced functionality that will cater for an increase in information and improved use of metadata.

Each of these workstreams will have their own detailed documentation.

Exclusions:

This project will not involve any reworking of the Intranet or Extranet sites, or the redesign of any RBKC microsites (except for header and footer records where appropriate).

Method of Approach

Prince2 Project Management Methodology will be adopted for the project.

Work on the four project workstreams will overlap with cross-project dependencies.

Project Stages and Key deliverables

The project will deliver a revamped website, providing an enhanced experience and improving the efficiency of both communication from the council to the public and internal resource usage.

Stage 1: Project Scoping

• Start date - 3 April 2006 • End date - 14 July 2006

• Description - In this stage the requirements and objectives for the four workstreams and supporting architecture will be scoped. Where third party services are required for consultations etc, a formal tender process will be carried out as part of this stage. Alternative CMS and SE products will be reviewed at site visits.

• Products - Requirement specifications Signed consultation contracts.

19916 Page 7 of 19

Stage 2: TAP Design

• Start date - 17 April 2006 • End date - 14 July 2006

• Description - Detailed scoping for TAP including architecture design. • Product - Business user feedback

Stage 3: Consultations

• Start date - 17 July 2006 • End date - 3 November 2006

• Description - The Website Redesign, Information Architecture and Search Engine workstreams will involve consultation with internal staff and/or the public. This consultation may be carried out with the assistance of third parties.

• Product - Signed-off design specifications.

Stage 4: TAP Architecture implementation

• Start date - 17 July 2006 • End date - 28 July 2006

• Description - Implementation of architecture for TAP purposes. • Product - Platform for software deployment.

Stage 5: TAP Deployment

• Start date - 31 July 1006 • End date - 11 August 2006

• Description - Deployment of the MS CMS system to a small team and review of results. The MS Search Engine will also be assessed as part of the TAP. Following User Feedback at the end of deployment a formal decision will be made as to whether to adopt the MS products or not. This decision will be based on performance of the products against those requirements known at the time the design specification was drawn up and any identified

subsequently. If necessary further testing will be carried out. • Product - Business needs survey.

Stage 6: CMS and SE Tender Process

• Start date - 14 August 2006 • End date - 6 October 2006

• Description - If following completion of the TAP one or both of the MS products are found to not be suitable a formal tender process will be undertaken. The requirements for the Web Design and Information Architecture workstreams will provide input to the tender.

• Product - Systems selected.

Note: If this stage is necessary it will delay all subsequent stages by up to four months.

Stage 7: Architecture implementation

• Start date - 14 August 2006 • End date - 25 August 2006

19916 Page 8 of 19

• Description - Implementation of architecture to support all workstream products.

• Product - Platform for software deployment.

Stage 8: Development

• Start date - 6 November 2006 • End date - 26 January 2006

• Description - All four workstream products will be implemented in the development environment.

• Product - Systems available for testing.

Note - If the MS CMS product is selected, the availability of a final version may delay this stage.

Stage 9: Testing

• Start date - 29 January 2006 • End date - 6 April 2007

• Description - Testing of the individual workstream products and the overall web architecture offering will be carried out in development by the project teams and key users. Any issues will be resolved and retested prior to the next stage.

• Product - System ready for migration to live environment.

Stage 10: Introduction

• Start Date - 9 April 2007 • End date - 8 May 2007

• Description - Documentation of the processes and procedures required to support the new CMS system, and ensure a smooth handover between staff. • Product - Support documentation.

Stage 11: Migration

• Start date - 9 April 2007 • End date - 21 June 2007

• Description - All elements will be migrated to the production environment and all published information migrated to the new CMS. Content authors will also receive training during this stage in both the CMS and Plain English.

• Product - System ready for launch.

Stage 12: Go Live

• Start date - 22 June 2007 • End date - 28 June 2007

• Description - CMS system launched. • Product - System live and in use.

Stage 13: Review

• Start date - 29 June 2007 • End date - 10 January 2008

19916 Page 9 of 19

• Description - On-going assessment of the system, and a post implementation review meeting.

• Product - Lessons learned report.

Constraints and Interfaces

In order to comply with the requirements and timescales of the TAP the Microsoft CMS product will be evaluated in isolation.

The TAP and MS 2007 product will be evaluated against a key set of requirements due to timescales before scope documentation and from scoping to review.

Additional requirements will be documented alongside the TAP.

If the 2007 product is found to be unsuitable based on performance against the key list of requirements. A full tender process will be entered into.

If the key requirements are met the product will go through further evaluation against the full requirements.

This project, and the workstreams within it, will draw heavily on the time of people within the IMT team. Lack of availability will impact heavily on the project due to the overlapping nature of the work involved.

Key Interfaces Why is this a key interface Links and

Contacts

Internet Internal

Extranet Links to areas of the Internet Internal

TMP Jobs Website interaction with the Internet Karen Sale

London Connect List supplied. Helen

Booth

Direct Gov List supplied tbc

Intranet Links to areas of the Internet Internal

PCT (Primary Care Trust), Internal CSD (Children's Directory Services) Internal

Business case

The current RBKC website has been in place for five years. In that time, the requirements and aims of the site have changed, the quantity of material published by the council has grown significantly, and the councils’ requirements for communication, publicity and branding have also grown and changed.

On these points the current interface design does not meet the needs of the council. Nor will it do so in the future, as council communications grow in number, frequency and complexity.

In addition to this the website is becoming increasingly focused on providing interactive services to the public. This is driven by the need to meet the

e-19916 Page 10 of 19

Government directive of to put all government services online. The current system will not be able to meet these increasing transactional needs.

The CMS was developed for RBKC by a third party, it is no longer supported and there is minimal documentation available for reference. All changes to the system therefore present a degree of risk.

The hardware on which the CMS is based is out of warranty, presenting a high risk of failure, however given the lack of support migrating the CMS to new hardware presents an even greater risk.

RBKC is one of only three LGA websites to achieve 'AA' compliance in line with the Disability Discrimination Act (DDA), and is also a supporter of the Freedom of Information (FOI) act. Meeting these legislative requirements is becoming increasingly difficult with our current system.

Changes required to web pages due to branding and accessibility standard changes, can not be implemented globally and must be made page by page. This is extremely time-consuming and has the risk that individual pages will be missed.

Content Authors from across the borough provide content for the Internet. This content is provided in Word format and has to be transformed to HTML by the central Content Editors, of whom there are only two. The Content Editors also check that common information is captured for the type of content supplied so that consistency is maintained, and that Plain English standards are adhered to before returning the HTML versions to the Content Authors for approval and subsequent publishing. The Authors also need to specify where their content should be displayed and the categorisation for each item. These allocations must then also be checked and confirmed by the editors to again ensure consistency across the site.

This reliance on Content Editors and complexity of the publishing process, have become progressively more impractical as the volume of information to be published has increased.

The customer experience is hampered by a lack of consistency of branding between different types of council communication due to the difficulties of globally updating the site.

Cost:

The initial anticipated costs for this project are in the following areas:

• Tender costs for Website Redesign, Information Architecture and *CMS partners. • Consultant fees for website redesign consultation - external

• Consultant fees for content categorisation - internal • CMS software costs

• Search engine software costs • Communication costs

• Training costs

19916 Page 11 of 19 • Hospitality costs

Communication plan

The Project Board provides the overall direction and management of the project from a corporate perspective. The project board will need to give approval to all major plans and authorise any major changes. The project manager will request meetings at these critical times.

A typical Project Board meeting will include the following agenda items: • Project Plan – review current activities against planned tasks

• Review of Issues and Risk Logs – to review the current status of project risks • AOB – any additional items to be discussed

• Next Meeting – confirm date of next meeting

Item/Description Frequency Audience Comments Project Board

Meetings

Quarterly Project Board Members

Project Manager

For approval of plans, and at stage and project ends.

Project Team Meetings

Monthly Project Team Members

To be held prior to Board Meetings Key Contacts

Meetings

Varies Internal (non-project team) contacts on the distribution list.

Specific functional area input to project and also communicating project progress across the business.

Information architecture Working Group Meetings

Varies Representatives from the content authors.

tba with the consultants

Website Redesign Working Group Meetings

Varies Representatives from the public.

tba with the consultants

Workstream team meetings tbc Individual workstream team members. tbc by the workstream leaders. Progress Meeting

Weekly Internet & Media team e-Manager Project Manager

A weekly meeting to discuss project progress and issues

PID Once Project Board Will receive approval

prior to stage one. Highlight

Reports

Quarterly Project Board e-Government Manager Project Board

Gives progress and highlights upcoming events

19916 Page 12 of 19 Project Team Working Groups Key Contacts Stage Plans Twelve Project Board e-Government Manager Project Board Project Team Working Groups Key Contacts

CCAG Quarterly Committee

Lessoned Learned Report

Once Project Board Following post

implementation review Progress

Updates

Ad-hoc Public, third parties, and content authors.

Including Surveys re design and navigation. Updates on the website to keep public up to date.

Boroughwide Communication

Ad-hoc All RBKC staff Communication at key milestones to raise awareness.

Project Quality Plan

This project will follow the ISD QMS Operating Procedures

Following the PRINCE2 Project Management Methodology, regular quality reviews will be held. This quality review is a procedure designed to assess whether a product is ‘fit for purpose’ and meets business requirements. The working group will conduct these reviews.

The Internet & Media eManager will conduct reviews for the actual project at various stages during the lifecycle of the project

Project assurance will ensure that the project remains focused on goals and deliverables, that the scope does not creep and that communication is successful.

Project controls

The Project Board will review this project at significant points. Major reviews will take place to approve this PID and for post implementation review.

Highlight Reports will be provided to Project Board members monthly until post implementation sign off.

Stage plans will be provided to the Project Board for approval at the start of each stage.

19916 Page 13 of 19

Responsibility for all day-to-day controls will rest with the Project Manager. Overall responsibility for the successful delivery of the project will rest with the Project Executive.

The e-Manager will undertake a checkpoint review at the different stages through the project to ensure project and quality management standards are adhered to.

The Project Board's approval will be sought for any changes to project scope or timescales.

Exception Process

Proposed: Notify board if timescale slips by more than 1 month via an exception report.

Contingency plans

20% contingency will be included for this project due to the high number of unknowns and the interlocking nature of the workstreams.

Project filing structure

Some project filing will be held on the RBKC extranet. All external contacts will have permissions restricted to the workstreams in which they are directly involved.

The majority of project documentation will be held on the RBKC Intranet.

Project organisation structure

The PRINCE2 project management structure consists of roles and responsibilities that bring together the various interests and skills involved in, and required by, the project.

19916 Page 14 of 19 Corporate or Programme Management

Project Board

Senior User Executive Senior Supplier Project Assurance Project Manager Project Teams Project Support Main Responsibilities: Project Board:

1. Authorise the start and continuation of the project from the corporate perspective 2. Set Project Tolerances

3. Approval of the Project Initiation Document 4. Delegation of any Project Assurance roles

5. Review and approval of next stage plans and exception plans 6. Commitment of project resources required by the next Stage Plan 7. Set and review overall strategy and interfaces with other initiatives

Project Board: Executive – David Tidey

1. Ownership of the Project’s Business Case including validation and monitoring 2. Overall direction and guidance for the project

3. Monitor and control the progress of the project at a strategic level

4. Monitoring and assessing changes to the project plan and business case 5. Chair Project Board meetings and reviews

6. Sign off management reports

19916 Page 15 of 19

Project Board: Senior Supplier – Trevor Ridley

1. Ownership of the project from a Supplier viewpoint 2. Advise on development strategy, design and methods 3. Monitor change and impact from a supplier viewpoint 4. Monitor any risks in the production aspects

5. Ensure quality control procedures are used correctly 6. Attend Project Board meetings and reviews

Project Board: Senior User – Derek Fenwick and Martin Fitzpatrick.

1. Ownership of the project from a User viewpoint 2. Check the specifications meet the user’s needs 3. Quality checking of the product

4. Ensure quality control procedures are used correctly to meet user requirements 5. Risks to the users are monitored

6. Impact of changes are monitored from a Users point of view 7. Attend Project Board meetings and reviews

Project Board: Project Assurance - Janette White

1. Maintenance of thorough liaison throughout the project between the supplier and the customer

2. User needs and expectations are being met or managed 3. Risks are being controlled

4. Adherence to the Business Case

5. Constant reassessment of the value-for-money solution 6. Fit with the overall company strategy

7. The right people are being involved

8. An acceptable solution is being developed 9. The project remains viable

10. The scope of the project is not 'creeping upwards' unnoticed 11. Focus on the business need is maintained

12. Internal and external communications are working 13. Applicable standards are being used

14. Adherence to quality assurance standards.

Project Manager: Rachel Circus

1. Day-to-day management of the Project 2. Planning, monitoring and control

3. Reporting progress through Highlight Reports 4. Management of Team Managers and Contracts 5. Delivery of the project’s Products

6. Configuration Management, Filing and Change Management

Project Support: Rebecca Kitchen

1. Administer change control 2. Maintain project files

3. Compile, copy and distribute all project management products 4. Collect actuals data and forecasts

19916 Page 16 of 19 6. Administer Project Board meetings 7. Assist with the compilation of reports

Workstream Leaders:

Alan Koeninger - Website Redesign

Rachel Circus (Maureen Kerr)- Information Architecture

Rachel Circus (James O'Malley)- Search Engine Replacement (?)

Rachel Circus (James O'Malley)- Content Management System Replacement.

1. Prepare plans for the workstreams and agree these with the Project Manager 2. Receive authorisation from the Project Manager to create products.

3. Day-to-day management of teh workstream

4. Take responsibility for the progress of the team's work and use of team resources and initiate corrective action where necessary within the constraints laid down by the Project Manager

5. Advise the Project Manager of any deviations from plan, recommend corrective action and help prepare any appropriate Exception Plans

6. Pass back to the Project Manager products that have been completed and approved.

7. Ensure all Project Issues are properly maintained on teh issue log

8. Ensure the evaluation of Project Issues that arise within the team's work and recommend action to the Project Manager

9. Liaise with any Project Assurance roles

10. Attend any stage assessments as directed by the Project Manager 11. Arrange and lead team checkpoint meetings and produce Checkpoint

Reports as agreed with the Project Manager 12. Maintain workstream documentation.

13. Identify and advise the Project Manager of any risks associated with the workstream.

14. Ensure that all identified risks are entered on the Issues and Risks Log 15. Manage specific risks as directed by the Project Manager.

19916 Page 1 of 19

Initial Risk Log

Known Risks How

likely

How serious

Total Score

Steps to address them

1. Lack of availability of staff 4 4 6 Planning and identification of

resources ahead of time. 2. Adoption of the MS CMS and SE products based on incomplete

requirements known at the start of the TAP process.

2 3 6 Maintain full list of

requirements throughout the TAP and readdress following deployment to ensure

capability. 3. Individual workstreams are delayed impacting on the overall

project

2 2 4 20% Contingency included in

plans. 4. Products from individual workstreams to not meet each others

requirements

2 4 8 Regular communication and

progress updates from each workstream. 20% contingency included in plans.

5. Technology is found not to meet requirements following implementation.

2 4 8 Ensure comprehensive

requirements are captured and monitored throughout the project. Project Assurance to ensure that user expectations are being met.

This risk may increase if the MS CMS product is not selected.

19916 Page 1 of 19

Initial project plan with timescales

Link to project plan -

http://teamareas/boroughwide_projects/warp/Project%20Documents/WARP%20Proje ct%20Plan.mpp

19916 Page 2 of 19

Glossary

Accessibility

Web accessibility means that people with disabilities can perceive, understand, navigate, and interact with the Web, and that they can contribute to the Web.

Content Author

Content Authors provide Content for publishing on the Intranet, and approve the web pages before they are published.

Content Editors

Content Editors translate the content provided by Content Authors and generate valid web pages for approval and publication.

(IPSV) Integrated Public Sector Vocabulary

An 'encoding scheme' for populating the e-GMS subject element of metadata. Metadata

Metadata is data about data. e.g. This document may have additional metadata to describe it such as: Author, creation date, document size etc.

Microsites

Microsites are areas of the RBKC site, which exhibit localized characteristics different from the main website. e.g. Venues For Hire.