75N97019R00003_-_Attachments.pdf

PDF 458 KB Posted

Attached to
OER Software Design and Development
Solicitation number
75N97019R00003
Issued by

About this file

Attachments to 7597019R00003

View the file

Other files

File Type Posted
Amendment_One_-_Answer_to_Questions.pdf PDF
75N97019R00003_-_RFP.pdf PDF

On GovTribe

Work with this file

  • Download the original file
  • Contacts named in this file
  • Similar government files
  • Ask GovTribe AI about this file

Text version

75N97019R00003 Attachment 1

Packaging and Delivery of Proposal

1. Proposals shall be delivered in electronic form to the Contracting Officer at jeremy.white@nih.gov.

2. Offerors shall provide 10 hard copies of the Technical Proposal and 5 copies of the Cost Proposal by 2:00 PM ET, July 17, 2019.

Deliveries are to be made to:

Jeremy White, Contracting Officer 6700 Rockledge Drive Room 2122 Bethesda, MD 20892 mailto:jeremy.white@nih.gov

75N97019R00003 Attachment 2

Statement of Work (SOW)

OER Agile Software Development Support Services

RFP 75N97019R00003

1. Introduction, Background and Scope

1.1 Introduction

The Department of Health and Human Services (HHS), National Institutes of Health (NIH), through this contract intends to procure a wide range of software development services to support the Office of Extramural Research (OER) and its offices and divisions, including, Office of Electronic Research Administration (eRA), Division of Data Systems and Data Quality (DDSDQ), Division of Loan Repayment (DLR) and other offices/divisions within the

OER.

1.2 Background

The NIH mission is to uncover new knowledge that will lead to better health for everyone. NIH accomplishes that mission by conducting research in its own laboratories; supporting the research of non-Federal scientists in universities, medical schools, hospitals, and research institutions throughout the country and abroad; helping in the training of research investigators;

and fostering communication of biomedical information.

The OER is an office within the NIH Office of the Director. OER supports the entire NIH extramural research community by providing policy, guidance, systems and other support to the recipient community as well as to the 24 NIH Institutes and Centers that award grants. OER serves as a vital interface for the biomedical research community by guiding investigators through the process of attaining grants funding and helping them understand and navigate through federal policies and procedures.

The OER Office of electronic Research Administration (eRA), the largest of the OER offices, provides NIH's customized enterprise-wide grants management system, an end-to-end electronic system used by the grantee community and grantor staff to apply for, evaluate, award, manage and track, and close out grants. The system supports the Federal Business Lifecycle – Grants Management from GRM.010 through GRM.050 as documented at https://www.ussm.gov/fibf-gm/. The system is designed, developed, maintained, updated, and supported to address the grant management policies, processes, and requirements of NIH’s extramural research mission and also to support the grants management needs of partner agencies. As an HHS Grants Center https://www.ussm.gov/fibf-gm/ of Excellence (COE), eRA systems provide information technology solutions and support for the full life cycle of grants administration functions for the NIH as well as for partner agencies including the Agency for Healthcare Research and Quality (AHRQ), Centers for Disease Control and Prevention (CDC), Food and Drug Administration (FDA), the Substance Abuse and Mental Health Services Administration (SAMSHA), and the Veterans Administration (VA).

The OER Division of Data Systems and Data Quality (DDSDQ) develops and maintains research portfolio reporting databases and analysis tools on behalf of the NIH. The purpose of these tools is to improve NIH-wide internal staff and public access to data on NIH research in order to facilitate evaluation and management of research portfolios and to satisfy certain reporting requirements of the NIH Reform Act of 2006 (P.L. 109-482; H.R. 6164, §402B).

These tools integrate new and existing data sources to allow user-defined querying, reporting, analysis, evaluation, and visualization of NIH grants, intramural projects, contracts, and associated outputs. An additional purpose is to develop and maintain similar tools to support other Federal science agencies. Specific program within DDSDQ include:

• NIH Research Portfolio Online Reporting Tools (RePORT). NIH RePORT is an NIH program to share public reports, statistics, visualizations, and re-usable data, meeting the goals of the NIH Reform Act and several open data initiatives. Included in this are modules for official budget reporting by spending category, summary of awards by location or organization, searchable databases of funded NIH projects linked to outcomes including patents, publications, clinical trials, and other resources, as well as the recently released NIH Data Book. This information is served to more than 120,000 users per month, with more than 70,000 users conducting grant-related queries per month through NIH RePORTER. RePORT offers similar tools for the federal-wide community under Federal RePORTER.

• The Query, View, and Report (QVR) system: Comprised of three modules, (QVR, iRePORT, and SPIRES), the QVR system includes interlinked tools for internal staff to query internal grants data and documents, viewing informative summaries and data downloads, and delivers compelling and interactive visualizations to allow data driven decision-making by NIH scientific staff, and complex information into customer-friendly reports. NIH staff conduct more than 1 million queries per year, and tens of thousands of customized reports across all extramural business areas.

• The Portfolio Analysis and Reporting Data Infrastructure (PARDI): This cloud-based analytic data lake and data warehouse provides enterprise-wide support for both quantitative and qualitative research on the NIH portfolio and long-term results of NIH-funded research. Combining multiple high-value data sources of data into one data system, allows the data can to be uniformly managed, accessed, integrated, and used across NIH. Key information sources include NIH awarded grants and contracts, USPTO patents, clinical guidelines and references from the AHRQ National Guideline Clearinghouse, Clinicaltrials.gov registrations, publications and citations from Clarivate Web of Science, the FDA Orange Book, and the Derwent Patent Citation Index.

