Task_Order_Request-_TO-01_tracked_changes_amendment_0002.pdf

i

TASK ORDER REQUEST

Task Order One

1.0 INTRODUCTION

This Task Order Request (TOR) is issued to support the Pension Benefit Guaranty Corporation’s (PBGC’s) requirement for FMS-ITSS Transition, Operations and Maintenance. Details of this procurement are identified below.

TOR Identification Number TO-01

Contract Type Firm Fixed-Price

Other Direct Costs (ODCs) Authorized

No

Period of Performance (including options)

November 1, 2018 to October 31, 2019 (Subject to change based on IDIQ Award)

Place of Performance PBGC Headquarters, 1200 K Street NW, Washington

DC 20005

Method of Evaluation See IDIQ Sections L & M

Task Order Proposal Due Date See IDIQ Due Date

2.0 TASK ORDER ONE PROPOSAL INSTRUCTIONS

Your Company is requested to submit a written Task Order proposal with a separate pricing section in response to this TOR and IDIQ RFP under which the resulting Task Order will be placed.

Offeror shall include a table of contents identifying the contents of each Task Order proposal section.

2.1 Technical Proposal

The Task Order technical proposal shall conform to the instructions set forth in Section L. See Section L.2.2 Part B– Task Order One Response of this solicitation.

ii

Offeror’s Task Order technical proposal shall address all aspects of the Government’s technical requirements and provide a cross reference to the location of each requirement in the Statement of Objectives (SOO) to ensure that all technical requirements are satisfied. The SOO is provided as Attachment A of this TOR. No materials shall be incorporated by reference, as this section must be a standalone document.

The technical factors are identified below.

1. Technical factor 1 – Approach and Understanding of Requirements

2. Technical factor 2 – Key Personnel

3. Technical factor 3 – TO Management Approach

The Offeror shall fully address all the factors set forth in the solicitation.

Note: No pricing information is to be included in the TO technical proposal to ensure that the technical evaluation is not influenced by price.

2.2 Price Proposal

The Task Order Business proposals shall conform to the instructions set forth in section L. See L.3 Business / Price Proposal (Volume II) of the solicitation.

Offer shall identify any exceptions, deviations, or assumptions made and provide sufficient description, including benefits to the Government, to permit evaluation. Exceptions, deviations, and assumptions which do not provide significant benefit to the Government or which the Government finds unacceptable may preclude the offeror’s Task Order proposal from further consideration.

Offeror shall provide a cover letter signed by an official with the authority to bind the company in this section of their Task Order proposal.

Offeror shall provide the unit prices for all Line Item Numbers (LINs) and periods contained in the Price Schedule provided as Attachment 2 of this TOR.

Offeror shall provide a statement in the Price Proposal specifying the extent of agreement with all terms, conditions, and provisions included in this TOR, and agreement to furnish any or all items offered at the prices contained in the price schedule of their Task Order proposal.

3.0 BEST VALUE PROCUREMENT - RELATIVE IMPORTANCE OF TECHNICAL

VERSUS PRICE FACTORS:

PBGC will use the evaluation process described in Section M for proposals received in response to the FMS-ITSS solicitation.

4.0 Attachments:

A. Task Order One Statement of Objectives B. Task Order One Price Schedule

ATTACHMENT A

Task Order #1

Statement of Objectives Transition, Operations and Maintenance

Contents

1.0 Transition from Implementer

2.0 Operations and Maintenance

3.0 Personnel, Performance Work Statement, and Quality Control Plan

Task Order 1: Transition, Operations and Maintenance The objective of this task order (TO) is to provide transition, operations and maintenance (O&M) support for the FMS IT systems as defined in the FMS-ITSS IDIQ contract. The three four systems to be transitioned and supported under this TO include MyPAA, PPS, CFS and TAS. Transition and IT support periods are detailed in the sections below. The contractor shall propose in the PWS all tasks and activities required to meet the objectives.

While the Government has proposed minimum elements to be included, the contractor must provide complete details on its propose approach and is encouraged to proposed innovative solutions and address the objectives but include minimum elements.

Task Order Type: Severable, Firm Fixed Price Period of Performance (POP): One year from Date of Award Place of Performance: PBGC Headquarters, 1200 K Street NW, Washington DC 20005

1.0 TRANSITION FROM IMPLEMENTER

Over the POP of this TO, three all four of the FMS IT systems will be required to transition from the incumbent to the successful vendor of the contract award. The systems and their expected transition periods are as follows:

• MyPAA Transition Period: November 1 to December 31, 2018

• TAS Transition Period: December 19, 2018 to February 17, 2019

• PPS Transition Period: February 1, 20198 to March 31, 2019

• CFS Transition Period: August 1, 2019 to September 30, 2019

With respect to IDIQ task area 3.12, the objective of will be to ensure successful transition support through effective planning and a proven transition approach when taking over the work performed by the incumbent O&M contractor that addresses technical, staffing, and contractual transition tasks. The contractor shall ensure that they become

Commented [SD1]: Q&A #191 and 194

Commented [SD2]: Q&A #193

