Attachments_-_Sample_Development_Task_Scenario.pdf

Page | 1

Financial Management Systems Information Technology Support Services

(FMS-ITSS)

Sample Development Task Scenario

Statement of Objectives

MyPAA Modernization

Page | 2

Contents Sample Task Order: MyPAA Modernization

1.0 MyPAA Modernization Scope and Objectives

2.0 MyPAA Modernization Development Objectives

3.0 Personnel, Performance Work Statement, and Quality Control Plan

Page | 3

Sample Task Order: MyPAA Modernization

The objective of this sample task order is to implement a modernized My Plan Administration Account (MyPAA) system based on Oracle COTS components within 15 months from award. 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: Non-Severable, Labor Hour Period of Performance (POP): 15 months from Date of Award Place of Performance: PBGC Headquarters, 1200 K Street NW, Washington DC 20005

1.0 MyPAA Modernization Scope and Objectives

Over the period of performance of this task, the objective will be to develop and implement a modernized MyPAA replacement solution. This implementation project must be managed with all the diligence required by projects as part of the PBGC ITSLCM. The solution will increase the integration with the Premium Practitioner System (PPS) to such an extent that the result will be viewed as a premium system front-end. Below reflects the context for the new solution:

Page | 4

The scope of this TO includes the business and operational functions provided by the My Plan Administration Account (My PAA) modernization and its integration with the Premium Practitioner System (PPS) ERISA components. The replacement solution will be based on Oracle COTS to the maximum extent possible. An approach shall resemble something similar to the following:

The proposed solution will meet the following high-level requirements:

Customer Module: Intuitive and user-friendly front-end for premium filers

Req. No Description

CBA_REQ-1 The current state of the filing portal is .Net Framework on Windows Server and Oracle 11g Relational Database Management System

(RDBMS).

The modernization requirements include:

a) Implement a modernized practitioner facing front-end

b) Integrate with the common validation rule engine

c) Integrate with premium calculations

d) Finalize the filing into PPS

Page | 5

CBA_REQ-2 The current state of the costumer module uses User Experience (UX) tool

– Cascading Style Sheets (CSS) Bootstrap and lacks intuitiveness to use MyPAA screens.

The modernization requirements include:

a) Redesign MyPAA screens and map form-fields in a tabular layout

b) Online and intuitive help screens

c) Dashboard to access self-service features

d) Improve filing manager page

Customer Module: Validation Errors

Req. No Description

CBA_REQ-3 The current state of the filing portal lacks the ability to review validation errors.

The modernization requirement is to:

a) Provide ability to review rule engine validation errors at summary and detail level Customer Module: Draft Filing

Req. No Description

CBA_REQ-4 The current state of the filing portal lacks the ability to save draft filing at all steps of premium filing.

The modernization requirements include:

a) Provide ability to save and review draft filing

b) Keep the latest draft version of the filing

c) Convert draft to final version once all validation errors are resolved

Single Rule Engine for Validation and Premium Calculation Rules Req. No Description

CBA_REQ-5 The current state of the business rules combines internal and external validation services.

The modernization requirement is to:

a) Populate a common rule engine with PPS validation, premium calculation rules, and MyPAA validations

Page | 6

Unified front-end and back-end database

CBA_REQ-6 The current database setup has the MyPAA database isolated from

PPS.

The modernization requirements include:

a) Common filing and premium database

b) Ensure 24/7 availability of MyPAA front-end during maintenance window

Intuitive and user-friendly front-end for admin staff Req. No Description

CBA_REQ-7 The current state of the admin module lacks intuitiveness to use MyPAA Admin Module.

The modernization requirement is to:

a) Modernize the MyPAA admin module to make it intuitive and user-friendly

Validation Errors Req. No Description

CBA_REQ-8 The current state of the admin module lacks the ability to monitor validation errors online.

The modernization requirement is to:

a) Implement a dashboard to look at all filing validation errors at summary and detail level

Website Administration: MyPAA Admin Module (UI) Req. No Description

