Current Roles and Responsibilities of the Customer

Request for Proposal (RFP)
DS01-136
APPENDIX A – REQUIREMENTS
CONTENTS
PROJECT START DATE AND TIMEFRAME
CURRENT SITUATION/ BACKGROUND INFORMATION
REQUIRED OUTCOMES
USER NEEDS
CAPABILITIES AND ROLES
PRICING MODEL
CUSTOMER LOCATIONS
TEST & DEVELOPMENT REQUIREMENTS
DS01-136 – APPENDIX A – CUSTOMER REQUIREMENTS
Page 1 of 5
Request for Proposal
Digital Services – RM1043
PROJECT START DATE AND TIMEFRAME
We are looking to procure services for the Alpha and Beta phase of our project. We propose a start date of
25th February 2015 with a proposed completion date of 26th June 2015.
Key delivery dates
PROJECT PHASES
START DATE
COMPLETION DATE
Alpha
4th March 2015
25th March 2015
Beta
26th March 2015
26th June 2015
CURRENT SITUATION / BACKGROUND INFORMATION
There is no current live service as the plan is to replace a paper based system for submitting bills. There is a
pre-existing ‘online portal’ through which users access billing areas for other fee schemes, and it is proposed
that this is reused for this project to identify users. The new system would therefore need to interact with this
portal at the front end. The new system would need support from a document management system at every
stage of the billing process and the workflow requested would need to point to documents held on this system.
Internal IT resource will be made available to discuss and assist with these interactions. Due to these
dependencies, it is proposed that the selected delivery partner will allocate staff who will work in the offices of
the Legal Aid Agency and use their environments.
Current artifacts
●
The vision for this MVP is to replace a paper process that currently handles around 250,000
transactions per year. There are around 15 submission forms to be recreated on the online billing
system and a need for workflow management accessible internally and viewable by providers
alongside a document management solution.
●
●
●
User stories have been defined to a high level and are in the process of being refined.
●
●
User feedback gained so far is attached.
●
The level of service development is alpha and private beta. Following these stages an assessment
will be made of the needs for further iteration.
●
There is no current code as there is no live system at present. Code for legacy systems is readily
available.
Product map identifying component parts and value to user
Assisted digital is not a consideration as the system faces our solicitor clients and internal
caseworkers.
An understanding of how many of your users will need assisted digital support, and what their user
needs are
Current Roles and Responsibilities of the Customer
The team will be comprised of staff from the LAA and MoJ Digital Services as well as from the contracted
delivery partner. Roles currently in place are;
-
Product Manager
Associate Delivery Manager
DS01-136 - APPENDIX A - CUSTOMER REQUIREMENTSDocument1
Page 2 of 5
Request for Proposal
Digital Services – RM1043
-
Business Analyst
Technical Architect
In-house developers as required for Legacy systems
Testers for integration with Legacy systems
We require;
-
Front end developers
Back end developers
Current Technologies and Languages
Although a decision hasn’t been made on integration with these systems the current technologies are listed
below;
-
Online Portal for login - Oracle application
CCR and CCLF - Internal systems that hold billing information. Oracle applications.
REQUIRED OUTCOMES
The overall project aim is to build a web based, front end billing application. This application will need an
integrated workflow that allows users from bot sides of the process to access information on where the bill
currently sits in the process. Additionally, internal LAA users will need access to be able to allocate cases to
caseworkers on the system.
This build will sit alongside a document management solution that will provide evidence submission in support
of these bills.
This development activity is a stepping-stone to providing solicitor users with the ability to upload bills using
an API that it is planned will be built in a following development phase.
All development activity must also be geared to meeting the Digital by Default Service Standards.
As an entirely paper based process at present, the basic user need is to be able to submit bills using digital
means. Users need to do this in the most efficient and cost effective way to reduce overheads. The Legal Aid
Agency also needs to create efficiency in their billing process in order to be able to cut administrative budgets.
●
Business outcomes: Reduced admin, improved interactivity between solicitor users and LAA,
reduced overheads, less rework of bills.
●
Solicitor/advocate users need the most efficient and effective way of submitting bills to the LAA. This
needs to cut out the need for physical post services, reduce rework necessary on bills and allow the
solicitor to see at a glance where in the system their bill sits at any given time. The LAA users need
to be able to effectively and efficiently allocate work to caseworkers, see bill data injected into backend systems, and where re-work is necessary, have the most effective means of communication with
the provider on that bill.
●
The system needs to be accessed anywhere, on any device using any browser. Security
requirements are still being finalised, although there is an option for hosting on existing LAA
environments which would reduce the potential security risks.
●
Volumetrics: Around 250,000 transactions per annum - around 6,000 potential users.
DS01-136 - APPENDIX A - CUSTOMER REQUIREMENTSDocument1
Page 3 of 5
●
Request for Proposal
Digital Services – RM1043
Management Information: MI is needed internal to show numbers of bills processed by caseworker,
timings and appeals data.
CAPABILITIES AND ROLES
Alpha Phase
CAPABILITY
ROLES
CUSTOMER’S REQUIRED OUTCOME
2 Back-end developers
Developers must have a proven track record of
working within Government in a Digital Services
environment and must be well versed in the
Digital by Default Service Standard.
Proof of concept for a robust, integrated, userfriendly service: meeting the above standard.
Software
Engineering
and Ongoing
Support
3 Front end developers
Developers must have a proven track record of
working within Government in a Digital Services
environment and must be well versed in the
Digital by Default Service Standard.
Proof of concept for a robust, integrated, userfriendly service: meeting the above standard.
Beta Phase
CAPABILITY
ROLES
CUSTOMER’S REQUIRED OUTCOME
3 Back-end developers
Developers must have a proven track record of
working within Government in a Digital Services
environment and must be well versed in the
Digital by Default Service Standard.
Proof of concept for a robust, integrated, userfriendly service: meeting the above standard.
Software
Engineering
and Ongoing
Support
3 Front end developers
Developers must have a proven track record of
working within Government in a Digital Services
environment and must be well versed in the
Digital by Default Service Standard.
Proof of concept for a robust, integrated, userfriendly service: meeting the above standard.
DS01-136 - APPENDIX A - CUSTOMER REQUIREMENTSDocument1
Page 4 of 5
Request for Proposal
Digital Services – RM1043
PRICING MODEL
Customer’s preferred pricing model or models, for SOWs that may be awarded as a consequence of this
Further Competition, are shown in the following table:
PRICING MODEL
PROJECT PHASES
Capped time and materials
Alpha & Beta
CUSTOMER LOCATIONS
UK REGION
CUSTOMER LOCATIONS: CITIES OR TOWNS
London and South East of England
MoJ HQ 102 Petty France Westminster.
TEST & DEVELOPMENT REQUIREMENTS
We are able to provide access to LAA Test and Development environments, but would like to hear from
potential Delivery Partners as to whether they believe these environments will allow for efficient delivery.
DS01-136 - APPENDIX A - CUSTOMER REQUIREMENTSDocument1
Page 5 of 5