Project definition document
TSol
LION extranet and Lawyers database redevelopment
26 January 2011
Vanessa Leisegang
020 7956 3126
[email protected]
14-Jul-17, 1:36 AM
Document1
Page 1 of 172
Version control
V
Date
Author
Comment
0.1
07/12/2010
Vanessa Leisegang
Internal draft
0.2
09/12/2010
Vanessa Leisegang
Internal revisions round 1
0.3
13/12/2010
Vanessa Leisegang
Internal revisions round 2
1.0
13/12/2010
Vanessa Leisegang
1st client release
1.1
17/12/2010
Vanessa Leisegang
Feedback from Mark Sawney, Maureen Brooks and Keri Williams
1.2
22/12/2010
Vanessa Leisegang
Formatting repair, revisions based on scope agreement and calculation corrections
1.3
06-01/2010 –
11/01/2010
Vanessa Leisegang
Amends incorporating client feedback as follows:
1.3 addition of final bullet point
2.4 addition of the last two bullet points
3.11 removal of:
– OL3.1 discussion boards
– OL3.2 link to TSol library
– OL3.3 job opportunities
– OL3.5 job opportunities stats
3.2 provided additional clarification for the following deliverables
– 2) Project requirements document
– 5) Site map
– 6) Taxonomies
– 9) Functional specifications document
– 10) Technical specifications document
– 11) Technical design document
– 12) Test plan and scripts
– 13) Content migration plan
– 16) Design assets
– 18) CMS and extranet site development
– 19) Content migration
14-Jul-17, 1:36 AM
Document1
Page 2 of 172
– 21) UAT
– 22) Training and documentation
– 25) Database design document
– 26) Data migration plan
– 27) Database development
– 28) Data migration
– 30) Training and documentation
– 31) UAT
– 33) Project management
– 38) Technical management
– 39) Governance
3.4.2 amended as follows:
– Removed cross-linking reference
– Added caveat to ML1-005
– Added domain setup info to ML1-008
3.4.4 added developer effort to TMP-002
3.4.5 amended as follows:
– Added further info to ML3-005
– Re-worded ML3-009 per client feedback
– Added assurance to ML3-010 about how the control will be improved
3.4.7 added note to ML4.1-009
3.4.9 amended as follows
– Changed section title
– Added LION admins to ML4.3-003
3.4.10 added decision tree note to ML4.4-002
3.4.12 added variance rationale to ML4.6-001
3.4.12 added explanation of C/R/U/D
3.4.13 amended as follows:
– Updated description for ML4.7-002
– Added a note and a reference to ML4.7-008a
– Updated second sub-bullet in description of ML4.7-008b
3.4.17 amended as follows:
– Added qualification of process design to ML4.11-004a
– Changed 'super user' to 'editor' across all requirements where applicable
3.4.22 changed 'super user' to 'editor' across all requirements where applicable
14-Jul-17, 1:36 AM
Document1
Page 3 of 172
3.4.23 amended as follows:
– Added references to CMS-002 and CMS-003
– Added requirement CMS-004 which was omitted from PDD v1.0
– Added section 3.8.27 Lawyers database software purchase, which was omitted from PDD v1.0
3.4.28 amended as follows:
– Added MD2-003 database design document, which was omitted from PDD v1.0
– Removed 'optional free text field' from MD4-005b per client feedback
– Updated MD24-002 to include deletion of non-GLS records by database administrators
– Updated MD24-002 to include deletion of all records in fast and intuitive manner
3.4.29 amended as follows:
– Added reference to DBUI-002
– Added further explanation to final bullet point for DBUI-003
3.4.30 amended as follows:
– Changed 'super user' to 'editor' across all requirements where applicable
– Added further rationale for cost variance to MD20-001
3.4.31 added qualification about instructions for variants of reports to MD22-001a
3.4.36 removed 'PDF' document type from all requirements
3.4.38 updated section title
3.7 added OL3.1. 3.2, 3.3, 3.4 and 3.5
1.4
13/01/2010
Vanessa Leisegang
Corrected and cross-referenced all cost tables. Delivered for Endava review
1.5
19/01/2011
Vanessa Leisegang,
Jessica Ashworth,
Endava
Refinements with Endava as follows:
3.1.1 updated optional requirements bullet point
3.2. updated as follows:
– Clarified 'preview of functionality' in budgeted iterations for deliverable 18
– Added number of days to deliverable 24
– Updated description and budgeted iterations for deliverable 25
– Clarified 'preview of functionality' in budgeted iterations for deliverable 27
 Updated description for deliverable 30
3.4.5 updated as follows:
– Clarified digest notification parameter for MC25-001
– Clarified description of ML3-007
– Added caveat to ML3-007
– Added PRDv1.0 reference to ML3-010
3.4.7 removed automated removal of bounced email addresses from ML4.1-005
14-Jul-17, 1:36 AM
Document1
Page 4 of 172
3.4.31 removed the word "confirm" from MD22-004
3.6 updated as follows:
– Updated assumption 3 (LION content migration)
–Updated assumption 4 (Lawyers database data migration)
– Added assumption 7 (LION search)
3.7 removed forum reference from final bullet point
1.6
21/01/2010 –
25/01/2010
14-Jul-17, 1:36 AM
Vanessa Leisegang
Jessica Ashworth
1.4 added a new term to the glossary
3.2.2 added a note to deliverable 21) UAT
3.2.2 updated number of iterations for deliverable 4
3.2.3 added a note to deliverable 31) UAT
3.3 added notes to SET-002 and SET-003
3.4.12 updated as follows:
–Updated the assumption for ML4.6-001
–Updated the assumption for ML4.6-003
3.4.2 updated caveat for ML1-005
3.4.2 updated the assumption for ML4.7-003
3.4.15 updated as follows:
– Added an introduction
– Split search requirements between GSA and Lucene in ML4.9-002
–Moved an assumption re Lawyers database from ML4.9-002 to ML4.9-001
– Add a list of assumptions to this section
3.4.17 updated the lookups assumption for ML4.11-004b
3.4.22 updated as follows
– Removed references to forums from all requirements
– Confirmed number of logged-in CMS users as 8 per selection of SiteCore Professional Edition licence
model
–Re-numbered the requirements to remove a duplicate LUS-003
3.4.24 clarified staging environment in LQT-003
3.4.28 added an assumption to MD4-002
3.4.30 added a caveat to MD21-001a
3.4.42 clarified pen testing on hosting infrastructure in SEC-003b
3.4.43 added caveat to system performance ML6.3-001 and MD24.3-001
3.4.5 updated as follows:
– Added assumption to ML3-002
Document1
Page 5 of 172
– Added note to ML3-010
3.4.6 updated the assumptions for content migration ML3-014
3.4.7 updated ML4.1-007 – process is manual, not automated
3.5 changed section title
3.5.1 added variance description to OL5
3.6 updated the section in full and cross-referenced to requirements
4.2.1. updated staging environment location in the UAT section
4.2.2 added Lucene to the 'SiteCore' bullet point
4.3 amended as follows:
– Replaced "obfuscated" with "anonymised"
– Updated the description of how live lawyers' data will be migrated to the staging environment
– Removed references to sharing of the OGC GSi leased line and updated the deployment text for the
Lawyers database
Addition of section 5.4.4 high-level risk analysis
9.5.1 amended as follows:
– Removed "options" from the title
– Added GLS selection of the Professional Edition for project implementation
9.5.3 updated the notes for SiteCore CMS and MS Dynamics
9.6.1 Added a note about the start of the hosting contract
1.7
25/01/2011
Vanessa Leisegang
Draft for review
1.8
26/01/2011
Vanessa Leisegang,
Jessica Ashworth, Adam
Croxen, Peter Barker
Final revisions prior to client release as follows:
3.2.2 updated deliverable 6 to exclude metatdata
3.4.1 updated WCAG version in ML2-002
3.4.5 specified an archive folder in MC25-002
3.4.17 updated ML4.11-001to include data origin from the Lawyers database
3.4.19 specified the feedback form as static in ML4.13-001
3.4.23 added a note about unique IP addresses to MS-003
3.4.27 updated report definitions in MD2-003
3.4.27 updated second bullet point MD10-001
3.4.37 updated DEP-002 with a task for The GLS
4.2.1 updated text re CMS installation, updated the UAT and deployment section
2.0
26/01/2011
Vanessa Leisegang
2nd client release
14-Jul-17, 1:36 AM
Document1
Page 6 of 172

Table of contents
Version control ......................................................................................................................................................................................................................... 2
1.
2.
3.
4.
Introduction........................................................................................................................................................................................................................11
1.1
Document purpose ......................................................................................................................................................... 11
1.2
Document distribution .................................................................................................................................................... 11
1.3
Project summary ............................................................................................................................................................ 13
1.4
Glossary of terms ........................................................................................................................................................... 13
Objectives and success factors ........................................................................................................................................................................................15
2.1
Business objectives........................................................................................................................................................ 15
2.2
End user objectives ........................................................................................................................................................ 15
2.3
Internal user objective .................................................................................................................................................... 15
2.4
Success factors .............................................................................................................................................................. 16
Scope of work ...................................................................................................................................................................................................................18
3.1
Overview ........................................................................................................................................................................ 18
3.2
Deliverables, tasks and iterations................................................................................................................................... 19
3.3
LION extranet and Lawyers database setup and requirements capture fees................................................................. 25
3.4
Mandatory requirements and fees.................................................................................................................................. 26
3.5
Requirements list as ‘optional’ in the RFP and fees ..................................................................................................... 113
3.6
Assumptions ................................................................................................................................................................ 116
3.7
Out of scope ......................................................................................................................Error! Bookmark not defined.
3.8
Business processes ..................................................................................................................................................... 120
Approach .........................................................................................................................................................................................................................124
4.1
Overview of our approach ............................................................................................................................................ 124
14-Jul-17, 1:36 AM
Document1
Page 7 of 172
5.
6.
7.
8.
9.
4.2
Technical approach ...................................................................................................................................................... 129
4.3
Security ........................................................................................................................................................................ 132
Project processes ............................................................................................................................................................................................................133
5.1
Reviews, feedback, amends and approvals ................................................................................................................. 133
5.2
Impact of schedule slippage ......................................................................................................................................... 134
5.3
Change management................................................................................................................................................... 134
5.4
Risk management ........................................................................................................................................................ 135
5.5
Quality management .................................................................................................................................................... 146
5.6
User acceptance tests.................................................................................................................................................. 152
Organisation ....................................................................................................................................................................................................................154
6.1
GLS roles and responsibilities ...................................................................................................................................... 154
6.2
Rufus Leonard roles and responsibilities ..................................................................................................................... 159
Communication ...............................................................................................................................................................................................................166
7.1
Status reporting ............................................................................................................................................................ 166
7.2
PM sync ....................................................................................................................................................................... 166
7.3
Meeting and phone call notes ...................................................................................................................................... 167
Timings ............................................................................................................................................................................................................................168
8.1
Schedule ...................................................................................................................................................................... 168
8.2
Milestones .................................................................................................................................................................... 168
Contract and budget ........................................................................................................................................................................................................169
9.1
Contractual basis ......................................................................................................................................................... 169
9.2
Summary of project fees and costs for 3-year period ........................................................Error! Bookmark not defined.
9.3
LION extranet fees ....................................................................................................................................................... 169
14-Jul-17, 1:36 AM
Document1
Page 8 of 172
9.4
Lawyers database fees and MS Dynamics licence ...................................................................................................... 169
9.5
SiteCore CMS costs ..................................................................................................................................................... 169
9.6
Hosting and application support costs...............................................................................Error! Bookmark not defined.
9.7
Billing schedule ............................................................................................................................................................ 170
10.
Appendixes ..................................................................................................................................................................................................................171
10.1
Proposed hosting infrastructure diagram ..................................................................................................................... 171
10.2
Breakdown of estimate management effort .......................................................................Error! Bookmark not defined.
14-Jul-17, 1:36 AM
Document1
Page 9 of 172
14-Jul-17, 1:36 AM
Document1
Page 10 of 172
1.
Introduction
1.1
Document purpose
The purpose of the project definition document (PDD) is to define the project scope, schedule and budget in order to form the basis for its management
and an assessment of its overall success.
The primary uses of the PDD are to:
 Act as a project foundation document against which the Rufus Leonard and The GLS project teams can assess progress, issues and ongoing viability
questions
 Provide a single source of reference about the project
 Reflect the current status, plans and controls of the project (the document’s component parts will be updated throughout the project lifespan to reflect
the current status of the project)
The version of the PDD approved for the project is preserved as the baseline scope, schedule and budget.
1.2
Document distribution
1.2.1
Rufus Leonard
Name
Role
Organisation
[INFORMATION
REDACTED UNDER
SECTION 40 FREEDOM OF
INFORMATION ACT]
Board report
Rufus Leonard
[INFORMATION
REDACTED UNDER
Client Partner
Rufus Leonard
14-Jul-17, 1:36 AM
Document1
Page 11 of 172
SECTION 40 FREEDOM OF
INFORMATION ACT]
[INFORMATION
REDACTED UNDER
SECTION 40 FREEDOM OF
INFORMATION ACT]
Senior Project Manager
Rufus Leonard
[INFORMATION
REDACTED UNDER
SECTION 40 FREEDOM OF
INFORMATION ACT]
Development Consultant
Rufus Leonard
[INFORMATION
REDACTED UNDER
SECTION 40 FREEDOM OF
INFORMATION ACT]
Information Architect
Rufus Leonard
1.2.2
The GLS and COI
Name
Role
Organisation
[INFORMATION
REDACTED UNDER
SECTION 40 FREEDOM OF
INFORMATION ACT]
Programme Sponsor
The GLS
[INFORMATION
REDACTED UNDER
SECTION 40 FREEDOM OF
INFORMATION ACT]
LION/Lawyers database owner
The GLS
[INFORMATION
REDACTED UNDER
SECTION 40 FREEDOM OF
INFORMATION ACT]
LION/Lawyers database manager/administrator
The GLS
[INFORMATION
REDACTED UNDER
SECTION 40 FREEDOM OF
INFORMATION ACT]
Programme Manager
TSol
14-Jul-17, 1:36 AM
Document1
Page 12 of 172
[INFORMATION
REDACTED UNDER
SECTION 40 FREEDOM OF
INFORMATION ACT]
LION Management Board / User representative
DfT
[INFORMATION
REDACTED UNDER
SECTION 40 FREEDOM OF
INFORMATION ACT]
Procurement and Technical Project Assurance
COI
1.3
Project summary
The GLS has commissioned the redesign and redevelopment of the Legal Information Online (LION) extranet using a new content management system
(CMS) and new Lawyers database.
The implementation of the two new systems will include migration of existing content to the new extranet and database, as well as hosting and ongoing
support post-launch.
Some of the key benefits in undertaking this project include:
 Ongoing cost savings
 Efficiencies in maintaining and updating the applications
 Better user experience
 Easier for the audience to update and share information
 Allowing GLS lawyers to work more cohesively as a community
 Providing savings in time to locate information on the LION extranet
1.4
Glossary of terms
14-Jul-17, 1:36 AM
Document1
Page 13 of 172
Term
Description/definition
RFP
COI Request for Proposal document, version 10 dated 25/05/2010 for COI job reference "301351 –GLS
CMS, Extranet & Database 09-10"
C/R/U/D
Create, read, update and delete
MSD
Microsoft Dynamics CRM
CMS
Content Management System
GSA
Google Search Appliance
UAT
User Acceptance Testing
API
Application Programming Interface
UI
User Interface
14-Jul-17, 1:36 AM
Document1
Page 14 of 172
2.
Objectives and success factors
2.1
Business objectives
From the RFP the high level objectives for the project are set as:
 Replace existing GLS systems to provide greater functionality and more flexibility to online communications
 Enhance the delivery of quality legal services and strive to ensure better value for money
 Implement an updated, robust and secure technology platform to meet GLS needs
 Implement a CMS that meets the requirements described in the RFP that creates efficiencies in the content creation and information management
across GLS
 Build a user friendly and efficient communications platform that enables knowledge sharing and collaboration amongst government lawyers
2.2
End user objectives
The following were identified as specific project/system objectives by end users of the LION extranet:
 An extranet that is customer-friendly and easy to use and manipulate
 Intuitive and advanced search functionality
 Reduction in time spent content editors/owners in uploading content, thereby increasing the quantity and quality of knowledge sharing
 A facility to provide practical, pragmatic and useful information for a lawyer drawn into a new area of law as they are moved across government
departments
2.3
Internal user objective
14-Jul-17, 1:36 AM
Document1
Page 15 of 172
The following were identified as specific project/system objectives by internal users (content owners and administrators) of the LION extranet and the
Lawyers database:
 Provide content owners/editors with an easy way to add and manage content on the LION extranet; flexibility to add and update content without
technical skills
 Date-stamped headlines will expire automatically based on a predefined time-expiry rule
 Provide a database interface for administrators that is intuitive and easy to use21
 Integration between the Lawyers database and LION extranet contacts directory, providing a single data entry point with auto-update of LION contacts
directory data when it is updated in the Lawyers database
 A facility to easily change the name of departments in the Lawyers database, which will consequently update email addresses in the database of all
lawyers associated with that department
 Site tracking that will provide metrics on popular and most used content
2.4
Success factors
Based on discussions with stakeholders, the following may be set as critical success factors:
 Project delivered to scope, budget and on time (It is recognised that the budget is fixed, therefore there is no room to accommodate change requests
without de-scoping other deliverables)
 Implementation of an efficient process for integrating LION contacts directory and Lawyers database data updates and publishing and avoidance of
duplication
 Realisation of savings in lawyers’ time spent updating and looking for content. This can be achieved with improved structure, user interface and search
functionality
 Reduction in time spent on back office legal editing of content
14-Jul-17, 1:36 AM
Document1
Page 16 of 172
 Avoidance of the duplication of record maintenance across the LION extranet and the Lawyers database
Note: measurement and reporting of the benefits is not within scope of this implementation project.
14-Jul-17, 1:36 AM
Document1
Page 17 of 172
3.
Scope of work
3.1
Overview
The following items are determined to be in scope of the project:
3.1.1
Redevelopment of the LION extranet on a new CMS platform, including:
 All mandatory functional requirements ML1 – ML6 as listed in the COI RFP (V10, 25/05/2010) except as elaborated within this document.
 Build of new GSe hosting environment meeting requirements OL1 and ML6 and deployment of the system onto this environment
 Requirements listed as optional in the RFP but now mandatory:
OL3.1-001 – content commenting facility
OL5 – limiting user access to authorised government departments
OL6 – providing secure content areas for authorised single end users
3.1.2
Provision of a CMS system that supports the following requirements stated in the RFP:
 Requirements MC1 to MC50 except as elaborated within this document
3.1.3
Redevelopment of GLS Lawyers database application with modified functionality based on the existing system:
 All mandatory functionality requirements MD1 - MD25 as listed in the COI RFP (V10, 25/05/2010), except as elaborated within this document
 Build of new GSe hosting environment for the Lawyers database and deployment of the system onto this environment
14-Jul-17, 1:36 AM
Document1
Page 18 of 172
3.2
Deliverables, tasks and iterations
Project deliverables were initially identified in the COI RFP. These are listed in the tables below together with the tasks and products required to complete
the project, along with the number of revisions for each item covered in the project budget.
3.2.1
Project set up and requirements
Deliverable
Summary description
Budgeted iterations
Requirements capture for both LION extranet and Lawyers database

Requirements
workshops
Up to 5 workshops to capture and define detailed requirements mapped to the
requirements listed in the RFP
Client approval not required on workshop
notes (these workshops have been completed
at time of issue of v2.0 of this PDD document).

Requirements
definition document
(PRD)
Record of detailed and prioritised requirements capture in the requirements
workshops that will form the basis of the project scope and be incorporated into
the PDD
Includes implementation of a single round of
client feedback.
(PRD v1.0 has been completed at time of
issue of v2.0 of this PDD document).
A formal document that captures and defines the scope, deliverables, schedule,
timelines, budget and processes to deliver against the requirements
Includes implementation of a single round of
client feedback.
Will be submitted for client approval.
Summary description
Budgeted iterations
Development of up to 5 personas and 5 key user journeys (based on requirements
listed in the approved PDD) tailored to different audience segmentation, including
engagement modes and interactions
Includes implementation of a single round of
client feedback.
Requires client approval.
The personas and user journeys will be
Project definition

Project definition
document (PDD)
3.2.2
LION extranet
Deliverable
Information architecture

Personas and User
journeys
14-Jul-17, 1:36 AM
Document1
Page 19 of 172
updated during the remaining IA work stream
as required, up to a maximum total of three
iterations.

Site map
Site map representing the structure of the LION extranet
Includes implementation of a single round of
client feedback initially. Includes two further
iterations during the wireframing task, up to a
maximum total of three iterations.
Requires client approval.

Taxonomies
Development of labelling in conjunction with the site map (excluding metadata)
Includes implementation of a single round of
feedback from the client initially. Includes two
further iterations during the wireframing task,
up to a maximum total of three iterations.
Requires client approval.

Wireframes
Development of up to 10 key annotated template wireframes mapped to the site
map, personas and user journeys
Includes implementation of three rounds of
feedback from the client.
Requires client approval.

Content matrix
Based on the approved site map and approved wireframes, development of a matrix
describing how content in the existing structure will be mapped to the new
structure
Will be submitted for client approval.
Technical documents

Functional
specifications document
A document defining the front-end user interaction and functional behaviours for the
published LION extranet site, including user types and permissions matrix,
workflows, validation and error messages. The functionality defined in this
document will be based on the approved wireframes.
Includes implementation of a single round of
feedback from the client for correction of errors
only. Changes to functionality approved in the
wireframes will be managed under the change
management process.
Requires client approval.

Technical
specifications document
A document describing the agreed technologies and environments of the LION
extranet system, including:
–
System architecture
–
Supported browsers and operating systems
–
Accessibility compliance level
–
CMS platform, installation, configuration settings
–
Infrastructure and security
–
Switch over plan from the existing system to the new system
–
Deployment plan
Includes implementation of a single round of
feedback from the client for correction of
accuracy.
Requires client approval.
14-Jul-17, 1:36 AM
Document1
Page 20 of 172



Technical design
document
Test plan and scripts
Content migration
plan
A low-level technical document produced by the solution architects that describes the
technical design of the backend of the LION system and that will be used by the
CMS developers to build the LION backend system
Will be submitted to client for approval.
A document describing the quality testing method and processes that will be
undertaken by Rufus Leonard and Endava and will include test scripts. The test
plan does not cover client UAT
Will be submitted to client for approval.
A document describing how content will be migrated from the existing system to the
new system and detailing automated migration tools and processes where
available
Will be submitted to client for approval.
Design deliverables

Design concepts
Two routes of design concepts applied to up to 3 key wireframes
Client selection of a single concept to be
developed in the interface design.

Interface design
Design layout of up to 10 templates, including a visual language for styles such as
fonts and colour palette
Includes implementation of two rounds of
feedback from the client.
Requires client approval.

Design assets
Production of design assets extracted from the approved interface design (e.g.
graphical elements such as buttons, imagery, etc/) for use by the development
team to build the user interface
Client approval not required as assets will be
extracted from approved interface designs.
Development deliverables

HTML and CSS
templates
Development of up to 10 HTML templates and associated CSS based on the
approved FSD, TSD and interface designs. Tested to the agreed accessibility
compliance level
Includes implementation of all defects
identified by the client (against approved
wireframes, approved TSD and approved
interface design) over a two-day period.
Requires client approval.

CMS and extranet site
development
Development of the CMS system and extranet site based on:
–
Approved PDD (requirements recorded in this document may be
superseded by the FSD, TSD and TDD)
–
FSD
–
TSD
–
TDD
–
HTML and CSS templates
Includes implementation of a single round of
client feedback during development prior to
UAT. Note, the review and feedback will be
based on preview of functionality (see project
plan).
Client approval on the functionality preview.

Content migration
Migration of existing site content to the new system, based on the content matrix and
content migration plan
Client approval not required until UAT.
14-Jul-17, 1:36 AM
Document1
Page 21 of 172
Testing and deployment deliverables

QA testing
Rufus Leonard quality testing of the completed LION extranet site against the FSD,
TSD and test plan and scripts, including interface, functionality, accessibility and
browser compatibility testing
Client approval not required.