CBA_REQ-9 The current state of the admin module is a standalone Java 2 Platform Enterprise Edition (J2EE) application – Linux, Oracle 11g cluster.

The modernization requirement is to:

a) Leverage COTS solution to perform site administrations

Page | 7

Ongoing e-filing and MyPAA website enhancements and self-service options

CBA_REQ-10 The current state lacks an efficient method to implement changes or enhancements.

The modernization requirement is to:

a) Implement a configuration layer to support business rules and validations

Improve filing schema maintenance Req. No Description

CBA_REQ-11 The current filing schema lacks the ability to implement changes on yearly requirements.

The modernization requirement is to:

a) Separate business and validation rules from the core filing schema in order to improve the change implementation process and minimal changes to the filing schema due to regulatory changes

Schema Validations Req. No Description

CBA_REQ-12 The current state of the filing schema requires improvements to validations at the schema level.

The modernization requirement is to:

a) Enforce yearly changes to schema structure validations at the schema level (version verification)

External Services: Vendor Validator Req. No Description

CBA_REQ-13 The current state of the vendor validator operates on Linux, Oracle WebLogic 11g Server.

The modernization requirement is to:

a) Adopt an efficient method to maintain flexibility of the vendor validator

Page | 8

External Interfaces: ACH Pay.Gov /Treasury Services and Routing number validation (MyPBA)

Req. No Description

CBA_REQ-

The current ACH processor is a standalone component that handles the ACH payments submission to Pay.gov, through MyPAA.

The modernization requirements include:

a) Integrate external interfaces via web services

b) Provide ability for the practitioner to save multiple payment accounts/payment methods with MyPAA

c) Leverage industry standards to provide payment options

Integration of Web Services Req. No Description

CBA_REQ-15 The current state of web service integration operates on J2EE Web Services (WS), Oracle WebLogic Server.

The modernization requirement is to:

a) Enhance existing web services relating to security

Identify and Address Security Vulnerabilities Req. No Description

CBA_REQ-16 The current state does not support multi-way and filing authentications.

The modernization requirement is to:

a) Implement front-end security using COTS

Multi-way MyPAA User authentication Req. No Description

CBA_REQ-17 The current security state lacks a multi-way authentication system for user verification.

The modernization requirement is to:

a) Implement a multi-factor authentication for user verification

Page | 9

Authenticate Filing

CBA_REQ-18 The current security state needs to enhance its ability to authenticate filings and filers.

The modernization requirements include:

a) Implement a filing authentication process based on user account

b) Implement filing event process for filing coordinator to invite practitioner to participate and validate their profile in PBGC

c) Implement filing event as a required step in the workflow to complete upload process

Application Performance Monitoring and Reporting Req. No Description

CBA_REQ-19 The current state lacks performance monitoring and reporting capabilities for FOD applications.

The modernization requirements include:

a) Implement a proactive real time application performance monitoring and reporting framework

b) Real-time alerts and notifications

Development Environment Req. No Description

CBA_REQ-20 The current development state operates on .NET Framework on Windows server and Oracle 11g RDBMS, J2EE components on Linux - Oracle WL.

The modernization requirement is to:

a) Leverage Service Oriented Architecture (SOA) framework, COTS products, integrated development environment, scalable, reliable, efficient solutions and development tools with ability to support internal/external deployments

Page | 10

Customer/Practitioner Communication

CBA_REQ-21 The current communication state includes legacy coded modules such as:

a) Statement of Account (SOA) and Dunning Letters

b) Customer Invoices and Past Due File Notices (PDFN)

c) MyPAA Reports The modernization requirements include:

a) Consolidate written communication to/from practitioner using COTS services

b) Integrate communication with unified front-end

c) Implement self-service option to choose mode (mail/electronic) to receive communication

d) Implement chat service for practitioner to connect with PBGC support staff

Email Communication Req. No Description

CBA_REQ-22 The current communication methods include dunning letters, and correspondences generated via Thunderhead application.

The modernization requirements include:

