Request for Proposal (RFP)
DS01-149
CUSTOMER REQUIREMENTS
OVERVIEW:
CCS Project Lead:
Kirsty Manning
Customer:
DVLA
Delivery Location:
DVLA, Swansea SA67JL (see “Delivery Location” section
for further detail)
Phase(s):
Phase 1 Alpha and Phase 2 Discovery - plus optional
continuation into Beta and Live (subject to further spend
approvals & satisfactory supplier performance)
Project:
DS01-149
Required Capabilities:
Include, but are not limited to: (mark those that apply)
 Software engineering and On-going Support
 Agile Delivery Management
 Front-End Design and Interaction design
 System Administrations and Web Operations
Contract Charging Mechanism (Alpha Phase):
Time & Materials
Contract Charging Mechanism (Beta Phase):
Time & Materials
Contract Charging Mechanism (Live Phase):
Time & Materials
RFP Start Date:
09/02/2015
RFP Response Deadline
27/02/2015 (12:00 midday)
Proposed length of phase:
Alpha: 3 months estimated
Beta (optional): 2 months estimated
Live (optional): 2 months estimated
Proposed Commencement Date of Project:
Resources to begin work at DVLA Swansea week
commencing 16/03/2015
WHATS INCLUDED
Appendix A – Customer Requirements (this document)
Appendix B – Pricing Matrix (template to be completed)
Appendix C – Award Questionnaire (template to be completed)
Appendix D – Order Form and Call-Off Contract (Customer specific)
Appendix E – Supplier List for Partnership Possibilities
Page 1 of 10
Digital Services – RM1043
Request for Proposal
LOTTING STRUCTURE, SUBCONTRACTING & PARTNERSHIP
The Customer has structured this procurement as follows:
Lot 1
Software Engineering and Ongoing Support
and System Administration and Web
Operations
i.e. Developers, Developers (QA/Testers), Web
Operations
Lot 2
Agile Delivery Management and Front-end
Design and Interaction Design
i.e. Delivery Manager (Scrum Master), Business
Analysts, Designer

Suppliers are permitted to subcontract for individual roles if desired.