UAT
Client user acceptance testing – on the staging environment – of the completed
CMS and LION extranet site against the following approved deliverables:
–
PDD (requirements recorded in this document may be superseded by the
FSD, TSD and TDD)
–
FSD
–
TSD
–
Interface designs
–
HTML and CSS templates
–
Content matrix
Includes implementation of fixes against
defects raised by the client using the online
issue-tracking system supplied by Rufus
Leonard/Endava.
Client UAT to be conducted on the entire
system in a single round over 8-day period.
Thereafter, client UAT of fixed defects over a
further 2-day period.
Client approval to launch is required at
culmination of the UAT task.
Provision of 3-day training course within the M25 for training of up to 3 CMS
administrators
Provision of training materials and CMS documentation covering instructions for
administering the extranet site and CMS
Provision of documentation specific to content owners covering instructions for
managing their content, subscribers, polls, surveys and ratings
Client participation only.

Training and
documentation

Deployment

Content population
support
3.2.3
Deployment of the approved CMS system and LION extranet to the production
environment
Provision for up to 37.5 hours over 10 consecutive days of developer support during
client population of the new system with edited and new content
At the completion of this task, client approval
to launch.
Lawyers database
Deliverable
Summary description
Budgeted iterations
A document defining:
–
Data model specification and entity relationship diagram
–
Report definitions for 5 reports (ad hoc report configuration will be covered
in the database training documentation)
Includes implementation of two rounds of
feedback from the client (one round for data
model specification and one round for DDD).
Requires client approval.
Technical documents

Database design
document
14-Jul-17, 1:36 AM
Document1
Page 22 of 172
–
–
–
–


Database solution
presentation
Data migration plan
Screen flow diagrams
Database architecture
MS Dynamics version and configuration
Security configuration
A presentation by the database designer of the proposed database solution and
highlighting any areas of concern (e.g. requirements that haven’t been taken into
consideration, requirements that have been misunderstood)
Requires client approval.
A document describing the Rufus Leonard and GLS tasks leading up to and including
the migration task, along with any associated post-migration tasks necessary to
migrate the data held in the existing system to the new system. This may include:
–
Requirement to clean data to remove duplicated and dead records (to be
undertaken by The GLS)
–
Requirement to export data in a format suitable for import into the
redeveloped database (export to be undertaken by The GLS)
–
Details on development an import script
Includes implementation of one round of
feedback from the client.
Requires client approval.
Build the database, functionality and reports per the approved database design and
specifications documentation. The database will be built to use the default MS
Dynamics user interface
Includes implementation of a single round of
client feedback on preview of functionality
during development.
Client approval required on preview of
functionality.
Development

Database
development

Data migration
Migrate data per the data migration plan and validate:
–
Export and cleaning of data from the existing system (to be undertaken by
The GLS)
–
Development of an import script (Rufus Leonard/Endava)
–
Import supplied data into the new system
–
Post-import validation
Client approval not required until UAT.

QA testing
Quality test the database system, including reporting, per the test plan
Client approval not required.
Training for The GLS administrators for the Lawyers database
A document covering database functionality for both administrators and editors,
including how to run ad hoc reporting queries against the database
Client participation only.
Client user acceptance testing – on the staging environment – of the new database
system against the following approved deliverables:
PDD (requirements recorded in this document may be superseded by the TSD and
Includes implementation of fixes against
defects raised by the client using the online
issue-tracking system supplied by Rufus


Training and
documentation
UAT
14-Jul-17, 1:36 AM
Document1
Page 23 of 172

Deployment
3.2.4
DDD)
TSD
DDD
Data migration plan
Leonard.
Client UAT to be conducted on the entire
system in a single round over 5-day period.
Thereafter, client UAT on fixed defects over a
further 2-day period.
Client approval to deploy is required.
Deploy the database system to the production environment
At the completion of this task, client approval
to launch is required.
Project management
Deliverable
Summary description
Budgeted iterations
Project management

Provide project
management services for
the duration of the project
Calculated as a percentage against each task, varying from 10 – 20% across the
different work streams
Role and responsibility details are defined in section6.2.4 of this document

Produce and update
project plan schedule
Including phase and delivery milestones

Produce and update
risk log
Risk log will be updated as required and transferred to the issue log as required

Produce and update
issue log
Issue log will be updated as required through the project lifecycle

Produce and update
status report
Weekly delivery and status call
Technical management

Provide technical
leadership services for
the duration of the project
Calculated as a percentage against each task
Governance

Provide account
governance
14-Jul-17, 1:36 AM
Calculated as a percentage against each task
Governance is provided by heads of discipline and ensure that work is conducted to
Document1
Page 24 of 172
best practice and standards
Account management

Provide account
management services for
the duration of the project
3.3
Calculated as a percentage against each task
LION extranet and Lawyers database setup and requirements capture fees
Requirement
Requirement
ID
Name
Description
Priority
Proposal fees
Re-
Variance
16/07/2010
quoted
19/07/2010
fees
Variance
RFP
description/note
reference
SET-001
Kick-off and
materials
review
Project kick-off with
stakeholders and materials
review
1
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
2,960
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
Some of the work
was covered by
the stakeholder
workshop
Deliverable
1 SOW,
page 57
SET-002
Requirements
Requirements capture
workshops to capture all
project requirements and
record them in a PRD
(project requirements
document)
1
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
11,600
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
This work has
been completed
and the output
(the PRD)
incorporated into
the PDD
None
SET-003
Scope of work
Project definition document
(PDD) detailing scope,
deliverables, requirements,
budget, schedule,
processes, roles and
responsibilities and
contractual information
1
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
4,440
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
A draft SOW
was produced to
the COI SOW
template. On
request, this was
merged with the
PRD, culminating
in the PDD
Deliverable
1 SOW,
page 57
[INFORMATION
£19,000
[INFORMATION
Sub-total
14-Jul-17, 1:36 AM
Document1
Page 25 of 172
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
3.4
Mandatory requirements and fees
3.4.1
LION Design refresh
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
LION is required to have a design refresh as part of this project. The design refresh is limited to the LION extranet end user interface.
Requirement
Requirement
ID
Name
Description
Priority
ML2-001
LION end user
interface
design refresh
Refresh the LION end user
interface design (layout and
styling), which may include –
but is not limited to – refresh
of the core components such
as colour palette, fonts, and
logo 1
The design refresh will
implement some of core
elements of the current
design in order to maintain
some consistency of the
LION identity 1
1
ML2-002
WCAG 2.0
compliance
The refreshed design will
observe WCAG 2.0 Level 2
accessibility standards
(Rufus Leonard
understanding the WCAG 2.0
guidelines will be detailed in
1
14-Jul-17, 1:36 AM
Proposal fees
Re-
16/07/2010
quoted
19/07/2010
fees
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
Document1
19,100
Variance
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
Variance
RFP
description/note
reference
ML2
Design,
pg 19
Page 26 of 172
the test plan)
ML2-003
Creative
concepts
Two creative concepts, applied
to 3 key wireframes, will be
presented to The GLS, one
of which will be selected for
development into template
design 1
1
ML2-004
Page
templates
The chosen design route will be
applied to the design of up to
10 key page templates 1
1
ML2-005
Design assets
Build assets will be created
from the approved designs
and handed off to the
development team for HTML
& CSS build 1
1
Sub-total
1 GLS
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
£19,100
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
‘brand identity’ guidelines (covering logo, look-and-feel, tone of voice, imagery) will be required as inputs for ML2-001. Development of a new brand
identity is not a deliverable for this project. The GLS will be responsible for updating the existing content owners guide(s) to reflect the new LION online
design. The design production files will be provided to The GLS in raw PSD format for The GLS to use to create any necessary guidelines documentation.
3.4.2
LION information architecture and taxonomy
Currently, the LION extranet site has 4-level hierarchical content structure with variable branch depth. The overall structure for levels 2 – 4 may be
retained in the new site but with a new IA presentation.
14-Jul-17, 1:36 AM
Document1
Page 27 of 172
Requirement
Requirement
ID
Name
Description
Priority
Proposal fees
Re-
16/07/2010
quoted
19/07/2010
fees
Variance
Variance
RFP
description/note
reference
ML1-001
Redesign the
information
architecture
Redesign the information
architecture across the
entire site to provide a
consistent, user-friendly,
uncluttered site with an
intuitive user experience.
1
ML1-002
Redesign
hierarchical
structure
Design a hierarchical site
structure to ensure that
important content is not
buried under third-level
menus. Where possible,
users should be able to
locate content within three
clicks
1
ML1-003
Redesign
home page
Redesign the home page to
ensure key content is more
accessible. Content that
should be accessible from
the home will be defined in
the information architecture
work stream and will include
the GLS networks area
amongst others
1
ML1
information
architecture,
pg 19
ML1-004
IA usability
and
accessibility
Implement COI guidelines
detailed on
http://usability.coi.gov.uk/ for
usability and accessibility
when designing the
information architecture to
the highest practical
implementation of W3C level
AA standards
1
ML1
information
architecture,
pg 19
ML1-005
IA longevity
Ensure the user experience
1
ML1
14-Jul-17, 1:36 AM
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
Document1
28,750
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
ML1
information
architecture,
pg 19
ML1
information
architecture,
pg 19
Page 28 of 172
can provide a medium to
long-term (3-5 year) platform
for online communication 2
2 Note: it is the responsibility of
The GLS to ensure that the
integrity of the approved
information architecture is
maintained after the site
launches and while site
structure and content is
managed by The GLS.
information
architecture,
pg 19
ML1-006
Modifiable
structure
The content hierarchy at root
level (e.g. new L1 sections
such as new legal topics)
must be modifiable through
the CMS without coding
changes or deletion of
content pages (i.e. LION
administrators to have the
ability to add/rename/delete
sections and sub-sections)
In particular, LION
administrators to have the
ability to add or delete
several items in level 2
section menus
A limit to the total number of
items per level 1 and 2 will
need to be defined in order
maintain the integrity of the
user interface from an IA
and design perspective
1
ML1
information
architecture,
pg 19
ML1-007
Menu Order
Content owners and LION
administrators will have the
ability to change the order of
items in sub-section menus
in the CMS without requiring
coding changes
1
ML1
information
architecture,
pg 19
14-Jul-17, 1:36 AM
Document1
Page 29 of 172
ML1-008
URL
The site is to be hosted on a
new fully qualified domain
root URL, e.g.
http://lion.gsi.gov.uk
Setup of the new domain will
be the responsibility of TSol
1
Sub-total
3.4.3
0
0
0
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
£28,750
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
New
LION technical specifications and documentation
Requirement
Requirement
ID
Name
Description
Priority
Proposal fees
Re-
16/07/2010
quoted
19/07/2010
fees
Variance
Variance
RFP reference
description/note
ML1-009
FSD
Functional specifications
and behaviours
document covering
LION end users only
1
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
13,465
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
Deliverable 6 –
Functional and
behaviours
specifications
document,
pg58
TDC-001
TSD
Technical specifications
document describing the
technologies and
environments of the
system.
It will include system
architecture overview
and diagrams and will
be updated, if
1
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
11,350
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
Technical
specifications
document, pg
58
14-Jul-17, 1:36 AM
Document1
Page 30 of 172
necessary, prior to the
final delivery and include
release notes and
exceptions if required.
The document will also
describe the general
installation, configuration
settings for SiteCore
CMS
TDC-002
TDD
Technical design
document covering lowlevel technical design
information on the
system. Will be used by
the CMS developers and
will form the basis of the
system documentation
on hand-over
1
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
22,593
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
This is an
additional
document
required by
Endava for use
by the CMS
development
team and covers
the specifications
not detailed in
the FSD and
TSD.
None
TDC-003
Security set up
and
documentation
Covers set up of system
security and
documentation of the
setup
1
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
1,940
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
Better
understanding of
the requirements
has reduced the
effort required.
Set up fit-forpurpose
security and
produce
related
documentation,
pg 59
TDC-004
Quality plan
and test scripts
A document describing the
quality testing method
and processes and
including test scripts
where appropriate
1
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
7,850
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
[INFORMATION
REDACTED
UNDER
SECTION 43
£57,198
[INFORMATION
REDACTED
UNDER
SECTION 43
Sub-total
14-Jul-17, 1:36 AM
Document1
Quality plan
and test
scripts, pg 64
Page 31 of 172
FREEDOM OF
INFORMATION
ACT]
3.4.4
FREEDOM OF
INFORMATION
ACT]
LION template build
Requirement
Requirement
ID
Name
Description
Priority
Proposal fees
Re-
Variance
16/07/2010
quoted
19/07/2010
fees
TMP-001
HTML & CSS
templates
Build and QA test up to 10
HTML templates and
associated CSS to agreed
accessibility and
compliance
1
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
18,550
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
TMP-002
CMS
templates
Incorporate tested HTML &
CSS into SiteCore to
create CMS templates
1
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
6,660
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
£25,210
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
Sub-total
14-Jul-17, 1:36 AM
Document1
Variance
RFP
description/note
reference
Deliverable
11 – Build
templates,
implement
coding and
functionality,
pg 63
Better
understanding of
the requirements
has increased the
estimated effort
required to build
the CMS
templates, this
equates to 14
days of CMS
template
development
Deliverable
11 – Build
templates,
implement
coding and
functionality,
pg 63
Page 32 of 172
3.4.5
LION content13
Requirement
Requirement
ID
Name
Description
Priority
Proposal fees
Re-
16/07/2010
quoted
19/07/2010
fees
Variance
Variance
RFP
description/note
reference
Covered by CMS
content templates
ML3
Content and
migration,
pg 19
ML3-001
LION pages
The site is required to contain all
content that is currently
available on LION – except as
agreed during the information
architecture work stream
where old or unused content
is identified and may not be
migrated
1
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
0
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
ML3-002
Linked content
The system will have the ability
to host text, attachments (MS
Word, Excel, PowerPoint,
PDF, etc.), images, audio and
video content 3
Streaming technology for audio
and video content is not
required
3 Note: it is assumed that the
volume of audio and video
content (Windows Media format
only) will be low and not exceed a
total of 100GB. The larger the file
size for each audio or video
content item, the poorer the user
experience in the absence of
streaming technology. All audio
and video files will be in Windows
Media Format and assumes
client-side presence of Windows
Media Player.
1
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
0
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
ML3
Content and
migration,
pg 19
ML3-003a
External
linking
The system will have the ability
to link to external systems
and link to internal sections
1
[INFORMATION
REDACTED
UNDER
0
[INFORMATION
REDACTED
UNDER
ML3
Content and
migration,
14-Jul-17, 1:36 AM
Document1
Page 33 of 172
and pages
SECTION 43
FREEDOM OF
INFORMATION
ACT]
SECTION 43
FREEDOM OF
INFORMATION
ACT]
pg 19
ML3-003b
External link
presentation
A standard look-and-feel
presentation, e.g. opens in
new tab or browser window,
will be used for all external
links
2
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
0
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
ML3
Content and
migration,
pg 19
ML3-004
Content
editing
Most of the pages on the site are
editorial pages and must be
editable through the CMS
System-generated elements will
not be editable via the CMS
content editing UI, such as
site map, feedback form, error
and validation messages,
global elements in the header
and footer
1
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
0
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
ML3
Content and
migration,
pg 19
ML3-005
Primary
language
The system will be designed to
accommodate English only
and the site will be published
in English only
1
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
0
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
ML3
Content and
migration,
pg 19
MC25-001
Content expiry
Content owners to have the
ability to set expiry
(unpublished) dates on
content
The system will notify content
owners by email that content
has expired
A single digest notification will
be sent to content owners
when multiple pages from a
1
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
0
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
14-Jul-17, 1:36 AM
Document1
Covered by CMS
generic
functionality
ML3
Content and
migration,
pg 19
Page 34 of 172
section expire on the same
day
MC25-002
Automated
archiving of
expired
content
Expired content will be archived
automatically by the system to
an archive folder
3
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
280
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
This is an
additional
requirement
New
ML3-007
Update
reminders
LION administrators can
manually set periodic system
reminders to content owners
to update content in their
sections (the period will be
defined in a business process
outside of the system)4
Content update reminders will
be sent in digest format
collating multiple reminders
for a day or week4
Content owners will have the
ability to manually set periodic
system reminders in addition
to those set by the LION
administrators4
Recipient email address for
reminders can be set on an
ad hoc basis. (This will be
used for requesting updates
to items such as org charts)
4 Note: these reminders will not
be linked to content items, i.e.
reminder will consist of date, title,
message content, recipient email
address
2
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
0
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
Covered by CMS
generic
functionality
MC25
Notification
and expired
dates, pg 53
14-Jul-17, 1:36 AM
Document1
Page 35 of 172
ML3-008
Print this page
The system should provide a
“Print this page” link on every
page as default, linking to a
printable view of the page
(e.g. without navigation,
header and footer)
Content owners to have the
ability to disable this on
specific pages they own
2
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
185
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
Additional
requirement not
stated in the RFP
New
ML3-009
Help pages
A help section will be created
(the current section will not be
migrated) and may be moved
in the content hierarchy
depending on the IA
Help content requires re-writing
by The GLS
1
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
0
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
Covered by CMS
content templates
ML3
Content and
migration,
pg 19
ML3-010
Document list
control
The system will provide an
embeddable document list
control that will:
–
Allow content owners
to upload documents,
appending to each
document an optional
date/time property and free
text keywords
–
Allow end users to
filter documents on a page
that are linked to the control
by date/time or keyword 5
While the basic functionality
(ability to append the above
properties to documents and
to filter the document lists by
these properties) will replicate
the functionality of the existing
document list control, the user
experience (both for content
owners and end users) will be
improved
3
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
370
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
14-Jul-17, 1:36 AM
Document1
Page 36 of 172
5
Note: the proposed filtering by
keyword functionality will be
based on the metadata (as
specified by content owners on
upload of documents) of the
associated documents, the
filtering will only be as accurate
as the metadata content
ML1-012
Page specific
help
Existing page-specific help to be
available on relevant pages,
through a standardised “help
text” presentation
Contextual help text can be
defined in the IA process but
copywriting will be the
responsibility of The GLS
2
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
370
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
Additional cost
covers option
contextual help
New
ML1-013
Home page
The home page will include –
but not be limited to – the
following mandatory items:
–
News highlights
–
Banner/s
–
Link to the
amalgamated calendar
–
Links to subscription
services (e.g. Lexis Nexis,
Lawtel, Justis)
–
Links to the GLS
network pages
Other mandatory content to be
defined during information
architecture work stream
1
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
0
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
Covered by CMS
content templates
ML1
information
architecture,
pg 19
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
£1,205
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
Sub-total
14-Jul-17, 1:36 AM
Document1
Page 37 of 172
4 System
reminders that can be set by content owners to remind them of content expiry will not be linked to content items, i.e. the reminder will consist of
user-specified date, title, message content and recipient email address.
13 The
GLS will define the business- and legal-specific keywords, categories and terms that will be used by the search appliance and for tagging content
3.4.6
LION content migration
Requirement
Requirement
ID
Name
Description
Priority
Proposal fees
Re-
Variance
16/07/2010
quoted
19/07/2010
fees
Variance
RFP
description/note
reference
ML3-013
Content
migration plan
A content migration plan will
be produced, including a
content matrix
1
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
9,280
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
On-site review of
the LION extranet
has provided a
clearer indication
of the extent of
migration
planning required
to fit existing
structure into the
new structure.
The additional
cost pertains to
the content
matrix, which will
aid migration
tasks.
Deliverable14
Content
migration
plan, pg 59
ML3-014
Content
migration
Existing LION content to be
migrated to the new
system. The content
comprises HTML copy and
images and attachments
(DOC, XLS, PPT, PDF,
WMV, WMA)
The HTML content does not
exist in separate document
1
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
6,835
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
On-site review of
the LION extranet
has provided a
clearer indication
of the amount of
content to be
migrated.
ML3 Content
and
migration, pg
19
14-Jul-17, 1:36 AM
Document1
Page 38 of 172
format
Where possible, migration will
be automated. Restrictions
may apply and will be
detailed in the migration
plan.6
ML3-015
Support during
content upload
Rufus Leonard will provide
support to The GLS during
GLS upload of new and
edited content. The support
covers 37.5 hours of
resource over 10 days
1
Sub-total
6
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
1,110
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
£17,225
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
Support will be
provided by junior
CMS developer
rather than a
senior CMS
developer.
ML3 Content
and
migration, pg
19
The GLS will grant Rufus Leonard read access via secure VPN to the existing live LION installation in order to review and assess the system to plan
content migration.
Rufus Leonard will identify suitable software tools to facilitate automated extraction of content (in a format suitable for import into the redeveloped LION
system) from the existing system.
It is the responsibility of The GLS to install and test these software tools, ready for content extraction. Rufus Leonard will extract the content.
Alternatively, the extraction of content in a format suitable for import into the redeveloped LION system will be performed by The GLS and the extracted
content provided to Rufus Leonard to schedule.
Cleaning of existing data (removing unused, corrupt and duplicate data) is the responsibility of The GLS and will be undertaken prior to the content
extraction task.
14-Jul-17, 1:36 AM
Document1
Page 39 of 172
The GLS will be required to define the metadata for all existing content that will be migrated to the redeveloped system and tag the migrated content once
migration is complete.
3.4.7
LION notification of content changes31 and 32
Requirement
Requirement
ID
Name
Description
Priority
ML4.1-001
Content
notification
End users will be able to
subscribe to content updates
for:
–
Legal topic
–
Category (L1
categories)
–
News items
–
Home page
Updates will be sent as plain
text emails
1
ML4.1-009
My
subscribers –
per page
management
Content owners will have the
ability to review and manage
subscribers to their content
on a per page basis
(managing subscribes on a
per section basis has been
excluded to reduce budget for
this requirement)
1
ML4.1-003
My
notifications
End users will be able to
manage their notifications as
follows:
–
Delete notification
subscription
–
Edit notification
frequency
1
14-Jul-17, 1:36 AM
Proposal fees
Re-
16/07/2010
quoted
19/07/2010
fees
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
Document1
Variance
4,275
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
Variance
RFP
description/note
reference
ML4.1
Subscription
to content,
pg 20
Page 40 of 172
This will be secured by login
ML4.1-010
My
subscribers –
per user
Content owners will have the
ability to review and manage
individual subscribers based
on email address, i.e. the end
user will be removed from all
subscriptions to content
owned by that content owner
1
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
370
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
This is an
additional
requirement
New
ML4.1-002
Notification
update
frequency
End users will be able to select
notification frequency:
–
Daily digest (this will
be the default setting)
–
Weekly digest
1
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
550
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
This is an
additional
requirement
New
ML4.1-004
Suppress
notifications
Content owners will have the
ability to suppress content
update notifications on
individual content items. This
is to ensure that notifications
are not sent for minor
updates
2
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
220
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
This is an
additional
requirement
New
ML4.1-005
From email
Notifications will be sent from a
single central (GLS) email
address that can be
monitored for bouncebacks 31
2
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
2,725
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
This is an
additional
requirement
New
and 32
ML4.1-006
14-Jul-17, 1:36 AM
Automated
update of
notification list
When an end user record is
removed from the contacts
directory, or the GLS
Secretariat marks a person
as a ‘leaver’ in the Lawyers
database, the email
notification list will be
automatically updated
2
Document1
New
Page 41 of 172
ML4.1-007
Removal of
bounced email
addresses
from
notification list
When a bounce back is
received from an email
address, that email address
will be removed from the
notification list manually by
the administrator7
7 Note: quoted costs do not cover
provision of automated removal
of bounced email addresses from
notification lists (reference
ML4.1-005 in PRD v1.0)
3
New
Sub-total
31 Provision
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
£8,140
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
of SMTP server: to comply with GSi standards, the redeveloped LION extranet and Lawyers database systems must use an existing SMTP
server on the GSi (possibly with authentication) for sending outbound email. The GLS will provide access and authentication information to this server
prior to the start of production of the DDD (database design document).
32 In
order to meet GSi standards, it is assumed that TSol will provide a white-listed email address in the format [email protected] that will be
used to send emails out from the system.
3.4.8
LION last updated/reviewed content
Requirement
Requirement
ID
Name
14-Jul-17, 1:36 AM
Description
Priority
Proposal fees
Re-
16/07/2010
quoted
19/07/2010
fees
Document1
Variance
Variance
RFP
description/note
reference
Page 42 of 172
ML4.2-001
Last
updated/reviewed
display
Each content page will display
the date on which it was last
updated or reviewed
1
Sub-total
3.4.9
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
740
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
£740
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
CMS
configuration
only, does not
require
customisation
ML4.2
Date
updated,
pg 20
LION rate this page and comment on page
Requirement
Requirement
ID
Name
ML4.3-001
14-Jul-17, 1:36 AM
Rate this page
Description
 End users will have the ability
to rate pages on a 1-5 star
scale
Rating will be limited to one
rating per page/item per
user session
A page or item’s rating will be
visible only to the content
owner
Rate this page functionality
will be turned on by default
– content owners will not
have the ability to turn this
off
Priority
1
Proposal fees
Re-
16/07/2010
quoted
19/07/2010
fees
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
Document1
2,220
Variance
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
Variance
RFP
description/note
reference
Additional fees
cover limiting one
rating per session
and hiding the
rating from all but
the content
owner
ML4.3
Rate this
page, pg
20
MC33
Supported
feature, pg
54
Page 43 of 172
OL3.1-001
Comment on page
End users will have the ability
to comment on a page
using a free text field
Ends users will need to be
authenticated in order to
comment on content
Comments will be visible only
to the content owner
1
ML4.3-003
Ratings and
comments report
Content owners and LION
administrators will be able
to generate a report of the
ratings and comments on
their pages, This will show:
–
Total ratings count
–
Average ratings
–
Total numbers of
comments
–
Drilldown into
ratings and comments for
any page
1
ML4.3-006
Global Ratings
report
Content owners will be able to
generate a report showing
ratings across all pages,
broken down by:
–
Content area (to be
defined)
–
Content owner (to
be defined)
2
New
ML4.3-005
Ratings/comments
versioning
Ratings/comments will be
held and displayed for the
current and one previous
version of each page
2
New
OL3.1
Comments,
pg 28
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
Sub-total
14-Jul-17, 1:36 AM
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
Document1
1,110
£3,330
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
This is an
additional
requirement
New
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
Page 44 of 172
INFORMATION
ACT]
3.4.10
INFORMATION
ACT]
LION surveys and polls
Requirement
ID
Requirement
Name
Description
ML4.4-001
Polls
LION Administrators will have the
ability to embed polls on the
home page on behalf of content
owners. The poll results will be
displayed on the home page in
real time on which the poll is
embedded, unless overridden by
the LION administrator
Polls results to show results
graphically, for example:
–
Total number of votes
–
Total number of X votes
(either as a percentage of the
total or as a graph)
–
Total number of Y votes
(either as a percentage of the
total or as a graph)
1
ML4.4-002
Surveys
Content owners will have the ability
to implement surveys on a page
Surveys will take the form of a
questionnaire, with single flow
(i.e. surveys will not use decision
trees). Login will not be required
for end users to respond by
default but can be required by
the content owner
Only content owners and GLS
Secretariat will be able to see
1
14-Jul-17, 1:36 AM
Priority
Proposal fees
16/07/2010
19/07/2010
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
Requoted
fees
Variance
4,180
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
Variance
description/note
RFP
reference
Better
understanding of
the detailed
requirements
means more
accurate
estimation.
ML4.4
Surveys
and polls,
pg 20
MC27
Supported
feature,
pg 53
ML4.4
Surveys
and polls,
pg 20
MC27
Supported
feature,
pg 53
Document1
Page 45 of 172
survey results and may manually
process them for on-site reporting
ML4.4-002a
Survey
Questions
Survey questions types will include:
–
Yes/No
–
Multiple choice
(single/multi-select)
–
Free text
–
Rating 1-5
1
ML4.4
Surveys
and polls,
pg 20
ML4.4-003
Single Entry
Surveys and Polls will be restricted
to allow only a single “entry” per
browser session (if cookies are
disabled this may not be
enforceable).
1
ML4.4
Surveys
and polls,
pg 20
ML4.4-004
Survey and
poll archiving
Content owners will have the ability
to archive surveys and polls
results and view archived surveys
and polls
1
ML4.4
Surveys
and polls,
pg 20
ML4.4-005
Survey and
poll download
Polls and surveys raw data can be
downloaded in CSV format (from
CMS admin UI) for offline analysis
and publishing
1
ML4.4
Surveys
and polls,
pg 20
Sub-total
3.4.11
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
£4,180
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
LION news facility
14-Jul-17, 1:36 AM
Document1
Page 46 of 172
Requirement
Requirement
ID
Name
Description
Priority
Proposal fees
Re-
Variance
16/07/2010
quoted
19/07/2010
fees
Variance
RFP
description/note
reference
Better
understanding of
the detailed
requirements
means more
accurate
estimation.
ML4.5
News, pg
21
ML4.5-001
News display
The news page will list news
items displayed in date order
(most recent first) and then by
content section/area
LION administrators will have the
ability to publish news items to
the home page and specify an
expiry date, after which the
item will no longer display on
the home page
1
ML4.5-002
News
highlights
The system will highlight news
items by ‘Most Read’ or other
mechanism to be defined
during the information
architecture work stream (a
‘news ticker/scroller’ is not
specifically required. However,
the requirement for highlighting
key news items in a userfriendly and prominent manner
on the home page will be met
in another way and will be
defined during the information
architecture work stream)
1
ML4.5
News, pg
21
ML4.5-003
News
subscription
End users will be able to
subscribe to receive alerts31 and
32 for news items for specific
content areas/law topics. See
ML4.1-001 for details
1
ML4.5
News, pg
21
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
Sub-total
14-Jul-17, 1:36 AM
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
Document1
2,960
£2,960
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
Page 47 of 172
INFORMATION
ACT]
31 Provision
INFORMATION
ACT]
of SMTP server: to comply with GSi standards, the redeveloped LION extranet and Lawyers database systems must use an existing SMTP
server on the GSi (possibly with authentication) for sending outbound email. The GLS will provide access and authentication information to this server
prior to the start of production of the DDD (database design document).
32 In
order to meet GSi standards, it is assumed that TSol will provide a white-listed email address in the format [email protected] that will be
used to send emails out from the system.
3.4.12
LION calendars
Requirement
Requirement
ID
Name
ML4.6-001
14-Jul-17, 1:36 AM
Embeddable
calendars
Description
Content owners will have the
ability to embed calendars
on pages within their
content areas. Calendar
events will be managed by
content owners who will
have C/R/U/D* permissions
for their calendars
Calendar events properties 8:
–
Title
–
Type, e.g. seminar,
training, meeting, etc.
–
Description (brief
description with a
character limit)
–
Embedded URL
Priority
1
Proposal fees
Re-
16/07/2010
quoted
19/07/2010
fees
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
Document1
3,700
Variance
[INFORMATION
REDACTED UNDER
SECTION 43
FREEDOM OF
INFORMATION ACT]
Variance
RFP
description/note
reference
Better
understanding of
requirements
means less effort
is required to
build this
functionality than
originally
proposed.
ML4.6
Calendar,
pg 21
Page 48 of 172
(internal or external)
Event type (e.g.
training, seminar, court
date, etc.)
–
Start date and time
–
End date and time
–
Contact email
address
–
File association (e.g.
an agenda)
–
Meta tags (for
search)
8 Note: The GLS will provide
the full list of calendar event
properties to Rufus Leonard
prior to the start of the
wireframing task
–
ML4.6-003
14-Jul-17, 1:36 AM
Amalgamated
calendar
All calendar events (except
events from calendars in
secure content areas) will
appear on an amalgamated
calendar that will be
accessible from the home
page
Users will be able to filter 9 the
amalgamated calendar
events by:
–
Content section
area, e.g. Pro Bono
Network, Employment law
legal topic or GLS training
–
Type, e.g. seminar,
training, meeting, etc.
–
Year
–
Month
–
Date (dd/mm/yy)
9 Note: The GLS will provide
the full list of filter parameters
1
ML4.6
Calendar,
pg 21
Document1
Page 49 of 172
to Rufus Leonard prior to the
start of the wireframing task
ML4.6-004
Expired
events
Events with a date property
older than one year prior
the current day will be
hidden from the published
individual and the
amalgamated calendars
Expired events will remain
visible to content owners
within the CMS admin user
interface. There is no
separate archiving
3
ML4.6-002
News item
calendar
event
Content owners, when
creating a calendar event
that is also a news item, will
need a single point of data
entry that will then publish
the item to both the news
section (and home page
scroller or other) and to a
calendar.
3
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
870
[INFORMATION
REDACTED UNDER
SECTION 43
FREEDOM OF
INFORMATION ACT]
Additional
requirement.
New
ML4.6-005
Calendar
search
There will not be a separate
calendar-specific search
function; however, they will
be searchable through the
main site search
functionality
Calendar event information
will appear in site search
results based on date/time,
text content and meta tag
information (meta tags to be
defined)
3
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
370
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
Additional
requirement to
integrate the
calendar object
content with the
GSA search.
New
[INFORMATION
REDACTED
UNDER
SECTION 43
£4,940
[INFORMATION
REDACTED UNDER
SECTION 43
FREEDOM OF
Sub-total
14-Jul-17, 1:36 AM
ML4.6
Calendar,
pg 21
Document1
Page 50 of 172
FREEDOM OF
INFORMATION
ACT]
INFORMATION
ACT]
* C/R/U/D stands for: create, read, update and delete
3.4.13
LION training section
Requirement ML4.7 is defined in the RFP as a link to the GLS training microsite hosted on the National School of Government’s main website. This
requirement definition is now superseded by the requirements listed below:
Requirement
Requirement
ID
Name
Description
Priority
Proposal fees
Re-
16/07/2010
quoted
19/07/2010
fees
Variance
ML4.7-001
Training
courses
section
A training courses section will be
created as a level 1 content
section in LION
2
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
0
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
ML4.7-002
Courses –
legal areas
The training courses section will
contain a sub-section (at level
2) for each area within LION
for which training is available,
e.g. admin law, employment,
prosecutors, EU, etc.
2
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
0
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
14-Jul-17, 1:36 AM
Document1
Variance
RFP
description/note
reference
Standard content
templates
New
New
Page 51 of 172
ML4.7-003
Training
calendars
Each training section will contain
a calendar of training events
(re-using the calendar
functionality defined in ML4.6001 to ML4.6-005 of this
document) with the following
proposed visible event
properties 10:
–
Title
–
Description (brief
description with a character
limit)
–
Start date and time
–
End date and time
–
Venue
–
Location
–
Cost
–
Embedded url (this
could link to another page
on the site or to news item)
And the following hidden
properties (required for full
content indexing):
–
Event type (e.g.
training, seminar, etc.)
–
Meta tags (for search)
10 Note: The GLS will provide the
full list of training calendar event
properties to Rufus Leonard prior
to the start of the wireframing task
2
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
0
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
Re-use calendar
functionality of
ML4.6
New
ML4.7-004
Course details
The course details page will use
a standard content template
and will contain full course
details in standard text format,
including a link to the training
providers page
A course item may not
necessarily have its own
2
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
0
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
Standard content
templates
New
14-Jul-17, 1:36 AM
Document1
Page 52 of 172
content page but be a news
item
ML4.7-005
Training
providers
 A training providers page will be