a) Implement a secure inbox message retrieval service accessed via MyPAA portal

b) Email communication should be limited to notifications

c) Implement reminder notifications for follow-ups

Support Practitioner Premium Filing Req. No Description

CBA_REQ-23 The current communication state has no advance ability for routing calls and interacting with premium practitioner customer.

The modernization requirement is to:

a) Leverage Office of Benefits Administration (OBA) and Customer Communication Center (CCC) tools and infrastructure.

Page | 11

Customer Service Requests to Resolve Plan Practitioner Inquiries such as: General/Other, MyPAA specific, and Plan Specific

Req. No Description

CBA_REQ-24 The current communication state consists of a MyPAA admin module and Oracle Teleservice Customer Relationship Management (CRM).

The modernization requirements include:

a) Implement OBA's Customer Contact Center

b) Enhance MyPAA with additional Service Request feature

c) Enhance PPS - Oracle Teleservice CRM module to integrate with MyPAA Service Request feature

Front-End CRM Capabilities Req. No Description

CBA_REQ-25 The current state lacks a front-end CRM solution that integrates with PPS.

The modernization requirement is to:

a) Evaluate an integrated COTS based CRM module that provides both front-end and back-end service request functionality

2.0 MyPAA Modernization Development Objectives

The following are the overall development and development methodology objectives to be met in implementing the solution described above:

2.1 Project Management Support -

2.1.1 Project Management – The objective of project management for this TO is to plan, execute, manage and control the delivery of system changes into production.

All TO 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. Each release will be considered a project and further details in P3M described below as per the Project Management Plan deliverable.

2.1.2 Change Management – PBGC has established an integrated Financial Management 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

