Statement of Objectives

FINAL

REQUEST FOR QUOTE

ENTERPRISE COLLABORATION

AND

CUSTOMER RELATIONSHIP MANAGEMENT

CORRESPONDENCE SYSTEM IMPLEMENTATION

BPA Task Order 0001

Dated:

ACQUISITION SENSITIVE IAW FAR PART 3.104 1

Request for Quote Overview- Task Order 0001:

The __________________ intends to award an initial Task Order under the Multiple Award

Blanket Purchase Agreement for Development Support Services to support the implementation

of the Enterprise Collaboration platform and the Customer Relationship Management System

(CRM) Application.

Table of Contents

Section A. Statement of Objective

Section B. Instructions to Offerors

Section C. Evaluation of Offers

ACQUISITION SENSITIVE IAW FAR PART 3.104 2

Section A: Statement of Objective

1. Introduction and Overview

2. Objective

The objective of this task order is to utilize the Agile development process to establish the

Enterprise Collaboration platform as the primary workflow application for various

components and to develop a Customer Relationship Management (CRM) application. The

purpose of the CRM application will be to maintain a centralized view of all interactions and

outreach to citizens through various methods. This new system will replace all critical and

major businesses processes supported today by the legacy CRM system.

This system must be fully operational and be able to support all critical components by

October 01, 2013. Critical components are defined in Appendix C as “must have” features

and major business components are defined as “should haves” and “nice to haves.” All

additional major business components shall be completed by the end of the period of

performance as proposed in the resulting Performance Work Statement and Roadmap.

3. Scope

The scope of this task order falls under Functional Areas 1 & 2 of the Blanket Purchase

Agreement (BPA) and includes:

 Initial system design and implementation

 System configuration to support business processes

 Integration for input and output methods

 Configuration to support cloud encryption gateway technology

 Data import of records collected from legacy systems

 Training of end users on new system

Scope does not include:

 workstations, data centers, server systems, and connectivity

 Supporting Legacy applications/systems

4. Period and Place of Performance

The period of performance start date of the acquisition is 07/01/2013.

The primary place of performance for this effort will be at government or contractor facilities

if designated.

ACQUISITION SENSITIVE IAW FAR PART 3.104 3

5. Order Type/Award Term Option Incentive

This task order shall be Firm Fixed Price/Award Term Option Incentive.

For this task order the Government will offer Award Term Options which may encompass

future enhancements, releases, development efforts, or operations & maintenance related to

the establishment of the Enterprise Collaboration platform or the CRM application. Award

Terms may only be awarded for an overall “Excellent” performance rating based on mutually

accepted metrics. The Government will appoint an Award Term Determining Official

(AFDO) who will provide the official performance review and approval for an Award Term

Option to be exercised. The AFDO in conjunction with the Contracting Officer will make a

unilateral decision as to the exclusion of any portion of the performance period from the

evaluation of ratings and calculation of the award term.

Award Term Options are not required to be consecutive with the previous period of

performance of the base period or additional options. They are contingent on continued

Government requirements and funding availability for the Enterprise Collaboration platform

or CRM application. The Award Term Options are un-priced options that will be negotiated

and approved from a technical and budgetary standpoint prior to the Contracting Officer

awarding the option. Award Term Options must adhere to the proposed Agile methodology

and processes as awarded at the BPA level unless an exception is provided by the

Contracting Officer prior to award.

6. Technical Overview

a. Technical Environment

The platform will contain Sensitive But Unclassified (SBU) and Personally Identifiable

Information (PII). No classified information will be contained in these systems. Federal

Information Processing Standard (FIPS) 199 classification is likely High for Availability,

Moderate for Integrity, and Low for confidentiality.

The current system supports roughly 576 end users.

b. Stakeholders

For the completion of this task, the AGENCY will provide access to the following

stakeholders:

Technical Lead/Product Owner: Will manage and communicate with the stakeholder

community, is capable of making business decisions rapidly and setting priorities, will

participate in iterative planning sessions and will remove obstacles to project success.

Contracting Officer’s Representative (COR): Will be responsible for approving end

deliverables, managing the Quality Assurance Surveillance Plan (QASP), evaluating

ACQUISITION SENSITIVE IAW FAR PART 3.104 4

performance, and managing schedule according to the submitted Performance Work

Statement (PWS)

Stakeholders: For this effort the following offices have been designated as Stakeholders for