created at the root level within
the training courses section,
comprising:
–
Course provider name
–
Course provider contact
details
–
Course provider
description
2
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
0
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
ML4.7-006
Section
calendar
The training courses landing
page (section root page) will
contain a calendar (re-using
the calendar functionality
defined in ML4.6-001 to
ML4.6-005) for ad hoc one-off
events such as lectures and
talks (see ML4.7-003 for event
properties)
3
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
0
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
ML4.7-007
Update
access
Content for this section will be
managed by the LION
administrators and GLS
Secretariat editors
2
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
0
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
ML4.7-008a
Flat event
listing
Training calendar events should
also have the ability to be
viewed as a flat listing on the
page on which the calendar is
published
1
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
220
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
Providing a flat
listing of the
events ensure
that users with
JavaScript
disabled will be
able to view the
calendar events.
Guidelines
for UK
government
websites,
pg 7
ML4.7-008b
Flat event
listing display
option
Users will be able display event
flat listings by:
1
[INFORMATION
REDACTED
UNDER
370
[INFORMATION
REDACTED
UNDER
Additional
requirement.
New
14-Jul-17, 1:36 AM
Document1
New
Re-use calendar
functionality of
ML4.6
New
New
Page 53 of 172
–
–
Date
Area of law (applicable
only to ML4.7-006. This
does not apply to ML4.7-003
as each training calendar
specified in ML4.7-003 will
only contain events specific
to that section, e.g. a
specific area of law)
SECTION 43
FREEDOM OF
INFORMATION
ACT]
Sub-total
3.4.14
SECTION 43
FREEDOM OF
INFORMATION
ACT]
£590
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
LION subscription services links
Requirement
Requirement
ID
Name
ML4.8-001
Subscription
services links
Description
The system will support links to
the existing subscription
services (e.g. Lexis Nexis,
Lawtel, Justis), from the
home page and the online
library
These will be direct links to fixed
URLs with no ‘hidden login’
functionality
Priority
1
Sub-total
14-Jul-17, 1:36 AM
Proposal fees
Re-
Variance
16/07/2010
quoted
19/07/2010
fees
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
225
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
[INFORMATION
REDACTED
UNDER
SECTION 43
£225
+£225
Document1
Variance
RFP
description/note
reference
Moved from
OL3.2. Once the
functionality and
styling has been
put in place, this
can be re-used
without incurring
additional fees
ML4.8
Links to
subscription
services, pg
21
Page 54 of 172
FREEDOM OF
INFORMATION
ACT]
3.4.15
LION site search
GSA (Google Search Appliance) will deliver the search results that the user will require. However, it does not specifically meet all the detail requirements
set out in the RFP. If The GLS is not satisfied with the stand alone GSA solution it can be enhanced with Lucene that, in combination with GSA, will cover
all specific requirements. The Lucene search engine is an open source search that is an integral part of the SiteCore CMS. Lucene will be leveraged to
provide search results only for specific requirements (see ML4.9-002 in the table below) where these cannot be provided by GSA.
Requirement
Requirement
ID
Name
ML4.9-001
14-Jul-17, 1:36 AM
Site search
Description
The system will provide keyword
(end user-defined parameter)
search facility, across all site
pages (including body text,
headings and metadata) and
with the ability to perform full
text searches of attached
documents
The search function will search
calendars, news items, content
pages and the contacts
directory 11
The search function will also
match against defined
document metadata 13
The search will be conducted
against the entire site or
separate collections
The advanced search form for the
search function will be defined
Priority
1
Proposal fees
Re-
16/07/2010
quoted
19/07/2010
fees
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
Document1
18,150
Variance
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
Variance
RFP
description/note
reference
We have a better
understanding of
the integration of
SiteCore with
GSA API and can
provide a more
accurate
estimation.
ML4.9
Search,
pg 21, 22
Page 55 of 172
during the information
architecture work stream, at
which time a decision will be
made if separate search form
will be used for the contacts
directory search or a combined
form used for both the contacts
directory and LION site
11 Note: the search function will not
search the Lawyers database
ML4.9-002
Search
options
Search options using GSA
(primary search) will include12:
–
Natural
language/Boolean constructs
–
Misspelling correction
–
Autosuggest
–
Quoted strings, e.g.
single characters, whole word
(“Baby P” etc.)
–
Constrain by site section
–
Constrain by last
updated date
–
Faceted search
Search options using Lucene will
include12:
–
Wild cards
–
Meta characters
(including non-alphanumeric
characters)
–
Case sensitive search
1
ML4.9
Search,
pg 21, 22
ML4.9-003
Search results
Search results will 12:
–
Be ordered by relevance
or date
–
Highlight search
parameters (including those
found within attached
documents), showing 2-3
1
ML4.9
Search,
pg 21, 22
14-Jul-17, 1:36 AM
Document1
Page 56 of 172
–
ML4.9-004
Directory
search
lines of abstract text
Show a few lines of text
from the page that are
relevant to the search
parameters to allow the end
user to judge if this is the
correct page
Users will be able to select if the
search will include results from
the contacts directory
Contacts directory results will be
matched by name and expertise
fields
See associated requirement
ML4.11-002
2
ML4.9
Search,
pg 21, 22
Sub-total
12 Assumptions
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
£18,150
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
applicable to implementing requirement ML4.9:
 Synonyms will be used to facilitate the single character search. These will require periodic maintenance by the LION administrators to manage the
word lists and how they are converted in to search terms (maintenance will only be required if the synonyms need to be updated)
 Meta characters are ignored in GSA but may still return the expected results,(e.g. if a user searches for “A1-BN00” and the system contains separate
documents titled “A1-BN00” and “A1BN00”, both documents will be returned in the results). This can only be determined by testing the search with the
real data. Similarly, wildcards aren’t supported by GSA, however, the logic behind GSA may also return the correct results due to the intelligent nature
on how the search engine works
 Google Snippets (extensions to the default appliance configuration) will be used to provide search facets based on metadata criteria such as section,
author, etc.
14-Jul-17, 1:36 AM
Document1
Page 57 of 172
 The Lucene search engine is closely integrated with Sitecore and is leveraged to not only provide a search engine but is also used to provide live
content to sections of a website, such as home or landing pages. As a result, Lucene can be leveraged without the additional overhead of installing a
separate search engine
 Both search engines will not be used on every search, only the appropriate search engine would be leveraged depending on either the search string
entered or the option selected in the advanced search form
 Help information on the search pages should have enough information to clearly explain to the users when each of the search engines will be used
and why there may be inconsistencies in the results returned
 For efficiency and result accuracy, we recommend using GSA over Lucene whenever possible. It will be possible to switch off the Lucene search
functionality at any time without impacting the GSA search functionality
 The search will be configured to search only the LION extranet and not any external websites