Commented [SD3]: Q&A #128 familiar with the current MyPAA, PPS, CFS, and TAS capabilities, technical configuration, development environments and efforts underway. The contractor shall ensure that all documentation is accounted for and shall ensure retention of PBGC institutional knowledge. Upon completion of this transition, the contractor will be fully capable of supporting the systems and have appropriate access to all systems, environments and documentation.

2.0 OPERATIONS AND MAINTENANCE

Following the transition period for each system, the contractor will assume full responsibility for supporting IT operations and maintenance of the following systems:

• MyPAA O&M Period: January 1, 2019 to October 31, 2019

• TAS O&M Period: February 18, 2019 to October 31, 2019

• PPS O&M Period: April 1, 20189 to October 31, 2019

• CFS O&M Period: October 1, 2019 to October 31, 2019

The following are the detailed objectives of this tasks order (as further defined and organized by FMS-ITSS IDIQ task area):

2.1 Operations and Maintenance – Ensure that the FMS systems remain operational and effective in supporting FOD business processes and financial operations. This also includes achieving operational efficiency through meaningful measurement of productivity and system performance, success in goal attainment, enhanced management reporting, and the automation of manual processes where appropriate. The contractor shall ensure excellent communication and coordination with other technical teams and business partners to exchange information, solicit agreement on systems-related decisions, testing integration with other systems (internal and external to the agency), and following all security and enterprise architecture guidelines.

2.1.1 Tier-3 Technical and Operations Support - Provide exceptional customer service through the availability of timely, competent, and responsive third tier (Tier 3) technical support to help the user base with issues related to the system and its functionality as required. The estimated volume of support tickets received by the systems is as follows:

• MyPAA has approximately 2 technical tickets per month. However, overall technical and operations support issues addressed per month can vary greatly. Operations support issues can range from providing support to practitioners’ questions received via the Premium Operations Call Center, technical requests from FOD users, and database or connectivity issues that need to be resolved with help from ITIOD.

• PPS has approximately 20 tickets per month. Tickets include production support requests, audit / security requests, and data clean-up requests. The average time to resolve a ticket is 8 hours.

• TAS has approximately 20 tickets per month. Tickets include production support requests, audit / security requests, support for regression testing of partner systems, and other support responsibilities. While the number of hours per ticket varies widely, it is estimated that the average time to resolve a ticket is 8 hours. For TAS, support must ensure a collaborative environment across Contractor teams including Eagle, Interactive Data Corporation (IDC), and

Commented [SD4]: Q&A #133 other technical teams and business partners to exchange information, solicit agreement on systems-related decisions, testing integration with other systems, and following all security and enterprise architecture guidelines, to ensure a seamless, full service solution to PBGC.

• CFS has approximately 15 tickets per month to include production support requests and information request related to system function.

Any requests for FMS system support will be tracked via a support ticket and logged in the PBGC IT support system (currently HP Service Manager). The root cause of the issue will be analyzed and found, if applicable. Any tickets/issues requiring a system change will require generation of a Production Trouble Report (PTR) for a defect or a System Change Request (SCR) for system enhancement prior to closing the ticket. Detailed tracking of tickets, response and resolution timing is required. Recommendations of PTRs/SCRs to reduce tickets and stabilize the systems is also required.

Operations support also includes proactive monitoring of system status and performance through the use of performance monitoring tools to ensure maximum availability of the FMS systems.

• My PAA incorporates the use of HP Sitescope to review system status on a daily basis. Reviews of generated application status messages are reviewed regularly to confirm system health. Other monitoring tools that are utilized include Oracle ADDM, AWR, and ASH database diagnostic reviews on a recurring basis, but on a daily basis during the peak premium filing season (September 15th - October 31st)

• ForeSee customer satisfaction surveys that are presented to MyPAA practitioner users also provide the team with some feedback in regards to system performance. The ForeSee survey captures user experience ratings for system performance and provides a monthly grade. This additional information can be used by the IPT to determine if performance optimization is an urgent priority to address, or if our continuous performance monitoring and improvements are keeping pace with user expectations.

2.1.2 Enhanced Peak Period Support (i.e. fiscal-year end, peak premium filing season)

– Ensure enhanced support and full operational capabilities for the following peak period:

• Premium Peak Filing Season (September 15 – October 31) o The Premium Peak Filing season is a 45-day surge in the number of users logging into MyPAA to submit their comprehensive premium filings and payments that are due in mid-October each year.

o During this period, it is imperative that staffing resources from the integrated project team, are available to provide support in the event of any production issues identified.

o The integrated project team that supports the Premium Peak Filing season consists of representatives from MyPAA, PPS, IPS, FMSD, FOD, ITIOD Ops Support, ITIOD Cybersecurity, Premium Operations Call Center, Network Operations Center, Pay.gov, and ForeSee.

o PBGC must ensure that the user experience during this time is maintained at positive levels. To achieve this objective, MyPAA must be available, system performance must be maintained, and our interfacing partners must be available to provide their shared services to the premium filing process (e.g., Plan Account History from PPS, ACH routing number validation, Pay.gov ACH payment processing, ITIOD DBA memory management support, etc.)