Page | 12 been approved by the CCB. The Contractor shall prepare FMS system related change requests (including a 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.1.3 Release Management – This objective is to meet 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 and COOP environments. The contractor will be responsible for managing this process and interacting with appropriate stakeholders to ensure successful releases.

2.1.4 Configuration Management - Maintaining accurate configuration baseline for the system and the systems code base is required. The contractor shall create a detailed configuration baseline for the new solution and code and versioning stored in PBGC’s code repository which is currently PVCS.

2.1.5 Issue and Risk Management - Managing risks and addressing issues that arise as part of this TO helps to maintain project level control. Risks will be maintained in P3M for each release conducted. This risk management will be in compliance with the PBGC Risk Management policy. At a minimum it will include:

• Conducting an initial risk assessment

• Creating a risk plan with assessment findings, risk identification, quantification, and ranking of all identified risks and a strategy for avoidance or mitigation of each risk.

• Keep a risk register 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.1.6 The Contractor shall provide a weekly status report to be combined with the system report produced as part of O&M/Release activities. 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:

• Project Status o Task Completion Status o Upcoming Tasks

Page | 13

• 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 Schedule with a one (1) month forecast of those activities scheduled.

Efforts under this TO will be included in the 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.

2.1.7 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 project IPT. The IPT is comprised of members of the System Team, related system project team, Financial Management Services Division (FMSD), FOD business owners, Infrastructure, Enterprise Architecture, Enterprise Information Security Office, Quality Management Department (QMD), Pay.gov, 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, Business Project Manager and FOD Systems Accountant, will serve as the liaison between the Contractor and the IPT. The Contractor shall include the COR/Federal Project Manager, Business Project Manager and FOD Systems Accountant on all communications, meeting requests, etc. with the IPT. The COR/Federal Project Manager, Business 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.

As FMS systems have multiple integration points with systems internal and external to PBGC, additional members to the IPT must be included as impacted.

This extended IPT will be notified of any changes to FMSD systems and coordination and collaboration conducted to ensure release work can be completely successfully.

Page | 14

2.1.8 Meeting Participation – In response to the issuance of this TO, the Contractor shall propose an appropriate level of meeting support for release/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.

• Participate in cybersecurity meetings with FOD IT Security, ITIOD

Cybersecurity, and Enterprise Cybersecurity Division as needed

• Contractor organized meetings identified in the PWS and as requested to successfully complete development and implementation of release. For example, this would include requirements/user story definition sessions, design reviews or demonstrations, training sessions, deployment planning sessions, etc.

• Attending meetings with the Quality Management Department’s (QMD) Enterprise Evaluation Division (EED) and customer satisfaction survey contractor. This would include capturing requirements and objectives for the implementation of the customer satisfaction survey within the modernized MyPAA solution.

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.2 Systems Development and Engineering – The main objective of this task order is to engineer and implement a modernized replacement MyPAA solution. This effort must follow PBGC’s ITSLCM, comply with PBGC standards and be in coordination with FMSD and FOD practices. This includes the project code along with the processes used and documentation produced for the project.

The contractor may propose the appropriate development methodology for this task order effort, however, the Government believes an Agile methodology to be the most appropriate.

2.2.1 Requirements Definition, Analysis and Specification – Regardless of proposed development methodology, all releases will have documented requirements and a detailed requirements specification. Creative and industry standard methods will be used to elicit requirements from stakeholders and subject matter experts.

These methods will make efficient use of stakeholder time and produce a complete understanding of desired outcome for the solution. The requirements specification will represent what will be implemented and include both functional

Page | 15 and non-functional requirements. It will be documented in sufficient detail to map to applicable test scripts.

2.2.2 Design and Design Specification – As part of the project, regardless of proposed development methodology, a detailed design specification will be produced. The design must provide enough detail to demonstrate how the release requirements will be met and what system changes will be performed. Sufficient levels of functional, structural and behavioral modeling will be represented along with the following design elements:

• Functional Design;

• Technical Design;

• Architecture Design;

• Security Design;

• Logical Data Model Updates;

• Physical Data Model Updates.

• Interface Control Document Updates;

• Report Specification Updates.

As discussed above, the design will focus on an Oracle COTS solution meeting the high-level requirements and requirements elaborated as part of the development effort. Consideration must be given to usability, performance and appropriate processing of premium filings/payments and associated retention of those records of auditability.

2.2.3 User Experience Design - A key objective of the modernization effort is to architect a user-friendly and intuitive interface. The premium practitioner customer, from first time visitor to experienced user, must be able to logon to the modernized MyPAA and complete a form filing with the use of industry standard navigational icons and visual cues. The addition of context sensitive help tips will also provide a more useful experience. In addition to enhancing the user interface, MyPAA application performance is critical to supporting a positive user experience. The application response feedback time with regards to user activities and interactions such as navigating between form fields, selecting form buttons, retrieving form data, and navigating between pages, must feel natural to the novice or experienced user. To fully meet this objective, the contractor must include in its proposal its detailed approach to ensuring usability in the future solution.

2.2.4 Development (Prototyping, Coding and Configuration) – System development must incorporate industry best practices for software/system development and demonstrate effective and efficient coding practices. System construction activities will accurately translate requirements and designs into functionality with prototyping and proof-of-concept activities conducted as necessary to elucidate the requirements and design. Proposed quality assurance for

Page | 16 development will be incorporated as part of the quality control plan included with the PWS described below. At a minimum, the contractor shall ensure that code is peer reviewed for appropriate functionality, eliminating potential defects from being introduced and that the code addresses the requirements and design for the release and impacts do not go beyond the scope of the release. The contractor shall also ensure that code developed is peer reviewed to identify design flaws that could lead to potential cybersecurity vulnerabilities or lead to memory management issues that would degrade system performance. All code and versioning for code for deployment must be staged in PVCS following development and testing.

Servers hosting the modernized solution must be installed and configured using industry best practices with respect to Federal cybersecurity regulations (e.g., FISMA, NIST 800-53, NIST 800-70, OMB 15-13, DHS BOD 18-01, Presidential Executive Order on Strengthening the Cybersecurity of Federal Networks and Critical Infrastructure (May 11, 2017), etc), Federal Section 508 regulations, and industry standards for system performance.

2.2.5 Quality Assurance Testing – The new solution will be thoroughly tested prior to implementation. A comprehensive test plan (or plans) will be produced that documents the test approach and scope. Testing will include unit, system/integration and user-acceptance (UAT) testing. All test scripts will be managed in the PBGC approved test management tool, currently HP Quality Center. A complete set of test scripts and test cases will be developed to determine that the implementation meets its objectives, requirements are met, and no defects are introduced. Any defects identified during testing must be resolved prior to implementation and retested to ensure appropriate functionality.

Defects will be categorized via severity as follows:

• Urgent – Impact critical system functions with no available work-arounds

• High – Prevent execution of critical functionality by all users but work around available

• Medium – Prevents execution of some functionality and work-around is possible

• Low – Includes minor defects that may cause inconvenience or nuisances

• Cosmetic – Includes spelling errors, typos, error message language, fonts, formatting or other UI issues.

• Enhancement – Items discovered outside of the scope of the current release

• Deferred – Defect identified in other categories for which reasons exist not to address.

Items identified as enhancements or deferred items will be recorded in HP Quality Center as additional to the backlog.

Page | 17

The contractor may propose a recommended quality assurance testing approach, including recommended COTS testing suite software, as part of the Quality Control Plan described in the task order.

2.2.6 End to End Performance Load Testing – The new solution will undergo a managed end to end performance load test with integrated Financial Management System applications to ensure that the MyPAA user experience is preserved, compared to current state, and there is no performance degradation experienced by the existing FMS applications with the implementation of the modernized front-end application.

2.2.7 Section 508 of the Rehabilitation Act of 1973 and Web Content Accessibility Guidelines v2.0 Testing – The modernized MyPAA solution will undergo a comprehensive test to confirm compliance with the most recent revisions to Section 508 and the Web Content Accessibility Guidelines (WCAG). A test plan will be delivered that identifies the scope and approach of accessibility testing.

Following the testing cycle, a final report will be provided to demonstrate compliance with the most recent version of the Section 508 regulations. To fully meet this objective, the contractor must include in its proposal its detailed approach to ensuring accessibility compliance in the future solution. In addition, the proposal must also describe the software tools recommended to test Section 508 compliance.

2.2.8 FMS System Integration Approach

2.2.8.1 FMS System Integration Plan – The modernized replacement MyPAA solution will have upgraded front-end and middle-tier components that may require additional feedback from internal customers and practitioners to ensure that our final “Grand Opening” release is usable for most users. The contractor shall provide several options on the recommended approach on how to deploy the modernized MyPAA. (e.g., 1 major deployment release, phased deployment approach, production deployment for modernized solution simultaneously with current My PAA solution, etc.)

2.2.8.2 Implementation and Deployment – Implementation and deployment will be coordinated with ITIOD staff who maintain production access to FMS systems.

A detailed deployment plan will be prepared with sufficient detail to allow ITIOD staff to conduct implementation of the solution using final code and files contained in PVCS. For integrated releases, a master deployment activity dashboard will be prepared to coordinate release activities of integrated FMS systems. At a minimum the release activity dashboard will include:

• Pre-deployment, deployment and post-deployment activities

• Activity start time/date, end time/date, duration, assigned resource, and activity dependencies

Page | 18

As described above in Release Management, implementation and deployments must be done in compliance with PBGC Change/Release Management process.

For the purposes of deployment, this includes both the production and COOP environments. The contractor may propose a recommended system deployment approach, in collaboration with ITIOD staff, as part of the Quality Control Plan described in the task order. In addition, the contractor may propose a recommended COTS system deployment dashboard utility that may be used to help facilitate and manage each of the Production and COOP release activities.

2.2.9 Operations Turnover – As part of the deployment, the contractor shall ensure that

ITIOD operations staff responsible for production operations are fully equipped to operate and maintain the system based on introduced changes. A system operations document will be prepared as appropriate to document changes introduced from the release.

2.3 Program Analysis and Enterprise Architecture (EA) Support – Any changes introduced the solution implementation must be made in accordance with PBGC EA standards included development and design standard. EA representatives are members of PBGC system IPTs and must be made aware of and review proposed system changes.

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. If new system components or versions of those components are needed, a presentation will be prepared, and TRB 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. A data model must be established for the new solution and updates made to any impacted FMS systems 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 – For the new solution, all appropriate stakeholders will be effectively trained to understand and use the new system or changes being implemented. Training plans and training will be developed as part of the proposed project plan.

2.5 System Documentation, Documentation Maintenance and Technical Writing - The contractor shall maintain an up-to-date document repository for the project and system with new and updated artifacts, 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.

Page | 19

2.6 Section 508, Web Content Accessibility Guidelines 2.0, and Information and Communication Technology (ICT) Standards and Guidelines – The contractor shall ensure that each release is compliant with all federal accessibility requirements.

2.7 Data Quality Management – The staging and impact of the solution implementation to production data must be considered. Development and testing will use the most current data appropriate and will exclude the use of PII as referenced in the PII section below.

Data staging and refreshes will be coordinated with ITIOD as per ITIOD processes.

Attention must be paid to the financial transactions and auditability of changes to those transactions.

2.9 IT Security

2.9.1 IT Security – As part of the development process, the contractor will ensure that security and NIST security controls are built into project design. A security impact assessment will be completed as part of the effort to determine if impacts will be made to any internal controls. The solution will be tested and reviewed by the FOD IT Security team led by the FMS Information Systems Security Manager (ISSM) and delegated Information Security Systems Officers (ISSOs).

My PAA is a publicly facing web application and must comply with the Federal Information Security Management Act (FISMA), all NIST 800-53 controls, Federal Information Processing Standards (FIPS), Office of Management and Budget (OMB) Federal Web site requirements (e.g., M-15-13, etc), and any Department of Homeland Security (DHS) Cybersecurity requirements (e.g., BOD 18-01).

2.9.2 Authority to Operate – The modernized solution, as stated above, will undergo a security impact assessment. Based on the results of this assessment, an Authority to Operate will be provided by the Designated Approving Authority (DAA).

2.9.3 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, Page | 20 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.

• 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, 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) UAT Defect Escape Rate Percentage of high or medium defects discovered in UAT as a percentage of medium or high defects found