The OER Division of Loan Repayment (DLR) administers the Loan Repayment Program (LRP), which provides loan repayment services to highly qualified physicians and other health professionals with doctoral-level degrees to promote recruitment and retention in biomedical and https://report.nih.gov/ behavioral research careers by countering growing economic disincentives and staggering educational debt with loan repayment relief. LRPs are mandated by congress and have been established for health professionals pursuing clinical, pediatric, health disparities, and contraception and infertility research careers funded by non-profit institutions (Extramural LRP), and for health professionals serving in research positions and fellowships (clinical and basic science) in the NIH intramural laboratories. Additionally, the DLR has oversight over the Ruth L. Kirschstein National Research Service Awards (NRSA) Payback Service Center (PSC) for the administration of service payback requirements. Section 487 of the Public Health Service Act (42 USC 288), provides authority for the NIH to award National Research Service Awards (NRSA) to support predoctoral and postdoctoral training.

The OER offer vital solutions to manage the receipt, processing, review, award reporting and monitoring of over $30 billion in research and non-research grants awarded annually by NIH and other grantor agencies in support of the collective mission of improving human health. In addition to staff at the NIH ICs, the OER systems are used by applicants and grantees at over 38,000 institutions worldwide. OER’s focus are on supporting the mission of serviced agencies by providing systems to electronically manage and report on grants in a way that:

• Ensures strong system and data security.

• Provides flexibility to respond to the unique business needs of NIH and its federal partners.

• Provides a system that promotes effective and efficient, end-to-end management of federal grants.

• Provides dependable, responsive system availability with 24 x 7 on-call support.

• Continually enhances the OER systems to reduce the administrative burden on the user community as well as agency staff.

• Maximizes efficiencies.

• Provides a strong and scalable infrastructure.

• Is responsive to evolving customer needs.

• Employs sound management and secure controls.

• Delivers a satisfying user experience.

eRA:

The eRA, in particular, develops and supports multiple complex systems that:

• Record, review and process over 157,000 applications and awards each year.

• Support over 220,000 active users and close to 19,000,000 logins each year.

• Support over 65,000 reviewers and more than 3,700 review meetings.

• Process over 300,000 reviewer critiques.

• Administer more than 60,000 awarded competing and non-competing grants.

• Maintain patent and invention records for 25+ Federal agencies through iEdison.

• Support thousands of applicant interactions with the Federal Government before and after the grant award, through the eRA online interface.

The critical grants management systems, managed by eRA, align with Grants.gov (the one-stop web portal for finding and applying for federal grants), allowing for full electronic processing of grant applications from application submission through closeout of the grant award.

The entire eRA Enterpriseshares a common Oracle database. The system is a web-enabled multi-tier environment running in a high-availability configuration across two data centers (VA and MD). The Apache Tomcat application server is the primary middle tier platform. The hardware architecture is a combination of Windows NT and Linux servers. A migration from an on-premise environment to a similarly robust Infrastructure as a Service (IAAS) public cloud computing platform is underway. eRA has selected Amazon AWS as its primary cloud computing platform.

Division of Loan Repayment:

• Technology Stack: DLR systems are built using Microsoft .NET and the backend database is Microsoft SQL Server. Expertise with this technology stack is critical for supporting DLR.

• Privacy and Data: LRP award data is not publicly available due to privacy concerns. LRP has its own SORN and LRP application information that includes sensitive financial information. LRP data needs to be curated in specific way to ensure privacy.

• Reporting Requirements: DLR is responsible for interfacing with NBS and HHS to deliver reporting consistent with Data Act requirements.

Division of Data Systems and Data Quality:

• Technology Stack: Legacy applicable technologies still in use include: HTML, ColdFusion, .NET MVC, Angular, Microsoft SQL Server, SOLR, and Oracle.

• New system development takes advantage of next generation technologies to include, but not limited to: Drupal8, C#, Python, VUE.JS, PostgreSQL, Elastic Search, Microsoft Azure HDInsight, Apache Spark, and continuous integration and development through Jenkins automation.

System Characteristics:

Servers 430+ Physical and Virtual Storage 238 TB Component Modules 100+ major components Deployments Approximately 1,000 Production

Middle Tier and Database per FY Network/Operational Security 500+ Physical Network ports Database 10 Databases

1,500 tables 3 billion records

Over 5 million documents generated per year

The contract for eRA software development is HHSN276201400012C (Leidos). The contract for Reporting Systems is HHSN316201200160W/HHSN27600003 (NETE) and the contract or Division of Loan Repayment is HHSN316201200160W (NETE).

1.3 Scope

The scope of this contract will be to provide a wide range of software development services necessary to support OER offices, divisions and systems. The contract will provide software development services including design, development, and application testing services to the Government primarily following the eRA Agile software development lifecycle.

2.0 TECHNICAL REQUIREMENTS

Independently and not as an agent of the Government, the Contractor shall furnish all of the necessary services, qualified personnel, material, equipment, and facilities, not otherwise provided by the Government as needed to perform the Statement of Work below.

Specifically, the Contractor shall:

2.1 Quality Control Plan