o Planning meetings are held during the summer to identify representatives who will be available to provide support for the premium peak filing period.

• Post-Peak Premium Financial Close (October 31-November 15) o Following the peak filing period, all premium receipts and associated accounting entries must be processed, transferred to the general ledger and monthly closing completed. Due to the increased volume of filings and complexity of transactions, additional monitoring and support is needed.

• Fiscal Year-End (October 1 - November 15) o All FMS systems must remain in peak performance and operational during fiscal year close. Increased transactions and demand on all systems requires additional support to ensure a smooth closing process.

2.1.3 Maintenance/Emergency Release Development and Configuration – Over the course of the TO POP the contractor will perform maintenance or emergency release work to include patching, minor software development or configuration changes to FMS systems. The objective is to ensure system performance, security, and version compatibility, and performing SDLC activities (requirements, design, construction/configuration, testing) of maintenance releases for the following:

COTS software minor version upgrades, COTS functional patches, bug fixes to address defects found in production, changes to FMS systems that are required due to changes to FMS interfaces with other systems or the underlying platform (e.g., PBGC migrating from Windows 7 to Windows 10), and minor enhancements to existing FMS functionality. Enhancing major new functionality or COTS major software version upgrades is considered out of scope for the TO. While minor, any of these changes/releases must be meet ITSLCM standards and all release activities include SDLC steps referenced in the FMS-IDIQ including meeting auditor review standards. For the FMS systems, the following is the approximate number of maintenance/emergency releases expected:

• MyPAA has averaged approximately 1 to 2 emergency releases per year.

These releases have been small in level of effort (under 60 hours) and have been used to address an urgent production issue or database related fix.

• PPS has up to 2 emergency releases per year. These releases have been small in level of effort (about 120 hours) and have been used to address an urgent production issue or database related fix

• TAS has averaged 1 emergency release over each of the past three years.

These emergency releases have been small (under 40 hours) in effort and have been to address deployment or urgent production data problems.

• CFS requires on average one emergency/maintenance release per year to address needed system issues with the level of effort at approximately 120 hours.

2.1.4 Infrastructure Impact Analysis, Testing and Remediation – Ensure that FMS systems are able to accommodate and remain in sync with updates to PBGC’s infrastructure patching or upgrades (e.g. Oracle quarterly patching, Windows Patching, Oracle RDBMS 11G to 12C upgrade, Java 1.7 to Java 1.8, etc.) This includes assessing the impact of any hardware and software patching or upgrades to system infrastructure, conducting any associated regression testing and performing remediation to ensure continued compatibility of the FMS system.

The contractor will maintain efficient coordination with Infrastructure Technology Infrastructure Operations Department (ITIOD). The number of infrastructure changes per year is approximately:

• MyPAA – Since My PAA is a publicly facing web application, we work closely with ITIOD on a regular basis to ensure that ITIOD cybersecurity patches are deployed throughout the year and other major infrastructure upgrades are aligned with a major FMS production release. Over the next several years, we anticipate an upgrade to Windows 2016 server, an upgrade to Oracle Fusion middleware 12c and an upgrade to Red Hat Enterprise Linux v7. x.

• PPS – Historically, PPS has experience quarterly patching and updates to the infrastructure. Over the next several years, we anticipate an upgrade to Oracle Fusion middleware 12c and an upgrade to Red Hat Enterprise Linux v7.x.

• TAS – Since TAS is externally hosted, the impact of PBGC IT IOD infrastructure changes is limited to browser changes and changes to the middle tier Business Process Execution Language (BPEL) infrastructure used for the CMS to TAS interface maintained by the TAS team. Typically, TAS has coordinated the timing of changes to infrastructure to align to maintenance releases to eliminate the need for separate testing. However, monthly operating system patches are implemented in the externally hosted Eagle ADMS environment along with upgrades to additional configuration items integrated as SCRs into the three annual maintenance releases.

• CFS participates in approximately 3 to 4 testing/remediation efforts for integrated systems per year. This could include integration with other FMS systems or with partners such as Concur (travel) or Comprizon (procurement).

2.1.5 Integration Impact Analysis, Testing and Remediation – Similar to infrastructure changes, FMS systems must remain operational in their integration with interfacing systems. This includes assessing the impact of any changes made by integrated systems and their related interfaces, conducting any associated regression testing and performing remediation to ensure continued compatibility of the FMS system and the related interface. The contractor will maintain efficient coordination with the IT support teams responsible for all systems integrated with FMS systems. For FMS systems, approximately the following number of integration changes are experienced per year:

• MyPAA – The frequency of interfacing application upgrades that impact My

PAA varies from year to year. However, we maintain a close integrated relationship with partner applications such as PBGC.gov, PPS, IPS, Pay.gov, Address Validation Service, ACH Routing Number Validation Service, and ForeSee Customer Satisfaction Survey.

• PPS – average of 6 – 8 (yearly changes for DOL EFAST, CIR, MyPAA, and CFS; and have seen changes to FedDebt, Lockbox, CCS, and/or IPS averaging once every 2 – 3 years each)