Suppliers are permitted to partner together (with other Suppliers on the Framework) to bid for a
particular lot, provided that one supplier in the partnership acts as lead partner, taking responsibility
for managing the partnership’s relationship with DVLA and for the performance of the partnership
suppliers.
TIMESCALES
The Customer or CCS may change this timetable at any time. The Potential Provider will be informed by email
if there are any changes to this timetable.
It is the Potential Provider’s responsibility to monitor the online messaging facility (e-Sourcing).
DATE
WHO
ACTIVITY
09/02/2015
CCS
Publish tender to Potential Providers
Clarification period starts
12/02/2015
CCS, Customer and
Potential Providers
Live Clarification Webinar – 14:00hrs
Invite to webinar will be issue via the CCS eSourcing Suite. All
questions and responses will be published via the ESourcing
Suite.
19/02/2015
Potential Providers
Clarification Question period closes
Please submit all clarification questions by 23:59hrs
20/02/2015
CCS
Clarification Response period closes
Responses to all clarification questions will be published via the
ESourcing Suite.
27/02/2015
Potential Providers
Submission Deadline
Potential Providers must upload their submission to the
Authority via eSourcing Suite by 12:00noon
11/03/2015
Intention to award notification
Publish Successful and unsuccessful notification to Potential
Providers
W/C
16/03/2015
Expected “Commencement Date” for Call-Off Contract/s
Digital Services - RM1043
Document1
Page 2 of 10
Digital Services – RM1043
Request for Proposal
KEY DELIVERY DATES
Discovery phase was completed internally at DVLA between 01/10/2014 and 19/11/2014. Commencement of
Alpha is entirely dependent upon completion of this procurement and the mobilisation of the full team.
Estimate 3 months completion of Alpha from the point the full team is mobilised. There is a need for this work
to start immediately as DVLA is subject to significant, avoidable card issuer charges. All dates in the below
table are estimates.
PROJECT PHASES
START DATE
COMPLETION DATE
Phase 1 Alpha
w/c 16/03/2015
w/c 08/06/2015
Phase 1 Beta
w/c 08/06/2015
w/c 03/08/2015
Phase 1 Live
w/c 03/08/2015
w/c 05/10/2015
Phase 2 Discovery
TBC (To run in parallel with Phase
1 Alpha & Beta)
TBC (To run in parallel with Phase
1 Alpha & Beta)
CURRENT SITUATION / BACKGROUND INFORMATION
DVLA’s Strategic Card Payments project sits within our Strategic Transform portfolio, which has the key focus
of transforming the delivery of digital services and promoting a standardised ICT landscape. DVLA’s existing
ICT estate is characterised by high complexity, high cost resulting from manual processes, and uncompetitive
support arrangements. The shape of this legacy estate means it will become increasingly difficult to deliver a
set of coherent digital services to customers if individual, bespoke payment solutions are developed for each
of our payment-taking services.
As each of our transformation projects delivers services on common, cloud based platforms and
infrastructure this will facilitate our transition to a better value, more responsive digital platform. This project is
not responsible for delivering the shift of services from the legacy estate, but it will provide the integration
between the legacy and Open Systems Landscape technologies available at a point in time.
This Project will begin by delivering the Minimum Viable Product (MVP) for our Electronic Vehicle Licensing
(EVL) Service card payment requirement, followed by the addition of further features and services, in two
main Phases:
-
Phase 1: Delivery of a new strategic payment capability, and integration of the EVL service (Web and
Agent channels) into this.
Phase 2: Migration of DVLA’s remaining on-line payment-taking services into this new capability, plus
continuous improvement building on Phase 1.
The overall scope of this requirement is for:
a) Phase 1 Alpha
b) Phase 1 Beta
c) Phase 1 Live
d) Phase 2 Discovery (in parallel with Phase 1 Alpha & Beta)
As DVLA receives ICT spend approval for project work on an iterative basis, the Statements of Work (SoWs)
under this Call-Off Agreement are likely to be aligned to each subsequent approval as it is granted.
The Payment Service Provider (PSP) will be the Solve Centurion product, currently owned by the Logic
Group. This will be hosted off DVLA premise, and provide a ‘PCI compliant’ payment capability for the
DVLA. Communication to the PSP will be through formal web service interfaces published by the Logic
Group. To achieve the outcomes desired, additional work will be required over and above the provision of the
Digital Services - RM1043
Document1
Page 3 of 10
Digital Services – RM1043
Request for Proposal
aforementioned PCI compliant product provided by the Logic Group. This additional work requires an
abstraction layer to protect payment capability consumers (i.e. DVLA payment-taking services) from the
impacts of change to the PSP. This abstraction layer will be cloud hosted and provide a common mechanism
through which all payment interactions should be routed. A data store will also need to be provisioned to
assist in the process of payment related reconciliation, reporting and refunds. The data persisted should be
designed so that it does not fall within the scope of that which requires formal PCI accreditation.
Solve Centurion has already been commissioned and is being implemented by DVLA’s Vehicle Management
& Personalised Registration Project for their specific purpose and as a proof of concept.
Strategic Card Payments Phase 1 represents the first stage in the development of an improved card payment
solution, reducing DVLA’s liability to substantially increased payment card scheme charges and working
towards full compliance with PCI DSS v3.0. As such, it will build on the principles and lessons learned of the
prototype payment solution being developed by Vehicle Management & Personalised Registration Project.
The Agency is committed to meeting its Payments Strategy, in particular, providing assurance that all on-line
payments made to DVLA for its services are secure and PCI compliant. Existing services for which on-line
payments are currently required have their own unique and diverse architecture, residing on legacy platforms,
with processes that have each evolved separately to meet their own specific business and/or legislative
requirements.
EVL payments are currently handled by an on-premise implementation of the Solve SE product, also owned
by the Logic Group, but this is not PCI compliant and does not handle Amex payments.
The Discovery phase identified that these elements could be progressed during the Alpha phase:

Alpha delivery of the MVP to migrate Electronic Vehicle Licensing (EVL), web and agent channels, to
a secure payment solution, allowing customers to relicense with a greater range of payment cards
and providing them with assurance of payment card security.