Exceptional: 15% or less defect escapes

Page | 21

Acceptable: Greater than 15% and less than or equal to 35% Unacceptable:

Greater than 35%

UAT High Defect Number Number of high severity defects found during UAT testing in relation to the total number of test scripts.

Exceptional: 5% or less defects Acceptable: Greater than 5% and less than or equal to 12% Unacceptable:

Greater than 12%

Post Production High Defect Count

Measures quality of code deployed to production based on high severity defects logged after a release

Good: 0 high severity defects Acceptable: 1 high severity defects Unacceptable: Greater than 1 high severity defect identified

Project Cost Performance Index (CPI) (if using non-Agile methodology)

CPI score for project/release Exceptional: Between .96 and 1.04 Acceptable: Between .90 and .96 OR between 1.04 and 1.10 Unacceptable: Less than or equal to .9 or greater than or equal to 1.10

Project Schedule Performance Index (SPI) (if using non-Agile methodology)

SPI score for project/release Exceptional: Between .96 and 1.04 Acceptable: Between .90 and .96 OR between 1.04 and 1.10 Unacceptable: Less than or equal to .9 or greater than or equal to 1.10

ForeSee My PAA Customer Satisfaction Score

FY ForeSee Customer Satisfaction Rating – Post Replacement Solution Release

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