13 The
GLS will define the business- and legal-specific keywords, categories and terms that will be used by the search appliance and for tagging content
3.4.16
LION post and publish agendas and minutes
Requirement
Requirement
ID
Name
ML4.10
Post and
publish
agendas and
minutes
Description
The system will support the ability
to publish agendas and
meeting minutes, in addition to
regular text, attachments,
audio or video content.
Priority
1
Sub-total
14-Jul-17, 1:36 AM
Proposal fees
Re-
Variance
16/07/2010
quoted
19/07/2010
fees
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
0
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
[INFORMATION
REDACTED
£0
[INFORMATION
REDACTED
Document1
Variance
RFP
description/note
reference
This is a standard
content item and
will not need
additional
functionality
ML4.10
Post and
publish
agendas
and
minutes
feature,
pg 22
Page 58 of 172
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
3.4.17
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
LION contacts directory
Requirement
Requirement
ID
Name
Description
Priority
ML4.11-001
Contacts
directory
The system will include a dynamic
contacts directory section
containing lawyer profiles
showing data such as name,
department, address, telephone
numbers, grade, areas of
responsibility etc.
The data for the contacts directory
will be published out from the
Lawyers database
The full data model will be defined
in the data model specifications
document
All information in the contacts
directory will be accessible by
all LION users
1
ML4.11-003
Directory data
The directory will be populated
with a sub-set of data from the
corresponding Lawyers
database record (the Lawyers
database will hold the master
data set that will be used to
publish the profile sub-set to the
contacts directory)
The schedule for publishing
1
14-Jul-17, 1:36 AM
Proposal fees
Re-
16/07/2010
quoted
19/07/2010
fees
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
Variance
6,290
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
Variance
RFP
description/note
reference
Better
understanding of
the detailed
requirements
means more
accurate
estimation.
Covers
authentication
integration with
SiteCore and
integration with
GSA API.
ML4.11
Contacts
directory,
pg 23, 24
ML4.11
Contacts
directory,
pg 23
Document1
Page 59 of 172
updates to the contacts
directory is still to be defined
but will be a regular scheduled
event
ML4.11-005
Directory links
The system will provide an
embeddable widget or other
device to enable content
authors to dynamically link
contact details on a page to a
specified directory entry
1
ML4.11-004a
Directory
updates
Lawyers will be able to update
their own contacts directory
profile via a web form
Lawyers will need to be
authenticated in order to
perform the update
The update request may need to
be validated
The proposed processes for
updates are as follows but will
be finalised during the design
stage of the project:
–
Lawyer (GLS/non-GLS)
edits their profile data via a
web form on the LION
extranet – during this
process, database lookup
fields will be made available
to the LION web form
–
For automatically
updated data requiring no
admin approval: on submit,
an email31 and 32 will be sent to
the lawyer to confirm a
change has been made. The
email will contain a single-use
link, which, when clicked, will
update the record in the
database and the update
1
14-Jul-17, 1:36 AM
ML4.11
Contacts
directory,
pg 24
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
Document1
1,110
ML4.11
Contacts
directory,
pg 24
Page 60 of 172
published to the LION
contacts directory
–
For data changes
requiring admin approval: on
submit, an email31 and 32 will
be sent to the database
administrator for manual
validation and integrity check
(key changes such as email
address, grade, role, etc. will
be flagged as high priority).
On approval, the database
record update is saved and
the update published to the
contacts directory. An email
is sent to the lawyer to
confirm a change has been
made
ML4.11-002
14-Jul-17, 1:36 AM
Directory
search
The directory will be searchable
by 14:
–
Name
–
Department
–
Grade (includes Legal
Trainee)
–
Area of
Responsibility/Law
–
Any combination of
above
–
General search which
allows search on all fields
The need for a separate search
form for the contacts directory
will be defined during the
information architecture work
stream (see ML4.9-001)
1
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
Document1
740
ML4.11
Contacts
directory,
pg 24
Page 61 of 172
ML4.11-004b
Directory
lookups
The ‘request new’ and ‘request
update’ web forms field values
will be driven from the Lawyers
database
14 Note: some of the lookups, e.g.
‘department’, will require a free text
override option, details of which will
be defined in the data model
specification document produced
for the Lawyers database
Note: details on fields and
validation will be defined in the
data model specification document
produced for the Lawyers database
2
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
0
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
ML4.11-006a
Contacts
directory
editors (LUS006)
LION administrators will have the
ability to create contacts
directory editors. An editor will
be associated with a
department in the contacts
directory
2
3,330
ML4.11-006b
Contacts
directory
editor edit
profile
Contacts directory editors will
need to authenticate in order to
perform edits to lawyer profiles
in the contacts directory
Editors will have the ability to edit
all lawyer profiles associated
with their department only
LION administrator approval is not
required for some edits
performed by editors (see LUS002 for full details)
Bulk updates will not be required
2
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
14-Jul-17, 1:36 AM
Document1
New
Additional
requirement.
New
New
Page 62 of 172
ML4.11-006c
Contacts
directory
editor
add/delete
profile
Editors will need to authenticate in
order to add or delete lawyer
profiles in the contacts directory
Editors will have the ability to add
or delete profiles for lawyers
associated with their
department only
LION administrator approval is
required for additions and
deletions performed by editors
Bulk additions and deletions will
not be required
2
New
Sub-total
31 Provision
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
£11,470
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
of SMTP server: to comply with GSi standards, the redeveloped LION extranet and Lawyers database systems must use an existing SMTP
server on the GSi (possibly with authentication) for sending outbound email. The GLS will provide access and authentication information to this server
prior to the start of production of the DDD (database design document).
32 In
order to meet GSi standards, it is assumed that TSol will provide a white-listed email address in the format [email protected] that will be
used to send emails out from the system.
3.4.18
LION site map
Requirement
Requirement
ID
Name
14-Jul-17, 1:36 AM
Description
Priority
Proposal fees
Re-
16/07/2010
quoted
19/07/2010
fees
Document1
Variance
Variance
RFP
description/note
reference
Page 63 of 172
ML4.12-001
Site map
The system will automatically
generate a human-readable
site map that will be published
on a single page on the site
The site map will be dynamically
generated or updated at least
hourly
1
Sub-total
3.4.19
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
0
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
£0
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
SiteCore out of
the box
functionality
ML4.12
Site map,
pg 24
Variance
RFP
description/note
reference
Better
understanding of
the detailed
requirements
means more
accurate
estimation.
ML4.13
Feedback
form, pg
24
LION feedback form
Requirement
Requirement
ID
Name
ML4.13-001
14-Jul-17, 1:36 AM
Feedback form
Description
The system will provide a central
static feedback form (fields
TBC) to allow users to submit
feedback to LION
administrators
When a user submits
feedback, the system will send
an automated 'thank you' email
to the user
An email31 will be generated to
LION administrators (email
address to be defined32) and a
confirmation email sent to the
user – format and content of
both emails to be defined
Priority
1
Proposal fees
Re-
16/07/2010
quoted
19/07/2010
fees
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
Document1
Variance
370
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
Page 64 of 172
Feedback will be archived
Sub-total
31 Provision
£370
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
of SMTP server: to comply with GSi standards, the redeveloped LION extranet and Lawyers database systems must use an existing SMTP
server on the GSi (possibly with authentication) for sending outbound email. The GLS will provide access and authentication information to this server
prior to the start of production of the DDD (database design document).
32 In
order to meet GSi standards, it is assumed that TSol will provide a white-listed email address in the format [email protected] that will be
used to send emails out from the system.
3.4.20
LION web statistics
Requirement
Requirement
ID
Name
ML4.14-001
14-Jul-17, 1:36 AM
Web stats
Description
The system will provide statistics on
page views within the site, down to
page level and may include:
–
Total visits within a date
range
–
Total unique visits within a
date range
Priority
Proposal fees
Re-
16/07/2010
quoted
19/07/2010
fees
1
Document1
1,800
Variance
2,590
+790
Variance
RFP
description/note
reference
Better
understanding of
the detailed
requirements
means more
accurate
estimation.
ML4.14
Site
statistics,
pg 24
Page 65 of 172
–
Total page view within a date
range
–
Average page views per visit
within a date range
–
Number of pages viewed per
visit within a date range
–
Average time on site per visit
within a date range
Stats will be in displayed in both tabular
form (tables) and time graphed form
(graphs showing dates on the X axis
and numbers on the Y axis), and
available to content owners and
LION administrators
No usage data will be sent off site
No identifiable personal usage data will
be recorded
Sub-total
3.4.21
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
£2,590
+£790
LION user authentication
Requirement
Requirement
ID
Name
14-Jul-17, 1:36 AM
Description
Priority
Proposal fees
Re-
16/07/2010
quoted
19/07/2010
fees
Document1
Variance
Variance
RFP
description/note
reference
Page 66 of 172
AUTH-001
AUTH-002
14-Jul-17, 1:36 AM
User accounts
User login
Users with a contacts directory
profile will be able to create a
user account for the LION
site
The account credentials will be
used across all areas of the
site requiring user
authentication
Account creation will follow an
automated validation process
(probably email address
validation) and will require no
input from the LION
administrators, thus
–
User names and
passwords should be
issued automatically
–
Password changes
and password reminders31
and 32
will be requested by
the user online and
automatically reissued by
the system (using
automated validation)
New users will be prompted to
set up a LION user account
at the same time as setting
up a contacts directory profile
(the benefits of a LION user
account will be
communicated to users at
this point to encourage signup)
1
The account credentials will be
used across all areas of the
site requiring authentication
1
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
0
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
ML4.1
Subscription
to content,
pg 20
ML4.11
Contacts
directory,
pg24
OL3.1
Discussion
boards and
comments,
pg 28
OL3.4 Job
opportunities,
pg 28, 29
OL5 User
access, pg
31
OL6 Secure
content, pg
31
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
Document1
0
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
Page 67 of 172
ACT]
ACT]
AUTH-003
Login
authentication
User identity will be validated
with the user’s GSi email
address listed in their
contacts directory profile
1
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
0
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
AUTH-004
Department
verification
The user’s department will be
verified by the format of their
GSi email address (held in
the Lawyers database)
There may be multiple
permitted email address
formats against each
department*
1
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
0
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
£0
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
Sub-total
31 Provision
of SMTP server: to comply with GSi standards, the redeveloped LION extranet and Lawyers database systems must use an existing SMTP
server on the GSi (possibly with authentication) for sending outbound email. The GLS will provide access and authentication information to this server
prior to the start of production of the DDD (database design document).
32 In
order to meet GSi standards, it is assumed that TSol will provide a white-listed email address in the format [email protected] that will be
used to send emails out from the system.
3.4.22
LION users
14-Jul-17, 1:36 AM
Document1
Page 68 of 172
Requirement
Requirement
ID
Name
LUS-001
14-Jul-17, 1:36 AM
User types
Description
There will be seven types of LION
users:
–
LION administrator
–
GLS Secretariat editor
–
Content owner – open
access
–
Content owner – secure
access
–
End user – open access
–
End user – secure access
–
Contacts directory editor
Due to SiteCore licensing
restrictions, a max of eight LION
administrators, GLS Secretariat
editors and content owners can
be logged into the CMS admin UI
simultaneously. LION
administrators will be able to log
out other users
Priority
1
Proposal fees
Re-
16/07/2010
quoted
19/07/2010
fees
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
Document1
Variance
0
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
Variance
RFP
description/note
reference
Covered by
SiteCore user
roles and
permissions.
MC1
Access to
the
system,
pg 51
Page 69 of 172
LUS-002
LION
administrators
LION administrator
There are expected to be up to 4
of these users with identical rights
Will have access to all site, content
and user administrative functions
in the SiteCore CMS, including
but not limited to:
–
C/R/U/D content areas and
secure content areas
–
Assign content owners to
content areas and secure
content areas
–
Access reports as
specified elsewhere in this
document
–
Create ad hoc reports
within the constraints of
SiteCore reporting tools
–
Manage user roles and
permissions via the CMS admin
UI for all user types
–
Archive content and
restore content from the archive
–
LION administrators will
also have the permissions of all
other user types defined in
LUS-001
1
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
0
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
LUS-002
GLS
Secretariat
editors
GLS Secretariat editors
There are expected to be up to 4
of these users with identical rights
Will have access to all site content
management functions in the
SiteCore CMS as follows:
–
Create/edit/delete content
within content areas
–
Create/edit/delete content
within secure content areas
1
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
0
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
14-Jul-17, 1:36 AM
Document1
Page 70 of 172
LUS-003
14-Jul-17, 1:36 AM
Content
owner – open
access
LION content owner
There are expect to be ~50 of
these users with identical rights
Will have access to content
management functions in the
SiteCore CMS as follows:
–
Create/edit/delete content
within their own content areas
–
Read results on surveys
within their own content areas
–
Read comments within
their own content areas
Will have access to user
management functions in the
SiteCore CMS as follows:
–
View all end user
subscribers to content update
notifications within their own
content areas
–
Subscribe/unsubscribe
users to content update
notifications within their own
content areas
Will have access to data
management within the contacts
directory as follows:
–
Amend their own profile
data (basic details) without
admin approval
–
Amend their own profile
data (fundamental details) –
requires admin approval
–
Create/delete their own
profile – requires admin
approval
1
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
Document1
0
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
Page 71 of 172
LUS-004
14-Jul-17, 1:36 AM
Content
owner –
secure
access
LION content owner – secure areas
Will have access to content
management functions in the
SiteCore CMS as follows:
–
Create/edit/delete content
within their own content areas –
both open and secure areas
–
Read results on surveys
within their own content areas
–
Read comments within
their own content areas
Will have access to user
management functions in the
SiteCore CMS as follows:
–
Manage end user access
to their secure content areas
based on department and/or
individual
–
View all end user
subscribers to content update
notifications within their own
content areas
–
Subscribe/unsubscribe
end users to content update
notifications within their own
content areas
Will have access to data
management within the contacts
directory as follows:
–
Amend their own profile
data (basic details) without
admin approval
–
Amend their own profile
data (fundamental details) –
requires admin approval
–
Create/delete their own
profile – requires admin
approval
3
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
Document1
0
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
Page 72 of 172
LUS-005
End user –
open access
LION end user
Will have read access to all site
content in open areas
Will have write access to surveys,
polls and commenting in open
areas
Will have write access to rate pages
within open areas
Will have access to data
management within the contacts
directory as follows:
–
Amend their own profile
data (basic details) without
admin approval
–
Amend their own profile
data (fundamental details) –
requires admin approval
–
Create/delete their own
profile – requires admin
approval
1
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
0
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
LUS-006
End user –
secure
access
LION end user – authorised
department
Will have read access to all site
content in open areas
Will have read access to site content
in specific secure area dependent
upon their permissions
Will have write access to surveys,
polls and commenting in open
areas
Will have write access to surveys,
polls and commenting in specific
secure areas
Will have write access to rate pages
within specified secure areas
Will have write access to rate pages
within open areas
Will have access to data
3
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
0
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
14-Jul-17, 1:36 AM
Document1
Page 73 of 172
management within the contacts
directory as follows:
–
Amend their own profile
data (basic details) without
admin approval
–
Amend their own profile
data (fundamental details) –
requires admin approval
–
Create/delete their own
profile – requires admin
approval
LUS-007
Contacts
directory
editor
Contacts directory editor
There will be up to 5 of these user
types
Will have access to data
management within the contacts
directory as follows:
–
Amend profile data (basic
and fundamental details) for all
lawyers within their department
without admin approval15
–
Add/delete profiles for
lawyers within the department –
requires admin approval15
15 Note: the fields that can be edited
by contacts directory editors without
admin approval will be defined in the
data model specification
2
Sub-total
3.4.23
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
0
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
£0
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
LION CMS functional requirements
14-Jul-17, 1:36 AM
Document1
Page 74 of 172
Requirement
Requirement
ID
Name
Description
Priority
Proposal fees
Re-
16/07/2010
quoted
19/07/2010
fees
Variance
CMS-001
Content
archiving
The CMS will retain (archive16)
all previous versions of
pages within all sections for
a defined time period
LION administrators, GLS
Secretariat editors and
content owners will be able
to restore content from the
archive. This will be an easy
to use and intuitive process
16 Note: prior to production of
the technical specifications
document, the time period for
holding content in the archive
will need to be agreed.
1
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
0
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
CMS-002
Change
auditing
The CMS will record all content
changes in a content change
log at a level of granularity
that enables the
identification of users
changing content
The content change log will be
available to LION
administrators via the CMS
admin UI17
Content changes will be
displayed in user friendly
manner enabling
administrators to see
changes made easily17
17 Note: the native SiteCore
content log files view is user
friendly and does not require
additional customisation.
1
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
0
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
14-Jul-17, 1:36 AM
Document1
Variance
RFP
description/note
reference
Covered by
SiteCore
functionality
MC43
Archiving, pg
55
New,
requested by
The GLS
during
requirements
workshop
Page 75 of 172
CMS-003
Change IP
logging
When a user makes a change
to content, their IP address
will be recorded in the
content change log against
that change. The IP address
may not be unique to each
user, depending on the IP
address allocation used by
The GLS/TSol
2
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
0
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
CMS-004
CMS setup
and config
Install and configure SiteCore
CMS
1
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
4,090
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
£4,090
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
Sub-total
3.4.24
Security
Statement,
pg 69, 70
LION QA and UAT
Requirement
Requirement
ID
Name
LQT-001
14-Jul-17, 1:36 AM
QA testing
Description
QA testing and fixes to specified
quality and per the approved
test plan, including
accessibility, functional and
integration testing
Priority
1
Proposal fees
Re-
16/07/2010
quoted
19/07/2010
fees
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
Document1
31,635
Variance
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
Variance
RFP
description/note
reference
Perform
testing
services,
implement
fixes from
Page 76 of 172
INFORMATION
ACT]
LQT-002
UAT
Provide support during client
UAT to clarify queries and fix
and test reported bugs. Does
not include changes requested
during client UAT
1
INFORMATION
ACT]
LQT-003
UAT
environment
Provision of a staging
environment for client UAT 18
18 The staging environment set up
for client UAT will utilise the
production environment and will
be locked down by IP address
and/or IP range
1
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
0
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
£31,635
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
Sub-total
3.4.25
testing
cycles, pg
64
Included in
hosting costs
Preview
facility for
client to
perform
testing, pg
64
Variance
RFP
description/note
reference
LION implementation project management
Requirement
Requirement
ID
Name
Description
Priority
Proposal fees
Re-
Variance
16/07/2010
quoted
19/07/2010
fees
LM-001
Project
management
Project management
1
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
47,416
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
LM-002
Account
management
Account management and board
report
1
[INFORMATION
REDACTED
UNDER
7,200
[INFORMATION
REDACTED
UNDER
14-Jul-17, 1:36 AM
Document1
Project
management and
governance fees
have increased
due to the
detailed level of
engagement.
Account and
technical
management
Page 77 of 172
SECTION 43
FREEDOM OF
INFORMATION
ACT]
SECTION 43
FREEDOM OF
INFORMATION
ACT]
LM-003
Technical
Leadership
Technical management,
architectural guidance,
coaching
1
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
16,530
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
LM-004
Governance
Involvement by heads of
discipline to cover project
assurance
1
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
12,354
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
£83,500
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
Sub-total
3.4.26
fees have
decreased.
Lawyers database software purchase
Requirement
Requirement
ID
Name
MDP-001
14-Jul-17, 1:36 AM
Purchase
database
software
Description
MS Dynamics CRM licence, which
includes three years of software
assurance
Priority
1
Proposal fees
Re-
16/07/2010
quoted
19/07/2010
fees
[INFORMATION
REDACTED
UNDER
Document1
Variance
4,431
[INFORMATION
REDACTED
UNDER
Variance
RFP
description/note
reference
MD3 Data
migration,
pg 33
Page 78 of 172
SECTION 43
FREEDOM OF
INFORMATION
ACT]
Sub-total
3.4.27
SECTION 43
FREEDOM OF
INFORMATION
ACT]
£4,431
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
Lawyers database design19 and 20
Requirement
Requirement
ID
Name
Description
Priority
MD2-001
Schema
 The database will have a welldesigned technical structure
(schema) with the objective of
streamlining day-to-day
processes
1
MD2-002
Relational
design
Data will be re-organised into a
relational schema
1
MD2-003
Database
design
document
Produce database design
document containing:
–
Data model
specification and entity
relationship diagram
–
Report definitions for 5
reports (ad hoc report
configuration will be
covered in the database
training documentation)
–
Screen flow diagrams
1
14-Jul-17, 1:36 AM
Proposal fees
Re-
16/07/2010
quoted
19/07/2010
fees
Variance
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
2,630
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
9,596
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
Document1
Variance
RFP
description/note
reference
MD2 Design
and
architecture,
pg 32
Better
understanding of
the detailed
requirements and
complexity of the
proposed
schema means
more accurate
estimation.
MD2 Design
and
architecture,
pg 32
Page 79 of 172
–
–
–
Database architecture
Platform
Security
MD3-004
Legacy data
 The following fields/data are
NOT required in the new
system and will not be
migrated nor implemented:
–
Languages
–
Boarding experience
1
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
0
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
MD4-001
Data – lawyer
 The database will contain basic
data about lawyers such as
name, date of birth, ethnicity,
barrister/solicitor, date of entry
to GLS, grade on entry etc.
1
2,366
MD4-002
Data – lawyer,
don't publish
Lawyers records can be tagged
as 'do not publish' - this will
prevent the sub-set from
being published to the
contacts directory if a lawyer
so requests21
21 Assumes the purpose is to
exclude lawyers from the contacts
directory and will not be included
as a flag in standard reporting
1
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
MD4-003
Data – current
job
 The database will contain data
about a lawyer’s current job –
e.g. job title, grade,
department, areas of
responsibility and job
category, etc.
1
MD4 Sets of
data, pg 33,
34
MD4-004
Data – prior
job
The database will contain data
about a lawyer’s GLS and
non-GLS prior jobs such as
start and end dates,
organisation, job category,
1
MD4 Sets of
data, pg 33,
34
14-Jul-17, 1:36 AM
Document1
MD3 Data
migration,
pg 33
Better
understanding of
the detailed
requirements and
the data model
means more
accurate
estimation.
MD4 Sets of
data, pg 33,
34
New
Page 80 of 172
grade etc.
MD4-005a
Reference
data
A number of entities will be
treated as updateable
reference data, e.g.
department codes, division
codes, university codes
All reference data must be able
to be tagged as ‘active’ or
‘inactive’
Reference data will be easy to
update
1
MD4 Sets of
data, pg 33,
34
MD4-005b
Discipline
reduction
‘Active discipline’ codes will be
renamed to ‘areas of
responsibility/law’ and be
rationalised at the point of
migration
1
MD4 Sets of
data, pg 33,
34
MD5-001a
Pending
records
Lawyer records can be created
in the system and identified as
‘pending’ i.e. inactive with a
future start date
Pending records will not be
included in any reporting that
counts live GLS lawyers.
1
MD5-001b
Pending
records – auto
update
Once the start date has arrived,
the record will be removed
automatically from pending
status and will become a GLS
lawyer record which will be
included in reports, etc.
2
14-Jul-17, 1:36 AM
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
1,169
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
MD5
Pending
records, pg
35, 36
MD5
Pending
records, pg
35, 36
Document1
Page 81 of 172
MD6-001
GLS leaver
records
Lawyer records can be identified
as ‘leaver’, and may include –
but not be limited to – the
following data:
–
Leaving date
–
Reason for leaving
(e.g. retired, resigned,
loaned to non-GLS dept,
etc.)
–
Grade on leaving
1
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
516
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
MD6 GLS
leavers, pg
36
MD7-001
Non-GLS
personnel
Non-GLS personnel records will
contain the information
required to for a LION
contacts directory entry such
as name, organisation, nonGLS flag and contact details,
etc.
1
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
887
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
MD7
Associates
and nonGLS
lawyers, pg
36, 37
MD8-001
Postretirement
indicator
Leaver records must be able to
be optionally tagged to
indicate a lawyer is retired,
i.e.:
–
‘Post-retirement
register’ indictor
–
Contact details
–
The type of work they
are interested in/field of
expertise (free text)
Database administrators will be
able to delete these records
should the lawyers no longer
wish to be considered for
short-term assignments
1
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
516
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
MD8 Postretirement
register, pg
37
MD9-001a
Lookups
The system will support the
following – but not be limited
to – lookup rules:
–
Department –
Division(s)
–
Department –
1
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
1,675
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
MD9
Lookup
fields, pg
37, 38
14-Jul-17, 1:36 AM
Document1
Page 82 of 172
–
–
–
–
–
Location(s)
Division – Job Cat
Code(s)
Division – Discipline
Code(s)
Grade – Pay Band(s)
Qualification –
Board(s)
Division – Default
Email format
ACT]
ACT]
MD9-001b
Unknown
Lookup values will have an
available value of Unknown
(‘99’ has been used to date to
mark fields as 'no applicable')
1
MD9
Lookup
fields, pg
37, 38
MD9-002
Pay band
If pay grade is set to ‘SCS’ then
pay band must be set as a
mandatory field
1
MD9
Lookup
fields, pg
37, 38
MD10-001
New fields
Database administrators will
have the ability to add nonrelational new fields to lawyer
and job records (relational
fields will require code
changes/development work)
It is recognised that this may
require changes to existing
defined reports, which will
require database developer
resource and will be handled
under the Rufus Leonard
change control process
1
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
789
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
MD16-001
Last updated
and change
logging
All lawyer and job records will
include the fields ‘last
updated’ (date) and ‘updated
by’ (user), automatically
populated when a change is
made
A mandatory free text field will
1
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
1,557
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
14-Jul-17, 1:36 AM
Document1
MD10 Add
new fields,
pg 38
Proposal fees
covered out-ofthe-box database
entity level
auditing only and
excluded
archiving.
MD16 Audit
trail and
archiving,
pg 40
Page 83 of 172
be added, where a ‘reason’ for
change must be recorded
(see MD16-002)
MD24-002
Record
deletion
By default, GLS lawyer records
will be retained for historical
purposes and not deleted.
However, database
administrators will be able to
delete GLS lawyer records (in
the instance of
mistakes/duplication) and
post-retirement records on
request from the lawyer
Database administrators will
have the ability to delete nonGLS lawyer records
Deletion operation for both GLS
and non-GLS records will be
handled in a fast and intuitive
manner
1
Sub-total
19 Lawyers
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
560
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
£22,261
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
New
database data model: The GLS will provide the fields, business logic and validation rules for the data required in the Lawyers database and
LION extranet contacts directory prior to the start of the data model specification work.
20 Lawyers
database data model design: the database costs quoted in this document are based on the data model details agreed during requirements
capture and as defined in PRD v1.0. While refinement is expected during the design and specification stages of the database redevelopment project,
large deviation from the data model details will impact both budget and schedule and will be treated as a change request
14-Jul-17, 1:36 AM
Document1
Page 84 of 172
3.4.28
Lawyers database user interface22
Requirement
ID
Requirement
Name
Description
MD9-003
UI lookups
The database UI will use the
lookup rules defined in the
database (MD9) to present
options at point of entry. It will
be possible to override defaults.
Lookups can have constraints
(provide certain values) and
defaults (default to certain value
in UI for new records). Default
values can be overridden, within
the constraint range
Only active reference data items
will be offered for new record
creation; all ref data will be
offered for editing existing
records (subject to lookup rules)
1
MD11-001
Lawyer
Search
It will be possible to search for
either GLS lawyer or non-GLS
lawyer records by:
–
Lawyer code
–
Surname
–
Department (new)
–
Division (new)
MD11-002
Lawyer
advanced
search
It is desirable to be able to search
for lawyers by any of their
record data
14-Jul-17, 1:36 AM
Priority
Proposal fees
Requoted
fees
Variance
Variance
description/note
RFP
reference
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
0
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
Fees bundled
with MD9-001a,
MD9-001b,
MD9-002.
MD9 Lookup
fields, pg 37,
38
1
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
145
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
1
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
145
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
16/07/2010
19/07/2010
Document1
MD11
Search
function, pg
38
Proposal fees
did not cover
search on all
fields,
MD11
Search
function, pg
38
Page 85 of 172
DBUI-001
Screen flow
diagrams
Produce screen flow diagrams
showing basic details of
functionality and data for each
screen and includes interaction
between screens.
1
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
2,910
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
DBUI-002
Lawyer update
screens
The system will have dedicated
screens for the following
operations:
–
Add new lawyer
–
Edit lawyer
–
Job change. Note, with a
promotion, the new ‘date to
grade’ field will auto-default
and ‘exit method’ on old job
will default to ‘promotion’
Lawyer leaving GLS. The following
data are required:
–
Leaving code
–
Grade on leaving
–
Date of leaving
1
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
0
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
New,
requested by
The GLS
during
requirements
workshop
DBUI-003
GLS lawyer
reinstatement
Where a lawyer is ‘reinstated’, i.e.
the record is changed from
‘leaver’ to a current GLS lawyer,
the system will check for
duplicates based on ‘first name’,
last name’ and ‘DOB’ before the
record is changed
A ‘period of absence’ will be
calculated automatically based
on ‘leave date’ and ‘reinstated
date’
For consistency, a ‘leaver’ job
record will be recorded in the
system but will not appear in
standard data record searches
(or reports). Thus, the new
2
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
0
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
New
14-Jul-17, 1:36 AM
Document1
The MSD UI
maximises user
interaction on
single screens,
thus reducing
the number of
screens used.
Produce
screen flow
diagrams, pg
61
Page 86 of 172
system will follow part of the
existing process where a new
job record will be created for a
leaver but it is flagged as
‘leaver’. This ensures
consistency between the
existing and new data
Sub-total
22 Lawyers
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
£3,200
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
database user interface: costs and timings quoted in this document are based on utilising the default MS Dynamics user interface for the
Lawyers database users
3.4.29
Lawyers database processes
Requirement
Requirement
ID
Name
MD12-001
14-Jul-17, 1:36 AM
Export to
LION contacts
directory
Description
The database will export the
contacts directory sub-set* of
data for active records to LION
on a regular scheduled basis
during the day
Records that have been removed
from the database (whether
directly or via a contacts
directory update) will be
unpublished from LION with
the next scheduled export
* Note: the sub-set of data for the
Priority
1
Proposal fees
Re-
16/07/2010
quoted
19/07/2010
fees
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
Document1
Variance
740
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
Variance
RFP
description/note
reference
Covers two-way
MSD and
SiteCore
integration.
MD12
Export to
LION
directory,
pg 38
Page 87 of 172
contacts directory will be defined
in the data model specification
MD13-001
Contacts
directory
updates
The database will present
inbound contacts directory
update requests (from lawyers
and contacts directory editors)
for approval by database
administrators
Some requests will be updated
without approval, e.g. nonGLS records plus basic
changes to GLS lawyer
records.* They will then be
updated in the database and
propagated to the LION
contacts directory
There are three types of updates:
–
Add: request to be
added to the contacts
directory
–
Modify: request to
modify details
–
Delete: request for
removal from the contacts
directory, including reason
for leaving completed by
requestor
Approved requests will be
archived
Rejected requests will be held in
the system, not deleted
* Note: changes to fields requiring
admin approval will be defined in
the data model specification
1
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
2,366
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
Additional fees
cover the logic for
providing two
forms of selfservice updates
from the contacts
directory (a data
set requiring
admin approval
and a data set
not requiring
admin approval).
MD13
Contact
Directory
updates, pg
39
MD14-001
Record
extraction for
email merge
The database must support
extraction of lawyer records to
defined criteria such as ‘GLS
network,’ ‘group’ or
1
[INFORMATION
REDACTED
UNDER
SECTION 43
2,191
[INFORMATION
REDACTED
UNDER
SECTION 43
Additional fees
cover export to
Excel format.
MD14
Email
groups/lists,
pg 39
14-Jul-17, 1:36 AM
Document1
Page 88 of 172
‘committee’
The database must support
export of this extracted data
(including contact details and
email addresses) to MS Excel
format
FREEDOM OF
INFORMATION
ACT]
FREEDOM OF
INFORMATION
ACT]
MD15-001
Data
protection
record
The database will support
generation of a given lawyer’s
record for Data Protection Act
(DPA) requests. This will show
all the data held in the
database on that lawyer and
will be plain text format
1
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
556
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
MD20-001
Updates from
external
sources
Where updated database data
comes from government HR
teams and external
recruitment providers, the data
entry will be handled manually
by the database administrators
1
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
585
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
MD21-001
Mass updates
of records
The database will support mass
updates of records in
response to “Machinery of
Government” changes, etc.
This will be implemented by ad
hoc querying. Examples of the
changes that should be
supported are listed below, but
not limited to:
–
Changing the
department name of a group
of lawyers
–
Changing the division
name of a group of lawyers
–
Changing the email
domain of a
department/division
–
Changing the location
1
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
1,299
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
14-Jul-17, 1:36 AM
Document1
This will generate
a humanreadable plain
text document.
MD15 Data
protection,
pg 40
MD20
Information
flows, pg
41, 42
Better
understanding of
the detailed
requirement
means more
accurate
estimation.
MD21 Mass
updating of
records, pg
42
Page 89 of 172
of a group of lawyers
Changing the job of
lawyers within a department
when the department remit
changes23
23 Note: this sub-requirement
needs further clarification in order
to confirm it will not impact the
estimated cost
–
Sub-total
3.4.30
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
£7,737
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
Lawyers database reporting
Requirement
Requirement
ID
Name
MD22-001a
14-Jul-17, 1:36 AM
Standard
reports
Description
The system will provide the
following standard reports 24:
–
Standard print
(snapshot)
–
Cumulative date range
for movers/joiners/leavers
–
Movers and shakers
–
SCS Gateway
Assessment Centre
24 Note: the above reports will be
defined in the database design
document (DDD). Where they exist
in multiple sub-types/variants, a
Priority
1
Proposal fees
Re-
16/07/2010
quoted
19/07/2010
fees
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
Document1
4,106
Variance
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
Variance
RFP
description/note
reference
MD22
Reporting,
pg 42, 43
Page 90 of 172
single report will be created and
instructions for variant configuration
provided to The GLS, which will be
defined during the course of the
project and prior to client UAT.
MD22-001b
Standard
reports – print
to MS Word
The system will support printing of
a database record to MS Word
(template to be defined)
3
MD22
Reporting,
pg 42, 43
MD22-002
Records
excluded
Standard reports should:
–
Exclude pending records
–
Exclude leaver records
–
Exclude non-GLS
records
1
MD22
Reporting,
pg 42, 43
MD22-003
Ad hoc
reporting
The system will support ad hoc
querying against the entire
database (e.g. also pending
records, etc.), which will be
provided by either extracting
data to Excel to then manipulate
or using the in-built report
builder25
The reporting interface is required
to be easy to use and intuitive25
25 Note: costs and timings quoted in
this document cover use of the
export of data to Excel format
and/or use of the default MS
Dynamics report builder tool and
default user interface for running ad
hoc reports. Should additional
customisation be required, this will
be costed separately and managed
under the Rufus Leonard change
control process
1
MD22
Reporting,
pg 42, 43
MD22-004
Record
currency
report
The system will be able to
generate a report of all lawyer
records that have not been
updated in the last 12 months
1
MD22
Reporting,
pg 42, 43
14-Jul-17, 1:36 AM
Document1
Page 91 of 172
(this will be reported on by both
GLS and non-GLS separately)
 This report should be exported to