The contractor shall establish and maintain a complete Quality Control Plan (QCP) to ensure the requirements of this contract are provided as specified in accordance with the applicable Inspection of Services Clause. The contractor shall develop and implement procedures to identify, prevent, and ensure non-recurrence of defective services. The contractor’s quality control program is the means by which the contractor shall assures all work and services provided comply with the requirements of this contract. The QCP is to be delivered within 30 days after contract award. An electronic copy of a comprehensive written QCP shall be submitted to the contracting officer and contract officer representative within 5 working days when changes are made thereafter. After acceptance of the quality control plan the contractor shall receive the contracting officer’s acceptance in writing of any proposed change to the QC program and plan. The Contracting Officer (CO) will notify the contractor of acceptance or required modifications to the plan. The contractor shall make appropriate modifications (at no additional costs to the government) and obtain acceptance of the plan by the CO. The Government has the right to require revisions of the QCP (at no cost to the Government) should the incorporated plan fail to control the quality of the services provided at any time during the contract performance.

The Contractor shall perform quality assessments of program processes and products to ensure adherence to guidelines, standards, and plans. The Contractor shall develop and maintain technical documentation in support of quality management functions, conduct quality assessments, and develop reports documenting findings. The plan shall include, but is not limited to the following:

• A description of the inspection system covering all services listed.

• The specification of inspection frequency.

• The title of the individual(s) who shall perform the inspection and their organizational placement.

• A description of the methods for identifying, correcting, and preventing defects in the quality of service performed before the level becomes unacceptable.

The Contractor shall review and validate the quality of tasks performed. The Contractor shall summarize the results of its quality reviews of all assigned tasks, identify gaps/issues, and recommend corrective action, as needed. The Contractor shall provide technical support to validate the successful execution of the corrective action.

The Contractor shall ensure that all documented guidelines and operating procedures for quality assurance/control are followed for all areas of performance. The Contractor shall develop and implement additional quality assurance/control procedures as necessary to ensure all work performed is in accordance with standards prescribed in this contract for the duration of the contract, and the Contractor shall stress to its staff the importance of quality control and quality assurance.

The Government will conduct Quality Assurance Surveillance Reviews (QASR) throughout the life of the contract to ensure that the Contractor is performing the services required in an acceptable manner. The Government reserves the right to alter or change the QASR at its own discretion. A Performance Based Service Assessment Survey will be used in combination with the QASRs to assist the Government in determining acceptable performance levels. The COR(s) will determine if the performance of the Contractor is below a metric standard and deem it unacceptable. The COR will then notify the Contracting Officer.

2.2 Reports

The Contractor shall write monthly status reports. Each status report shall provide the status of each work area defined in section 2.4 that was worked on, or was scheduled to be worked on, during the reporting period. Each status report shall also document any problems encountered and how they were, or will be, resolved. Each report shall also document the Contractor’s plans for the next reporting period, including expected accomplishments, anticipated problems and projected solutions. The report shall include a financial report with an Earned Value Management (EVM) table (see Section 2.7.3 for more information on the financial report). The Contractor shall deliver status reports by the fifth working day of each month following the first full month of contract performance.

The Contractor shall prepare all documentation associated with work areas specified in this statement of work in accordance with the OER document standards and primarily the eRA Agile software development lifecycle (SDLC).

2.3 Personnel and Management Requirements

The contractor shall provide on-site management staff with full authority to oversee the assigned resources and enable rapid resolution of day-to-day service delivery issues. The contractor shall provide all management, administration, staffing, planning, and scheduling for all services required by the contract.

The contractor shall provide program management, project control, and contract administration necessary to manage the contract process so that cost, schedule and quality requirements are tracked, communicated to the Contracting Officer's Representative (COR), and Technical Monitors (TMs).

The TMs are government staff assigned to specific tasks and teams.

The Contractor’s Project Manager, or an appropriate designee, shall prepare a monthly status report for each significant task or project in which the Contractor’s staffs are engaged. The monthly status report shall report on the status of each work area (as defined in 2.4) that was worked on and scheduled to be worked on, during the reporting period. The status report shall also document any problems encountered and how they were, or will be, resolved. Each report shall also document the Contractor’s plans for the next reporting period, including expected accomplishments, anticipated problems and projected solutions.

The Program Manager is a senior manager responsible for coordinating the management of all work performed under this contract. The Program Manager is responsible for coordinating the efforts of any subcontractors, team members, vendors, etc. The Program Manager shall act as the central point of contact with the Government and shall have the full authority to act for the Contractor in the performance of the required work and services under the contract. The Program Manager works independently or under the general direction of senior level Contractor business management on all phases of performance, including contract management, coordination of resource needs, coordination with corporate resources and management, and has direct accountability for the technical correctness, timeliness and quality of deliverables. The Contractor's Project Manager, or the appropriate designee, shall meet weekly with the COR, TMs and other eRA personnel to discuss work in work areas (as defined in 2.4) and problem areas. In accordance with the eRA Risk Management Plan, the Contractor shall identify any risks and/or issues which could impact the activities executed under this contract, with corresponding mitigation and contingency plans.

The Contractor shall support the development and maintenance of project schedules, for tracking the work performed on the tasks described in the statement of work.

2.3.1 Personnel

The Contractor shall provide a mix of personnel experienced and qualified to perform tasks in coordination with the COR and TM's related to accomplishing this statement of work.

The Contractor shall be responsible for providing trained, experienced staff for performing the work ordered under this contract, and for continuously monitoring, managing and controlling the work. The Contractor shall make its best efforts to retain staff members who have gained experience on this contract, and to minimize staff turnover.