Future proofing the payment solution to enable the integration of other existing services through the ecommerce and telephony channels, while also making it available for new, emerging services where
payment is required.

Ensuring the solution is loosely coupled with the Payment Service Provider so that it could be
decoupled should a change of payment service provider be required.
Current artifacts
Underpinning the business services that are in scope are a key set of high-level service requirements. The
table below sets out the minimum, intermediate and maximum service requirements and will be continually
refined as delivery progresses;
Minimum
Intermediate
Maximum
Interface with EVL (web and agent)
business service and take appropriate
payments as directed by the service
As for Minimum, plus:
As for Intermediate, plus:
Interface with other DVLA
business services and take
appropriate payments as
directed by those services
Interface with all DVLA
business services and take
appropriate payments as
directed by those services
As a payment service be able
to cater for additional peak
volumes associated with
additional services that migrate
to the payment solution, with
sufficient headroom
Enable payments using these
cards:
Validate that the card is not fraudulent
and sufficient funds are in an account
prior to processing the transaction
Provide confirmation of card payment
authorisation to customer, with unique
payment identifier, for pre and final
authorisations.
Digital Services - RM1043
Document1
Visa Debit (foreign), Visa
Credit (foreign), Mastercard
Debit (foreign), Mastercard
Page 4 of 10
Digital Services – RM1043
Request for Proposal
Enable payments using these cards:
Visa Debit, Visa Credit, Visa Electron,
Visa Business Debit, Visa UK
Chargecard, Mastercard Debit,
Mastercard Credit, Maestro/Switch
Credit (foreign), International
Maestro, Commercial Debit
Cards, Commercial Credit
Cards, JCB, Diners
Enable payment via Paypal
Enable payment using American
Express cards
Provide confirmation that card
payment has been taken, with unique
payment identifier
Have the ability to refund any duplicate
payments back to the payment card.
As a payment service be resilient and
available 24/7, in line with EVL service
hours
As a payment service be able to cater
for EVL peak volumes with sufficient
headroom
Provide ready access to clear
assistance if a customer has a problem
while making a payment
Be able to refund any
overpayment back to the
payment card (including
automatic VED refunds –
dependent upon change to
primary legislation). This may
also be required if/when the
Driving Licence Online (DLO)
service is migrated.
Be able to refund all customers
electronically, even if the
service was not paid for
electronically.
Provide the capability for a
customer to use multiple cards
on a customer account (only
required for the Sale of Marks
(SOM) service)
Ensure all card payments taken over
the Internet are 3D secure
Provide assurance that the payment
product and its implementation is fully
compliant with PCI DSS v3.0
Provide management information on
all payments received, with
breakdowns on payment types and
identification of how much levy and
VED has been taken.
Provide suitable reconciliation
functionality
Provide adequate functionality to
ensure payments are correctly
accounted for in DfT’s Shared Services
Centre.
Provide functionality to monitor
availability, completion rates and
transaction timings.
Ensure the solution is built in a way
that is re-usable for other DVLA
services and is loosely coupled with
the Payment Service Provider
Digital Services - RM1043
Document1
Page 5 of 10
Digital Services – RM1043
Request for Proposal
NB The requirements listed in ‘Minimum’ above represent the starting point for MVP. Through progression of
technical and PSP contractual elements during Alpha, it may emerge that any given requirement may
introduce an unacceptable cost and/or delivery timescale impact, resulting in all or part of that requirement
being moved to intermediate or maximum requirements.
The Outputs of Phase 1 Discovery are embedded below:
1) DVLA Technical Architecture Approach
DVLA_Strategic_Pay
ments_3 0.ppt
2) Strategic Card Payment Features, Themes and User Stories
SCP Features,
Themes and User Stories.doc
3) Whiteboard Plan
Whiteboard Plan
2.doc
Current Technologies and Languages
Delivery Approach
 The solution will be developed using an agile methodology conforming to the Government Digital
Service phases of service design, i.e. Discovery, Alpha, Beta, Live.
 The solution will be continually iterated via a cycle of continuous integration / continuous