the CRM application.

7. Required Tasks

a. Task 1: Initial Enterprise Collaboration System Configuration and

Implementation

Objective: Contractor shall provide the agency with a secure, stable, records compliant,

commercial collaboration, workflow enabled Enterprise Collaboration Platform.

i. The contractor shall design the system for maximum interoperability

across all components and offices to ensure flexibility in leveraging the

system for future applications.

ii. The contractor shall approach system design in as “off-the-shelf” (COTS)

a manner as possible with focus on preventing or minimizing system

customization.

iii. The contractor shall configure the following system instances to support

tiered code-release separation and quality assurance testing methodology:

Instance Name

Description and Purpose

Development

Description: The Development instance(s) will exist as the primary

development site for integrators to fix bugs, develop new features, and test

unit functionality to ensure items are ready for update to Staging. These

instances will be accessed typically only by administrators and developers.

Purpose: To provide isolated system instance(s) for active development

and/or Unit Testing.

User-base: Integrator development team and infrequently the Integrated

Project Team as required.

Availability: The Development instance(s) shall not be bound to any Service

Level Agreement and may be subject to maintenance and upkeep on an as-

needed basis.

Feature Set: The Development instance(s) shall run the code version

required for active development.

ACQUISITION SENSITIVE IAW FAR PART 3.104 5

Data: The Development instance(s) shall dummy data such that it is

rendered non-sensitive and non-specific for the purposes of development.

Staging

Description: The Staging instance shall be a system for formal User

Acceptance Testing and Training as well as collaboration with the Integrated

Project Team and agency user community.

Purpose: To separate User Acceptance Testing and Training activities from

Unit Testing or Production activities.

User-base: Integrator development team, the Integrated Project Team, and

designated users for testing and training as required.

Availability: The Staging instance shall be generally available to Integrated

Project Team members during working hours (7:30am – 7:30pm) and at the

integrator’s discretion for maintenance and upkeep.

Feature Set: The Staging instance shall run the most current version of the

production code. It may be updated with Unit Test or new release code

until being fully replaced with the current code after the next production

release.

Data: The Staging instance shall include masked, truncated, or redacted

agency data such that it is rendered non-sensitive for the purposes of

testing and training.

Production

Description: The Production instance shall be a system supporting the work

of active Production instance users.

Purpose: To separate development and testing activities from actual

government business processes and records.

User-base: The integrator’s development team, the Integrated Project

Team, and the Production user community within the Agency.

Availability: The Production instance shall be available for user access in

accordance with the service level agreement for the platform.

Feature Set: The Production instance shall run the current version of the

production code feature set after a release to production. The Production

and Recovery instances must run the same code version at all times.

Data: The Production instance shall include live, SBU agency data and only

be modified by authorized users within their assigned security roles. The

data set active on the Production instance should be complete, comply with

Federal Records Act (FRA) requirements, be backed up in accordance with

ACQUISITION SENSITIVE IAW FAR PART 3.104 6

the platform disaster recovery plan, and be able to be properly exported for

transfer to National Archives and Records Administration (NARA) at the

appropriate times.

Recovery

Description: The Recovery instance shall be an entirely separate, hot fail-

over system to support the work of the Production instance users in the

event of an outage or inaccessible Production instance.

Purpose: To provide continuity of operations for critical business processes

as well as recovery and preservation of production data in the event of a

catastrophic outage with the Production instance.

User-base: The integrator’s development team, the Integrated Project

Team, and the Production user community.

Availability: The Recovery instance shall be available for user access in

accordance with the service level agreement for the platform.

Feature Set: The Recovery instance shall run the current version of the

production code feature set after a release to production. The Production

and Recovery instances must run the same code version at all times.

Data: The Recovery instance shall include live, SBU agency data and only be

modified by authorized users within their assigned security roles. The data

set active on the Recovery instance should be complete, comply with the

Federal Records Act requirements, be backed up in accordance with the

platform disaster recovery plan, and be able to be properly exported for

transfer to NARA at the appropriate times.

iv. The contractor shall design and implement a user rights, permissions, and

security model as notionally described in APPENDIX A -Rights Model

Spreadsheet.

v. The system shall securely transmit all data using Secure Socket’s Layer

encryption at 128-bit or higher.

vi. The system shall restrict all network traffic to be accessible only from

designated networks.

vii. The contractor shall design database entities to comply with the FRA:

1. The contractor shall configure the system such that complete sets

of database records can be easily exported into separate, discrete

export files.

b. Task 2: CRM Application Design and Implementation

Objective: The contractor shall design and implement the basic system features to support

traditional CRM functions including the following:

1. One centralized constituent record per citizen with links to all

associated vital data and correspondence records

ACQUISITION SENSITIVE IAW FAR PART 3.104 7

2. Newsletters (bulk e-mail)

3. Reports and dashboards

4. Advanced search

5. External web forms (Contact Us)

6. Internal web forms (Gifts, Greetings)

7. Rules engines, workflow, analytics, and service-level-agreements

8. Ad-hoc data import and export

9. Document version control, workflow, and library

templates/repository

10. Highly customized printed correspondence in batches.

7.2.1 The contractor shall architect system objects, fields, and database entries to

support the associated business processes.

ii. The contractor shall utilize the system support business processes as

described in APPENDIX B-Vignettes Slide Deck and APPENDIX C –

User Stories as the basis for the CRM application.

iii. The contractor shall ensure the system is configured to support expansion

for additional requirements.

iv. The contractor shall configure the system in a way to support “Open

Source” publishing

c. Task 3: Integration for Input and Output Methods

Objective: The CRM application shall be able to accept and distribute high volumes of

correspondence from and to various sources:

i. The contractor shall configure the system to receive “hard mail” files

scanned and uploaded to the system.

ii. The contractor shall configure the system to receive electronic faxes as

typical SMTP e-mails.

iii. The contractor shall configure the system to support high quality printing

for the Production and Greetings departments.

iv. The contractor shall configure the system to provide bulk and automated

e-mail by groups, lists, or individuals to support Newsletter functionality.

v. The contractor shall configure the system to support a universal

unsubscribe function for constituents.

vi. The contractor shall configure the system to receive “hard mail” files

scanned and uploaded to the system:

1. The high capacity scanners used for this function are Hard mail

scanning:

2. Hard mail items shall be processed by optical character recognition

(OCR) and pre-populated with available data such as name,

address, and subject etc., in a similar manner as entries are ingested

from web forms.

vii. The contractor shall configure the system to receive electronic faxes as

typical SMTP e-mails.

1. Fax items shall be processed by optical character recognition

(OCR) and pre-populated with available data such as name,

ACQUISITION SENSITIVE IAW FAR PART 3.104 8

address, and subject etc., in a similar manner as entries are ingested

from web forms.

viii. The contractor shall configure the system to support high quality printing

production including:

1. Supporting printing through local printer entries only

2. Support for various letter, letterhead, and envelope types as

prescribed by the government

ix. Bulk and automated e-mail by groups, lists, or individuals to support

Newsletter functionality including:

1. Reply-to addresses

2. Whitelist support with major e-mail spam filter organizations

3. Analytics for click-through, open rates, bounce back reporting

4. Support A-B newsletter testing

d. Task 5: Data Import collected from Legacy Systems

Objective: The contractor shall import data collected from legacy systems in a manner that

maintains vital record data such as name, address, e-mail address; association data such as group-

membership, interests, contact preferences, flags, and affiliations; as well as correspondence

items, linkage with constituent record, contact history, and attachments.

i. The contractor shall analyze, assist with exports, de-duplicate/scrub,

prepare, and import data that has been collected from legacy systems

including:

1. The primary legacy CRM system,:

o Provided as a government intermediary MySQL database available

to the contractor

o Approximately 40GB of data and 400GB of file attachments

ii. The contractor shall work with the government stakeholder offices during

design sessions to identify and separate legacy system data into two sets of

relevant data: Operational data records and Historical data records.

o Operational data records are required for critical business processes

and shall be prioritized, imported, and available to users at system

activation

o Historical data which must be imported to ensure overall data

integrity for the stakeholder departments and shall be treated as a

lesser priority than operational data but planned for with regard to

overall data integrity

iii. All legacy system data must be imported, validated, and certified within 3

months of system activation.

e. Task 6: Documentation and Training

ACQUISITION SENSITIVE IAW FAR PART 3.104 9

Objective: The contractor shall provide complete documentation for all systems and applications

and provide training that will enable end users to utilize the system.

i. The contractor shall provide comprehensive training materials for end

users and system administrators for utilization and administration of the

system.

1. Videos or self-guided training materials may be used