The Contractor shall train its own staff to ensure that all personnel are able to perform their duties under each task satisfactorily, including training specific to certain Work Areas. The Contractor shall furnish the COR with formal documentation of the training provided to each labor category under the contract as recommended by the COR and approved by the CO, including testing tools for determining if individual employees have achieved competence in their labor categories. Except where specifically approved by the CO, with recommendation by the COR, training of Contractor staff is not separately billable. Specialized training recommended by the COR and approved by the CO beyond that which would normally be required to perform under the contract may be billable with advance approval by the CO with recommendation by the COR.

In addition to job-specific or professional training, the Contractor shall ensure its employees on this contract are trained on "contract-specific" issues such as HHS ethics, standards of conduct, individual conflicts of interest, confidentiality requirements, HHS security requirements, the function of reporting, and the importance of quality control and quality assurance. In addition, Contractor managers shall be educated regarding the terms and conditions of the contract.

2.4 Technical Work Areas

All recommendations, designs, and/or recommended solutions provided by the Contractor to the Government must be compliant with OMB Memorandum M-05-22, Transition Planning for Internet Protocol Version 6 (IPv6). Unless the agency Chief Information Officer waives the requirement, when designing and making recommendations using Internet Protocol, the requirements documents must include reference to the appropriate technical capabilities defined in the USGv6 Profile (NIST Special Publication 500-267) and the corresponding declarations of conformance defined in the USGv6 Test Program.

The applicability of IPv6 to agency networks, infrastructure, and applications specific to individual acquisitions will be in accordance with the agency's Enterprise Architecture (see OMB Memorandum M-05-22 dated August 2, 2005).

The work areas for this contract include, but are not limited to:

a. Project Planning Support (Work Area 1)

b. Requirements analysis and documentation (Work Area 2)

c. Design (Work Area 3)

d. Implementation (coding/new development and maintenance) (Work Area

4)

e. Application Testing (Work Area 5)

f. Project Integration Management/Development Support (Work Area 6)

g. Enterprise System and Production Support (Work Area 7)

h. Documentation Support (Work Area 8)

i. Training Support (Work Area 9)

j. eRA Infrastructure (Work Area 10)

k. Application Security (Work Area 11)

a. Project Planning Support (Work Area 1)

The Contractor shall participate in OER planning activities. A non-exhaustive list of examples of the type of work the Contractor shall perform under this work area is:

• Risk Management

• Issue Management

• Maintaining and updating project schedules

• Release planning

• Level of effort estimating

• Technical Dependency Management

• Program Management Support

• Portfolio Management and Project Tracking Support

• Enterprise Consultation and Implementation Support

• Project Management Support

b. • Requirements analysis and documentation (Work Area 2)

The Contractor shall support requirements development. The Contractor shall assist in defining a set of customer requirements to use in the development of product requirements. A list of examples of the type of work to be performed under this work area includes, but is not limited to:

• Participate in Requirements phases of the Agile SDLC

• Development of Requirements Artifacts including but not limited to Epics and User Stories

• Support in the assessment and documentation of OER’s analysis and requirements management policies and processes

• Elicit, analyze, validate and communicate customer needs, expectations, and constraints to obtain customer requirements

• Communicate high level and detailed requirements to OER Agile teams and collaboration among the teams to ensure requirements are properly documented

• Support OER Business Process Reengineering

c. Design (Work Area 3)

The Contractor shall assist with software product-component design. The work for each software development project will consist of two broad phases of design that may overlap in execution: preliminary design (high level design) and detailed design. The Contractor shall develop and keep up to date design documentation. Each preliminary design shall establish product capabilities and the product architecture, including identification of new or affected product-components; external product interfaces; database changes; adoption of new tools, technologies, or patterns; dependencies on other software components; security requirements performance and load considerations; business or technical impacts; and impacts on system monitoring, capacity, or data backups. Detailed designs shall fully define the structure and capabilities of the product components introduced in the preliminary design. A non-exhaustive list of examples of the work to be performed under this work area is:

• Developing solution alternatives, selection criteria, and design issues

• Conceptual modeling

• Developing preliminary (high level) designs

• Developing detailed designs and updates

• Conducting preliminary and detailed design reviews

• Design verification

• Interface design

• Conducting make, buy, or reuse analyses

• Tracking user requirements to ensure that requirements are satisfied

• Analysis and assessment of defects identified during independent functional/integration testing

• Impact analysis

• Developing proof of concepts, prototypes and wireframes

• Data Analysis

d. Implementation (coding/new development and maintenance) (Work Area 4)

The Contractor shall translate executable software from the detailed design specifications produced during the design phase are translated into executable software. Initial prototypes are transitioned into operational products. Software shall be unit tested, integrated, and retested in a systematic manner. A non-exhaustive list of examples of the work to be performed under this work area is:

• New major software development to expand the capabilities of the current system and database

• Evaluation, adoption, and updating of OER’s application development framework

• Developing alpha, beta, and other test releases

• Maintenance

• Defect repair and enhancements

• Conducting code inspections and walkthroughs

• Demonstration of new software enhancements and defect fixes to senior leadership, product owners, teams and stakeholders

e. Application Testing (Work Area 5)

The contractor shall perform all team level testing for the OER software tasks. Application testing occurs in different stages throughout the Agile software development lifecycle, from testing small elements of the system in collaboration with development, to integration testing, regression testing and user acceptance testing. A non-exhaustive list of examples of the work to be performed under this work area is:

• Test scenarios

• Test data creation

