Website Architecture Refresh Project

Transcription

1 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 Revision date Version Summary of Changes Changes marked Page 1 of 19

2 Approvals This document requires approvals from the following: Name Signature Title Date of Issue David Tidey Head of Information Systems Trevor Ridley E-Manager Derek Fenwick Janette White Martin Fitzpatrick Service Manager Business Support Head Of Business Support Head of Media and Communication Version 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 Page 2 of 19

3 Karen Sale Matt Graves Mark Laridon ISD Management Team TMP idox Bucksnet Contents 1. Document History 2. Contents 3. Purpose of Document 4. Background 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 Page 3 of 19

4 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 Page 4 of 19

5 Project Definition Objectives: 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: Page 5 of 19

6 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 Page 6 of 19

7 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 Page 7 of 19

8 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 Page 8 of 19

9 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 Internal Trust), 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 Page 9 of 19

10 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 Extranet costs for project filing Page 10 of 19

11 Hospitality costs Communication plan Project Board 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 Project Board Quarterly Project Board Meetings Members Project Manager Project Team Monthly Project Team Meetings Key Contacts Meetings Information architecture Working Group Meetings Website Redesign Working Group Meetings Workstream team meetings Varies Varies Varies tbc Members Internal (non-project team) contacts on the distribution list. Representatives from the content authors. Representatives from the public. Individual workstream team members. Internet & Media team e-manager Project Manager Page 11 of 19 Comments For approval of plans, and at stage and project ends. To be held prior to Board Meetings Specific functional area input to project and also communicating project progress across the business. tba with the consultants tba with the consultants tbc by the workstream leaders. Progress Meeting Weekly A weekly meeting to discuss project progress and issues PID Once Project Board Will receive approval Highlight Reports Quarterly Project Board e-government Manager Project Board prior to stage one. Gives progress and highlights upcoming events

12 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 Boroughwide Communication Ad-hoc Public, third parties, and content authors. Including Surveys re design and navigation. Updates on the website to keep public up to date. 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 Page 12 of 19

13 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. The Project Management structure: Page 13 of 19

14 Corporate or Programme Management Project Board Senior User Executive Senior Supplier Project Assurance Project Manager Project Support Project Teams 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 7. Delivery of a suitable end Business Product Page 14 of 19

15 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 5. Administer the quality review process Page 15 of 19

16 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 Page 16 of 19

17 Initial Risk Log Known Risks How likely How serious Total Score Steps to address them 1. Lack of availability of staff 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. 3. Individual workstreams are delayed impacting on the overall project 4. Products from individual workstreams to not meet each others requirements 5. Technology is found not to meet requirements following implementation Maintain full list of requirements throughout the TAP and readdress following deployment to ensure capability % Contingency included in plans Regular communication and progress updates from each workstream. 20% contingency included in plans 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 Page 1 of 19

18 Initial project plan with timescales Link to project plan - ct%20plan.mpp Page 1 of 19

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 Page 2 of 19