Excel and include email
addresses
3.4.31
Sub-total
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
Priority
Proposal fees
£4,106
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
Lawyers database users
Requirement
ID
Requirement
Name
Description
MD17-001
User types
There will be three types of
database users, and
approximately up to 5 of each
type of user:
–
Administrators
–
Editors
–
Read and report only
1
MD17-002
Field based
security
Security will be applied at the field
level matching user roles, to
restrict C/R/U/D access to
particular user types for specific
fields or records
2
MD18-001
Administrators
Administrators will be able to:
Manage database users
Manage reference codes as well
as active/inactive flags
1
14-Jul-17, 1:36 AM
16/07/2010
19/07/2010
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
Requoted
fees
Variance
1,252
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
Variance
description/note
RFP
reference
Better
understanding
of the detailed
requirement
means more
accurate
estimation.
MD17 Access
to the
database, pg
40
MD17 Access
to the
database, pg
40
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
Document1
1,665
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
MD18
Administration
requirements,
pg 40, 41
Page 92 of 172
Manage lookup fields/rules
Add new non relational fields
Perform mass updates of data
(machinery of government
change MD21)
Append new fields to standard
reports
As well as all rights of editors and
read and report users
INFORMATION
ACT]
MD19-001
Editors
Editors will be able to:
Run all standard reports
Manage lawyer and job data
(create/update)
Generate audit email list
Approve contacts directory full
updates
Free query against the database
As well as all rights of read and
report users
1
MD19-002
Read and
report only
Read and report users will be able
to:
Run standard reports
Search for lawyers
View lawyer records
Generate Data Protection Act
report
Print lawyer records
1
Sub-total
3.4.32
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
INFORMATION
ACT]
787
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
MD19 Data
maintenance
users, pg 41
MD19 Data
maintenance
users, pg 41
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
£3,704
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
Lawyers database migration26
14-Jul-17, 1:36 AM
Document1
Page 93 of 172
Requirement
ID
Requirement
Name
Description
Priority
MD3-001
Data migration
Existing data in the Lawyers
database will be migrated to the
new database once cleaned –
except as otherwise advised by
the GLS
1
MD3-002
Data migration
- automated
The data migration process will be
automated where possible
2
MD3-003
Data migration
plan
A data migration plan will be
produced and agreed with The
GLS
1
Requoted
fees
Variance
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
2,251
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
1,228
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
£3,479
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
16/07/2010
19/07/2010
Sub-total
26 The
Proposal fees
Variance
description/note
RFP
reference
Fee reduction
assumes The
GLS will clean
the data and
export the
current data to
XML or CSV
format, where
multi-value fields
are separated.
MD3 Data
migration,
pg 33
MD3 Data
migration,
pg 33
MD3 Data
migration,
pg 33
GLS will provide exports of the existing data in XML or CSV format (and where multi-value fields are separated) containing all GLS lawyer records
that will be migrated to the new Lawyers database. Rufus Leonard will perform a maximum of three imports of cleaned and de-duplicated GLS lawyer
data, requiring The GLS to provide Rufus Leonard with three exports of data to schedule. Only GLS lawyer records will be imported in the redeveloped
Lawyers database. All non-GLS lawyer records will be input manually into the redeveloped Lawyers database by users themselves via the LION extranet
contacts directory or by the database administrator via the Lawyers database admin UI
3.4.33
Lawyers database QA and UAT
14-Jul-17, 1:36 AM
Document1
Page 94 of 172
Requirement
ID
Requirement
Name
Description
Priority
DQT-001
Post-migration
validation
Perform post-migration validation
of data
1
DQT-002
QA testing
QA testing of the completed
database system based on
more standard implementation
of MS Dynamics and use of
OOB functionality wherever
possible
1
DQT-003
UAT
Support will be provided during
client UAT, covering fixes and
testing of reported bugs
1
Proposal fees
Sub-total
3.4.34
Requoted
fees
Variance
Variance
description/note
RFP
reference
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
970
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
Assumes import
of cleaned data
as separated
XML or CSV.
Produce
quality
assured
deliverables,
pg 61
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
4,660
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
Better
understanding of
the detailed
requirement
means more
accurate
estimation.
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
£5,630
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
16/07/2010
19/07/2010
Lawyers database implementation project management
Requirement
ID
Requirement
Name
Description
DM-001
Project
management
Project management
14-Jul-17, 1:36 AM
Priority
Proposal fees
16/07/2010
19/07/2010
1
[INFORMATION
REDACTED
Document1
Requoted
fees
Variance
17,207
[INFORMATION
REDACTED
Variance
description/note
RFP
reference
Project
management and
Page 95 of 172
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
DM-002
Account
management
Account management and board
report
1
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
7,500
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
DM-003
Technical
Leadership
Technical management,
architectural guidance, coaching
1
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
5,420
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
DM-004
Test
management
Technical test team management
1
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
280
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
DM-005
Governance
Involvement by heads of discipline
to cover project assurance
1
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
3,437
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
£33,844
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
Sub-total
14-Jul-17, 1:36 AM
Document1
governance fees
have increased
due to the
detailed level of
engagement.
Account
management
fees have
decreased due to
assignment of
senior PMs to the
project.
Page 96 of 172
INFORMATION
ACT]
3.4.35
INFORMATION
ACT]
LION extranet and Lawyers database documentation
Requirement
ID
Requirement
Name
Description
Priority
ML5-001
LION admin
documentation
Documentation will be provided
(in (MS Word format),
covering CMS admin and
content management
operations
1
ML5-002
Content owner
documentation
Documentation will be provided
(in (MS Word format),
covering content
management operations
specific to content owners
MD23-001
Database
admin
documentation
Documentation will be provided
(in (MS Word format),
covering in detail all database
functionality for both
administrators and editors,
including how to run ad hoc
reporting queries against the
database
Requoted
fees
Variance
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
6,675
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
3
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
1,620
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
1
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
1,620
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
£9,915
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
16/07/2010
19/07/2010
Sub-total
14-Jul-17, 1:36 AM
Proposal fees
Document1
Variance
description/note
RFP
reference
ML5 Training,
pg 24, 25
MC48 CMS
training, pg
56
Proposal fees
assumed that
GLS will repurpose admin
documentation
for content
owners
ML5 Training,
pg 24, 25
MC48 CMS
training, pg
56
MD23
Training
administrators
and
operators, pg
43
Page 97 of 172
ACT]
3.4.36
ACT]
LION extranet and Lawyers database administrator training
Requirement
Requirement
ID
Name
Description
Priority
Proposal fees
Re-
16/07/2010
quoted
19/07/2010
fees
Variance
Variance
RFP
description/note
reference
ML5-003
LION
administrator
training
Up to three days on-site
training will be provided to
The GLS LION
administrators detailing all
operations in the new
system – including content
management, user
administration and
reporting, etc.
1
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
3,200
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
ML5 Training,
pg 24, 25
MC48 CMS
training, pg
56
MD23-002
Database
administrator
training
Up to two days on-site training
will be provided to The GLS
Lawyers database
administrators, detailing all
operations in the new
system
1
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
2,960
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
MD23
Training
administrators
and
operators, pg
43
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
£6,160
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
Sub-total
3.4.37
LION extranet and Lawyers database deployment
14-Jul-17, 1:36 AM
Document1
Page 98 of 172
Requirement
Requirement
ID
Name
Description
Priority
Proposal fees
Re-
Variance
16/07/2010
quoted
19/07/2010
fees
DEP-001
Deployment
plan
A deployment plan minimising
system downtime and risk will
be developed and agreed
with The GLS prior to the
planned launch
1
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
970
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
DEP-002
System
Deployment
Rufus Leonard/Endava will
manage the system cut-over
to the new hosted system(s)
according to the deployment
plan (The GLS will manage
user expectations and
communications). The GLS,
as domain owners, will need
to log a request to point the
domain at the new IP
address
1
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
1,645
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
£2,615
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
Sub-total
3.4.38
Variance
RFP
description/note
reference
Better
understanding of
the detailed
requirement
means more
accurate
estimation.
Deliverable
12 Switch
over plan,
pg 59
Deliverable
13
Deployment,
pg 59
LION extranet and Lawyers database hosting and hosting setup for year one29 and 30
Requirement
Requirement
ID
Name
14-Jul-17, 1:36 AM
Description
Priority
Proposal fees
Re-
16/07/2010
quoted
19/07/2010
fees
Document1
Variance
Variance
RFP
description/note
reference
Page 99 of 172
OL1-001b
GSe hosting annual cost
The system will be
hosted in a secure
hosting environment
connected to GSi
with an approved
GSe connection.
Rufus Leonard
recommends that
where the hosting is
separated from the
GSe endpoint, the
interconnectivity will
be secured as an
accredited LAN
extension
1
[INFORMATION
REDACTED UNDER
SECTION 43
FREEDOM OF
INFORMATION ACT]
72,504
[INFORMATION
REDACTED UNDER
SECTION 43
FREEDOM OF
INFORMATION ACT]
OL1-001a
GSe hosting setup
Initial capital
expenditure cost for
hosting
infrastructure,
applied at year 1 only
1
[INFORMATION
REDACTED UNDER
SECTION 43
FREEDOM OF
INFORMATION ACT]
9,979
[INFORMATION
REDACTED UNDER
SECTION 43
FREEDOM OF
INFORMATION ACT]
OL1 Hosting,
pg 27
Hosting
considerations,
pg 86
OL1-002
GSi leased
line - annual
cost
 Annual cost for leasing
the GSi line
1
[INFORMATION
REDACTED UNDER
SECTION 43
FREEDOM OF
INFORMATION ACT]
22,313
[INFORMATION
REDACTED UNDER
SECTION 43
FREEDOM OF
INFORMATION ACT]
OL1 Hosting,
pg 27
Hosting
considerations,
pg 86
OL1-003
GSi leased
line - setup
Initial capital
expenditure cost for
GSi leased line,
applied at year 1 only
1
[INFORMATION
REDACTED UNDER
SECTION 43
FREEDOM OF
INFORMATION ACT]
17,677
[INFORMATION
REDACTED UNDER
SECTION 43
FREEDOM OF
INFORMATION ACT]
OL1 Hosting,
pg 27
Hosting
considerations,
pg 86
OL1-003
Hosting
support
Any access of the live
system for support by
Rufus
Leonard/Endava
must meet GSe
accreditation
standards
1
[INFORMATION
REDACTED UNDER
SECTION 43
FREEDOM OF
INFORMATION ACT]
0
[INFORMATION
REDACTED UNDER
SECTION 43
FREEDOM OF
INFORMATION ACT]
OL1 Hosting,
pg 27
Hosting
considerations,
pg 86
14-Jul-17, 1:36 AM
Document1
See section
Error!
Reference
source not
found. for
variance
description
OL1 Hosting,
pg 27
Hosting
considerations,
pg 86
Page 100 of 172
OL1-004
System
access –
LION
The LION extranet (and
admin UI) must be
available from any
GSi computer. It
must not be available
outside the GSi
1
[INFORMATION
REDACTED UNDER
SECTION 43
FREEDOM OF
INFORMATION ACT]
0
[INFORMATION
REDACTED UNDER
SECTION 43
FREEDOM OF
INFORMATION ACT]
OL1 Hosting,
pg 27
Hosting
considerations,
pg 86
OL1-005
System
access –
Lawyers
database
Access to the Lawyers
database will be
restricted to the GLS
Secretariat
1
[INFORMATION
REDACTED UNDER
SECTION 43
FREEDOM OF
INFORMATION ACT]
0
[INFORMATION
REDACTED UNDER
SECTION 43
FREEDOM OF
INFORMATION ACT]
OL1 Hosting,
pg 27
Hosting
considerations,
pg 86
[INFORMATION
REDACTED UNDER
SECTION 43
FREEDOM OF
INFORMATION ACT]
£122,473
[INFORMATION
REDACTED UNDER
SECTION 43
FREEDOM OF
INFORMATION ACT]
Sub-total
29 Hosting:
the hosting contract starts on the date on which the hosting infrastructure is made available for installation and configuration of SiteCore CMS,
SQL and MS Dynamics for CSEG accreditation.
30 Hosting:
any changes to the proposed hosting environment configuration (illustrated in section 10.1 of this document) as a result of policy changes
applied by external parties (e.g. OGC buying Solutions, Cable and Wireless, etc.) are not covered by the costs and timings quoted in this release of the
project definition document and will be managed under the Rufus Leonard change control process.
3.4.39
LION extranet and Lawyers database support hours and security
Requirement ID
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
14-Jul-17, 1:36 AM
Requirement
Name
Description
Support hours
Support is required within
standard working hours
Monday to Friday 09:00 to
17:00 (excluding Bank
Holidays/Public Holidays)
Priority
Proposal fees
1
Document1
Requoted
fees
Variance
16/07/2010
19/07/2010
0
0
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
Variance
description/note
RFP
reference
OL1
Hosting,
pg 27
Page 101 of 172
INFORMATION
ACT]
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
INFORMATION
ACT]
Support group
Support users outside TSol who
will provide application support
will be set up as a separate
auditable group on both the
LION extranet and the Lawyers
database
1
[INFORMATION REDACTED UNDER SECTION 43 FREEDOM OF
INFORMATION ACT]
3.4.40
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
0
0
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
£0
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
OL1
Hosting,
pg 27
Security
Requirement ID
Requirement
Name
Description
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
TSol
Information
Security
The systems delivered will
meet TSol Information
Security policy
1
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
Domains
The system will NOT
integrate with TSol Active
Directory and must have its
own authoritative Domain
Controller
1
14-Jul-17, 1:36 AM
Priority
Proposal fees
Requoted
fees
Variance
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
0
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
Security
Statement, pg
69, 70
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
0
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
Security
Statement, pg
69, 70
16/07/2010
19/07/2010
Document1
Variance
description/note
RFP reference
Page 102 of 172
INFORMATION
ACT]
INFORMATION
ACT]
INFORMATION
ACT]
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
Penetration
testing applications
Penetration testing of the
applications should be
carried out before the
systems go live
Penetration testing will need
to be carried out by a
CESG-approved third
party, managed by TSol at
a cost to TSol. Rufus
Leonard will ensure the
availability of appropriate
developer and testing
resources to fix and test
any issues that arise from
penetration testing on the
applications
1
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
0
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
Security
Statement, pg
69, 70
OL1 Hosting,
pg 27
Hosting
considerations,
pg 86
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
Penetration
testing –
hosting
infrastructure
Penetration testing of the
hosting infrastructure will
be carried out as part of
the CSEG accreditation at
initial setup of the
infrastructure
Penetration testing of the
hosting infrastructure will
be carried out by a CESGapproved third party,
managed by Rufus
Leonard. Rufus Leonard
will ensure the availability
of appropriate resources to
fix and test any issues that
arise from penetration
testing on the hosting
infrastructure
1
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
6,000
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
Security
Statement, pg
69, 70
OL1 Hosting,
pg 27
Hosting
considerations,
pg 86
14-Jul-17, 1:36 AM
Document1
Page 103 of 172
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
IP Logging
The system will log database
administrators’ and LION
administrators’ system
access
2
[INFORMATION REDACTED UNDER SECTION 43 FREEDOM OF
INFORMATION ACT]
3.4.41
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
0
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
£6,000
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
Security
Statement, pg
69, 70
Availability
Requirement ID
Requirement
Name
Description
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
LION/database
availability
Both systems are required to
meet availability of 98% per
quarter
1
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
Offline
maintenance
If offline maintenance is to be
scheduled, The GLS requires
2 weeks advance notice
1
14-Jul-17, 1:36 AM
Priority
Proposal fees
Requoted
fees
Variance
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
0
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
OL1
Hosting,
pg 27
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
0
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
OL1
Hosting,
pg 27
16/07/2010
19/07/2010
Document1
Variance
description/note
RFP
reference
Page 104 of 172
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
Maintenance
times
Planned maintenance must not
occur during standard working
hours, i.e. Monday to Friday
09:00 to 17:00 (excluding
Bank Holidays/Public
Holidays)
1
[INFORMATION REDACTED UNDER SECTION 43 FREEDOM OF
INFORMATION ACT]
3.4.42
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
0
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
£0
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
OL1
Hosting,
pg 27
Volume metrics
Requirement ID
Requirement
Name
Description
Priority
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
LION
scalability
The LION extranet must be
designed to handle 10,000
users on the approved hosting
platform.
1
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
Lawyers
database
scalability
The Lawyers database must be
designed to handle up to
15,000 lawyers records
1
Requoted
fees
Variance
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
0
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
ML6.2
Scalability,
pg 25
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
0
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
MD24.2
Scalability,
pg 43
[INFORMATION
REDACTED
£0
[INFORMATION
REDACTED
16/07/2010
19/07/2010
Sub-total
14-Jul-17, 1:36 AM
Proposal fees
Document1
Variance
description/note
RFP
reference
Page 105 of 172
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
3.4.43
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
Performance
Requirement
Requirement
ID
Name
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
14-Jul-17, 1:36 AM
LION
performance
Description
On the basis of 200
concurrent users, response
times for the site must not
exceed 3 seconds27. This
includes:
–
Page load
–
Search results
display
–
Pages sent to
archive
–
Pages retrieved
from archive
–
Pages republished
from archive
27 Note: system performance
and response times are
influenced by other factors
outside of the control of the
hosting environment and
software/application, e.g.
network connectivity and local
bandwidth and may affect the
benchmarks specified in the
RFP against these
requirements. Therefore, times
Priority
1
Proposal fees
Re-
16/07/2010
quoted
19/07/2010
fees
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
Document1
Variance
0
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
Variance
RFP
description/note
reference
ML6.3
System
performance,
pg 25
Page 106 of 172
cannot be guaranteed for all
users in all circumstances
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
14-Jul-17, 1:36 AM
Lawyers
database
performance
On the basis of a system with
6,000 records:
–
15 users accounts
–
All auditing features
enabled
–
Load simulating 6
concurrent users
Then the system should meet
the following metrics:
–
95% of user
‘navigation’ actions
should be responded to
in less than 3 seconds
Perform the following
activities in less than 3
seconds: 27
–
Load any page
screen
–
Perform a search
(returning around 450
lawyers)
–
Save changes to a
record
27 Note: system performance
and response times are
influenced by other factors
outside of the control of the
hosting environment and
software/application, e.g.
network connectivity and local
bandwidth and may affect the
benchmarks specified in the
RFP against these
requirements. Therefore, times
1
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
Document1
0
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
The MS
Dynamics licence
quoted provides
for 5 users. At
this stage, we
have not
increased the
licence cost to
support additional
users until further
discussion with
The GLS
MD24.3
System
performance,
pg 43
Page 107 of 172
cannot be guaranteed for all
users in all circumstances
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
[INFORMATION REDACTED UNDER SECTION 43 FREEDOM OF
INFORMATION ACT]
3.4.44
£0
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
User platform
Requirement
Requirement
ID
Name
Description
Priority
Proposal fees
Re-quoted fees
Variance
16/07/2010
Variance
RFP
description/note
reference
19/07/2010
USER-001
14-Jul-17, 1:36 AM
LION end user –
browser support
The LION
extranet
front-facing
interface is
required to
support the
set of GSi inuse
browsers/OS
s to be
determined
by The GLS
in
accordance
with “Govt
Website
Guideline
1
0
Document1
0
0
Guidelines
for UK
government
websites,
pg 7
Page 108 of 172
TG117 –
Brower and
operating
system
support” and
identified at
the time of
writing as:
– Internet
Explorer 6, 7
and 8 on
Windows XP
– Opera 9
(representing
Mozilla 4
browsers) on
Windows XP
USER-002
14-Jul-17, 1:36 AM
LION end user –
JavaScript
The LION
extranet
front-facing
interface may
use
JavaScript to
enhance
functionality
but will
provide
fallback
functions if
JavaScript is
disabled in
end user
browsers.
The system
should
degrade
gracefully
and display
all
information
required in a
1
0
Document1
0
0
Guidelines
for UK
government
websites,
pg 7
Page 109 of 172
user-friendly
manner
USER-003
LION end user –
ActiveX/Java/Flash
The LION
extranet
front-facing
interface
must not rely
on Java,
ActiveX or
Flash
functionality
1
0
0
0
Guidelines
for UK
government
websites,
pg 7
USER-004
LION admin user–
browser support
The LION
admin (CMS)
interface
must work
with the set
of GSi in-use
browsers/OS
s in
accordance
with Govt
Website
Guideline
TG117 –
Brower and
operating
system
support) and
identified as:
– Internet
Explorer 6, 7
and 8 on
Windows XP
– Opera 9
(representing
Mozilla 4
browsers) on
1
0
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
0
Guidelines
for UK
government
websites,
pg 7
14-Jul-17, 1:36 AM
Document1
Page 110 of 172
Windows XP
USER-005
14-Jul-17, 1:36 AM
LION admin user –
JavaScript
The SiteCore
CMS admin
interface
requires
JavaScript to
provide
administrativ
e and content
management
functionality.
This applies
to all users of
the CMS UI
(LION
administrator
s, GLS
Secretariat
editors and
content
owners).
Therefore, it
will not
strictly
comply with
all WCAG 2.0
guidelines.
JavaScript
will need to
be enabled
on those
machines
that require it
1
0
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
Document1
0
Guidelines
for UK
government
websites,
pg 7
Page 111 of 172
across
departments
(the site will
need to be
‘white listed’
for this
purpose)
Sub-total
3.4.45
£0
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
Requoted
fees
Variance
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
0
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
£0
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
Accessibility
Requirement
ID
Requirement
Name
Description
ACCESS001
Accessibility
The LION extranet front-facing
interface is required to be
developed to WCAG ‘AA’
accessibility standards across
all components
It is the responsibility of The GLS
to ensure continued compliance
with the accessibility
requirements in respect of the
content created and uploaded
to the LION extranet site
Priority
16/07/2010
19/07/2010
1
Sub-total
14-Jul-17, 1:36 AM
Proposal fees
Document1
Variance
description/note
RFP
reference
Guidelines
for UK
government
websites,
pg 7
Page 112 of 172
INFORMATION
ACT]
3.5
Requirements list as ‘optional’ in the RFP and fees
3.5.1
LION limiting user access
Requirement
Requirement
ID
Name
OL5
Site access
control
Description
Access to the site will be gained
by user login prior to access of
the home page and will be
based on user permissions
Priority
2
Sub-total
3.5.2
INFORMATION
ACT]
Proposal fees
Re-
Variance
16/07/2010
quoted
19/07/2010
fees
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
225
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
£225
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
Variance
RFP
description/note
reference
Defining access
control via user
login prior
reduces
implementation
cost.
OL5
Limiting
user
access,
pg 31
Variance
RFP
description/note
reference
LION secure content areas (OL6)
Requirement
Requirement
ID
Name
14-Jul-17, 1:36 AM
Description
Priority
Proposal fees
Re-
16/07/2010
quoted
Document1
Variance
Page 113 of 172
19/07/2010
OL6-001
Secure
content areas
The system will provide a secure
content scheme whereby
secure content areas can be
defined in the LION CMS and
opt-in access provided to
selected content owners (for
editing) and end users (for
viewing)
LION administrators will create
and defined secure content
areas in the content tree
2
OL6-002
Access control
– content
owners
LION administrators will associate
a content owner with a secure
content area
This will grant to secure content
owners the following
permissions for their content
areas:
–
Content management
(create/edit/delete)
–
End user access
management
2
OL6-003a
Access control
– end users
Secure content owner will grant
end users access to their
secure content based on:
–
Department
and/or
–
Individual
2
OL6-003b
User
authentication
End users will be required to
authenticate to see secure
content
The authentication will need to be
validated against criteria yet to
14-Jul-17, 1:36 AM
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
Document1
fees
3,835
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
Better
understanding of
the detailed
requirements
means more
accurate
estimation,
OL6
Secure
content
areas, pg
31
Page 114 of 172
be defined, e.g. user names
and passwords28
28 Note: validation criteria for user
authentication will be defined in the
information architecture work
stream
OL6-004
Secure
content
visibility
Secure content areas will be
visible in the site navigation for
all users
Unauthenticated users will be able
to view a generic landing page
for the secure content area
Unauthenticated users will not be
able to navigate past the
generic landing page
Authenticated users will be able to
view a specific landing page for
the secure content area
Authenticated users will be able to
navigate past the landing page
Secure content areas/content will
appear as menu items in the
SiteCore CMS content tree (in
CMS admin UI) but will not be
accessible for editing without
appropriate permissions
2
OL6-006
Secure
content
reporting
Secure content areas/content will
only appear in the CMS
reporting (in CMS admin UI) for
permissioned authenticated
content owners
2
OL6-005
Secure
content search
Secure content areas/content will
only appear in the site search
results (front site) and CMS
content search (in CMS admin
UI) for permissioned
authenticated end users and
content owners
2
14-Jul-17, 1:36 AM
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
Document1
2,590
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
Additional
requirement and
covers
dynamically
linking to GSA
security API.
New
Page 115 of 172
This may require secure content
owners to tag content as
‘secure’ on upload. In this
event it should be mandatory for
secure content owners to define
whether content is ‘secure’ or
not
Sub-total
3.6
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
£6,425
[INFORMATION
REDACTED
UNDER
SECTION 43
FREEDOM OF
INFORMATION
ACT]
Assumptions
Costs and timings associated with this version of the project definition document are based on the assumptions listed in the table below.
No.
Assumption
Ref requirement ID
1
LION design refresh:
GLS ‘brand identity’ guidelines (covering logo, look-and-feel, tone of voice, imagery) will be required as inputs for ML2-001.
Development of a new brand identity is not a deliverable for this project.
The GLS will be responsible for updating the existing content owners guide(s) to reflect the new LION online design. The
design production files will be provided to The GLS in raw PSD format for The GLS to use to create any necessary
guidelines documentation
If a TSol or GLS image library is available, The GLS to provide Rufus Leonard with access to the image library and to
provide Rufus Leonard with high resolution images from the library as required and to schedule
ML2-001, ML2-003, ML2004 and ML2-005
2
LION IA longevity:
It is the responsibility of The GLS to ensure that the integrity of the approved information architecture is maintained after the
site launches and while site structure and content is managed by The GLS
ML1-005
3
LION support of audio and video linked content:
It is assumed that the volume of audio and video content (Windows Media format only) will be low and not exceed a total of
100GB. The larger the file size for each audio or video content item, the poorer the user experience in the absence of
streaming technology. All audio and video files will be in Windows Media Format and assumes client-side presence of
ML3-002
14-Jul-17, 1:36 AM
Document1
Page 116 of 172
Windows Media Player
4
LION content update reminders:
System reminders that can be set by content owners to remind them of content expiry will not be linked to content items, i.e.
the reminder will consist of user-specified date, title, message content and recipient email address
ML3-007
5
LION document list control:
The proposed filtering by keyword functionality will be based on the metadata (as specified by content owners on upload of
documents) of the associated documents, the filtering will only be as accurate as the metadata content
ML3-010
6
LION content migration:
The GLS will grant Rufus Leonard read access via secure VPN to the existing live LION installation in order to review and
assess the system to plan content migration.
Rufus Leonard will identify suitable software tools – as required – o facilitate automated extraction of content (in a format
suitable for import into the redeveloped LION system) from the existing system
It is the responsibility of The GLS to install and test these software tools, ready for content extraction. Rufus Leonard will
extract the content.
Alternatively, the extraction of content in a format suitable for import into the redeveloped LION system will be performed by
The GLS and the extracted content provided to Rufus Leonard to schedule
Cleaning of existing data (removing unused, corrupt and duplicate data) is the responsibility of The GLS and will be
undertaken prior to the content extraction task
The GLS will be required to define the metadata for all existing content that will be migrated to the redeveloped system and
tag the migrated content once migration is complete
ML3-014
7
LION notification of content changes – from email:
Costs and timings in this document do not cover provision of automated removal of bounced email addresses from
notification lists
ML4.1-006
8
LION embeddable calendars:
The GLS will provide the full list of calendar event properties to Rufus Leonard prior to the start of the wireframing task.
ML4.6-001
9
LION amalgamated calendar filter functionality:
The GLS will provide the full list of filter parameters to Rufus Leonard prior to the start of the wireframing task.
ML4.6-003
10
LION training section calendars:
The GLS will provide the full list of training calendar event properties to Rufus Leonard prior to the start of the wireframing
task.
ML4.7-003
11
LION site search:
The search functionality will not search the Lawyers database. Updates to LION search results as content documents are
uploaded are not required in real time. Search result currency to within 4-12 hours is sufficient (real time updates will
required additional development work, and will have a detrimental performance impact on the system).
ML4.9-001
14-Jul-17, 1:36 AM
Document1
Page 117 of 172
12
LION site search implementation:
In order to meet all requirements, the SiteCore search engine Lucene will be used to meet the requirements not met by
GSA. It is assumed that the search options requiring the use of Lucene will form part of an advanced search (to be
defined in the IA) and that it will be made transparent to the user. The Lucene search will not integrate with GSA and
therefore the settings in GSA e.g. for search biasing will not influence the Lucene search results.
Synonyms will be used to facilitate the single character search. These will require periodic maintenance by the LION
administrators to manage the word lists and how they are converted in to search terms (maintenance will only be required
if the synonyms need to be updated)
Meta characters are ignored in GSA but may still return the expected results,(e.g. if a user searches for “A1-BN00” and the
system contains separate documents titled “A1-BN00” and “A1BN00”, both documents will be returned in the results).
This can only be determined by testing the search with the real data. Similarly, wildcards aren’t supported by GSA,
however, the logic behind GSA may also return the correct results due to the intelligent nature on how the search engine
works
Google Snippets (extensions to the default appliance configuration) will be used to provide search facets based on metadata
criteria such as section, author, etc.
The Lucene search engine is closely integrated with Sitecore and is leveraged to not only provide a search engine but is
also used to provide live content to sections of a website, such as home or landing pages. As a result, Lucene can be
leveraged without the additional overhead of installing a separate search engine
Both search engines will not be used on every search, only the appropriate search engine would be leveraged depending on
either the search string entered or the option selected in the advanced search form
Help information on the search pages should have enough information to clearly explain to the users when each of the
search engines will be used and why there may be inconsistencies in the results returned
For efficiency and result accuracy, we recommend using GSA over Lucene whenever possible. It will be possible to switch
off the Lucene search functionality at any time without impacting the GSA search functionality
The search will be configured to search only the LION extranet and not any external websites
ML4.9 as a whole
13
LION site search - metadata:
The GLS will define the business- and legal-specific keywords, categories and terms that will be used by the search
appliance and for tagging content
ML4.9 and ML3
14
LION contacts directory – directory lookups:
Some of the lookups, e.g. ‘department’, will require a free text override option, details of which will be defined in the data
model specification document produced for the Lawyers database
Details on fields and validation will be defined in the data model specification document produced for the Lawyers database
ML4.11-002, ML4.11004b
15
LION ‘editor’ users – contacts directory edits:
Field editing permissions for this user type requiring or not requiring database administrator approval will be defined in the
data model specification produced for the Lawyers database
LUS-007
16
LION content archiving:
CMS-001
14-Jul-17, 1:36 AM
Document1
Page 118 of 172
Prior to production of the technical specifications document, the time period for holding content in the archive will need to be
agreed
17
LION change auditing:
LION administrator view of the content change log will utilise the native SiteCore content log view
CMS-002
18
Staging environment:
The staging environment set up for client UAT will utilise the production environment and will be locked down by IP address
and/or IP range during UAT
LQT-003
19
Lawyers database data model – GLS input:
The GLS will provide the fields, business logic and validation rules for the data required in the Lawyers database and LION
extranet contacts directory prior to the start of the data model specification work
MD2, MD3, MD4, MD5,
MD6, MD7, MD8, MD9,
MD12, MD13, MD16,
ML4.11
20
Lawyers database data model design:
The database costs quoted in this document are based on the data model details agreed during requirements capture and
as defined in PRD v1.0. While refinement is expected during the design and specification stages of the database
redevelopment project, large deviation from the data model details will impact both budget and schedule and will be
treated as a change request
MD2, MD3, MD4, MD5,
MD6, MD7, MD8, MD9,
MD12, MD13, MD16,
ML4.11
21
Lawyers database – do not publish:
MD4-002
Assumes the purpose is to exclude lawyers from the contacts directory and will not be included as a flag in standard reporting
22
Lawyers database user interface:
Costs and timings quoted in this document are based on utilising the default MS Dynamics user interface for the Lawyers
database users.
MD9-003, MD11-001,
MD11-002, DBUI-001,
DBUI-002, DBUI-003
23
Lawyers database mass updating of records:
Mass updates to the job of lawyers within a department when the department remit changes needs further clarification in
order to confirm it will not impact the estimated cost and timings
MD21-001
24
Lawyers database standard reports:
Costs and timings quoted in this document for the five standard reports will be defined in the database design document
(DDD). Where they exist in multiple sub-types/variants, a single report will be created and instructions for variant
configuration provided to The GLS, which will be defined during the course of the project and prior to client UAT.
MD22-001a
25
Lawyers database ad hoc reporting:
Costs and timings quoted in this document cover use of the export of data to Excel format and/or use of the default MS
Dynamics report builder tool and default user interface for running ad hoc reports. Should additional customisation be
required, this will be costed separately and managed under the Rufus Leonard change control process.
MD22-003
26
Lawyers database data migration:
The GLS will provide exports of the existing data in XML or CSV format (and where multi-value fields are separated)
MD3-001, MD3-002 and
MD3-003
14-Jul-17, 1:36 AM
Document1
Page 119 of 172
containing all GLS lawyer records that will be migrated to the new Lawyers database
Rufus Leonard will perform a maximum of three imports of cleaned and de-duplicated GLS lawyer data, requiring The GLS
to provide Rufus Leonard with three exports of data to schedule
Only GLS lawyer records will be imported in the redeveloped Lawyers database. All non-GLS lawyer records will be input
manually into the redeveloped Lawyers database by users themselves via the LION extranet contacts directory or by the
database administrator via the Lawyers database admin UI
Anonymising data – it is assumed that the only lawyer records data in the database will be anonymised for use during
development. The exact level to which the data needs to be anonymised will be agreed with The GLS during production of
the data migration plan
27
System performance for the LION extranet and the Lawyers database:
System performance and response times are influenced by other factors outside of the control of the hosting environment
and software/application, e.g. network connectivity and local bandwidth and may affect the benchmarks specified in the
RFP against these requirements. Therefore, times cannot be guaranteed for all users in all circumstances
ML6.3-001, MD24.3-001
28
LION user authentication:
Validation criteria for user authentication will be defined in the information architecture work stream
OL6-003b
29
Hosting and Licences:
The hosting contract starts on the date on which the hosting infrastructure is made available for installation and configuration
of SiteCore CMS, SQL and MS Dynamics for CSEG accreditation
The Software Assurance starts on the date on which the software is installed for CSEG accreditation
OL1
30
Hosting:
Any changes to the proposed hosting environment configuration (illustrated in section 10.1 of this document) and costs (see
section 9.6 of this document) as a result of policy changes applied by external parties (e.g. OGC buying Solutions, Cable
and Wireless, etc.) are not covered by the costs and timings quoted in this release of the project definition document and
will be managed under the Rufus Leonard change control process.
OL1
31
Provision of SMTP server:
To comply with GSi standards, the redeveloped LION extranet and Lawyers database systems must use an existing SMTP
server on the GSi (possibly with authentication) for sending outbound email. The GLS will provide access and
authentication information to this server prior to the start of production of the DDD (database design document).
ML4.1, ML4.5-003,
ML4.11-004a, ML4.1005, ML4.13-001, AUTH001
32
System ‘from’ email address:
In order to meet GSi standards, it is assumed that TSol will provide a white-listed email address in the format
[email protected] that will be used to send emails out from the system.
ML4.1, ML4.5-003,
ML4.11-004a, ML4.1005, ML4.13-001, AUTH001
3.7
[INFORMATION REDACTED UNDER SECTION 43 FREEDOM OF INFORMATION ACT]
14-Jul-17, 1:36 AM
Document1
Page 120 of 172
3.8
Business processes
3.8.1
Overview
The following key administrative business processes have been identified during the course of requirements gathering. This list may not be exhaustive
and is provided for reference.
LION extranet management:
 Update LION content (content owner, LION administrator)
 Update LION contacts directory details (lawyer/departmental editor, LION administrator) *
 Create new LION legal content section (LION administrator)
 Update news headlines (LION administrator)
 Update home page highlights banners (LION administrator)
 Self-service user account management *