ii. The contractor shall provide initial end-user training on a per-department

basis during the initial on-boarding of users to the new system.

iii. The contractor shall provide “train-the-trainer“ classes for selected trainers

and administrators.

8. Constraints

9. Deliverables

The contractor shall ensure proper control and coordination of all deliverables as proposed in the

work plan to ensure they are on time.

Unless otherwise stated, the Government will review deliverables and notify the contractor of

findings within 10 workdays. Representatives of the contractor shall meet with the COR and

other member of the Government as necessary as to review status and other deliverables.

ACQUISITION SENSITIVE IAW FAR PART 3.104 10

SECTION B: Instructions to Offerors

10.1 SUBMISSION OF QUOTES

Quotes shall be submitted by 12:00 noon Eastern Standard Time on.

Quotes shall be submitted to the

Quote submission will consist of two (2) parts: Technical Submission and Price

In addition to price the following factors will be used to determine best value. Technical factors

are more important than price:

 Performance Work Statement

 Product Roadmap

 Notional Quality Control Plan

10.2 SECTION I - TECHNICAL SUBMISSION

The Technical submission shall include the following:

FACTOR 1 – Performance Work Statement (PWS)

FACTOR 2 – Product Development Roadmap

FACTOR 3 – Notional Quality Control Plan

Technical Assumptions, Conditions or Exceptions

10.3 FACTOR 1 – Performance Work Statement

Offerors shall provide a Performance Work Statement (PWS) in response the Statement of

Objectives and this RFQ. The proposed solution shall include an explanation of how project and

contract management, communication/collaboration with the Government, security requirements,

documentation, and reporting will function in conjunction with the proposed Agile methodology.

10.4 FACTOR 2 – Product Development Roadmap

Offerors shall propose an Agile product development roadmap which correlates how the stated

objective aligns with the timeframe for implementation and the offeror’s proposed Agile

methodology. The product development roadmap shall demonstrate where testing, training,

security, and cut over planning, will be included.

10.5 FACTOR 3 – Notional Quality Control Plan (QCP)

Offerors shall describe the QC and Performance Measurement approach, including how

proposed performance standards will be monitored, evaluated, and reported. The purpose of the

notional QCP is to provide evaluators with an understanding of how measures and metrics will

be applied based on the proposed technical solution.

ACQUISITION SENSITIVE IAW FAR PART 3.104 11

10.6 Technical Assumptions, Conditions, or Exceptions

Technical submissions shall include all (if any) assumptions, conditions, or exceptions with any

of the requirements or terms and conditions of the Statement of Objectives. If not noted in this

section of your quote, it will be assumed that there are no assumptions for award, and that the

Contractor agrees to comply with all of the terms and conditions as set forth herein. It is not the

responsibility of the Government to seek out and identify assumptions, conditions, or exceptions

buried within the submission.

The Government reserves the right to reject any quote that includes any assumption that impacts

or affects the Government’s requirements.

10.6 SECTION II – PRICE

The price quote shall include the following:

 Firm, fixed price for the effort required

 Supporting documentation

 Assumptions, conditions, and exceptions

The Government anticipates that a Firm Fixed price Task Order will be issued as a result of this

solicitation.

Supporting Documentation: The price quote shall provide supporting documentation to backup

the pricing proposed. This shall demonstrate the correlation between the proposed technical

solution in the PWS and the pricing submitted.

Price Assumptions, Conditions, or Exceptions

Submit all (if any) assumptions, conditions, or exceptions with any of the terms and conditions

of this statement of objectives. If not noted in this section of your quote, it will be assumed that

the offeror proposes no assumptions for award, and agrees to comply with all of the terms and

conditions as set forth herein. It is not the responsibility of the Government to seek out and

identify assumptions, conditions, or exceptions buried within the offeror’s quote.

ACQUISITION SENSITIVE IAW FAR PART 3.104 12

Section C: Evaluation of Offers

11.1 Evaluation and Method of Award

This task order will be awarded to the Enterprise Collaboration Platform Development Services

Blanket Purchase Agreement award holder that can provide the services that represent the best

value to the Government. In addition to price, this assessment will be based on the Technical

Factors of Factor 1-Performance Work Statement, Factor 2-Product Roadmap, and Factor 3-

Notional Quality Control Plan

11.2 FACTOR 1 – Performance Work Statement