development.
Main Solution Components
 The solution will be deployed on a JVM in a cloud-hosted Linux platform.
 A standards-based API (either using REST/JSON or SOAP) will be exposed by the service, to be
consumed by the relevant systems (i.e. by EVL in Phase 1 and by other DVLA services thereafter).
 The payment service component itself should not need to know about the implementation of the
legacy systems. This legacy element will be delivered through a combination of in-house and legacy
supplier development, but will need to be closely aligned with the development of the card payment
solution that is to be delivered via this DSF procurement.
 The main elements of the solution will be built using either Java or Scala. There is also a requirement
for a backing data store, which could use PostgreSQL (to be determined during Alpha definition).
Hosting
 The solution is to be externally cloud hosted and not deployed on premise.
 Cloud hosting and operational support (monitoring, patching, etc) requirements are to be defined
during Alpha and not available via Digital Services RM1043
Digital Services - RM1043
Document1
Page 6 of 10
Digital Services – RM1043
Request for Proposal
REQUIRED OUTCOMES
Phase 1 Alpha:
 This requirement is to provide the specified resource for agile roles to support the definition of the
delivery & integration approach for EVL Web and Agent channels to the Strategic Card Payment
Solution.
 This will include investigation, definition, solution design, option analysis, development, test and
implementation with resources working within a co-located & blended team of DVLA staff, legacy IT
suppliers and PSP (Logic Group) to develop a cohesive, end-to-end solution for delivering the
required changes & integrating them with the legacy platforms, with minimal disruption to live service.
The new payment service must support up to 30,000,000 transactions per annum and peaks of 6,000
per ten minutes.
 Key deliverables will include, at a minimum:
Definition of Alpha, sprint planning and implementation approach.
Ongoing maintenance of product backlog
Technical Solution including abstraction layer and data store, incorporating the end-to-end
integration of EVL (including back-end finance system), Solve Centurion and any other
externally-delivered or hosted systems/elements.
Definition of cloud hosting requirements for dev, test and live
Definition of operational support requirements
Delivery of Alpha Phase
Definition of beta and live implementation with plans and estimates for the resource/cost to
deliver
Phase 1 Beta:

Delivery of Beta Phase as defined by the Alpha Phase outputs (in line with Agile delivery
methodology).
Phase 1 Live:
 Live implementation as defined in the Alpha Phase and refined in the Beta Phase.
Phase 2 Discovery:



Joint discovery in collaboration with PACT, DVLA & PSP.
Assess feasibility of the future migration of remaining DVLA payment-taking services to the new
payment capability in Phase 2.
Validate that the solution delivered by Phase 1 meets its requirement to be re-usable for other DVLA
services.
TEST & DEVELOPMENT REQUIREMENTS