• Automated test scripts

• Test collaborations

• Test plans

• Test results

• Test evaluation summary

• Support Performance testing efforts

• Support Load testing efforts

• Security testing

• User Acceptance Testing support

f. IT Integration Support (Work Area 6)

The Contractor shall coordinate with staff in several areas throughout the software development lifecycle. A non-exhaustive list of examples of the type of work to be performed under this work area is:

• Technical solution coordination with system architects

• Coordination with Operations team

• Configuration management coordination

• Coordinating with COR and federal managers to ensure that comprehensive development best practices and standards are defined, that these are aligned with the software architecture and strategic vision communicated effectively to development staff and kept current on a regular basis.

g. Production Support (Work Area 7)

The purpose of this task is to operate and maintain multiple enterprise systems and websites. A non-exhaustive list of examples of the type of work to be performed under this work area is:

• Transitioning software products to the user community

• Problem diagnosis

• Problem resolution

• Developing data correction scripts

• Tier 3 response/help desk tickets

• Updating data and links to other websites

• Supporting the operating environment

h. Documentation Support (Work Area 8)

The Contractor shall provide documentation support. A non-exhaustive list of examples of the type of work to be performed under this work area is:

• Assisting with end-user documentation including online help, communications and FAQs

• Other documentation as required

i. Training Support (Work Area 9)

The Contractor shall provide training support, which includes assisting with preparation and delivery of training and training materials as required.

j. Infrastructure and Architecture Support (Work Area 10)

The Contractor shall provide OER infrastructure and architecture support. A non-exhaustive list of examples of the type of work to be performed under this work area is:

• Participate in collaboration of development and design of infrastructure and shared components and services

• Participate in technical evaluations

• Participate in product evaluations

• Promote innovative solutions

• Support architectural alignment between eRA and the NIH, DHHS, and OMB

• Enterprise Architecture

• Support integration services between eRA and designated NIH enterprise applications as well as NIH ICs, other OPDIVs and Agency partner applications

• Assess the adequacy of current software documentation

• Support security methods, policies, and procedures for the eRA infrastructure

Technologies used in the OER systems include but not limited to: Java, .NET, SQL Server, Spring, Spring MVC, Angular, Bootstrap, Vue.js and Cold Fusion along with a significant number of additional open source and commercial libraries running on the Tomcat application server. Web Services, both SOAP and REST utilize Apache CXF and use certificate authentication. Solr is used for text indexing and searching and ÜberResearch Indexer is used for project indexing. Aspose is used for PDF generation and JasperReports is used for document generation.

k. Application Security (Work Area 11)

The contractor shall provide system security support and services for OER systems. Including, but not limited to, application security monitoring and remediation, application security guidance, best practices, tools support, training, monitoring, escalation and testing.

2.5 Adherence to Architectural Standards and Guidelines

Except as directed or approved by the COR and concurrence by the CO, the contractor shall adhere to OER architectural standards and guidelines unless otherwise proposed by the Contractor.

In addition to the standards and guidelines, the eRA program has developed extensive frameworks and shared business components (SBCs). The Contractor shall use those frameworks and shared business components under the guidance of the eRA architecture team.

2.6 User Interface Standards

All user interfaces to the system shall conform to eRA User Interface Standards and Section 508 of the Disabilities Act (29 U.S.C. 794d)

2.7 Deliverables Requirements

The contractor shall provide deliverables as defined by the Deliverables chart in section 3.4.7.

The Contractor shall deliver all draft, revised, and final documentation to the COR and CO electronically in Microsoft Word with any diagrams or charts embedded in the Word files. The Contractor shall also deliver monthly status reports electronically in Microsoft Word.

2.7.1 Project Schedules

http://www.section508.gov/

The Contractor shall assist in the development of project schedules for assigned tasks and sub-tasks. The Contractor shall provide updated information for the project schedules on a weekly basis, until the task or sub-task is completed. Project schedules shall be delivered to the CO and COR within two (2) working days after the assignment of tasks.

2.7.2 Prepare a Monthly Status Report (MSR)

The contractor shall develop and provide a MSR. The MSR shall include the following:

• Activities during reporting period, by work area (include on-going activities, new activities, and activities completed, and progress to date on all above-mentioned activities). Each section shall start with a brief description of the task.

• Problems and corrective actions taken. Also include issues or concerns and proposed resolutions to address them.

• Personnel gains, losses, and status (security clearance, etc.).

• Government actions required.

• Schedule (show major tasks, milestones, and deliverables; planned and actual start and completion dates for each).

2.7.3 Prepare a Monthly Financial Report (MFR)

The contractor shall develop and provide a MFR. The MFR shall include the following:

• Accumulated invoiced cost for each Contract Line Item Number (CLIN) up to the previous month.

• Forecasted Hours, Actual Hours, and Variance by Month up to the previous month

• Forecasted Costs and Actual cost for each CLIN including Approved Amount, Amount Expended, Amount Remaining, and Percentage Expended.

• Summary of travel expenses incurred.

• Consolidated listing of Contract Employees and Subcontractors including Rate

Per Hour and Monthly Hours Worked per month

2.7.4 Deliverables Chart

Deliverables Due Date Master list of risks and issues

2 working days after each meeting.

Project Scheduling information

5 working days after assignment of task component

Monthly Status reports Fifth working day of each month, starting after first full month of contract performance.

Monthly Financial report Fifth working day of each month, starting after first full month of contract performance.