Lawyers database management:
 Add new lawyer
 Edit lawyers details
 Set lawyer as having left GLS
 Extract and provide Lawyers database full record in response to DPA request
 Mass update of database records (mainly in response to “machinery of government” changes)
 Perform annual audit of Lawyers database records *
* These three processes will be changed materially by implementation of the new systems
14-Jul-17, 1:36 AM
Document1
Page 121 of 172
3.8.2
Process details
Process ID
Requirement Name
Description
Priority
BP-001
Self-service contacts
directory update –
basic, no admin
approval
The new LION contacts directory will implement a self-service workflow for updates by lawyers of their
basic contacts directory profile information
–
Submitted changes to GLS lawyers’ basic information will not require approval by database
administrators but will require lawyers to validate the requested change
Submitted changes to all non-GLS lawyers’ information will not require approval by database
administrators but will require lawyers to validate the requested change
The lawyer’s record in the database will be updated, which, in turn, will be published to the LION contacts
directory
Note: basic data that does not require approval will be defined during in the data model specification
(related to the Lawyers database)
1
BP-002
Self-service contacts
directory update –
fundamental, with
admin approval
The new LION contacts directory will implement a self-service workflow for updates by GLS lawyers’ of
their fundamental contacts directory profile information
–
Submitted changes to GLS lawyers’ fundamental information will require approval by database
administrators (e.g. when a GLS lawyer requests updates to fields that are considered of importance
in terms of statistics)
The lawyer’s record in the database will be updated (once approved by the database administrator), which,
in turn, will be published to the LION contacts directory
Note: fundamental data that requires approval will be defined during in the data model specification (related
to the Lawyers database)
1
BP-003
Contacts directory
editor update
The new LION contacts directory will implement a departmental ‘editor’ update process for contacts
directory profile information. Administrator approval rules to be defined. See requirement LUS -006 in
section 0 for details on this user type
2
BP-004
Audit Lawyers
database records
process
The system will implement a semi-automated process for confirming all lawyers’ details. This will be
manually initiated as a bulk process (usually annually)
1
BP-005
Self-service user
account management
Users with a contacts directory profile can create a user account for the LION extranet without requiring
administrator approval
The account will be activated via a validated email sent to the user's GSi email address registered against
their contacts directory profile
Users without a contacts directory profile but with a record in the Lawyers database can create an account
for the LION extranet but will require administrator approval
The LION administrator will receive an email alert and verify the user offline. On verification, the
1
14-Jul-17, 1:36 AM
Document1
Page 122 of 172
administrator will approve the account creation. The account will then by activated via a validation email
sent to the user's GSi email address registered against their record in the Lawyers database
Users can request a password reminder via an automated function on the LION extranet that will be
validated against their registered GSi email address
Users can request a password reset via an automated function on the LION extranet that will be validated
against their registered GSi email address
User passwords will be encrypted and not visible to LION administrators. However, LION administrators
will be able to trigger a password reset, that will make use of the self-triggered password reset function
described above
14-Jul-17, 1:36 AM
Document1
Page 123 of 172
4.
Approach
In this section we will provide details of our approach to delivery of the project, from a technical, management and security perspective. The section
begins with a general overview of our approach to delivering the LION extranet and Lawyer’s database.
4.1
Overview of our approach
All of our digital projects are based on a methodology we have developed, which we call E4, these help to shape a project as follows:
Evaluate – scope the project and agree requirements, timeframes, etc.
Explore – research and analysis, to provide strategic direction for the project
Envision – creation and development of site architecture, design, content, and full specifications
Execute – site development, content writing, photography, user and site testing, testing and launch
The overview of approach to the project is described within these phases of work and covers both the LION extranet and the Lawyer’s database.
NB: The LION extranet project incorporates the selection and implementation of the CMS.
Some of the key points of our approach are detailed below:
4.1.1
Evaluate
Project initiation
 Activity
This stage of work includes kick off meetings, review of additional project documentation and setting up the project. It also gives us the opportunity to
finalise scope, timings and approach based on the requirements gathering stage below
14-Jul-17, 1:36 AM
Document1
Page 124 of 172
 Deliverable
Statement of Work
Requirement capture
 Activity
We need to validate requirements with stakeholders in order to ensure a comprehensive shared understanding of all requirements. For this project
five workshops have been planned including one for the Lawyer’s database, with additional time for write up, additional review of requirements and
research on specific points occurring around the workshops
 Deliverable
Project Requirements Document (PRD)
Project definition
 Activity
Define in full the project scope, timings, budget and approach based on the requirements capture stage
Finalise the project scope, timings and budget based on prioritisation of requirements
 Deliverable
Project definition document (PDD)
4.1.2
Explore
Given the level of detail in the RFP and technical nature of this project, exploration of the objectives and requirements is rolled into requirements
gathering and specification work, and is not a separate phase of work.
14-Jul-17, 1:36 AM
Document1
Page 125 of 172
4.1.3
Envision
Information Architecture
 Activity
The information architecture stage will begin with the creation of personas and user journeys. These inform the approach to organising the
information in an easy to use, useful manner for the audience
We will then create a site map with navigation principles that accommodate the personas and user journeys before working with you to develop the
site taxonomy (labelling principles). Following sign-off of these elements, we will create wireframes of the key pages describing the types of content
that will sit at different levels of the site
Following a presentation and two amendment rounds, we will annotate the wireframes as an input to the FSD and create a content matrix detailing
where existing content will sit on the new site
 Deliverables
Up to 5 personas and user journeys
Site map and taxonomy
Up to 10 wireframe diagrams with annotations describing navigation
Content matrix
Design
 Activity
Following the information architecture phase, we will be in a position to design the templates based on your brand. This begins with us creating two
concepts that we will present and review with you. On selection of one of the concepts, we will develop a specific route that will complement your
organisation and work well with the structure of the templates
14-Jul-17, 1:36 AM
Document1
Page 126 of 172
Following a second presentation and amendments loop, we will have a final set of designs that we will roll out to 10 key templates and a set of design
assets for the build team
 Deliverables
Concepts
Interface design for up to 10 key wireframes
Design assets for the build team
Specifications
 Activity
Based on the approved information architecture, we will create a functional specifications document (FSD) incorporating a detailed understanding of
how the site will work for end users in terms of navigation, bespoke functionality, specific content types, validation and error messages, etc.
We will ask you to review the FSD and will amend it based on your comments. Once the FSD is signed off, we will be in a position to create test
plans and scripts so that the test team will have a check list of what to test and how the functionality will work
We will also create a technical specification document (TSD) detailing the technical aspects of the project
In parallel with the LION-specific tasks listed above, we will produce the data model specification, defining the full data set required for the Lawyers
database, This document will contain details on all fields, their properties, formats and types, along with a high-level data object diagram
Once the data model specification has been signed off, we will produce the database design document (DDD) incorporating the data model
specification, the entity relationship diagram, screen flow diagrams and database design and architecture.
In addition, we will produce a data migration plan for the Lawyers database, describing the tasks leading up to and including the migration task, along
with any associated post-migration tasks necessary to migrate the data held in the existing system to the new system
14-Jul-17, 1:36 AM
Document1
Page 127 of 172
Finally, we will use these documents to create a test plan, with test scripts, to be used during testing, to ensure the build of the site, functionality and
database functions are as described in the FSD, the TSD and the DDD
 Deliverables
Functional specification document (FSD)
Technical specifications document (TSD)
Database design document (DDD)
Data migration plan
Test plan and scripts
4.1.4
Execute
Development
 Development of the LION extranet site will be based on the FSD, TSD, TDD and interface designs and begin with creation of HTML templates with
associated CSS. These will be quality tested before being handed over to the CMS development team who will build CMS templates and incorporate
the specified functional components
 Development of the Lawyers database will be based on the DDD and completion of the database is a dependency of the new LION extranet, which will
comprise a subset of the database data for the extranet contacts directory section
 See the technical approach section for details of development
Testing and deployment
 The testing process is typically a process of finding faults based on the test plan and scripts created at the specification stage and assigning them to
developers for fixing. These are then re-tested and assigned until they are passed as accepted. Additional testing such as load and penetration testing
may be completed at this time or, alternatively, after deployment
14-Jul-17, 1:36 AM
Document1
Page 128 of 172
 A user acceptance testing process is incorporated in this stage, during which support will be provided to fix and re-test any reported bugs. Completion
of UAT culminates in sign-off from The GLS that the site is fit for purpose before the site is deployed to the production environment and launched
See the technical approach section for details of testing and deployment.
Training
 We will work with The GLS to determine the most appropriate stage in the project at which to train the LION administrators and the Lawyers database