Qualys SSL Labs – SSL Server Test ScoreAgile Metrics

As per proposed PWS As per proposed PWS

Page | 22

Web Application Performance Metrics

As per proposed PWS As per proposed PWS

• 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 deliverable 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 Management Plan Draft within 15 business days after award with 5 business days for review/updates.

Project Schedule Per PWS* Weekly Project Status Reports (to be combined with system operational reports)

Weekly

IPT Meetings and Agendas (to be combined with system operational meetings)

Weekly

CCB Artifacts and Updates As required.

P3M (MS Project Online) Plan and Updates Upon CCB approval with updates weekly at a minimum Project release artifacts in accordance with the PBGC ITSCLM (including, but not limited to, requirements documentation, design documentation, test plans, documentation and results, deployment plans, operational guide updates)

As required.

FMS System Release Code (staged in PBGC PVCS code repository)

As required.

Page | 23

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

Updates to FMS system configuration documentation noting changes (including configuration baseline and system environment plan (SEP).

As required.

Production ready FMS system release As required 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.

Program Management Review (PMR) Briefing Updates (for O&M PMR)

Coordinated with O&M PMR Briefing

Logical Data Model Updates As required.

Quality Control Plan Per PWS Training Plan Per PWS* Training Materials – PBGC Specific User and Administrative

Per PWS*

Risk and Issue Management Plan Per PWS* PBGC Specific User Documentation (i.e., tri-fold, step-by-step procedures, etc.)

Per PWS*

System Documentation Updates Per PWS* IT Security Impact Analysis (documenting security impact of changes)

Per PWS*

At a minimum include these agile project artifacts:

Product Backlog, Sprint Backlog, Product Increment

Per PWS*

• Project Management Plan: The Contractor shall provide, as a deliverable in the PWS (Performance Work Statement) within 10 working days from the date of award, a project management plan. 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 project. 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

Page | 24 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:

of all the budgeted costs for each work package must equal the planned cost for the complete objective of all the schedules for each of the work packages must equal the planned schedule for the complete objective 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 A separate work package may be used for expenses which are directly reimbursed, pending approval of the Contracting Officer. However, in such case the work package shall contain a planned schedule for the expected expenditures.

Where the expenditure is for an item (as opposed to a service) which is purchased;

the planned and later the actual expenditure shall be separately identified so that the accountability for the property can be readily identified by the PBGC.

o If the project plan includes a contingency in the schedule for project slippage, the Contractor shall identify it in a separate work package along with the planned cost (if additional costs will be incurred by a schedule slippage).

o If the project plan includes a contingency in the labor estimate, the Contractor shall include it in a separate work package along with the estimated hours by labor category and contract labor rates.

o Approved project work plans must be entered and maintained in P3M (Microsoft Project Online)

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. It will be based on the PWS and to ensure compliance with all required PBGC directives and enterprise standards to include PBGC’s ITSLCM, program management activities, and specific compliance with all Federal Information Technology Regulations, including, but not limited to: Section 508 accessibility, acquisition, and OMB and DHS federal web site and cybersecurity mandates. The contractor will be responsible for ensuring all contractor staff are trained upon entry on quality control, in regard to any changes to quality control methods and that refresher training happens at least annually.

For release work, the quality control plan must address:

• Code Quality Review (e.g. peer review, automated code review, etc.)

• Regression and System Testing Quality – Ensuring defects are not released to production

Page | 25

• Performance Load Testing – Plan to execute system wide performance load testing with the modernized MyPAA and PPS with sample scenarios and data that would provide full comprehensive results to highlight the system and application performance variances under different user session loads and transactional loads

• Section 508 Accessibility Testing – Provide testing checklists and final reporting template to demonstrate compliance with most recent version of Federal Section 508 Accessibility and Web Content Accessibility Guidelines

• Compliance with OMB M-17-06, Policies for Federal Agency Public Websites and Digital Services

• Ensuring User Experience Satisfaction

• Checklists – Inclusion of checklists to confirm all steps and actions have been completed

• Production/COOP System Deployment Management – Plan to coordinate deployment of solution to production and COOP environments in collaboration with ITIOD resources.

This plan may also identify any recommended COTS deployment management dashboard utilities to help facilitate and manage each of the release activity tasks and to serve as a management dashboard to communicate status during deployment.

• Scope Management – Plan for ensuring agreed scope is included in releases and that release does not include unrelated changes

3.0 Personnel, Performance Work Statement, and Quality Control Plan