• TAS – Each of the three (3) partner systems to TAS implement two – three releases annually. Regression testing and, at times, remediation is required to ensure continued seamless integration between TAS and partner systems.

2.1.6 Financial and Enterprise Reporting – Producing effective and accurate reporting from FMS systems is essential. While established reports exist in the system, the data supporting those reports and other data conditions may require analysis.

One-time extracts, queries and other ad-hoc support is required to provide reporting outside of established reports.

2.1.7 FMS End to End Performance Load Testing – On an annual basis, an end to end performance load testing exercise is facilitated between the application teams to confirm that the latest batch of production deployment releases have not caused any performance degradation between the interfacing applications. TRB approved performance testing and monitoring tools are utilized to develop system performance reports. This report will serve as a confirmation that the Financial Management System is performing at expected threshold ranges and is prepared for the increased load surge experienced at the end of the fiscal year and during the Premium Peak Filing period in September and October.

2.2 Project Management Support – Project management support as part of this task order is the overall management of operations and maintenance activities, system performance, ensuring compliance with Federal, PBGC directives and standards as well as providing project, activity and system status reporting. The contractor shall also contribute business process support for FMS planning, integration, and/or assessment activities.

2.2.1 Project Management – As discussed above the objective of O&M project management is to actively manage system operations and any activities (maintenance release or otherwise) related to ensuring operation of the system and delivery of system and management reporting for system performance and task activities. All activities and tasks conducted will be identified and tracked in PBGCs P3M Project Management Tool (based on Project Online). These will be sourced from the TO Performance Work Statement (PWS) identified below along with associated status, risk, issue and other task reporting. P3M will be updated at a minimum weekly. The contractor will measure at least semiannually taking into account PBGC’s satisfaction with services provided across all task orders under the FMS ITSS contract.

2.2.2 Change Management – PBGC has established an integrated Financial Systems Change Control Board (CCB) for the financial systems which meets as needed to approve any changes to FMS systems. The CCBs consist of business unit representatives, Office of Information Technology (OIT) staff members, and attended by Contractor representatives. The objective is to ensure that any system changes or expenditure of resources for FMS systems have been approved by the CCB. The Contractor shall prepare FMS system related change requests (including a level of effort (LOE) and the impact) for CCB review and consideration, and capture CCB deliberations and decisions for FMS systems related change requests via meeting minutes.

2.2.3 Release Management - There are two main objectives relating to release management. The first is establishing a well-planned release process that minimizes releases. For this TO, it is not anticipated that there will be a significant number of releases due to the stability of the systems. The second objective is meeting PBGC’s very detailed release/change management process that is managed by ITIOD. This process details all the steps required to introduce changes into the production environment. The contractor will be responsible for managing this process and interacting with appropriate stakeholders to ensure successful releases.

2.2.4 Demand and Backlog Management – As part of FMS system support, a log of system change requests (SCRs) and production ticket reports (PTRS) will be generated. The objective to continue to maintain and groom this backlog of proposed system changes to provide an understanding of the level of effort (LOE) to accomplish the work through a detailed understanding of the request.

Currently this is managed in HP Quality Center. At a minimum there will be quarterly reviews of this backlog with the business area.

2.2.5 Configuration Management – Maintaining accurate configuration baseline for the system and the systems code base is required. The contractor shall maintain a detailed account of changes made to the system either as part of this TO or other task orders. This configuration baseline will be continually maintained as any changes are made to the systems and code and versioning stored in PBGC’s code repository which is currently PVCS. On an annual basis the complete configuration baseline of each FMS system will be reviewed and updated with the ISSM/ISSO as part of security control reviews.

2.2.6 Issue and Risk Management – Managing risks and addressing issues that arise as part of this TO helps to maintain system and project level control. Risks will be maintained in P3M for the system and any TO activities or projects. This risk management will be in compliance with the PBGC Risk Management policy. At a minimum it will include:

• Conducting an initial risk assessment for the FMS systems

• Updating the FMS Risk Management Plans per system with the assessment finding, risk identification, quantification, and ranking of all identified risks and a strategy for avoidance or mitigation of each risk.

• Keep risk registers updated in P3M on a weekly basis, report any changes to the risk profile to the COR as soon as identified and reporting on risk monthly at system IPT and FMS Program Management Review.

The Contractor shall document all issues and concerns that arise during execution of this task order. The Contractor shall identify a method to identify the issues, propose resolutions, estimate a timeframe for issue resolution, track the status of issues (by project phase and by business area) through closure and report their status during weekly IPT meetings, as part of the Status Reports, or other reporting mechanism. The Contractor shall identify a method to identify the action items, assign ownership, estimate a timeframe for closure and report their status during weekly IPT meetings, as part of the Status Reports, or other reporting mechanism.

2.2.7 Status Reporting - The Contractor shall provide a weekly status report divided by system. This status report will include a system status dashboard providing a view the systems operations, stability, availability and overall system health. The Contractor shall modify the format or subject content of the report at the direction of the COR but all reporting shall remain consistent across all FMS systems. At a minimum the status report will include:

• System Status o Outages, Planned Outages o System Performance Metrics (Availability/Uptime)

• Operations Status o Ticket Volume and Descriptions o Ticket Response/Resolution Time

• Project/Release Status o Task Completion Status o Upcoming Tasks

• Narrative review of work accomplished during reporting period and/or significant events;

• Status of all ongoing activities;

• Identification of problems (including issues that may impact work performance) encountered and recommended solutions;

• Anticipated activity for the next reporting period; and

• Updated Project /Release Schedule with a one (1) month forecast of those activities scheduled.

A monthly Program Management Review (PMR) will also be held to update PBGC leadership on the FMS ITSS contract status and all activities and projects for TOs currently underway on the FMS ITSS contract and related systems. This meeting will focus on management reporting to review overall system health with metrics on system trends, backlog size/composition, problem areas and highlight system risks and make recommendations. At a minimum this should include:

• Production ticket summary

• Release summary and schedule

• TO Resource Distribution

• Contract Status and Details

• Staffing Summary and Status

• Highlight Contract Efficiencies

• Program and high magnitude system/project risks

• Team Challenges and Solutions

• Priorities and Action Items status from past PMRs

As part of system reporting, a system sustainability roadmap will be provided that identifies the technical components of all FMS systems, the versions of those components and then maps those technology components to vendor roadmaps to ensure PBGC minimizes technical obsolescence and maintains supportability for all systems. This is particularly important for Oracle eBusiness Suite (EBS) applications and modules as well as associated patching.

2.2.8 Integrated Project Team (IPT) – For all FMS systems, an Integrated Project Team (IPT) has been established to coordinate system operations and changes.

The Contractor shall be an active member and coordinator of the system IPTs.

The IPT is comprised of members of the System Team, related system project team, FMSD, FOD business owners, Infrastructure, Enterprise Architecture, Enterprise Information Security Office, other interfacing project teams, and PBGC functional staff and users as required. At a minimum, the contractor will:

• Attend weekly IPT status meetings to review, communicate, and coordinate the system’s operational status and status of any related projects with similar or the same content as weekly COR status reporting referenced above.

• Present information regarding accomplishments over the previous period, plans for the next period, any issues or action items, deviations in schedule of effort, status of critical dependencies, risk status, and other areas of note.

• The COR/Federal Project Manager and FOD Systems Accountant, both members of the IPT, will serve as the liaison between the Contractor and the IPT. The Contractor shall include both the COR/Federal Project Manager and FOD Systems Accountant on all communications, meeting requests, etc.

with the IPT. The COR/Federal Project Manager and FOD Systems Accountant will provide coordinated feedback on Contractor deliverables, route Contractor deliverables for approval and sign-off, and will serve as the first point of escalation for the Contractor.

2.2.9 Meeting Participation - In response to the issuance of this TO, the Contractor shall propose an appropriate level of meeting support for system and project meetings. At a minimum this will include:

• Attending weekly COR status meetings

• Attending weekly system IPT meetings

• Participate in bi-weekly FMS integration meetings and meetings with interfacing teams.

• Contractor organized meetings to ensure operational effectiveness of FMS systems including project meetings to develop requirements or achieve agreement on project deliverables.

• ForeSee Customer Satisfaction meetings

• Participating in cybersecurity meetings with FOD IT security as needed

• Facilitating FMS End to End Performance Load Testing meetings

• Facilitating and participating in Premium Peak Filing Period Monitoring support meeting

For each meeting held, the contractor shall provide appropriate briefing materials and agenda.

Following the meetings, the contractor shall provide meeting minutes from all meetings any of the Contractor staff attend, which shall include information regarding the discussion, decisions made, action items, and next steps. The meeting minutes shall be routed for review within one business day after the meeting and accepted as the official minutes upon Federal Government approval.

2.3 Program Analysis and Enterprise Architecture (EA) Support – While no major changes are anticipated to FMS systems during the course of O&M work, it will be necessary to provide system information and coordination with EA related to EA FMS system technical configurations and data models. Additional, all EA standards must be complied with and input is regularly required for comment on those standards.

2.3.1 Technical Reference Model/Review Board (TRM/TRB) Support – All system components must be approved by the PBGC TRB and contained in the PBGC TRM. Will new system components or versions of those components be needed, a presentation will be prepared, and approval received, prior to any deployment of that component in any PBGC environment.

2.3.2 Data Model Development and Maintenance – All FMS systems have an EA mandated logical data model that must be updated and maintained in accordance with the PBGC EA data standard. For any updates, the data model must be updated to ensure a current data model is available for review. Data models will tie to the enterprise data model and be developed in approved modeling tools.

2.4 Training – The objective of training as it relates to this TO is to provide ad hoc support to users in the use of the system. Requests for information may indicate the need for refresher training or tailored, specific training in particular areas of system functionality. This may relate to all types of users from day-to-day end users to system administrators. If any system changes are initiated as part of this TO, the appropriate level of training must be provided to appropriate stakeholders to ensure users are able to continue efficient and proper use of the system.