The Government will evaluate the feasibility of the proposed PWS to meet the Objectives of the

Agency.

11.3 FACTOR 2 – Product Development Roadmap

The Government will assess the proposed Agile roadmap to determine if it demonstrates an

understanding of the complexity of the effort and how the stated objective aligns with the

objectives and timeframe for implementation and the offeror’s proposed Agile methodology. The

Product Roadmap shall demonstrate where testing, training, security, cut over planning, etc. will

be included.

11.4 FACTOR 3 – Notional Quality Control Plan (QCP)

The proposed QCP will evaluate the rational for the proposed performance standards and

performance measurement methodology and assess whether the total solution will ensure that the

performance standards are met.

11.5 Technical Assumptions, Conditions, or Exceptions

All assumptions shall be evaluated as part of the individual factor or sub factor to which they

apply. The Government reserves the right to reject any quote that includes any assumption(s)

that impact satisfying the Government’s requirements.

11.5 SECTION II – PRICE

Price will be evaluated to determine whether the firm, fixed price proposed is reasonable. This

determination will be based on the review of the technical solution in comparison to the total

proposed price and the backup documentation submitted.

11.5.1 Price Assumptions, Conditions, or Exceptions

Submit all (if any) assumptions, conditions, or exceptions with any of the terms and conditions

of this statement of work. If not noted in this section of your quote, it will be assumed that the

offeror proposes no assumptions for award, and agrees to comply with all of the terms and

ACQUISITION SENSITIVE IAW FAR PART 3.104 13

conditions as set forth herein. It is not the responsibility of the Government to seek out and

identify assumptions, conditions, or exceptions buried within the offeror’s quote.

ACQUISITION SENSITIVE IAW FAR PART 3.104 14

ALTERNATIVE EVALUATION CRITERIA EXAMPLES:

Pricing: In order to determine best value – pricing for this effort is required to be on unit of

measure that is equivalent to the proposed sprint/iteration/release cycle as proposed in the SOW.

The technical solution for sizing, iteration time, and throughput must correlate to the proposed

pricing.

Backup Documentation: The price quote shall provide backup documentation to support

the pricing proposed. This shall demonstrate the correlation between the proposed technical

solution in the PWS and the pricing submitted. This shall include any standard definitions that

will apply to the Agile unit of measure described.

FACTOR 1 – Performance Work Statement

Offeror shall provide a Performance Work Statement (PWS) in response the Statement of

Objectives for Award Term Option 2. The proposed solution shall include an explanation of how

project and contract management, communication/collaboration with the Government, security

requirements, documentation, and reporting will function in conjunction with the proposed Agile

methodology.

For this effort, the PWS shall clearly illustrate how the process through which Agile

Development of software in small iterations lasting two to five weeks results in usable software.

Each iteration is defined as a development cycle which includes planning, requirement analysis,

design, coding, testing, quality assurance and documentation all meet the offeror’s proposed

“Definition of Done”.

The deliverables under this PWS are to have functionality scheduled for an available release

without defects which the developers can present to the stakeholders in the project. In order to

meet this goal, fixed price units shall be developed to provide the repeatable framework from

which future users stories can be placed. The resulting proposed “units” will be “fixed time” and

“fixed price” but will not have “fixed scope”.

The PWS shall describe how user stories are to be sized, how estimation and determination of

sizes shall be accomplished, and how these will correlate to iterations and throughput.

The Offerror shall provide a notional release schedule which maps the proposed sprint/iteration

cycle to the calendar Period of Performance. This release schedule shall include relevant

governance process checkpoints such as Technical Reviews and Sprint Releases as well as Agile

methodology functions such as Sprint Planning, Sprint Review, and Sprint Retrospectives.

FACTOR 2 – Notional Quality Control Plan (QCP)

Offeror shall update the Quality Control and Performance Measurements based on the previously

agreed upon metrics as established under Award Term Option 1. The purpose of the notional

ACQUISITION SENSITIVE IAW FAR PART 3.104 15

QCP is to provide the agency with an understanding of how measures and metrics will be applied

based on the proposed technical solution. These metrics shall cover planning, inspecting, and

understanding progress under time. The metrics shall correspond with the “definition of done” as

proposed in the PWS. These metrics should be proposed based on the current throughputs and

sprints as developed under Award Term Option 1. They should indicate an “Acceptable” quality

level and an “Excellent” quality level to correspond to the Award Term determination.