Design Documentation Unit Test Plan Accepted Software Package

Completion of iteration.

Transition In Plan Five work days after contract award Transition Out Plan - Draft

Nine months before the end of the contract

Transition Out Plan - Final

Six months before the end of the contract

Quality Control Plan 30 days after contract award Invoices 30 days after the end of the month.

Roster of all Information Technology Staff

Within 14 days of the effective date of the contract or within 5 working days of staff changes.

Forms - Suitability Investigation Package

Within 14 days of submitting Roster.

Systems Security Plan Within 60 days of contract award (required only if the Contractor works offsite with government data).

OER Employee Onboarding

Before a new contractor employee starts working in OER.

OER Employee Offboarding

When contractor employees terminate.

Non-Disclosure Agreements

Prior to commencing work.

2.8 Collaboration

The contractors involved with OER shall work collaboratively with designated federal staff and other contractors. This collaboration includes day-to-day activities, planning, development, knowledge transfer and creating and sharing documentation.

The contractor PM shall participate in Technical Status Meetings with the COR, TM, and other Government stakeholders. The purpose of these meeting is to ensure all stakeholders are informed of activities, provide opportunities to identify other activities and establish priorities, and coordinate resolution of identified problems or opportunities.

The contractor PM shall provide minutes of these meetings, including attendance, issues discussed, decisions made, and action items assigned, to the CO and COR within five workdays following the meeting.

2.9 Contractor to Contractor Transition Support

The contractor shall ensure that there will be minimum service disruption to vital Government business and no service degradation during and after transition. The Contractor shall provide resources with the skills and experience required to assist the Government with the successful execution of the Transition Plans. The Contractor shall develop Transition Plans documenting all transition activities and the responsibilities of all parties involved with the transitions six (6) months before the end of the contract. The Contractor shall prepare and deliver draft and final versions of their Transition Plans which define the details of specific tasks, deliverables, and milestones required to ensure an orderly and complete transition.

At a minimum, the Transition Plans shall include the following:

• Transition approach and Contractor recommended methodologies

• Roles and responsibilities of Government and Contractor personnel involved in the transition

• An orientation phase and program to introduce Government personnel, programs, and users to the Contractor’s team, tools, methodologies, and business processes

• Methods for providing and maintaining expertise

• Change management issues to include methods of communicating to stakeholders

• Training to be provided

• Resource requirements

• Identification of risks and risk mitigation practices

• Transition Schedule

• Proposed staffing and distribution

• Transition costs for a 90-day transition (in and out)

2.9.1 Transition In

The incoming Transition Plan shall describe the steps to successfully execute transitions required at the beginning of the contract period of performance. The Contractor shall include recommendations, strategies, and tactical steps to ensure minimal disruption to the current OER environments and technical activities. The incoming Transition Plan shall describe how the Contractor’s proposed solution will integrate with the current eRA environment. Within 7 days of award of the contract, the incoming incumbent shall host a joint meeting with the outgoing contractor and the Government to review the draft project plan and to integrate the new Contractor’s transition-in activities. All Transition-In activities shall be completed 60 days after approval of final Transition-In Plan.

The contractor shall schedule, coordinate, and host a Project Kick-Off Meeting at the location approved by the Government (Deliverables Section 3.3.7). The meeting will provide an introduction between the contractor personnel and Government personnel who will be involved with this contract. The meeting will provide the opportunity to discuss technical, management, and security issues, and travel authorization and reporting procedures. At a minimum, the attendees shall include Key Contractor Personnel, other relevant Government personnel, and the

COR.

At least three days prior to the Kick-Off Meeting, the contractor shall provide a Kick-Off Meeting Agenda for review and approval by the COR prior to finalizing. The agenda shall include, at a minimum, the following topics/deliverables:

• Points of contact (POCs) for all parties

• Draft Project Management Plan (PMP) and discussion including schedule, tasks, etc.

• Personnel discussion (i.e., roles and responsibilities and lines of communication between contractor and Government)

• Staffing Plan and status

• Transition-In Plan and discussion

• Security discussion and requirements (i.e., building access, badges, Common

Access Cards (CACs))

• Invoicing considerations

• Transition discussion

• Quality Control Plan (QCP)

The Government will provide the contractor with the number of Government participants for the Kick-Off Meeting and the contractor shall provide sufficient copies of the presentation for all present.

The contractor shall draft and provide a Kick-Off Meeting minutes report documenting the Kick-Off Meeting discussion and capturing any action items.

2.9.2 Transition Out

The outgoing Transition Plan shall describe the steps to successfully execute transitions required at the end of the contract period of performance. In accordance with the approved plan, the Contractor shall assist the Government in planning and implementing a complete transition from the existing contract to a follow-on support provider. The Contractor shall ensure that the outgoing Transition Plan is current with all changes that occurred throughout the life of the contract.

At least nine (9) months prior to the end of the contract period of performance, the Contractor shall provide the Government a draft transition project plan that clearly describes a work breakdown structure, schedule, and assignment of responsibility for tasks between the incumbent contractor, the incoming Contractor and the Government.

The Contractor shall deliver a final eRA Transition Plan six (6) months before the end of the contract and must provide monthly updates thereafter.

75N97019R00003 Attachment 3

TECHNICAL REPORTING REQUIREMENTS AND DELIVERABLES

The items specified below as will be required to be delivered F.O.B. Destination as set forth in FAR Clause 52.247-35, F.O.B. Destination, Within Consignees Premises (April 1984), and in accordance with and by the date(s) specified below and any specifications stated in the contract.