administrators. This may fall between client UAT and deployment to the live environment or post-golive
4.2
Technical approach
4.2.1
Development methodology
Technical development will be executed based on the completed and approved TSD, FSD and interface designs (for the LION extranet) and DDD (for the
Lawyers database).
LION extranet
The LION extranet will be developed using standard CMS development processes. First the interface designs are converted to HTML templates and CSS
files. They will be quality tested, e.g. for accessibility and browser/OS support and any defects fixed before integration with the CMS.
CMS development usually begins with installation in the development environment of the target CMS system and configuration of the base security model
to match the project requirements. This work will be completed early in the project as part of the infrastructure setup and accreditation tasks. Using the
approved HTML and CSS, a master CMS template is created, followed by derivative templates to match all the page types (layouts) required in the final
system. Individual page components are then built to deliver the required functionality – this may involve both server-side (CMS) development and clientside (mainly JavaScript) coding. For certain elements of the LION project, some additional database-level development may be required but this will be
partitioned from the base CMS database to ensure future upgradeability.
14-Jul-17, 1:36 AM
Document1
Page 129 of 172
Some specific LION requirements will require other non-CMS development work, e.g. integration and configuration of Google Search Appliance (GSA) for
site search. There is also a dependency on integration with the Lawyers database, though this dependency can be managed by using ‘stub’ web services
to the database during the build phase, as is common practice.
All development work is thoroughly unit-tested before being handed over to the Quality Assurance department for system-level QA testing, prior to client
UAT.
Lawyers database
Development of the Lawyers database will follow standard processes for a Microsoft Dynamics (MSD) CRM implementation, in which:
 The security model and user types are established
 The base data records are defined in MSD (these are provisionally the lawyers/jobs/leavers records and associated lookup tables)
 The input/edit forms are configured in MSD – this implements the lookup rules and constraints, search, etc.
 Reports templates are defined and built against the database
In addition for this project, some custom development will be required specifically for export to the LION contacts directory, inbound lookups from the
LION extranet and email merging.
The Lawyers database system will then be tested standalone and integrated with LION.
Due to the sensitivity of the Lawyers database information, it is proposed that development and testing prior to client UAT is done with a data set
containing anonymised lawyer records.
Note that for both systems, standard development practices such as peer review of code, strong version/source control and secure partitioning from other
in-development systems, etc. will be applied
Client UAT and deployment
14-Jul-17, 1:36 AM
Document1
Page 130 of 172
Following internal testing of the integrated systems, they will be deployed to a staging environment (production environment in the target hosting) for
client UAT by The GLS. Any fixes from this testing phase will then be pushed through until client sign-off of the system is achieved. This testing phase
may use a test-migration of the LION extranet and/or Lawyers database data and content.
Finally, following client sign-off of the integrated system and the deployment plan, scheduled deployment to the production environment will take place.
This will follow the plan and will involve freezing of the existing systems, final extraction and processing of their data/content if required and loading into
the new systems.
4.2.2
Technology
The technology set that will be used includes:
 SiteCore CMS Professional Edition including Lucene integrated search
 Google Search Appliance, v6.8 for site search
 Microsoft Dynamics CRM v4
Any required custom server-side development will be based on the Microsoft .NET framework to integrate directly with SiteCore and MSD. In-built
features of SiteCore/MSD – such as task scheduling – will be used where possible rather than separate standalone development.
Integration between the Lawyers database and SiteCore will be achieved using standard web services, suitably secured to prevent external access.
Any required web client-side development will be based on ECMA-compliant JavaScript for cross-browser compatibility and future-proofing.
All deployment server systems will be hosted on Windows Server (exact configuration to be determined) and will leverage standard Microsoft server tools
for logging and systems management, as well as those provided specially by the hosting environment.
Lawyers database administrator access still to be determined but will most likely use the MS Dynamics CRM Add-In for Outlook. This has been certified
as “Citrix Ready”, thus integrating with the Windows thin-client desktop environment used by The GLS.
14-Jul-17, 1:36 AM
Document1
Page 131 of 172
4.3
Security
Security needs will be addressed throughout the project in a number of ways.
While the information contained in the LION extranet has not been classified highly there are other elements of the project that require special protection,
including the Lawyers database information and configuration information relating to the GSi/GSe on which the system will be deployed.
Our approach will be, as far as possible, to develop and test the systems in isolation without the live lawyers’ data. To this end, we propose using an
anonymised test data set representing the Lawyers database data (but not containing live data) throughout development and testing. The live Lawyers
database data will be migrated only to the staging system on the secure GSi-based hosting for final GLS user acceptance testing and then transferred (or
re-migrated) to the live system on the same server. This will preclude the need to provide additional security around our development environments and
minimise risks.
The same approach will be used for any other sensitive LION data. For example, if secure content areas are created, these will be simulated on
development/test systems – the content for the secure areas will be populated by The GLS only on the staging environment.
For implementation of the new GSe hosting, security clearances may be required for some personnel involved in this design/deployment. Rufus Leonard
has previously setup a GSx connection and ran an infrastructure on a GSe on behalf of The Office of Government Commerce (OGC). This means we are
familiar with the processes and comply with standards associated with hosting solutions in this fashion. We have Code of Connection (CoCo) accredited
infrastructure and will run a GSx router (through Cable and Wireless) connecting the GSi with the GSe-based solution for TSol. We have securityaccredited developers and support staff who will work on this aspect of the project.
We also have a GSe-accredited secure connection to our offices that was used for live system support for OGC and will be re-accredited for access to the
GLS system if ongoing data-level application support of the live system is required.
Finally, the system design itself will naturally take account of the security requirements. In particular, protection of the Lawyers database as far as
possible within the constraints of the hosting solution selected by The GLS. For example, it is likely that the Lawyers database and LION will be
configured with different user permissions and database accesses restricted by IP range to users from the TSol LAN only. Logging will also be configured
both in the application design and at system level to enable access auditing.
14-Jul-17, 1:36 AM
Document1
Page 132 of 172
5.
Project processes
Deliverables will be provided to The GLS in agreed format for sign-off. Sign-off is required in writing, either by email (referencing the deliverable name and
version) or signed and scanned PDF of the deliverable sign-off page.
5.1
Reviews, feedback, amends and approvals
The project schedule and budget include a specified number of revisions for project work. This is to ensure that the project remains within the agreed
schedule and budget as set at the start of the project.
It is the responsibility of The GLS to ensure that all GLS stakeholders’ feedback is consolidated and delivered to Rufus Leonard in a single feed for each
round and to schedule. Delays in feedback or receipt of unconsolidated/contradictory feedback will impact the project budget and schedule and,
ultimately, delivery.
A round is defined as a single set of collated feedback as agreed by all relevant stakeholders. Where required, Rufus Leonard will initiate discussion with
The GLS before amends are carried out to ensure the feedback is correctly interpreted and implemented.
Feedback should be supplied in writing, either by email or using feedback forms where applicable and as supplied by Rufus Leonard. Where verbal
feedback is provided, this will be supported by a written record to ensure quality and full record.
It is the responsibility of Rufus Leonard to ensure that revisions incorporate the consolidated feedback within scope of the project objectives/briefs and
remain within the agreed budget and schedule. Where feedback falls outside of the scope of the project, or steers the project off brief, this will be
managed via the Rufus Leonard change control procedure.
Should additional rounds of amends be required – outside of the numbers specified section 3.2 – these will be addressed as part of the project change
control procedure.
The number of budgeted revisions is specified against each task in section 3.2 of this document.
14-Jul-17, 1:36 AM
Document1
Page 133 of 172
5.2
Impact of schedule slippage
Rufus Leonard will secure resource to the agreed schedule. This necessitates that client reviews, feedback, approvals and supply of assets and inputs
happen to schedule.
Where a date is specified for feedback, approvals and asset delivery, this is set for 5pm of the specified date.
Should client feedback, approvals or asset delivery slip, this will impact the schedule and – if the secured resource cannot be reassigned – incur
additional costs to the project budget. These instances will be addressed as part of the Rufus Leonard change control procedure
5.3
Change management
Should additional reviews and revisions be required outside the number specified in section 3.2 and should additional deliverables be required not
explicitly stated in this document, The GLS is required to provide a written request for further iterations or additional deliverables, which will be managed
via the Rufus Leonard change control procedure.
Documents and deliverables that have been agreed and signed-off are considered baseline. The change control process also applies to changes to
baselined documents and deliverables.
Rufus Leonard will conduct an impact assessment (against budget, time, quality and resource availability) to determine the impact of the requested
change on the project; this will be recorded in a Change Request document. The GLS will be required to sign off the change request document and
provide purchase orders as required to ensure that all changes are carefully controlled and accounted for with respect to the budget and project schedule.
5.3.1
Change control process description
 The GLS or Rufus Leonard to initiate change request
 The GLS to produce brief/request and use change request form
 Rufus Leonard to complete a change request document with proposed description, turnaround time and breakdown of costs (per resource/hours/day)
14-Jul-17, 1:36 AM
Document1
Page 134 of 172
 Validation: Rufus Leonard to provide completed change request form to COI
 COI to check that it is complete, technically sounded and in line with industry standard metrics/costs. If all is correct, COI to send the change request
form to The GLS for approval
 The GLS to approve the change request and, if approved, to send approval to Rufus Leonard and COI
 COI to raise cost estimate and send to The GLS
 The GLS to send PO number to COI
 COI to send PO to Rufus Leonard and provide authorisation for implementation of the change request
5.4
Risk management
Every project has a degree of inherent risk. During planning we will jointly identify risks associated with the project and assess the likelihood of them
adversely affecting it. These risks, and any new risks identified throughout the course of the project, can then be managed, mitigated against or entirely
avoided.
We manage risks by assessing its impact and likelihood. Based on these criteria, we can decide how to manage and potentially mitigate the risk. All
identified risks are detailed in a risk register, which is assessed and updated with you regularly.
At the point at which a risk starts to impact a project it is re-classified as an issue and added to the issue log, and managed separately.
5.4.1
Risk rating
A fundamental tool to our approach to capturing risks is the RAG score (red, amber and green). The likelihood and impact of each risk is considered in
terms of low, medium and high (e.g. if the likelihood of a risk is high but its impact is low then it’s categorised at risk level 3).
14-Jul-17, 1:36 AM
Document1
Page 135 of 172
Risks with RAG scores that are either green or amber are considered manageable and are therefore relatively safe. However, such risks are still subject
to the usual project scrutiny and de-risking actions are introduced where possible to reduce the risk down to a zero rating.
Risks that are rated red on the RAG score are subject to direct action from both the risk owner and project manager to ensure the risk is fully understood,
controlled and managed. A key aspect of this process is to identify direct actions to reduce the risk to an acceptable level. Such action is not always
possible due to the nature of the risk; in such cases a policy must be agreed by all members of the project teams to maintain the risk at an acceptable
level.
At the heart of every website development project there are numerous reasons why they could fail. Understanding where that failure might lie and how it
can be avoided is an essential factor for success.
For the extranet and database redevelopment project, a robust approach will be necessary. The following sections investigate our approach to a classic
technical build from a project risk perspective.
14-Jul-17, 1:36 AM
Document1
Page 136 of 172
Whatever the nature of the task and the size of the project, risk management and analysis is principally the same. Where the two approaches may differ
is that the light-weight approach could reduce the breadth and complexity of the risk capture and therefore reduce the project overhead.
5.4.2
Approach
At the inception of the project, we recommend potential risks are captured via a risk register to identify, manage and eliminate risk where possible. The
process of managing risks can prove unnecessarily time-consuming unless a simple but rigorous approach is adopted.
In summary, our recommended approach to risk management is captured via the following criteria:
 Brief description of the issues
 Brief description of the impact of such a risk on the overall project or elements of the project
 Accepted project control procedure
 The risk owner who is nominated responsible for managing the potential risk and reducing its impact on the overall project
 Risk rating
 RAG score
 Risk status at the last review date
 Commentary on the progress of the risk
 Date of the last risk status report
When assessing the nature of the risk, the following points (and more) are considered when establishing the RAG score:
 Is the brief vague or ambiguous?
 Is the task technically difficult or challenging?
 Are the budget or time constraints restrictive?
14-Jul-17, 1:36 AM
Document1
Page 137 of 172
 Is there involvement with third parties?
 Is there critical dependency on client-side?
 Is the risk disproportionate to the value of the work to be undertaken?
 Are key client stakeholders in danger of destabilising the project?
5.4.3
Process
Once the risk register has been compiled, it is essential the register is treated as a significant tool for successful project completion. At each project
review meeting we strongly recommend all risks reading Red are discussed and an appropriate course of action to diminish the risk is agreed, logged and
an owner appointed. It is the risk owner who will report back to the project management team at the project review meetings and report on the actions
taken to bring such a risk under control.
Those risks sitting in Amber and Green are closely monitored by the Rufus Leonard project manager and only brought to the project management team’s
attention when their status moves into Red. If required, the full RAG score is discussed at project review meetings.
5.4.4
High-level risk assessment
Nature of risk
Impact on the project
Prob-
Impact
RAG
Actions required to mitigate risk
ability
14-Jul-17, 1:36 AM
Document1
Page 138 of 172
The GLS resource/stakeholders unavailable
for input and participation per the agreed
schedule.
Schedule impact including availability of
Rufus Leonard
resource. Delay in
delivery. Possible
impact on costs if
Rufus Leonard
scheduled resource
cannot be reassigned.
[INFORMA
TION
REDACTE
D UNDER
SECTION
43
FREEDO
M OF
INFORMA
TION
ACT]
[INFORMA
TION
REDACTE
D UNDER
SECTION
43
FREEDOM
OF
INFORMAT
ION ACT]
Rufus Leonard resource unavailable per the
agreed schedule.
Schedule impact.
Delay in delivery.
[INFORMA
TION
REDACTE
D UNDER
SECTION
43
FREEDO
M OF
INFORMA
TION
ACT]
[INFORMA
TION
REDACTE
D UNDER
SECTION
43
FREEDOM
OF
INFORMAT
ION ACT]
14-Jul-17, 1:36 AM
Document1
[INFOR
MATION
REDAC
TED
UNDER
SECTIO
N 43
FREED
OM OF
INFORM
ATION
ACT]
[INFOR
MATION
REDAC
TED
UNDER
SECTIO
N 43
FREED
OM OF
INFORM
ATION
ACT]
The GLS to ensure resource is booked in
advance per the agreed project schedule,
or approve subsequent schedule and cost
adjustments to accommodate delay.
Rufus Leonard will ensure resource is
available and, where required, will engage
additional resource.
Page 139 of 172
The GLS unable to provide materials, assets
and inputs per the agreed schedule.
Schedule impact including availability of
Rufus Leonard
resource. Delay in
delivery. Possible
impact on costs if
Rufus Leonard
scheduled resource
cannot be reassigned.
[INFORMA
TION
REDACTE
D UNDER
SECTION
43
FREEDO
M OF
INFORMA
TION
ACT]
GSe compliance means that once both
systems are live, data cannot be transferred
from Rufus Leonard/Endava over the
proposed secure VPN. This requirement
pertains to transmission of the LION extranet
content data and Lawyers database records
data and does not apply to application code or
software.
This impacts postlaunch support tasks
where these tasks
include content and
records data.
[INFORMAT
ION
REDACTED
UNDER
SECTION
43
FREEDOM
OF
INFORMATI
ON ACT]
14-Jul-17, 1:36 AM
Document1
[INFORMA
TION
REDACTE
D UNDER
SECTION
43
FREEDOM
OF
INFORMAT
ION ACT]
[INFOR
MATION
REDACT
ED
UNDER
SECTIO
N 43
FREEDO
M OF
INFORM
ATION
ACT]
[INFORM [INFOR
ATION
MATION
REDACT REDAC
ED
TED
UNDER
UNDER
SECTION SECTIO
43
N 43
FREEDO FREED
M OF
OM OF
INFORM INFORM
ATION
ATION
ACT]
ACT]
The GLS to source relevant materials,
assets and inputs in advance per the
agreed project schedule, or approve
subsequent schedule and cost adjustments
to accommodate delay.
Agree a deployment process with The
GLS whereby The GLS scans and
transfers the data to the production
environment in compliance with GSe
connection terms. Thereafter Rufus
Leonard/Endava will access the
production environment to complete
deployment of the fixes/changes.
Page 140 of 172
Rufus Leonard requires access to the existing
LION backend system to assess content
export feasibility and then to export content. If
this access cannot be provided then export of
the content becomes the responsibility of The
GLS.
Impacts the content
migration plan, which
will need to factor in
how existing content
can be exported to a
format suitable for
import into the new
system.
The GLS may need to
procure effort from
incumbent provider to
export content to a
suitable format for
import into the new
system.
[INFORMAT
ION
REDACTED
UNDER
SECTION
43
FREEDOM
OF
INFORMATI
ON ACT]
Changes required to the proposed hosting
environment configuration (illustrated in
section 10.1 of this document) and costs (see
section 9.6 of this document) as a result of
policy changes applied by external parties
(e.g. OGC buying Solutions, Cable and
Wireless, etc.)
Impacts the
configuration and cost
of the proposed
hosting infrastructure,
thereby impacting the
budget.
May impact the project
schedule if changes
are requested too late
for inclusion in the
scheduled CSEG
accreditation task, thus
delaying availability of
the staging
environment with a
knock-on effect on
client UAT and launch.
[INFORMAT
ION
REDACTED
UNDER
SECTION
43
FREEDOM
OF
INFORMATI
ON ACT]
14-Jul-17, 1:36 AM
Document1
[INFORM
ATION
REDACT
ED
UNDER
SECTION
43
FREEDO
M OF
INFORM
ATION
ACT]
[INFORM
ATION
REDACT
ED
UNDER
SECTION
43
FREEDO
M OF
INFORM
ATION
ACT]
[INFOR
MATION
REDAC
TED
UNDER
SECTIO
N 43
FREED
OM OF
INFORM
ATION
ACT]
[INFOR
MATION
REDAC
TED
UNDER
SECTIO
N 43
FREED
OM OF
INFORM
ATION
ACT]
Early migration assessment and planning
will be required to ensure all parties agree
to a workable migration methodology to
schedule.
Regular communication with all parties to
identify any potential issues as early in the
process as possible.
Page 141 of 172
GSi accreditation – while we believe that
sufficient time has been allocated in the
project schedule for acquiring GSi
accreditation, there are many factors outside
of Rufus Leonard control that may delay the
process.
Delay to deployment to
staging of the Lawyers
database for client
UAT. Impacts overall
schedule and budget
of the Lawyers
database
implementation.
[INFORMAT
ION
REDACTED
UNDER
SECTION
43
FREEDOM
OF
INFORMATI
ON ACT]
GSi SMTP central relay – owners of the
system have yet to be identified and,
therefore, there is a risk that setting up access
to use the SMTP server may be more of an
arduous process than expected
Impacts setup of the
infrastructure for
CSEG accreditation.
[INFORMAT
ION
REDACTED
UNDER
SECTION
43
FREEDOM
OF
INFORMATI
ON ACT]
14-Jul-17, 1:36 AM
Document1
[INFORM
ATION
REDACT
ED
UNDER
SECTION
43
FREEDO
M OF
INFORM
ATION
ACT]
[INFORM
ATION
REDACT
ED
UNDER
SECTION
43
FREEDO
M OF
INFORM
ATION
ACT]
[INFOR
MATION
REDAC
TED
UNDER
SECTIO
N 43
FREED
OM OF
INFORM
ATION
ACT]
[INFOR
MATION
REDAC
TED
UNDER
SECTIO
N 43
FREED
OM OF
INFORM
ATION
ACT]
Regular communication with all parties to
identify any potential issues as early in the
process as possible.
Working closely with The GLS to ensure
lines of communication are opened with
the relevant parties and all necessary
steps agreed to set up connection to the
server.
Page 142 of 172
Rufus Leonard is not familiar with Lotus
Domino systems.
LION content migration
planning and content
migration tasks will be
affected.
[INFORMAT
ION
REDACTED
UNDER
SECTION
43
FREEDOM
OF
INFORMATI
ON ACT]
IA integrity – allowing administrators and
content owners to rename, add and delete
pages at level 1 may degrade the information
architecture integrity of the site (depending on
the design).
Post-launch, this may
impact requirement
ML1-005 IA longevity.
[INFORMAT
ION
REDACTED
UNDER
SECTION
43
FREEDOM
OF
INFORMATI
ON ACT]
14-Jul-17, 1:36 AM
Document1
[INFORM
ATION
REDACT
ED
UNDER
SECTION
43
FREEDO
M OF
INFORM
ATION
ACT]
[INFORM
ATION
REDACT
ED
UNDER
SECTION
43
FREEDO
M OF
INFORM
ATION
ACT]
[INFOR
MATION
REDAC
TED
UNDER
SECTIO
N 43
FREED
OM OF
INFORM
ATION
ACT]
[INFOR
MATION
REDAC
TED
UNDER
SECTIO
N 43
FREED
OM OF
INFORM
ATION
ACT]
GLS to provide suitable personnel to
support the Rufus Leonard content
extraction task.
Ensure any limitations around the number
of pages allowed and the maximum
character lengths for the naming of level 1
pages is clearly defined in the
administrator and content owner
documentation.
Page 143 of 172
SiteCore plug-ins – in addition to the core
SiteCore product, there are a number of
SiteCore approved and supported plug-ins
that have been identified to facilitate some of
the requirements such as calendars. Due
diligence has been carried out by checking the
documentation of these plug-ins to ensure
they meet the requirements. However, for
certain plug-ins, these have not previously
been used or tested against GLS’s specific
requirements (e.g. the amalgamated
calendar).
Impacts development
of the LION CMS
system.
[INFORMAT
ION
REDACTED
UNDER
SECTION
43
FREEDOM
OF
INFORMATI
ON ACT]
Database data migration – moving data from a
non-relational format to a relational database
may require a greater amount of manual
intervention than currently specified.
Impacts the data
migration task for the
Lawyers database,
requiring more effort to
complete the migration
[INFORMAT
ION
REDACTED
UNDER
SECTION
43
FREEDOM
OF
INFORMATI
ON ACT]
14-Jul-17, 1:36 AM
Document1
[INFORM
ATION
REDACT
ED
UNDER
SECTION
43
FREEDO
M OF
INFORM
ATION
ACT]
[INFORM
ATION
REDACT
ED
UNDER
SECTION
43
FREEDO
M OF
INFORM
ATION
ACT]
[INFOR
MATION
REDAC
TED
UNDER
SECTIO
N 43
FREED
OM OF
INFORM
ATION
ACT]
[INFOR
MATION
REDAC
TED
UNDER
SECTIO
N 43
FREED
OM OF
INFORM
ATION
ACT]
Early identification of potentially
problematic plug-ins and a suitable
alternative identified (potentially using
bespoke .NET code).
Ensure the data is cleaned by The GLS
prior to export from the existing system
and any erroneous data is removed prior
to import of the data. Ensure that import
scripts accurately capture and report
errors during the import process
Page 144 of 172
MSD integration – a plug-in for Outlook has
been identified for use with MS Dynamics;
however there may be system limitations of
The GLS and potential conflicts with other
software installed on users’ machines.
Impact integration with
Outlook during
[INFORMAT
ION
REDACTED
UNDER
SECTION
43
FREEDOM
OF
INFORMATI
ON ACT]
Templates – the number of templates we will
produce during IA and build as is based on
previous experience). We will make every
effort to keep within this number of templates
but this cannot be guaranteed.
More time and more
budget required to
create more templates
during IA, design more
interface during design
and build more HTML
templates.
[INFORMAT
ION
REDACTED
UNDER
SECTION
43
FREEDOM
OF
INFORMATI
ON ACT]
14-Jul-17, 1:36 AM
Document1
[INFORM
ATION
REDACT
ED
UNDER
SECTION
43
FREEDO
M OF
INFORM
ATION
ACT]
[INFORM
ATION
REDACT
ED
UNDER
SECTION
43
FREEDO
M OF
INFORM
ATION
ACT]
[INFOR
MATION
REDAC
TED
UNDER
SECTIO
N 43
FREED
OM OF
INFORM
ATION
ACT]
[INFOR
MATION
REDAC
TED
UNDER
SECTIO
N 43
FREED
OM OF
INFORM
ATION
ACT]
Work closely with The GLS to identify
potential issues early on and establish
workarounds/alternatives with the internal
teams at The GLS
Agree with The GLS on how templates
can be rationalised in a manner not
detrimental to the quality of delivery
Page 145 of 172
Search – in order to meet all of the search
requirements, two search solutions have been
identified.
5.5
Impacts the IA work
stream and may
increase the effort
required to design the
search user
experience, thereby
impacting both budget
and schedule
[INFORMAT
ION
REDACTED
UNDER
SECTION
43
FREEDOM
OF
INFORMATI
ON ACT]
[INFORM
ATION
REDACT
ED
UNDER
SECTION
43
FREEDO
M OF
INFORM
ATION
ACT]
[INFOR
MATION
REDAC
TED
UNDER
SECTIO
N 43
FREED
OM OF
INFORM
ATION
ACT]
During the IA work stream, Rufus Leonard
will identify how best to maximise the user
experience of this combined solution.
Quality management
The need to ensure quality throughout this project requires that we can provide assurance both for the creative parts of the project (such as website
design and information architecture) and for the technical elements of the project, such as adhering to accessibility standards and testing of digital
deliverables.
As our case studies illustrate, Rufus Leonard has solid experience in delivering great brand/design and digital projects, particularly within the public sector
where the need for easy to use, accessible sites are key. This is demonstrated, for example, by having an in-house usability testing lab and a digital
testing team who oversee all development work to ensure quality and accessibility standards are delivered.
5.5.1
Brand and visual quality assurance
The development of any brand and visual identity is always at risk of being overly influenced by subjective views and preferences of the design team and
client. It is possible, however, to ensure that before we begin the creative process, we gather information (audits, interviews, reviews, research) that will
provide strong indicators and direction for brand and design development. This is intrinsic to the brand methodology that we use at Rufus Leonard which
has three key strands:
14-Jul-17, 1:36 AM
Document1
Page 146 of 172
 Understand – your organisation, your competitors, your views
 Define – how you should evolve (leading to the delivery of a creative brief, developed with you)
 Express – the new brand providing initial concepts that are reviewed and refined.
