Download original attachment
(Word document)
This is an HTML version of an attachment to the Freedom of Information request
'Contact Point and N.R.U.C'.
(Word document)
NB: all names and contact details have been redacted and replaced with “[name of organisation] OFFICIAL” because these details are incidental to the Freedom of Information request made.
NRUC (Westminster City Council) Submission to the Department of Children, Schools and Families
to
ContactPoint Enable the National Register or Unaccompanied Asylum Seeking Children
Introduction
What the National Register for Unaccompanied Asylum Seeking Children Delivers
The National Register for Unaccompanied Asylum Seeking Children (NRUC) began life as a local authority `Invest to Save' bid to the Treasury. The Home Office and the then Department for Skills and Education (DfES) also contributed funds to establish an appropriate infrastructure for it to operate as a National Register and also ensure that it had the potential for future service extension.
The National Register is an established system, easily accessible by all UK local authorities, relevant voluntary bodies and central government departments via a secure Internet connection.
It provides a single reference point, one view, on unaccompanied asylum seeking children for authorised child care practitioners across the UK.
It stores detailed identity and demographic information on all UK supported unaccompanied asylum seeking children and it enables these records (initially collected by the Home Office) to be searched.
It allows missing records, and other up to date information, be added to records by front line practitioners across the UK and it makes these changes immediately visible to the user community as a whole.
It enables differences between central government and local government identity and demographic data records for unaccompanied asylum seeking children to be more easily reconciled.
It improves the speed and ease of service history tracking by making contact details for the lead practitioner in the local authority with responsibility for the child, and other authorities who have previously had contact with the child, immediately accessible.
It allows assessments undertaken, services delivered, and all associated local authority spends to be recorded in an online service history and child event chronology.
It makes the transfer of the service responsibility for a child between different local authorities far easier.
It allows individual local authority management information reports to be produced on demand by the local authorities themselves.
It produces Home Office Annexe B/V12 reports for each local authority automatically.
ContactPoint Enabling NRUC
DCSF has formally identified NRUC as a National Implementation Partner.
The technical and functional requirements to ContactPoint enable NRUC were reviewed in a joint DCSF/NRUC/Esprit Technical Planning Meeting on 31st August 2007.
NRUC (Westminster City Council) were requested to submit a detailed funding proposal.
Given the architectural links between Esprit's ShareCare CMS and the NRUC system (both systems share Esprit's xplatform development environment and significant core functional components) DCSF representatives also asked Esprit to identify any cost saving that could be made by undertaking ShareCare CMS and NRUC development work as a joint project.
Submission Details
This document is a formal request for DCSF funding to ContactPoint enable the NRUC system.
The submission is made by NRUC (Westminster City Council), as the Lead Organisation, on behalf of the NRUC user community.
The submission document follows a similar structure to that applied by DCSF to local case management system.
A total project cost of £173,388, inclusive of VAT, has been identified for ContactPoint enabling NRUC in a joint ShareCare CMS and NRUC development project.
Savings in the order of £235,000 have been identified through a joint ShareCare CMS and NRUC development project.
Initial project planning suggests that the project to ContactPoint enable the NRUC system would run from January 2008 until September 2008 with Type Accreditation gained on 17th September 2008 and Instance Accreditation gained on 30th September 2008.
General Information on Lead Organisation and Vendor
Product
Product name
|
National Register for Unaccompanied Asylum Seeking Children (NRUC) |
Current version
|
NRUC Version 1.0 |
Next (major) release currently scheduled
|
NRUC Version 2.0 will be deployed in October 2007 |
For which version(s) of the product are you seeking ContactPoint-enablement funding?
|
NRUC Version 3.0 will be the software release that is ContactPoint enabled. |
What is the main purpose of the product.
|
The National Register for Unaccompanied Asylum Seeking Children supports services to unaccompanied asylum seeking children across the United Kingdom.
It is accessed over the Internet by Local Authorities in England, Scotland, Wales and Northern Ireland; NRUC (Westminster City Council) NRUC administration team and Home Office personnel.
The systems maintains up to date information on unaccompanied asylum seeking children, including case information and financial information relating to local service provisions supported by direct Home Office grant payments. The system supports regular batch uploading of demographic data records from the Home Office A-CID system; batch uploading of local authority data files; and real-time updating of demographic, case and financial records by Children's Services staff in UK local authorities.
|
Underlying technical platforms for the product (e.g. operating system, database, application server, etc.)
|
The NRUC system is a fully browser based application.
It is designed using standard XHTML 1.0T, CSS 2.0 and WAI Level A compliant interfaces and is tested using Internet Explorer Version 7.0.
The system is based on Esprit's J2EE `xplatform' technology and utilises the following third party components:
The system is deployed within a secure, hosted and managed service environment using a three-tier architecture comprising of web server, application server and database server, with firewalls protecting each tier.
The system is operated under a contract with Esprit and is available for use 24/7/365. |
Functional scope of the product (e.g. maintain child data, case note management, service scheduling, action planning and tracking etc)
|
NRUC is a wholly web based application delivering:
for unaccompanied asylum seeking children across all UK local authorities.
The system enables Children's Services practitioners to undertake:
|
Lead Organisation
Lead Organisation Name
|
NRUC (Westminster City Council) |
Primary Contact Name for Enquiries
|
NRUC OFFICIAL |
Primary Contact Job Role
|
Team Manager |
Contact Address
|
59½ Southwark Street, London, SE1 0AL |
Contact Telephone Number (preferably direct line)
|
REDACTED |
Contact Facsimile Number
|
Not Applicable |
Contact E-mail Address
|
NRUC [email address] |
Contact Website Address
|
|
Preferred Method of Contact (Telephone or Email)
|
|
Who would be the Designated SRO Contact (include their Job Role)?
|
NRUC OFFICIAL LASC Project Manager
|
Other information |
|
Who are the main users of the product? |
The NRUC system provides a single reference point, one view, on unaccompanied asylum seeking children for authorised child care practitioners across the UK. It is accessible by all UK local authorities, relevant voluntary bodies and central government departments via a secure Internet connection.
|
Contract - Type of Support Contract (Please consult the SoR Section 3.6)
|
The NRUC system is covered by a software support and maintenance contract and service level agreement (SLA) with Esprit Ltd.
|
If the contract for the CMS is not held by you directly, please state who does (include Name, Role, Organisation Name, Telephone, Email address). |
The contract for NRUC is held by Westminster City Council
WCC OFFICIAL ICT Relationship Manager
City of Westminster Social and Community Services 7th Floor, City Hall 64 Victoria Street, London SW1E 6QP
Tel: REDACTED Fax:REDACTED e-mail: WCC [email address]
|
Vendor
Vendor Name
|
Esprit Ltd |
Primary Contact Name for Enquiries
|
ESPRIT OFFICIAL |
Primary Contact Job Role
|
Commercial Director |
Contact Address
|
Esprit Limited, 1st Floor, Charlotte House, Wyvern Business Park, Derby. DE21 6BF |
Contact Telephone Number (preferably direct line)
|
REDACTED or mobile (REDACTED) |
Contact Facsimile Number
|
REDACTED |
Contact E-mail Address
|
[email address] |
Contact Website Address
|
|
Preferred Method of Contact (Telephone or Email)
|
|
Market sectors the vendor operates in (such as social care, education, Early Years, criminal justice etc).
|
Multi-agency service delivery primarily for Social Care, Education, Health and Youth Offending. |
State and give details of any published Government / Non-Government / Open standards or initiatives that you have supported (e.g. modified your product).
|
In addition to NRUC some of the other initiatives that Esprit has supported that have involved extensions and modification of their `xplatform' product suite include:
|
Any other products the vendor produces
|
|
Do you intend to make any other submissions for funding? If yes, please give details.
|
In partnership with the London Borough of Havering, Esprit has submitted a separate proposal to deliver ContactPoint integration for the ShareCare Child Case Management System (CMS).
However, following a formal request from DCSF, the ShareCare CMS submission also includes details on cost benefits that would accrue from a joint ShareCare CMS and NRUC development strategy.
|
Technical Approach to ContactPoint Enablement
NRUC Functionality
The National Register for Unaccompanied Asylum Seeking Children supports services to unaccompanied asylum seeking children across the United Kingdom.
It is accessed over the Internet by Local Authorities in England, Scotland, Wales and Northern Ireland; NRUC (Westminster City Council) NRUC administration team and Home Office personnel.
The systems maintains up to date information on unaccompanied asylum seeking children, including case information and financial information relating to local service provisions supported by direct Home Office grant payments.
The system supports regular batch uploading of demographic data records from the Home Office A-CID system.
It stores detailed identity and demographic information on all UK supported unaccompanied asylum seeking children and it enables these records (initially collected by the Home Office) to be searched.
It allows missing records, and other up to date information, be added to records by front line practitioners across the UK and it makes these changes immediately visible to the user community as a whole.
It enables differences between central government and local government identity and demographic data records for unaccompanied asylum seeking children to be more easily reconciled.
It improves the speed and ease of service history tracking by making contact details for the lead practitioner in the local authority with responsibility for the child, and other authorities who have previously had contact with the child, immediately accessible.
It allows assessments undertaken, services delivered, and all associated local authority spends to be recorded in an online service history and child event chronology.
It makes the transfer of the service responsibility for a child between different local authorities far easier.
It allows individual local authority management information reports to be produced on demand by the local authorities themselves.
It produces Home Office Annexe B/V12 reports for each local authority automatically.
3.2 What the NRUC to Contact Point integration will deliver
The NRUC system acts as information hub linking Home Office A-CID information to individual local authority demographic and case records for the same children.
To ensure that the linkages between the different data records for the same child are maintained a composite `multi-agency' record set will be communicated to ContactPoint whenever new records are added, or changes are made to exiting records within the NRUC system.
This composite `multi-agency' record will include details of the Home Office A-CID record (where this exists) as well as details of all Local Authority records for the same child. ID's for the Home Office and Local Authority elements of this `multi-agency' record will be provided along with Home Office Contacts, Local Authority Contacts and end dates on all completed involvements.
The NRUC system will only communicate information to ContactPoint for local authorities in England.
Checklist taken from the Detailed Integration Specification (DIS) illustrating how our Esprit intends to address individual requirements
The following table provides a quick reference checklist identifying mandatory (M), recommended (R) or optional (O) modifications to the National Register for Unaccompanied Asylum Seeking Children (NRUC).
This checklist is not exhaustive. It follows the format applied by DCSF to Data Feed Only requirements in local Case Management system (CMS) bids.
No Section Reference in DIS Description Data Feed Only Response
Additional Data
AD1 2.3.3 Lead Professional R Already Supported in NRUC Version 2.0 The NRUC system captures Primary Contact information.
AD2 2.1.6 2.3.3 Involvement Termination Date R Already Supported in NRUC Version 2.0 The NRUC system captures case and assistance cost start and end dates and applies a status that indicates when a case has been closed.
AD3 2.3.3 Address unknown M Already Supported in NRUC Version 2.0 The NRUC system allows address details to be omitted for a child or related party and in the absence of such information can infer that no address is known. If required the NRUC system address model could be extended with a specific flag to indicate address unknown.
AD4 2.3.3 Address overseas M Will be Supported in NRUC Version 3.0 The NRUC system does not currently support oversees addresses, but the address model will be extended to provide for indication that an address is overseas, and to allow entering of international post code, country etc.
AD5 3.2.1 Address verification status R Will be Supported in NRUC Version 3.0 All object instances within the NRUC system carry metadata attribution indicating the time of last change to the data. Verification levels can only be expressed for Date of Birth at present, but the model can be extended to provide generic verification that could be applied to any object.
AD6 2.3.3 3.2.1 Parent/Carer details R Already Supported in NRUC Version 2.0 The NRUC system captures details of parents and carers.
AD7 3.2.4 Date of Death R Will be Supported in NRUC Version 3.0 The NRUC system does not presently capture date of death details, but the model can be extended to enable these details to be recorded.
Additional Procedures
AP1 3.1.5 Consent notification. Note that although consent notification is shown as Recommended, if it is supported then handling withdrawal of consent becomes mandatory R Will be Supported in NRUC Version 3.0 The ability to express whether consent has been granted or withheld to view certain data, and to whom (the `targets') the consent has been granted or withheld is supported by the `xplatform' functionality that underpins the NRUC system. Consent targets are typically persons, organisations and teams within organisations, but the underlying model is generic enough to allow the notion of consent to be targeted at another `system', of which ContactPoint would be an example; in this way sensitive information could be managed as `requiring consent' before inclusion in ContactPoint data feeds.
Messaging Interface
M1 5.2 Web Service (SOAP) calls to ContactPoint M Will be Supported in NRUC Version 3.0 The NRUC system will use Web Service calls to ContactPoint
M2 2.1.8 3.1.16 5.3.3 Mediated Access from CMS (not the web interface) O Will NOT be supported in NRUC Version 3.0 Mediated access is not expected to be offered as an option in the NRUC system.
M3 3.1.2 Obtain system configuration information dynamically from ContactPoint at start up (reason codes, error codes, etc); refresh at least once per day M Will be Supported in NRUC Version 3.0 Configuration information will be extracted on startup (and regularly refreshed) from ContactPoint using standard web services libraries.
Retrieved information will be used within the application user interface appropriately.
Data Feed
D1 2.1.6 3.1.17 Identify data to be supplied at appropriate granularity M Will be Supported in NRUC Version 3.0 The NRUC system will use mappings to implement data transformation from the NRUC system domain model for service provisions to ContactPoint; where appropriate this could encompass some degree of aggregation so as to avoid excessive granularity of e.g. involvements. The NRUC system allows customer configuration of service involvement types, and how they are mapped to standard domains such as ContactPoint. This will allow administrators to be selective about which types are surfaced to ContactPoint (e.g. major involvements could be mapped, but minor subsidiary involvements may not).
D2 2.1.6 Convert information to be supplied to ContactPoint XML format M Will be Supported in NRUC Version 3.0 The NRUC system will use a data transformation service to map data from the NRUC domain model into ContactPoint XML format; this will most likely employ a third-party XML transformation architecture called OPS (a powerful and very configurable engine) which Esprit have used elsewhere for similar purposes. One of the benefits of this approach is the ability to modify mappings via configuration without the need to change or redeploy code.
D3 3.1.2 Chunk individual child records into larger messages for transmission to ContactPoint. Note that if the CMS operates in such a way that updates are supplied together, then they must be aggregated into larger messages. However this behaviour will not be mandatory where data is supplied to ContactPoint transactionally. R Will be Supported in NRUC Version 3.0 The NRUC system will provide some degree of flexibility in establishing a trade-off between timeliness of submissions and excessive numbers of small submissions. This will most likely be achieved using standard Java message queuing services together with some configurable policy that drives how many messages can be queued (and for how long) before a submission can be made. The policy will of course be constrained by whatever ContactPoint configuration settings are in force (e.g. Data Feed Maximum Records).
D4 5.2 Send data feed information to ContactPoint using SOAP interface, and receive responses M Will be Supported in NRUC Version 3.0 The NRUC system will use standard Java libraries to build and send SOAP messages for Data Feed to ContactPoint. Careful consideration will be paid to how responses are handled (e.g. by saving for later inspection), and to properly differentiate between those responses which require retries, or which should be flagged as failures.
D5 3.1.20 Interpret and act on Stop Notifications M Will be Supported in NRUC Version 3.0 The NRUC system will detect Stop Notices received from ContactPoint and flag the appropriate NRUC records so that they are not included in any future feeds.
D6 3.2.5 Present discrepancy information to CMS administrator R Will be Supported in NRUC Version 3.0 Discrepancy information will be modelled within NRUC and associated to the NRUC child record to be made available to suitably privileged users to inspect and possibly take action on.
D7 3.1.14 For new child record in CMS, search ContactPoint, pre-populate allowed fields in CMS, and seek confirmation from user. R Will NOT be supported in NRUC Version 3.0 Search functionality is not expected to be offered as an option in the NRUC system.
D8 3.1.14 For new child record in CMS, search ContactPoint, temporarily store ContactPoint UID for data feed, then delete UID M Will NOT be supported in NRUC Version 3.0 Search functionality is not expected to be offered as an option in the NRUC system.
D9 3.1.7 Ensure that child records supplied comply with legislation (do not relate to children who are not ordinarily resident in England or older than 25) M Will be Supported in NRUC Version 3.0 The NRUC system is designed to only store information on asylum seeking children and will supply those child records as requested.
D10 2.2.2 Supply domain-specific reference identifiers (DSIs) M Already Supported in NRUC Version 2.0 The NRUC system automatically allocates unique DSIs to all child records.
D11 2.1.6 Only supply child records where CMS info has changed since last feed (except for complete refresh of data, as agreed with ContactPoint) M Will be Supported in NRUC Version 3.0 NRUC child records will be flagged according to whether their ContactPoint related information has changed since the last data feed. Only changed records (or records that have never been fed) which are not the result of stop notices, or otherwise prohibited, will be included in data feeds.
D12 2.1.6 Able to occasionally (on demand) upload records for all children (full refresh) M Will be Supported in NRUC Version 3.0 A separate NRUC utility will be provided to perform a complete refresh of data.
D13 3.1.13 Transmit information to ContactPoint as it becomes available (near real-time) R Will be Supported in NRUC Version 3.0 The NRUC system transmission policy will strike a balance between timeliness of submission and too many frequent small submissions. It will be based on guidance from ContactPoint. It is likely that a configured maximum latency will be used to ensure that no information change remains unfed in the system beyond a sensible maximum period after the change is recorded within NRUC.
D14 3.1.10 3.1.11 Detect system or network failure in data load, and reschedule. M Will be Supported in NRUC Version 3.0 The NRUC system will attempt to retry a failed data feed transmission to ContactPoint. Where newer data has become available for the same record, NRUC will attempt to use that rather than re-send the original.
Failure information will be available for audit inspection by suitably privileged NRUC users (e.g. those with a `ContactPoint' administrator role).
D15 3.2.2 Allow loads to be performed in dummy-run mode R Will be Supported in NRUC Version 3.0 The NRUC system will support a dummy-run mode of operation.
D16 3.2.1 Supply metadata information R Already Supported in NRUC Version 2.0 The NRUC system supports verification metadata for child date of birth; schema extensions can be made to support similar metadata on other aspects (identifier, date of death, gender, name, address, parent/carer).
D17 3.2.1 Supply address validation information where applicable O Will be Supported in NRUC Version 3.0 Additional address validation can be worked into the NRUC model as required.
D18 3.2.10 Allow specification of optional involvement retention period O Will NOT be supported in NRUC Version 3.0 Involvement retention periods are not required by the NRUC business model.
D19 3.2.9 Allow specification of optional transition to adulthood date O Will be supported in NRUC Version 3.0 Transition to adulthood date will be added to the NRUC business model.
D20 3.2.7 Allow specification of optional Keep Accountable Body O Will NOT be supported in NRUC Version 3.0 Not presently required by the NRUC system.
D21 3.1.15 Allow supply of eCAF information R Will NOT be supported in NRUC Version 3.0 Not presently required by the NRUC system.
D22 3.1.4 Notify ContactPoint when information is no longer current in the CMS M Will be Supported in NRUC Version 3.0 NRUC will notify ContactPoint when information is no longer current by use of the end of involvement information.
D23 3.1.8 Translate missing or defaulted values into the correct ContactPoint representation. M Already Supported in NRUC Version 2.0 The NRUC system always uses absence of value to indicate that a value is unknown or not entered; special default values to indicate `unknown' are not used.
D24 3.1.9 Notify ContactPoint of a missing child using the correct ContactPoint representation. M Will be supported in NRUC Version 3.0 The NRUC system can enable can enable a missing child flag to be set and communicated to ContactPoint.
D25 3.1.18 Allow shielding notification to be sent when a child is in danger M Will be Supported in NRUC Version 3.0 The NRUC system can be modified to allow a “ContactPoint” shielding flag to be set on a child.
D26 3.1.19 Notify ContactPoint of a change in involvement details M Will be Supported in NRUC Version 3.0 As data changes NRUC will always send the latest complete set of information about a child to ContactPoint.
D27 3.2.6 Supply practitioner codes O Will NOT be supported in NRUC Version 3.0 Not presently supported by the NRUC system.
Security
S1 3.1.1 Authenticate the CMS against the appropriate Identity Provider and cache the system assertion in memory. M Will be Supported in NRUC Version 3.0 The NRUC system will be configured to direct requests for SAML 2.0 assertions to an appropriate Identity Provider. Caching of assertions may be done using a third-party caching engine that supports configuration of lifetime in cache and memory-only caching.
S3 5.2.1.2 Authenticate the CMS against the appropriate Identity Provider and cache the data source assertion in memory (may be the same as the system assertion) M Will be Supported in NRUC Version 3.0 The NRUC system will be configured to direct requests for SAML 2.0 assertions to an appropriate Identity Provider.
S4 5.6 3.1.1 Detect an expired assertion and initiate authentication to obtain a fresh one (either proactively or when ContactPoint rejects a request when an assertion has expired) M Will be Supported in NRUC Version 3.0 The NRUC system will examine the SAML 2.0 assertions before issuing the SOAP request and initiate re-authentication if it has expired.
S5 5.4.1 5.4.2 Construct WS-Security SOAP headers for each request. M Will be Supported in NRUC Version 3.0 The NRUC system will build the complete SOAP message (possibly using XML pipelining techniques) including the appropriate headers.
2.3.6 Single Sign-On - delegate CMS authentication to a ContactPoint-trusted Identity Provider to enable single sign-on between the CMS and ContactPoint O Will NOT be Supported in NRUC Version 3.0 The NRUC system will support the federated security model required by ContactPoint but will initially integrate with the ContactPoint Identity Provider as this is likely to be the sole provider to use the ContactPoint federated security model with dual-factor security at that point other than health. Esprit is keen to make use of the federated model to provide a single sign-on dual factor solution and expects to deliver this through Government Connects in a future release of software once Government Connect supports the required version of SAML
|
Please Note:
NRUC (Westminster City Council) will continue to monitor changes to the above Detailed Integration Specification in regular ContactPoint Management Meetings with Esprit.
Esprit has indicated that they will continue to:
monitor changes to the Detailed Integration Specification (DIS) throughout the specification and development phase of the NRUC to ContactPoint project;
make appropriate changes to NRUC functionality wherever these are required through changes to the Detailed Integration Specification (DIS).
Esprit has also stated that they do not expect to make additional charges against changes made to the Detailed Integration Specification unless the changes made are substantive i.e. have significant additional cost implications, or are made after the completion of relevant Esprit coding and testing work i.e. require significant re-working of functionality already completed.
Accreditation - DCSF wish to minimise the need for re-accreditation, how does your vendor support this requirement?
Although the NRUC system shares architectural and functional components with Esprit's ShareCare case management system (CMS) these components are wrapped into a standalone NRUC product.
Esprit has indicated that significant cost savings can be made if DCSF funding allows ContactPoint development work for the NRUC system and the ShareCare CMS to be undertaken jointly.
Once shared security and other components have been created for Esprit's underpinning `xplatform' architecture these will be engineered into a single product code-line for the NRUC system. The NRUC system will then be Type Accredited once only by Esprit and will similarly be Instance Accredited once only by NRUC (Westminster City Council).
As the NRUC system will deliver Date Feed Only functionality this process will precede both Type and Instance Accreditation for the ShareCare CMS.
The NRUC system will be Type accredited, Instance accredited and fully operational on Data Feed Only functionality by 30th September 2008.
The ShareCare CMS will be Type accredited, Instance accredited and fully operational on data feed and query functionality in the London Borough of Havering by 27th October 2008.
|
Project
What is the contractual mechanism you intend to use to implement ContactPoint adaptations? Are there any constraints involved with the contractual mechanism?
NRUC (Westminster City Council) (the Lead Organisation) will use enabling clauses within their current contractual arrangements with the Esprit (the vendor) to contract for the delivery of the ContactPoint upgrades to the NRUC system. There are no known constraints in contractual terms to inhibit implementation of NRUC Version 3.0, the proposed ContactPoint enabled version of the NRUC system.
|
What are your estimated costs for the ContactPoint-enablement you are seeking?
ContactPoint-Enablement |
Total (£) including Recommended Behaviours |
Data Feed (DF) only
|
£173,388, inclusive of VAT* |
|
* This figure assumes that NRUC development work is undertaken in a joint project with the ShareCare CMS. Separate figures for a wholly independent project are indicated in the cost section at the end of this document.
|
Note: All funding is for Project costs and project management overhead only, not operational costs. Further information relating to Recommended Behaviours is available in the Detailed Integration Specification.
When do you propose to deliver a ContactPoint-enabled product?
ContactPoint-enablement option |
Planned Date |
Data Feed (DF) only
|
Completion date i.e. Type and Instance accreditation successfully completed and system fully operational : 30th September 2008 |
Project milestones proposed for deliver a ContactPoint-enabled product
Milestones
1. Begin development of PID 07/01/08
2. Sign off PID 21/01/08
3. Technical Architecture Document Sign Off 28/01/08
4. Test Strategy Sign Off 25/01/08
5. Training Strategy Sign Off 28/01/08
6. Functional Specification Document Sign Off 10/03/08
7. Start Development 11/03/08
8. Complete Development + Sign Off 22/08/08
9. Type Accreditation 17/09/08
10. Internal & London Council Testing Completed 22/09/08
11. Instance Accreditation 24/09/08
12. Go Live 30/09/08
Payment Profile
1. Completion of PID = 15% 21/01/08
2. Design and Specification Completed = 25% 10/03/08
3. Type Accreditation = 40% 17/09/08
4. Instance Accreditation = 10% 24/09/08
5. Go Live = 10% 30/09/08
Project approach.
INTRODUCTION
The project for to ContactPoint enable the NRUC system will run from January 2008 until September 2008 with Type Accreditation gained on 17th September and Instance Accreditation gained on 24th September 2008.
OUTLINE IMPLEMENTATION PLAN
Our proposed implementation plan utilises a best practice approach to delivery combined with proven PRINCE2 Project Management disciplines that ensures mitigation of project risk, promotion of user acceptance and solution uptake.
At this stage, the plan should therefore be regarded as indicative of the flow of activity and streams of work. We will work with NRUC (Westminster City Council) and the DCSF to refine this during the procurement cycle and to confirm planned deployment and accreditation dates as achievable, based on a more detailed understanding of the requirement scope, timetable and constraints. The project milestones are provided as indicative dates only and are based on experience from similar projects. The Project Initiation Document includes as a deliverable an agreed project plan.
Our approach to the ContactPoint enablement project is to deliver through development, testing and then deployment phases.
The development phase will deliver the requisite NRUC Data Feed functionality in August. Type Accreditation testing can begin on 17th September.
Deployment will require the current NRUC configuration to be changed to reflect the ContactPoint enablement. These changes will be configured by Esprit's Technical Resource. Help Files and Training Documentation will also be updated accordingly.
Train the Trainer and System Administrator training sessions will be included.
Deployment to the Live NRUC will occur in September to enable Instance Accreditation to be gained by 24th September 2008.
This will be followed by a formal project closure including a project review and Lessons Learned.
PROJECT SCOPE
The NRUC to ContactPoint implementation project covers the following key deliverables:
Product Title Created By / Responsibility
PID Esprit and LC PM's
Technical Design Esprit Development Resource
Functional Specification Esprit Product Analyst
ContactPoint DF & QF Enablement Developed and Tested Esprit Development & Esprit Testing
Type Accreditation DCSF
Training Esprit Trainer
Installed ContactPoint DF & QF Enabled ShareCare to LC Esprit Technical Resource
Handover to Support Esprit Project Manager
Instance Accreditation DCSF
Rollout to rest of ShareCare community Esprit
Project Management Esprit Project Manager
Programme Management NRUC (Westminster City Council) Project Manager
Esprit will provide Project Management to cover the life cycle of the ContactPoint project, including the development of strategy documents, the reviewing of progress of project products, particularly during the development phase and a formal project close.
Programme / Project Management from NRUC (Westminster City Council) will be required in order to review and sign off the strategy documents; arranging and facilitating the testing, completion of the Configuration documents, accreditation testing and deployment to the live environment; Project Board meetings; Project Review meetings internally and with the vendor and the DCSF.
Programme management is required to ensure the delivery of this project is in line with NRUC (Westminster City Council) Programme Plan.
The following will be included in the implementation plan:
PROJECT ORGANISATION
To ensure that the NRUC system satisfies the long term ContactPoint business objectives requires that the project has effective management and technical governance.
PROJECT GOVERNANCE STRUCTURE
PROJECT BOARD ARRANGEMENTS
Overall responsibilities of the NRUC Project Board:
CONTACTPOINT PROJECT TEAM
Esprit Project Director - ESPRIT OFFICIAL, Director
ESPRIT OFFICIAL has acted as the Project Director for the RYOGENS National Project and the National Register for Unaccompanied Asylum Seeking Children (NRUC), among other large-scale projects. He is presently the Esprit Project Director for the Coventry City Integrated Children's System implementation, a project involving Common Assessment and integration with social care agencies across the Authority. Esprit Project Manager - ESPRIT OFFICIAL ESPRIT OFFICIAL is PRINCE2 Qualified and most recently worked for Nottinghamshire County Council as a Senior Project Manager on internal projects.
NRUC (Westminster City Council) Project Manager - NRUC OFFICIAL ESPRIT OFFICIAL is responsible for the operation of the established NRUC system and for the implementation and testing of new system and service features.
ESPRIT OFFICIAL has acted as the project support manager for the configuration and deployment of the NRUC system.
Esprit Product Analyst - ESPRIT OFFICIAL ESPRIT OFFICIAL is responsible for identifying and analysing requirements for NRUC. He produces the specifications and works closely with development. He has played a key role in the specification of requirements for NRUC Version 2.0 v2.2
Esprit Technical Support - ESPRIT OFFICIAL ESPRIT OFFICIAL will be responsible for the setting up and deployment of the infrastructure to support NRUC. He has been involved in the implementation of several national and regional projects, including the RYOGENS National Project, the NRUC project, and the Havering and Coventry ICS projects. ESPRIT OFFICIALis familiar with LAN/WAN, VPN, multi-tier server architecture environments, SQL database servers, remote access and administration, security mechanisms and policies.
Esprit Trainer - ESPRIT OFFICIAL ESPRIT OFFICIAL is our group trainer and has been instrumental in producing the help files and training material for the NRUC system.
ESPRIT OFFICIAL has over 20 years experience in Software Development and is responsible for much of the architecture on which the NRUC application is built. ESPRIT OFFICIALwill lead the development on this project and will manage another 1.5 developers.
MONITORING
We will follow standard PRINCE2 project management methodology and use a monthly highlight report to detail progress to the Project Board. The report will be drawn from project checkpoint reports and project review meetings.
Changes, updates and progress against key deliverables will be shown using our standard RAG (Red, Amber and Green) reporting.
Issues and risks (covered in more detail in the next section) will be maintained throughout the project on separate logs and will be transferred to the highlight report as required.
Accounts and receipts to show funding used to date, will be included, as appropriate.
RISK MANAGEMENT
A risk is defined as any potential event that poses a significant threat to the project. Our approach to managing risk includes the following key elements and steps: Risk Identification: we will prepare, maintain and communicate a list of all identified risks facing the project. We will differentiate between Programme level and Project level risks: Risks identified that have an impact on the programme, as a whole will be entered onto a programme risk log. Those which impact only the project will be entered onto the relevant risk log, which will be reviewed on a regular basis to ensure that these are being managed; and if necessary whether they should be escalated to Programme level. Risks will be categorised by `type', as follows:
Risk Estimation: We determine the criticality of each risk, based on an Assessment of its probability of occurrence and its likely impact. This will, in the most part, be a subjective exercise. We typically define a set of measures to allow appropriate prioritisation of outstanding risks, but this does not do much to reduce the inherent subjectivity;
Risk Planning: We identify appropriate actions that need to be taken to mitigate each risk. Based on this, we assign the necessary resources and define target dates. Where appropriate, a separate management action plan may be created the specifies how a specific risk will be mitigated;
Risk Controlling: Overall responsibility for monitoring progress made on risk mitigating actions lies with the Programme Board. On a day-to-day basis, the London Council's Project Manager will monitor progress made on mitigating actions through regular progress review meetings with the Esprit Project Manager;
Risk Monitoring: Following the completion of mitigating actions the probability of occurrence and/or potential impact will be reviewed in order to determine whether either/both have been reduced. This task is completed via meetings with the originator(s) of the risk. If mitigating actions are considered to have been unsuccessful, additional activities will be defined and the contingency plan (in case the risk is realised) reviewed and updated as appropriate;
Risk Reporting: We include a brief description of each new risk identified and its potential impact within the appropriate weekly Highlight reports.
PROJECT CONTROLS
Introduction The Project Board will review and approve all levels of the plan. It will authorise the project to proceed from one stage to another, ensuring that all outcomes within the stage have been completed and delivered (PRINCE 2).
End of stage Report The purpose of the report `is to give a summary of progress to date, the overall project situation and sufficient information to ask for a Project Board decision on what to do next with the project' (PRINCE 2). For example, approval to proceed to the next stage, revise the next stage plan.
Authorisation of New Stages At the commencement of each stage the Project Manager will submit a report detailing stage plans and expected outputs to the Project Board for approval. If the Project Board is happy with the plans it will give approval to commence the stage.
Tolerance limits As part of the process of initiation of the project the Project Board will define the constraints and tolerance delegated to the Project Manager. If those limits are likely to be exceeded then the issue will have to be escalated to the Project Board.
Highlight Reports These are time driven reports submitted by the Project Manager to the Project Board. The Project Board will use these reports to monitor stage and project progress. The format of the report is defined by the template provided in the implementation toolkit and the frequency will be set by the Project Board.
Change Control The Project Team will authorise changes to the project schedule assuming it is within the tolerance limits agreed by the Project Board. The Project Manager, detailing the purpose, will indicate the implications and any requirements of the change and submit a change control request to the Project Board.
PROJECT QUALITY PLAN
The project will be managed using the standards based on PRINCE2.
The Project Board will assure the quality of the activities (i.e. Local data sources) or appoint a Project Assurance Team to do this on its behalf.
ASSUMPTIONS
In order to produce a project plan a number of assumptions have been made:
TRAINING
It has been our experience that practitioners find the distinctions between issues about using the new system, understanding the new processes, and the implications for practice to be highly interlinked. This means that a close working relationship between the project team, senior management and the practitioner community is vital for success. Within the team an understanding of who is responsible for what will need to be entirely clear. However, the way in which the changes are introduced and training provided to practitioners must be supported by an integrated support structure that allows the project team to deal holistically.
The provision of professional training resources that will help to intelligently address the challenges of ContactPoint will be key to the success of the project. In order to address `intelligently' these needs, we believe that:
We propose the following elements:
Train the Trainer For a project of this nature we would expect to train `super users' who are going to act as trainers within the client environment. In our experience, in order to make sure cascade training is successful, it is necessary to make sure that the trainer not only knows the system, but also that they have an understanding of how to run an effective training course. We will provide course structure and course documentation to NRUC (Westminster City Council) staff.
|
Frequency of data update:
Frequency of update of data in the NRUC system.
Frequency of update of NRUC data to ContactPoint you envisage.
As described in 2.1 above NRUC is a national (multi-authority) system that supports regular batch uploading of demographic data records from the Home Office A-CID system; batch up loading of local authority data files; and real-time updating of demographic, case and financial records by suitably authorised Children's Services staff in UK local authorities. The frequency of updates in the NRUC system therefore includes real-time updating of child records.
The frequency of the NRUC to ContactPoint data updates will follow the preferred ContactPoint, web services model, which means that:
|
Full Cost Information
Please provide any other information that supports your submission for funding.
In addition to the NRUC system Esprit is also responsible for delivering the ShareCare Child system (with ICS, e-CAF, ESCR and other multi-agency, Children's Service functionality) to individual local authorities in the UK.
Given the architectural links between ShareCare and NRUC (both systems share Esprit's xplatform development environment and significant core functional components) DCSF representatives asked Esprit to indicate, in their ShareCare CMS submission, any cost benefits that could be delivered through a joint ShareCare/NRUC project, and to highlight the same benefits when submitting the NRUC funding proposal.
This proposal therefore focuses on the cost of ContactPoint enabling NRUC in a joint project with the ShareCare CMS, while also providing full cost details for a wholly independent NRUC only project.
If undertaken in isolation the development cost for the NRUC system will be: £407,859, inclusive of VAT
If the technical integration work to ContactPoint enable NRUC is undertaken in association with the ShareCare CMS the costs reduce to: £173,388, inclusive of VAT
Detailed ShareCare and NRUC project costings, inclusive of VAT
NRUC (Stand-Alone Project) Costs |
|
|
Development |
|
320 days plus VAT |
Esprit Project management, systems design, testing, accreditation, etc
|
197 days plus VAT |
|
NRUC programme management, contract management and administration |
|
20 days excluding VAT |
NRUC (standalone project) total days |
|
537 days |
Grand total @ £650 per day, plus VAT (where chargeable) |
£407,859 |
|
NRUC (Joint Development with ShareCare) Costs |
|
|
|
Development |
|
140 days plus VAT |
|
Esprit Project management, systems design, testing, accreditation, etc |
70 days plus VAT |
||
NRUC programme management, contract management and administration |
|
20 days excluding VAT |
|
NRUC (joint project) total days |
|
230 days |
|
Grand total @ £650 per day, plus VAT (where chargeable) |
|
£173,388 |
|
ShareCare |
|
|
|
Development |
|
231 days plus VAT |
|
Project management, systems design, testing, accreditation, etc |
206 days plus VAT |
||
Havering programme management, contract management and administration |
20 days excluding VAT |
||
ShareCare total days |
|
457 days |
|
Grand total @ £650 per day, plus VAT (where chargeable) |
|
£346,759 |
|
Combined ShareCare and NRUC Project Figures |
|
|
Days |
|
687 days |
Grand total @ £650 per day, plus VAT (where chargeable) |
|
£520,146 |
Proposal to ContactPoint Enable the National Register for Unaccompanied Aslylum Seeking Children
Submission document from NRUC (Westminster City Council) and Esprit Ltd
Status Final
Issue Date: 12/09/2007
1