a. Technical Reports Delivery and Distribution Schedule:

ITEM

TYPE OF DELIVERABLE

RFP/

CONTRACT

REFERENCE

DUE DATE

RECIPIENTS &

NUMBER OF COPIES

1 Master list of Risks and issues

Section 2.3 of the SOW

At least two (2) business days after each meeting

Electronic copy to COR, CO, and Technical Monitors (TM)

2 Design Documents Section 2.4.c of the SOW

As required Electronic copy to CO, COR, and TMs

3 Accepted Software Packages Section 2.4.d

SOW

As required Electronic copy to CO, COR and TMs

4 Unit Test Plans Section 2.4.e of the SOW

As required

Electronic copy to CO, COR and TMs

5 Project Scheduling Information

Section 2.7.1 of the SOW

5 Working days after assignment of task component

Electronic copy to CO, COR and TMs

6 Monthly Status Reports Section 2.7.2 of the SOW

Fifth working day of each month, starting after the first full month of the contract

Electronic copy to CO, COR and TMs

7 Monthly Financial Reports Section 2.7.3 of the SOW

Fifth working day of each month, starting after the first full month of the contract

Electronic copy to CO, COR and TMs

Draft Transition Plan Section 2.11 of the SOW

Nine months before the end of the contract

Electronic copy to CO, COR and TMs

9 Final Transition Plan Section 2.11 of the SOW

Six months before the end of the contract

Electronic copy to CO, COR and TMs

10 Quality Control Plan Section 2.0 of the SOW

30 days after contract award

Electronic copy to CO, COR and TMs

11 Roster of all Information Technology Staff

TBD when RFP is completed

Within 14 days of the effective date of the contract or within 5 working

Electronic copies to CO and COR

75N97019R00003 Attachment 3 days of staff changes

12 Forms – Suitability Investigation Package

TBD when RFP is completed

Within 14 days of submitting roster

Electronic copies to CO and COR

13 System Security Plan TBD when RFP is completed

60 days after contract award (required only if the contractor works offsite with government data)

Electronic copies to CO and COR

14 eRA Employee On-boarding Form

TBD when RFP is completed

Before a new contractor employee starts working in OER

Electronic copies CO, COR, TM and the eRA onboarding/offboarding mailbox

15 eRA Employee Off-boarding Form

TBD when RFP is completed

When a contractor employee departs OER or is terminated

Electronic copies CO, COR, TM and the eRA onboarding/offboarding mailbox

16 Non-Disclosure Agreements TBD when RFP is completed

Prior to starting work at OER

Electronic copies to CO and COR

17 Copy of Training Records for all mandatory training

TBD when RFP is completed

10 days after start of contract and annually thereafter

Electronic copies to CO and COR

18 Signed Rules of Behavior for all contractor employees

TBD when RFP is completed

10 days after start of contract and annually thereafter

Electronic copies to CO and COR

19 Incident Reports TBD when RFP is completed

Within 1 hour of incident

Electronic copies to CO and COR

20 Incident and Breach Response Plan

TBD when RFP is completed

Upon Request Electronic copies to CO and COR

75N97019R00003 Attachment 9

ADDITIONAL TECHNICAL AND BUSINESS PROPOSAL INSTRUCTIONS and Uniform Cost Assumptions

In addition to the format requirements for the Business Proposal that are contained in Section J of the solicitation, the information presented here intends to provide uniform cost assumptions and business clarifications to assist in the preparation of your proposal.

TECHNICAL PROPOSAL INSTRUCTIONS:

1. Page Length: Proposals shall not exceed 40 pages in length. This page count does not include a cover letter, resumes, or past performance examples.

2. Page Layout: Pages shall have uniform 1 inch margins on all sides. Technical Proposal must use a 12-point Times New Roman font. One exception to font size is tables and charts. Tables and Charts may use 10-point Times New Roman font. A maximum of three tables/charts can be 11 inches x 17 inches (double page) in size.

3. Key Personnel: Commitment letters must be submitted for all proposed key personnel.

4. Resumes: Resumes must be provided for all named personnel (both key personnel and non-key personnel). Resumes are limited to 2 pages per resume. Actual resumes are required – sample resumes for positions are not acceptable.

5. Past Experience: The Offeror shall provide a minimum of 3 and maximum of 5 examples of past performance/experience. The list of examples shall not exceed 2 pages per example. Past experience examples must include contact name, position, telephone number, and email address.

6. Offerors shall provide 10 hard copies of the Technical Proposal and 5 copies of the Cost Proposal by 2:00 PM ET, July 17, 2019.

COST/EFFORT ASSUMPTIONS:

1. The ESTIMATE OF EFFORT tables below provide an estimate of effort for the contract. This document provides guidance to the Offeror to be able to propose the required effort for each staffing member listed under the Statement of Work for the contract. This is only the Government’s recommendation as to the labor mix and the titles of the categories of personnel required for this effort. A range has been provided. The Offeror should provide their own specific estimate for mix and level of effort required that is supported by the offeror’s Technical Proposal’s approach.

UNIFORM ASSUMPTIONS (HOURS) – Minimum Requirement

Labor Category Year 1 Year 2 Year 3 Year 4 Year 5 TOTAL

Requirements Analyst

3,750 – 5,000

3,750 – 5,000

3,750 – 5,000

3,750 – 5,000

3,750 – 5,000

18,750 – 25,000