Build of appropriate test and development environments
Integration with corresponding DVLA environments and PSP environments
Conducting iterative agile testing
Conducting user acceptance, operational acceptance & performance testing as required
Conducting tests required by PSP and merchant acquirer
Digital Services - RM1043
Document1
Page 7 of 10
Digital Services – RM1043
Request for Proposal
CAPABILITIES AND ROLES
Current Roles and Responsibilities of the Customer
Role
Responsibilities
Delivery Manager
(in-place DVLA resource)
Dedicated to this Project and responsible for delivery of Strategic Card
Payments solution, Phase 1.
Role as per GDS job description: https://www.gov.uk/service-manual/theteam/recruitment/job-descriptions.html
Product Manager
(in-place DVLA resource)
Responsibilities include the Strategic Payment capability as a product.
Role as per GDS job description: https://www.gov.uk/service-manual/theteam/recruitment/job-descriptions.html
Portfolio Manager
(in-place DVLA resource)
Responsible for a portfolio of “common” services which includes the
Payment capability.
Role as per GDS job description: https://www.gov.uk/service-manual/theteam/recruitment/job-descriptions.html
User Researcher
(DVLA resource, TBC subject
to internal sourcing)
Shared resource, seconded at least part time to the Strategic Card
Payments project and responsible for user research.
Role as per GDS job description: https://www.gov.uk/service-manual/theteam/recruitment/job-descriptions.html
Technical Architect
(provided via existing 3rd party
Architecture Services contract)
Dedicated to this Project and responsible for technical architecture input.
Role as per GDS job description: https://www.gov.uk/service-manual/theteam/recruitment/job-descriptions.html
The following Supplier roles are proposed as the start-up team to commence the initial Statement of Work,
however the resource profile will be reviewed and agreed regularly between the Customer and Supplier(s), as
it is expected to flex up and down in line with requirements as work progresses. The Customer envisages the
team increasing (subject to further spend approval/budget) to a projected maximum of 18 throughout the
duration of the scope of work, as indicated below. At this RFP stage, Suppliers are requested to submit
proposals for the start-up team of 9 roles specified below:
Digital Services - RM1043
Document1
Page 8 of 10
Digital Services – RM1043
Request for Proposal
Required Capabilities and Outcomes of the Supplier
Capabilities
Outcomes
Developer – see person specification embedded below:
Software
Engineering
and Ongoing
Support
Start-up
team
Projected
maximum
x2
x5
x2
x4
x1
x3
x1
x1
x1
x1
x2
x4
SCP Developer
v1.doc
Developer with Quality Assurance Testing experience – see
person specification embedded below:
SCP Tester.doc
Business Analyst – see person specification embedded below:
SCP
Businessanalyst.doc
Agile Delivery
Management
Delivery Manager with Scrum Master experience – see person
specification embedded below:
SCP Scrum
Master.doc
Front-end
Design and
Interaction
Design
System
Administration
and Web
Operations
Designer – see person specification embedded below:
SCP Designer.doc
Web Ops – see person specification embedded below:
SCP WebOps v1.doc
DELIVERY LOCATION
Delivery is required to be on-site at DVLA Swansea for the duration of the work, as the Supplier personnel will
need to collaborate regularly with staff from DVLA, our legacy IT supplier and our Payment Service provider.
However, flexibility around working patterns will be considered provided that each individual works an average
37 hour week Monday to Friday.
Digital Services - RM1043
Document1
Page 9 of 10
Digital Services – RM1043
Request for Proposal
EVALUATION STAGES, MINIMUM PASS MARKS & PRICE EVALUATION
Evaluation Stages:
This RFP will be evaluated in a single stage following a two-stage approach:

Technical & Cultural evaluation

Pricing evaluation
Minimum Pass Marks:
The following paragraph applies if a short-listing first stage is used:
In order for Potential Providers to progress beyond the Short List stage of the process, they must achieve or
exceed the Minimum Pass Mark, as defined in the Award Questionnaire, in the evaluation of the first stage
Stage 1: Technical &
Cultural evaluation
All Potential Providers who achieve the required Minimum Pass Mark for a Lot
will be added to the Short List, and will be eligible to continue to Stage 2.
Stage 2: Pricing
evaluation
Detailed below within the ‘Price Evaluation’
Price Evaluation:
The Customer has selected the following mechanisms for Price Evaluation:
(1) Combined evaluation: Price evaluation will be conducted as described in the Lotting Structure
of the RFP (inverse proportion to the best price, which will obtain maximum marks). The mark
thereby obtained will be combined with the marks from stage 1 (moderated by Stage 2 if
applicable) in accordance with the weighting factors defined in the Award Questionnaire
(Appendix C)
“Combined evaluation”:
The Potential Provider’s price mark for each Lot will be evaluated by comparing the Total Price offered against
all other total prices submitted by other Potential Providers.
The Potential Provider who offers the lowest Total Price for a Lot will achieve the maximum score for that Lot.
Every Potential Provider will, for each Lot, be awarded a percentage of the maximum score on a reducing
basis based on the following formula:
Lowest Price Submitted Per Lot
x 100
Potential Provider’s Price Per Lot
= % of the maximum score, rounded to 2 (two) decimal places.
The pricing score, following the price evaluation; will be added to the scores already recorded for Sections A
and B of the Award Questionnaire (Appendix C) to arrive at a final total score
For the avoidance of doubt, depending on the results of the evaluation, the outcome of this procurement could
consist of a single Potential Provider being awarded all Lots, or each individual Potential Providers each being
awarded one of the Lots.
Digital Services - RM1043
Document1
Page 10 of 10