We also ensure that our designers follow industry best practice as part of the design process. For example, we know that any brand needs to work well
online and offline, so this will be considered when reviewing how the logo and typeface could work in different media - while the logo might look good
online, how will it print at a small size on an office printer?
We build client review and amendment cycles to all our plans, allowing for both client and user testing feedback to be incorporated into the next revisions
of the designs.
Our resource heads and project managers provide internal quality control throughout the process, checking that all designs are on brief and that revisions
have included considerations of all client and user testing comments.
Details of the frequency of quality control activities, is provided in the accompanying project plan. Finally, we provide you with a Client Partner or Account
Director who is there to ensure your expectations are being met, and acts as your representative within the project team.
In summary:
 Follow our brand development methodology
 Develop creative brief for design team that is signed-off by client
 Follow industry best practice
 Build in review and amendment time within each design iteration, taking on board client and user testing feedback
 Quality control provided by resource heads and project management before any designs released to client
 Account Director provides additional layer of assurance, acting as client representative on the project.
5.5.2
Digital quality assurance
14-Jul-17, 1:36 AM
Document1
Page 147 of 172
The development of websites and digital assets is by nature more scientific than brand and design activity. It is, therefore, easier to ensure that quality
standards have been met and the build is fit for purpose.
With 15 years experience in delivering digital projects, we have developed a suitable digital methodology, E4 (detailed in section 4.1) that underpins all
phases of the project and ensures we have the processes and procedures in place to ensure a successful project, with quality expectations met.
Each key stage and all phases require client sign-off before we move on to the next stage of work. This minimises any rework, or confusion as to the
project deliverables. In addition to meeting quality expectations, budget and timings are also reviewed at this time.
As well as following our E4 methodology for digital projects, we also have several PRINCE 2 practitioners. We recognise that using PRINCE 2 provides
tool that can enable continuous quality assurance. For example, clearly defining requirements and deliverables makes it easier for clients to sign off
deliverables with confidence that the acceptance criteria have been met.
Part of our standards process is to create a functional specifications document that details how all elements of the front-end build are expected to work.
This is followed by technical specifications and technical design documents, which detail the platform, architecture and technical design of the
infrastructure environment and the backend elements.
These become central documents where the quality of the build can be tested against the specification. This is done using test scripts for our test teams,
who use the ISEB-based testing methodology. This includes our test team initially testing all functionality and templates against the scripts and agreed
accessibility standards, and logging all fails in a detailed in a tracker, which is available to the client to view throughout development.
The developer will then make amendments and retesting will occur until the testing team are satisfied all agreed criteria are met.
Following the successful testing processes, we make deliverables available for the client to undertake user acceptance testing. This involves the client
checking deliverables independently of our test team, working to a plan evolved as part of creation of the FSD. UAT forms part of a wider approach to
quality assurance in which we follow a V-Model test strategy, whereby testing is introduced early on the development life cycle and testing and
development activities occur in parallel. At Rufus Leonard we have separate, secure environments for our development, quality assurance and User
Acceptance Testing (UAT).
In summary:
14-Jul-17, 1:36 AM
Document1
Page 148 of 172
 Follow our digital development methodology E4 and use of PRINCE2
 Develop functional specifications document (FSD) and test scripts
 Develop technical specifications document (TSD) and technical design document (TDD)
 Client user acceptance testing
 Follow industry best practice and adhere to appropriate standards and guidelines
 Build in review and amendment time within each key stage, taking on board client and user testing feedback
 Quality control provided by testing team, resource heads and project management before any releases to client
The Account Director provides an additional layer of assurance, acting as client representative on the project.
5.5.3
Promotional Test Model
In addition to our general digital quality principles, our partners Endava have developed the Promotional Testing Model (PTM) over a number of years
working on large financial systems. The PTM provides a framework for taking releases of code from a development team (or multiple teams) and
applying (in order) various testing phases that enable successful deployment into Live Production. The following diagram gives an example of a
Promotional Testing Model.
14-Jul-17, 1:36 AM
Document1
Page 149 of 172
The key concept is that once a phase of testing is complete (and the acceptance criteria are met) it is then promoted to the next phase. Each phase has
its own focus for finding defects and is resourced (people, data and environments) according to the needs of that testing phase. Each testing phase
(including the early phases) consists of both Functional & Non Functional (e.g. Performance & Load) testing aspects, with test automation (including test
harnesses, stubs & drivers) and regression testing being a fully integrated part of the testing effort. In addition, the use of Production (Live) data is key to
ensuring the success of the system in production, together with testing on pre-production environments that themselves get promoted into the production
zone (thus ensuring the operational transition and support of the system).
Key Testing Involvement:
From the types of testing outlined in the diagram above, Endava has planned the following for this project:
 Unit Testing will be a key component, where applicable. Unit tests are written by the project developers
 System Test, executed by testers – both manual and automatic – using Selenium
 Load Testing, to test for non-functional requirements
5.5.4
Specific information relating to our approach to quality
Accessibility standards
Inclusive design means addressing the needs of all segments, and giving all users an equal opportunity to use the internet. Users with special needs will
be addressed in our design, and any template design will need to be optimised and tested so that it can be used by users with a range of impairments,
from visual (blindness, colour blindness), to auditory, cognitive and motor. Access to the internet with a range of assistive technologies will also be
considered.
Rufus Leonard will ensure that all work completed for the website is accessible to disabled internet users by following the latest version of the Web
Content Accessibility Guidelines (WCAG 3) developed by the Web Accessibility Initiative (WAI).
14-Jul-17, 1:36 AM
Document1
Page 150 of 172
The WCAG guidelines have become widely accepted as the international standard for accessible web design. The guidelines are divided into three
different priority levels. Priority one guidelines are the minimum measures that must be taken to ensure that disabled intranet users can have any degree
of access at all to a site. Priority two guidelines should be followed to ensure a site is easier for disabled intranet users to use. Priority level three
guidelines should be followed to create a site that offers disabled Intranet users optimum user experience.
We recommend that all work we complete conforms to a minimum priority two standard. This ensures that all site content and functionality is accessible to
disabled internet users as defined in the WCAG whilst minimising the development costs. Testing for accessibility compliance is a part of the scope of this
proposal. We will ensure compliance according to these guidelines, within the scope of work we undertake.
We have previously worked with the RNIB as well as other third party bodies (such as Segala and the Shaw Trust) to gain accreditation and would enjoy
working with them again to ensure accreditation for your site is forthcoming. Please note that accreditation should be sought both at the template sign-off
stage and also prior to the launch of the sites. We will ensure that the site pages may be operated via the use of access keys (UK Government Standard)
and that pages are ‘readable’ by common screen reader software and may be operated using voice recognition software. Our existing test bed includes a
number of screen reader applications.
Rufus Leonard is familiar with PAS 78/Draft BS 8878 having been previously chosen by one of the BS 8878 advisory board to comment on the document
from the perspective of a design agency. Many of the practices found in PAS 78/Draft BS 8878 follow our own in-house practices and we would welcome
the chance to work with a client in complying fully with its recommendations.
Compatibility
Rufus Leonard has an extensive test lab that covers a wide variety of browsers and platforms combinations. The test lab consists of multiple virtual test
machines which utilise a variety of PC and Mac operating systems. Each machine is locked down to ensure no unwanted software is installed on the
machine that could invalidate the testing.
The Rufus Leonard test team has a thorough and extensive knowledge of web, mobile and assistive browsers. We understand the limitations of certain
browsers and can pinpoint areas of a website which may be problematic for them. In addition we have up-to-date knowledge of the usage statistics for
each browser enabling us to advise clients on which browsers to support and what percentage of the market this will cover, both in the UK and globally.
14-Jul-17, 1:36 AM
Document1
Page 151 of 172
5.6
User acceptance tests
The following process will be used for UAT:
 The GLS or third party will develop a test plan and scripts
 Once the system has achieved the exit criteria for system testing, Rufus Leonard will prepare the staging environment for UAT and will deliver a
release note to COI/The GLS
 A UAT kick-off meeting will be held (conference call if necessary) and a daily cut-off for logging observations is agreed
 Testing will be conducted by a GLS-nominated UAT company, The GLS and COI (to be confirmed)
 Observations will be recorded in an online bug tracker tool set up by Rufus Leonard prior to UAT. Each observation will categorised and defects will be
allotted a severity according to the table below
 A daily wash-up call between Rufus Leonard and The GLS will be held to review new observations and defects and clarify their circumstances,
categorisation and severity
 New releases will be installed at agreed intervals during testing. The exact timing will depend on the number and severity of observations recorded
 UAT will be deemed completed when all tests have been run and the system meets the defined exit criteria
 Note: all defects reported should be fixed before deployment. Only The GLS can accept if any of the reported bugs remain unfixed for deployment. It is
expected that critical or major bugs will not be reported during UAT.
Defect severities:
1 – Critical
Catastrophic defect that causes total failure of the software or unrecoverable data loss. There is no work around. In general, a
severity 1 defect would prevent the product from being released.
2 – High
14-Jul-17, 1:36 AM
Defect results in severely impaired functionality. A work around may exist but its use is unsatisfactory. In general, a product will not be
Document1
Page 152 of 172
released with such a defect.
3 – Medium
Defect causes failure of non-critical aspects of the system. There is a reasonably satisfactory work around. The product may be
released if the defect is documented, but the existence of the defect may cause user dissatisfaction.
4 – Low
Defect of minor significance. A work around exists or, if not, the impairment is slight. Generally, the product could be released and
most customers would be unaware of the defect's existence or only slightly dissatisfied.
Design and cosmetic issues. For example a copy change or image correction.
14-Jul-17, 1:36 AM
Document1
Page 153 of 172
6.
Organisation
6.1
GLS roles and responsibilities
6.1.1
Senior Responsible Owner
Responsible for the overall direction and management of the Programme. Acts as the project’s ‘voice’ to the outside world and supported by the GLS
Systems Programme Board.
The GLS
 [INFORMATION REDACTED UNDER SECTION 40 FREEDOM OF INFORMATION ACT]
Responsibilities and escalation
Overall Responsibilities:
 The SRO is ultimately accountable for the project, supported by the GLS Systems Programme Board
 The SRO will ensure that the project gives value for money, ensuring a Business Case focused approach to the project
 The SRO is responsible for the overall business direction of the project, i.e. that it remains on target to deliver products which will achieve the
expected business benefits, and the project will complete within its agreed tolerances for budget and schedule
Specific Responsibilities:
 Ensuring that there is a coherent project structure and logical plans, appointments will be made by the SRO, assisted by the Project Manager
 The SRO ensures the Board performs the responsibilities detailed in its delegated remit, and Chairs the Project Board meetings
 In addition the SRO is specifically responsible for escalating serious problems
14-Jul-17, 1:36 AM
Document1
Page 154 of 172
 Agreeing project, stage and phase tolerances1
Approve/authorise on behalf of The GLS:
 Project definition document (which incorporates the scope, schedule and budget)
 Change requests
 Exceptions
 Completion of each stage/phase and authorise the start of the next stage/phase
 Final project delivery
6.1.2
GLS Systems Programme Board
The GLS
 [INFORMATION REDACTED UNDER SECTION 40 FREEDOM OF INFORMATION ACT] (SRO)
 [INFORMATION REDACTED UNDER SECTION 40 FREEDOM OF INFORMATION ACT] (GLS Secretariat)
 [INFORMATION REDACTED UNDER SECTION 40 FREEDOM OF INFORMATION ACT] (Finance)
 [INFORMATION REDACTED UNDER SECTION 40 FREEDOM OF INFORMATION ACT] (ICT)
 [INFORMATION REDACTED UNDER SECTION 40 FREEDOM OF INFORMATION ACT] (LION Management
Board)
 [INFORMATION REDACTED UNDER SECTION 40 FREEDOM OF INFORMATION ACT] (Information
Assurance)
 [INFORMATION REDACTED UNDER SECTION 40 FREEDOM OF INFORMATION ACT] (PM)
14-Jul-17, 1:36 AM
Document1
Page 155 of 172
Responsibilities and escalation
Ultimate responsibility for:
 Responsible for the overall direction and management of the Programme
 Acts as the project’s ‘voice’ to the outside world
 Monitoring business risks outside the project that may affect the project
6.1.3
Senior User
The GLS
 [INFORMATION REDACTED UNDER SECTION 40 FREEDOM OF INFORMATION ACT]
Responsibilities and escalation
Overall Responsibility:
 The Senior User represents the Users and ensures that the needs of all those who will be impacted by the project are specified and supported,
and that their needs are met
 The Senior User ensures deliverables are continuously monitored against requirements and that user resources are identified and where
possible, provided
 The Senior User is accountable for any products supplied by the users, such as making sure that requirements have been clearly and
completely defined, that what is produced is fit for its purpose and for monitoring that the solution will meet user needs
Specific Responsibilities:
 Provide user resources; ensure that the project produces products and outcomes that meet user requirements; ensures that the products and
outcomes provide the expected user benefits.
14-Jul-17, 1:36 AM
Document1
Page 156 of 172
 Ensuring changes to scope, cost or schedule are checked against their possible effects on the business case
 Providing information and inputs required to produce the project products and deliverables
 Procuring stakeholder participation in review and feedback of project products and deliverable
6.1.4
LION Focus Group
Project management runs the project on a day-to-day basis on behalf of the project owners. The project manager’s prime responsibility is to ensure the
project delivers the identified deliverables to the required standard of quality, and within the specified constraints of time and cost.
The GLS
Responsibilities and escalation
Overall Responsibility:
 To represent The GLS Secretariat and LION Management Board interests within the project
 The LION Focus Group is represented on the project Board
6.1.5
Project Assurance
Project management runs the project on a day-to-day basis on behalf of the project owners. The project manager’s prime responsibility is to ensure the
project delivers the identified deliverables to the required standard of quality, and within the specified constraints of time and cost.
TSol and COI
 [INFORMATION REDACTED UNDER SECTION 40 FREEDOM OF INFORMATION ACT] (Information
Assurance, TSol)
 [INFORMATION REDACTED UNDER SECTION 40 FREEDOM OF INFORMATION ACT] (Technical
14-Jul-17, 1:36 AM
Document1
Page 157 of 172
Assurance - COI)
Responsibilities and escalation
Overall Responsibility:
 Monitor all aspects of the project’s performance and products
 Assurance covers all interests of a project, including Business, User and Supplier
 Project assurance will be independent of the Project Manager
6.1.6
Project Manager
Project management runs the project on a day-to-day basis on behalf of the project owners. The project manager’s prime responsibility is to ensure the
project delivers the identified deliverables to the required standard of quality, and within the specified constraints of time and cost.
TSol
 [INFORMATION REDACTED UNDER SECTION 40 FREEDOM OF INFORMATION ACT]
Responsibilities and escalation
Overall Responsibility:
 Manage the project on a day to day basis, on behalf of the Board within the constraints laid down by the Board
 Ensure the project produces the required products to the required standard of quality and within the specified constraints of time and cost
 Responsible for the project producing a result that is capable of achieving the approved benefits
Specific Responsibilities:
14-Jul-17, 1:36 AM
Document1
Page 158 of 172
 Manage the production of the required products
 Plan and monitor the project and delivery partners
 Take responsibility for overall progress and use of resources and initiate corrective action where necessary
 Liaise with the Project Board, Project Teams and stakeholders, regularly reporting progress to the Board
6.2
Rufus Leonard roles and responsibilities
Rufus Leonard is the nominated Senior Supplier and represents the interests of those designing and developing the project products. The Senior
Supplier is accountable for the quality of products delivered.
Overall responsibilities include:
 Advise on the selection of development strategy, design and methods
 Monitor potential changes and their impact on the correctness, completeness and integrity of products
 Monitor any risks in the production aspects of the project; ensure quality control procedures are used correctly, so that products adhere to
requirements
6.2.1
Board Report
Rufus Leonard
[INFORMATION REDACTED UNDER SECTION 40 FREEDOM OF INFORMATION ACT]
Responsibilities and escalation
Own:
 Project quality
14-Jul-17, 1:36 AM
Document1
Page 159 of 172
 Project finance
Role:
 The Board Report has overall responsibility for ensuring Rufus Leonard meets client expectations and will be the highest escalation point with
any issues raised by The GLS and COI
Ultimate responsibility for:
 Client satisfaction
 Attend key presentation and review meetings
 Monitoring the progress of the work throughout the contract
6.2.2
Client Partner
Rufus Leonard
[INFORMATION REDACTED UNDER SECTION 40 FREEDOM OF INFORMATION ACT]
Responsibilities and escalation
Own:
 Project finance
 Rufus Leonard resource
 Rufus Leonard deliverables
14-Jul-17, 1:36 AM
Document1
Page 160 of 172
 Relationship with The GLS
 Relationship with COI
Ultimate responsibility for:
 Ensuring all project output is to agency and industry best practice and to brief and to scope
 Ensuring the project remains viable
 Ensuring the project is appropriately resourced
 Ensuring risks are being controlled
 Monitoring business risks outside the project that may affect the project
 Ensuring project, stage and phase risks are tracked and mitigated effectively
 Ensuring changes to scope, cost or schedule are checked against their possible effects on the business case
 Agreeing project, phase and stage tolerances
Approve/authorise on behalf of Rufus Leonard:
 Project definition document (which incorporates the scope, schedule and budget)
 Briefs
 Change requests
 Exceptions
14-Jul-17, 1:36 AM
Document1
Page 161 of 172
Delivery flow/escalation:
 To the Rufus Leonard board report
 To The GLS Senior Responsible Owner
6.2.3
Development Consultant
Rufus Leonard
[INFORMATION REDACTED UNDER SECTION 40 FREEDOM OF INFORMATION ACT]
Responsibilities and escalation
Ultimate responsibility for:
 Translating business and user requirements into project requirements and specifying the solution to meet the agreed requirements
 Writing or contributing to project requirements document (PRD)
 Writing and/or supervising the production of technical specifications document (TSD)
 Oversight of the information architecture and interface design
 Writing and/or supervising the production of system design and functional specifications (FSD)
 Writing and/or supervising the production of the database design document (DDD)
 Writing and/or supervising the production testing and implementation plans
 Specifying the development team and overseeing the development, testing and deployment process of a project
 Managing the development team during the build, test, implement and deployment stages
14-Jul-17, 1:36 AM
Document1
Page 162 of 172
 Build program management
 Test program management
 Project technical delivery and deployment
 Maintenance and support plans
 Estimating time to complete for development, testing and deployment tasks
Delivery flow/escalation:
 To the Rufus Leonard project manager
6.2.4
Project Manager
The Project Manager runs the project on a day-to-day basis on behalf of Rufus Leonard. The project manager’s prime responsibility is to ensure the
delivery to quality, budget and schedule.
Rufus Leonard
[INFORMATION REDACTED UNDER SECTION 40 FREEDOM OF INFORMATION ACT]
Responsibilities and escalation
Specific responsibilities:
 Planning and monitoring the project
 Preparing the PRD
 Preparing the SOW (including project scope, schedule and cost estimate)
14-Jul-17, 1:36 AM
Document1
Page 163 of 172
 Preparing exception plans
 Managing the risk log
 Oversight of the issue log
 Managing change control
 Managing version control of documentation and deliverables
 Managing production of the required deliverables
 Managing Rufus Leonard resource
 Monitoring overall progress and use of resources (and initiating corrective action where necessary)
 Preparing and delivering communications per the communication plan
 Liaising with the TSol Project Manager, the Rufus Leonard Account Director and the Rufus Leonard Board Report regarding overall direction and
integrity of the project
 Identifying and obtaining the support and advice required for the management, planning and control of the project
Delivery flow/escalation:
 To the Rufus Leonard Account Director
 To the TSol project manager
Liaison:
 With the TSol Project Manager
14-Jul-17, 1:36 AM
Document1
Page 164 of 172
14-Jul-17, 1:36 AM
Document1
Page 165 of 172
7.
Communication
As best practice, we will deliver a number of project reports to keep The GLS project team apprised of project status.
7.1
Status reporting
A weekly highlight report will be prepared by the Rufus Leonard project manager to provide the Rufus Leonard account director and the TSol project
manager with a summary of the project status, for subsequent distribution to the Rufus Leonard board report and The GLS project owners and sponsor
The status report will be delivered by email (using the agreed highlight report template) by 4pm on Thursdays and will comprise:
 Date and period covered
 Budget status summary
 Schedule status summary
 Summary of deliverables/documents completed during the period
 Summary of actual/potential problems and risk update where required
 Summary of deliverables to be completed during next period
 Budget and schedule impact of any changes
7.2
PM sync
A weekly phone conference or face-to-face meeting between the TSol and Rufus Leonard project managers is recommended to monitor and track all
aspects of the project, covering:
 Overall project status (including budget, schedule, quality, risks and issues)
14-Jul-17, 1:36 AM
Document1
Page 166 of 172
 Completion of agreed actions
 Set follow-on actions
Phone call/meeting notes will be distributed to the TSol project manager and the Rufus Leonard account director.
7.3
Meeting and phone call notes
Notes will be taken at all meetings and during all phone calls between Rufus Leonard and The GLS, TSol and COI where options are discussed and
decisions made. These notes will be distributed to participants and to the Rufus Leonard account directory and the TSol project manager if not also
present.
14-Jul-17, 1:36 AM
Document1
Page 167 of 172
8.
Timings
8.1
Schedule
Please refer to the detailed project plan for low-level schedule information: TS1001_schedule_v2.0.mpp
Task timings shown in the schedule are estimates, however, key milestones will be met as defined in section 8.2 below.
8.2
Milestones
The following key milestones will be met against the contract:
01-Feb-11
GLS approval of v2.0 of the Project Definition Document
14-Feb-11
GLS decision on hosting provider
22-Aug-11
GLS UAT on the Lawyers database
07-Oct-11
GLS UAT on the LION extranet integrated with the Lawyers database
14-Jul-17, 1:36 AM
Document1
Page 168 of 172
9.
Contract and budget
9.1
Contractual basis
The following refers to the COI Framework Agreement and indicates dispute resolution procedure, liquidated damages and contract termination.
9.1.1
Dispute Resolution
Ref Clause 2.32 in the Framework Agreement:
On a day–to-day basis the escalation path on Rufus Leonard’s side would be Project Manager, Client Partner, Board Report, and Managing Director. As
far as we understand these correspond to Project Manager, Senior User and Senior Responsible Owner at The GLS and TSol.
9.1.2
Contract Termination
This is dealt with under clauses 2.27, 2.28, 2.29 and 2.30 of the COI Digital Framework Agreement.
9.2
[INFORMATION REDACTED UNDER SECTION 43 FREEDOM OF INFORMATION ACT]
9.3
[INFORMATION REDACTED UNDER SECTION 43 FREEDOM OF INFORMATION ACT]
9.4
[INFORMATION REDACTED UNDER SECTION 43 FREEDOM OF INFORMATION ACT]
9.5
[INFORMATION REDACTED UNDER SECTION 43 FREEDOM OF INFORMATION ACT]
14-Jul-17, 1:36 AM
Document1
Page 169 of 172
9.6
[INFORMATION REDACTED UNDER SECTION 43 FREEDOM OF INFORMATION ACT]
9.7
Billing schedule
Rufus Leonard will provide a detailed budget sheet showing the billing schedule for the project. We will bill on a monthly basis for all work undertaken
within that month.
14-Jul-17, 1:36 AM
Document1
Page 170 of 172
10.
Appendixes
10.1
Proposed hosting infrastructure diagram
14-Jul-17, 1:36 AM
Document1
Page 171 of 172
10.2
[INFORMATION REDACTED UNDER SECTION 43 FREEDOM OF INFORMATION ACT]
14-Jul-17, 1:36 AM
Document1
Page 172 of 172