Junior Level Developer

13,000 – 15,000

13,000 – 15,000

13,000 – 15,000

13,000 – 15,000

13,000 – 15,000

65,000 – 75,000

Mid-Level Developer

30,000 – 35,000

30,000 – 35,000

30,000 – 35,000

30,000 – 35,000

30,000 – 35,000

150,000 – 175,000

Senior Level Developer

50,000 – 60,000

50,000 – 60,000

50,000 – 60,000

50,000 – 60,000

50,000 – 60,000

250,000 – 300,000

Development Lead

5,000 – 6,000

5,000 – 6,000

5,000 – 6,000

5,000 – 6,000

5,000 – 6,000

25,000 – 30,000

Application Software Developer/Tester

15,000 - 17,000

15,000 - 17,000

15,000 - 17,000

15,000 - 17,000

15,000 - 17,000

75,000 – 85,000

Application Security Engineer

3,750 – 5,000

3,750 – 5,000

3,750 – 5,000

3,750 – 5,000

3,750 – 5,000

18,750 – 25,000

Senior Software Systems Designer

– Level 2

3,750 – 5,000

3,750 – 5,000

3,750 – 5,000

3,750 – 5,000

3,750 – 5,000

18,750 – 25,000

Senior Software Systems Designer

– Level 1

3,750 – 5,000

3,750 – 5,000

3,750 – 5,000

3,750 – 5,000

3,750 – 5,000

18,750 – 25,000

Graphical Designer, User Interface Designer

3,750 – 5,000

3,750 – 5,000

3,750 – 5,000

3,750 – 5,000

3,750 – 5,000

18,750 – 25,000

Program Manager 1,250 – 2,000

1,250 – 2,000

1,250 – 2,000

1,250 – 2,000

1,250 – 2,000

6,250 – 10,000

TOTALS 133,000 –

160,000

133,000 – 160,000

133,000 – 160,000

133,000 – 160,000

133,000 – 160,000

665,000 – 800,000

UNIFORM ASSUMPTIONS (HOURS) – Maximum if Option Quantities Exercised

Labor Category Year 1 Year 2 Year 3 Year 4 Year 5 TOTAL

Requirements Analyst

7,000 – 8,000

7,000 – 8,000

7,000 – 8,000

7,000 – 8,000

7,000 – 8,000

35,000 – 40,000

Junior Level Developer

22,500 – 26,500

22,500 – 26,500

22,500 – 26,500

22,500 – 26,500

22,500 – 26,500

112,500 – 132,500

Mid-Level Developer

54,000 – 58,000

54,000 – 58,000

54,000 – 58,000

54,000 – 58,000

54,000 – 58,000

270,000 – 290,000

Senior Level Developer

90,000 – 100,000

90,000 – 100,000

90,000 – 100,000

90,000 – 100,000

90,000 – 100,000

450,000 – 500,000

Development Lead

9,000 – 10,000

9,000 – 10,000

9,000 – 10,000

9,000 – 10,000

9,000 – 10,000

45,000 – 50,000

Application Software Developer/Tester

26,000 - 28,000

26,000 - 28,000

26,000 - 28,000

26,000 - 28,000

26,000 - 28,000

130,000 – 140,000

Application Security Engineer

7,000 – 8,000

7,000 – 8,000

7,000 – 8,000

7,000 – 8,000

7,000 – 8,000

35,000 – 40,000

Senior Software Systems Designer

– Level 2

7,000 – 8,000

7,000 – 8,000

7,000 – 8,000

7,000 – 8,000

7,000 – 8,000

35,000 – 40,000

Senior Software Systems Designer

– Level 1

7,000 – 8,000

7,000 – 8,000

7,000 – 8,000

7,000 – 8,000

7,000 – 8,000

35,000 – 40,000

Graphical Designer, User Interface Designer

7,000 – 8,000

7,000 – 8,000

7,000 – 8,000

7,000 – 8,000

7,000 – 8,000

35,000 – 40,000

Program Manager 2,500 – 3,000

2,500 – 3,000

2,500 – 3,000

2,500 – 3,000

2,500 – 3,000

12,500 – 15,000

TOTALS 239,000 –

265,500

239,000 – 265,500

239,000 – 265,500

239,000 – 265,500

239,000 – 265,500

1,195,000 – 1,327,500

75N97019R00003 Attachment 10 Mandatory Experience Criteria

A – Experience in the last 5 years with similar size* grants management systems

Contracting Agency

Prime or Subcontra ctor

Period of Performance

Contract or Subcontracting

Value

Number of Java

Developers (for entire system)

Description of the work

*As described in the Technical Evaluation Criteria (75 or more Java Developers required for entire system)

B - Federal Business Lifecycle Grants Management Standards Federal Integrated Business Framework - https://www.ussm.gov/fibf-gm/

Function Activity Name

Demonstrated software design, development and functional testing experience (Yes or No)

Describe demonstrated experience

GRM.010 Grant Program Administration

GRM.010.010

Grant Program Set-up and Maintenance

GRM.010.020

Grant Program Funding Opportunity

GRM.020 Grant Pre-Award Management

GRM.020.010

Grant Application Support and Receipt

GRM.020.020

Application Review and Selection

75N97019R00003 Attachment 10

GRM.030 Grant Award Management

GRM.030.010

Grant Award Issuance

GRM.030.020

Payment Processing

GRM.040…

This is the start of the file's text. The full file is on GovTribe.

File details come from the government source that posted it.