2.5 Continuity of Operations (COOP) Support – As PBGC FMS systems are essential to PBGC business, they all have an established warm COOP instance. Support is needed to ensure that the COOP instances are current with production and quickly stood-up in a COOP event. While ITIOD is primarily responsible for COOP event, support will be needed will issues occur in bring up the system or during annual COOP testing. This event occurs over a weekend, once per year where contractor staff will be expected to provide on-call support. It is expected that the Contractor will support ITIOD in resolving any issues in bringing up the FMS systems during a COOP event and support the annual COOP test. COOP shall also remain in sync with any production deployments. If there is a major change to the application architecture or a significant failure is experienced during the annual COOP event, an additional validation of the COOP configuration is scheduled to ensure verification prior to PBGC’s Annual COOP test.

2.6 System Documentation, Documentation Maintenance and Technical Writing – The contractor shall maintain an up-to-date document repository with new and updated artifacts related to each system, release notes and other documents as recommended by internal procedures and in accordance with standard industry best practices. Any documentation edited or produced for the FMS systems will be quality reviewed to ensure they are accurate both from a technical perspective but also grammar, spelling and formatting.

2.7 Data Call Support – As part of this TO, the contractor will be requested from time-to-time to provide information related to the systems and/or data within the system.

Examples include requests such as: number of users, table structure, configuration settings, total number of filings, status of all filings, etc. Many of these requests will be made with little time for response.

Additionally, PBGC conducts internal audit review of all FMS systems on an annual basis from April to November as part of the annual Financial Statements Audit. For each FMS system, the contract will need to provide records of all release and project materials completed in the past fiscal year.

2.8 IT Security - The contractor shall ensure Information Security compliance with NIST and all applicable regulations and guidance. This includes providing technical information to the FMS Information System Security Manager (ISSM) and delegated Information System Security Offices (ISSOs). At a minimum, this includes:

• Provide artifacts to FOD IT Security, Enterprise Cybersecurity Department, and

ITIOD Security regarding:

o Continuous monitoring o POAMS

• Perform system security analysis, including review of business processes and quarterly scan results.

• Provide evidence of security control implementation at the request of the ISSM/ISSO as part of continuous monitoring activities.

• Implementing as part of system releases/changes POAM corrective actions & enhancements (design, test, implement)

• Coordinate with General Support System (GSS) Info Security program which is managed by ITIOD and encompasses the infrastructure supporting the FMS systems.

2.8.1 Personally Identifiable Information (PII) – PII will be protected at all times in accordance with Federal PBGC polices. For PBGC, no PII will be introduced into the development and testing environments. Development activities will use at a minimum masked data but will need to transition to artificial data in the near future.

3.0 PERSONNEL, PERFORMANCE WORK STATEMENT, AND QUALITY

CONTROL PLAN

3.1 Personnel: The Contractor shall propose a number and labor category mix of personnel adequate to accomplish the requirements of this TO.

The Contractor may, with the approval of the COR, include in the project-definition phase of the work plan, at no cost to the PBGC, a subtask identified as “Project Team Staffing”, and by mutual agreement with the COR establish a scheduled date for completion. Otherwise, the Contractor shall ensure that an objective will be 80% staffed and the project personnel on-site, ready to begin work, within ten (10) working days of approval of the project work plan. Failure to complete staffing on time may be considered a cause for PBGC to terminate the TO for cause at no cost to the Government and to make alternative arrangements to obtain coverage possibly including placing the work on another Government contract.

All personnel proposed by the Contractor for this TO shall have specific experience relating to the type of service and labor category required in the activity for which the person was proposed. PBGC will not be responsible for training Contractor personnel on any hardware or software required to support the efforts identified in the solicitation.

3.2 Performance Work Statement: For the objectives in this task order, the Contractor shall respond with a Contractor Performance Work Statement (PWS). This PWS at a minimum will contain:

• Performance Requirements: Provide a narrative of the specific performance requirements or tasks that make up the PWS. Describe the work in terms of the required output. Number the tasks sequentially, e.g., Task 1 - Title of Task and description, Task 2

- Title of Task and description, etc. The PWS should reflect the deliverable, timing and PBGC process constraints identified in the TO.

• Performance Standards: Performance standards establish the performance levels required by the Government. PBGC will utilize performance measures to evaluate the contractor’s performance in meeting the objectives of each TO objective. The Contractor will propose performance standards appropriate for completing tasks in the PWS.

o Based on the objectives of each performance-based task-statement in the PWS, the contractor must identify and propose performance measures. Performance measures and metrics/service level agreements will form the basis of the PBGC’s deliverable Inspection and Acceptance. Examples of performance standards:

Quality Standards: Condition, Error rates, Accuracy, Form/Function, Reliability, Maintainability Quantity Standards: Capacity, Output, Volume, Amount Timeliness Standards: Response times, Delivery, Completion times, Milestones o The Contractor shall propose performance measures that would allow the PBGC to effectively evaluate the contractor’s performance. Where feasible, the Contractor shall align the performance measures to the objectives stated in this solicitation. The contractor must include performance measures to evaluate the contractor’s performance with regard to acceptable Cost, Schedule, and Quality thresholds. Proposed performance standards should have no more than 3 levels (i.e. exceptional, acceptable, unacceptable). At a minimum, the following performance measures will be included in any proposal:

Performance Standard Performance Requirement Acceptable Quality Level

(AQL)

User Support Response Time (Urgent Ticket)

Response within 1 hour Exceptional: ≥95% of tickets are responded to in 1 business hour Acceptable: < 95% and ≥ 85% of tickets are responded to in 1 business hours Unacceptable: < 85% of tickets are responded to in 1 business hours

User Support Response Time (Non-Urgent Ticket)

Response within 3 hours Exceptional: ≥ 95% of tickets are responded to in 3 business hours Acceptable: < 95% and ≥ 85% of tickets are responded to in 3 business hours Unacceptable: < 85% of tickets are responded to in 3 business hours

Urgent Ticket Resolution Time Average ticket resolution time is less than or equal to 2 business days

Exceptional: Average ticket resolution time is less than 1 business day Acceptable: Average ticket resolution time is 1 to 2 business days.

Unacceptable: Average resolution time is greater than 2 days.

Non-Urgent Ticket Resolution Time Average ticket resolution time is less than or equal to 4 business days

Exceptional: Average ticket resolution time is less than 2 business day Acceptable: Average ticket resolution time is 2 to 4 business days Unacceptable: Average resolution time is greater than 4 days.

Ticket Tracking/Aging Actively managing ticket backlog and ticket reporting

Exceptional: Weekly review and reporting of ticket activity Acceptable: Monthly review and reporting of ticket activity Unacceptable: Less often then monthly review and reporting

Unplanned System Outage or Degradation in Systems Performance or Fault preventing System Use (per occurrence)

Within 1 business day (12 business hours) either:

- Resolve Issue

- Provide Workaround

Exceptional: Outage resolution time is less than 4 business hours.

Acceptable: Outage resolution time is 4

Formatted Table

(AQL)

business hours to 1 business day.

Unacceptable: Outage resolution time is greater than 1 business day.

Contract Administration Timely delivery of:

- Staffing reports

- Onboarding/Separation process

- Key Personnel

Changes

- P3M updates

- Corrective Action

Plans

- Invoice Submission

- Other Contract

Administration Items

Exceptional: 100% of the Contract administrative tasks assigned by the COR are completed on recurring or one time deadlines Acceptable: 95% of the Contract administrative tasks assigned by the COR are completed on recurring or one time deadlines Unacceptable: Less than 95% of the Contract administrative tasks completed by established deadline

Customer Satisfaction Customer satisfaction score from customer satisfaction surveys (minimum of 2 per year)

Exceptional: Average score at or above 3.6 Acceptable: Average score between 2.6 and 3.6 Unacceptable: Average score below 2.6

Deliverable Timeliness Percentage of deliverables meeting delivery timelines

Exceptional: 100% of deliverables meet delivery timeline Acceptable: less than 100% and greater than or equal to 90% Not Acceptable: Less than 90%

PBGC Policy/Process Compliance & Contract Clauses

Adherence to PBGC policy and processes and Contract Clauses.

Including, but not limited to:

- ITSLCM Compliance

- Risk Management

Policy

Acceptable: 100% Unacceptable: Less than 100%

Compliance with Quality Control Plan Adherence to proposed quality control plan

Exceptional: 100% Acceptable: 95% Unacceptable: Less than 95%

Production Ticket Root Cause Analysis rate

Measures the percentage of production tickets with

Exceptional: 75% or more tickets

Commented [SD5]: Q&A #124

(AQL)

associated root cause analysis findings logged as PTR/SCR, so that effective prioritization of corrective action can be made based on the highest impact.

Metric Formula is:

(Total # of Production Tickets that have an associated PTR or SCR) / (Total # of Production Tickets)

Acceptable: less than 75% and greater than or equal to 25% Not Acceptable: Less than 25%

ForeSee My PAA Customer Satisfaction Score

FY ForeSee Customer Satisfaction Rating

Exceptional: 85 or Greater Acceptable: 78-85 Unacceptable: < 78

Continuity of Operations (COOP) Support Provide sufficient on-call and/or on-site support for annual COOP testing events and COOP events if applicable to system

Acceptable: COOP Testing/Event Support Unacceptable: COOP Testing/Event not supported

Sustainability Roadmap Development and Maintenance

Ensure establishment and/or maintenance of system sustainability roadmap which identifies end-of-support life (EOSL) dates for current and future versions of system/application IT components to include:

- Infrastructure EOSL

Items

- System/Application

Technical Stack

- Development Tools required to support systems/applications

Acceptable: 100% complete with monthly review and updates Unacceptable:

Incomplete and reviewed/updating greater than monthly.

Maintenance of System Documentation Extent to which the system documents reflect the current release in production.

Exceptional: 100% of system documents reflect current production version Acceptable: < 100% and ≥ 95% of system documents reflect current production release Unacceptable: < 95% of system documents reflect current production version

• Quality Assurance Surveillance Plan (QASP): This portion of the PWS explains to the contractor what the Government’s expectations are, how (and how often) deliverables or services will be monitored and evaluated, and incentives that encourage the contractor to exceed the performance standards and that reduce payment or impose other negative incentives when the outputs/outcomes are below the performance standards. Attach the QASP to the PWS.

• Deliverables and Delivery Schedule: List all outputs/outcomes with specific due dates or time frames. Include media type, quantity, and delivery point(s). State due dates in terms of calendar days after task order award. All system software documentation must be in accordance with the PBGC ITSLCM. Documentation shall be delivered in both hard copy and electronic format. At a minimum, the list of deliverables will include the deliverables listed below. The contractor is encouraged to propose additional deliverables based upon industry best practices, company experience, project management expertise, and PBGC’s ITSLCM:

Deliverable Due (frequency of items identified with an * will be as proposed by offeror)

Kick Off Meeting – Proposed Agenda Item Submission Within 10 business days after award Project/Operations Management Plan – Describes standard operating procedures for conducting service desk support and maintenance/emergency releases

Draft within 15 business days after award with 5 business days for review/updates.

Transition Plan to ensure continuous operations/support of the FMS systems

Within 10 days of start of CLIN’s period of performance.

Artifact Review/Worksheet Per PWS* Project/Operations Schedule Per PWS* Weekly Project/Operations Status Reports including production support ticket status/statistics, service desk interactions and system operational dashboard

Weekly

Program Management Review (PMR) Briefings

Monthly – first 6 months.

Every other month – thereafter. (Note:

Government may later authorize moving to Quarterly PMRs if authorized by the contracting officer and as specified in a task order or modification to a task order (Government reserves the right to increase the frequency of formal PMRs depending on issues that arise if more Government oversight and contractor reporting is required due to issues experience during performance.)

System Sustainability Roadmap With initial PMR and updated monthly IPT Meeting Agendas and Minutes Weekly Customer Survey Semiannually at a minimum Peak Period Support Reporting Per PWS* Operational and Production Ready FMS system including application monitoring

Daily

Maintenance/Emergency Release Project artifacts in accordance with the PBGC ITSCLM

As required.

Deliverable Due (frequency of items identified with an * will be as proposed by offeror)

FMS system change backlog (including LOE and impact) Maintained continuously with a minimum of quarterly reviews

CCB Artifacts and Updates Per release and change in scope, schedule or cost

Release Management Artifacts per PBGC Change/Release Management Process

Per release

Configuration Management Plan Draft within 15 business days after award with 5 business days for review/updates.

FMS System Configuration Baseline Updated per system change FMS System Code in PBGC code repository Updated per system change Impact Analysis and Remediation for Infrastructure Changes As required.

Impact Analysis and Remediation for Integrated System Changes

As required.

Financial Analysis and Data Exports As required.

Data Call Responses As required.

P3M (MS Project Online) Updates Weekly Risk and Issue Management Plan and Artifacts Per PWS* Reports, presentations, agenda and meeting minutes in support of IT and business project managers for meetings and briefings.

As required.

Quality Control Plan Per PWS Quality Control Plan Process and Training Documentation Per PWS Training Plan Per PWS* Training Materials – PBGC Specific User and Administrative Per PWS* EA TRB Presentations and TRM Updates Per change requiring TRB approval Logical Data Model Updates Per change in FMS system data physical/logical data model System Documentation Updates Per change of system elements requiring documentation updates

• Project/Operational Management Plan: The contractor shall provide a project/operational management plan within 10 working days from the date of award as a deliverable in the PWS. The project management plan shall be in writing and include a description of how the plan will be used by the contractor to manage the work in meeting the TO requirements. The project management plan must meet the following criteria:

o For each deliverable in the PWS, the Contractor shall define a task or series of tasks (i.e., work packages). The work packages shall define all of the work necessary to complete the specific deliverable. Work packages shall be defined in such a way that the scope of the work package will not need to be redefined during the execution of the TO. Additional work shall be added by additional work packages.

o For each work package, the Contractor shall specify a beginning and ending date. Where a work package cannot begin until a different work package is started or completed, the Contractor shall note that relationship in the description of the work in the work package. Dates may be identified in terms of number of days after award, actual calendar dates, or some other methodology which is consistently applied, and which is acceptable to PBGC.

o For each work package, the Contractor shall estimate the number of hours needed to complete the work package by the proposed category of labor and the contract labor rate to establish a baseline for the work package.

o The sum:

o - of all the budgeted costs for each work package must equal the planned cost for the complete objective o - of all the schedules for each of the work packages must equal the planned schedule for the complete objective o - of the work defined in all the work packages must equal all the deliverables on the complete objective o A separate work package may be identified for level of effort work (e.g., project management) which is planned to occur evenly over the delivery period of the objective.

o Approved project work plans must be entered and maintained in PBGC’s P3M (Microsoft Project Online) system.

3.3 Quality Control Plan: The Contractor shall provide a contractor Quality Control Plan (QCP) as a part of the proposal submission. This plan will be used by the Government to ascertain if appropriate plans are in place for contractor quality control and will be used as a part of the proposal evaluation process.