Task_Order_Request-_TO-02_tracked_changes_amendment_0002.pdf

i

TASK ORDER REQUEST

Task Order Two

1.0 INTRODUCTION

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

TOR Identification Number TO-02

Contract Type Labor Hour

Other Direct Costs (ODCs) Authorized

No

Period of Performance (including options)

November January 1, 20198 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 TWO 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.3 Part C– Task Order Two Response of this solicitation.

Commented [SD1]: Q&A #134

Commented [SD2]: Q&A #179 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 B 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 Two Statement of Objectives B. Task Order One Two Price Schedule Commented [SD3]: Q&A #179

ATTACHMENT A

Task Order #2

Statement of Objectives Standard Releases

Contents

Task Order 2: Standard Releases

1.0 FMS Standard Releases

2.0 Personnel, Performance Work Statement, and Quality Control Plan

TASK ORDER 2: STANDARD RELEASES

The objective of this task order (TO) is to provide standard release support for the FMS IT systems defined in the FMS-ITSS IDIQ contract. Release support includes developing and implementing system updates introducing new code, configurations and other changes. 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: Labor Hour Period of Performance (POP): Severable, One year from Date of Award Place of Performance: PBGC Headquarters, 1200 K Street NW, Washington DC 20005

1.0 FMS STANDARD RELEASES

Over the period of performance of this task, the objective will be to develop and implement software releases for FMS systems. For the purposes of this TO, all releases will be considered projects and must be managed with all the diligence required by projects as part of the PBGC ITSLCM. These releases will be based on identified and prioritized PTRs/SCRs in the backlogs of the FMS systems.

Releases will be delivered during the following periods of performance for this TO:

• MyPAA Release Period: January 1, 2019 to October 31, 2019

• PPS Release Period: April 1, 2019 to October 31, 2019

• TAS Release Period: February 18, 2019 to October 31, 2019

The anticipated volume of releases for the FMS systems under this task order includes:

• MyPAA – MyPAA delivers approximately three (3) releases of varying sizes for total release hours not to exceed 8,250 hours in a 12-month period. During the 10-month period of performance for this TO, the My PAA team would expect to deliver two (2) releases of varying sizes for total release hours not to exceed 5,500 hours and provide support for the third release not to exceed 1,375 hours.

• PPS – PPS typically delivers three releases of varying sizes per year. For this release period, it is expected that approximately one release will be implemented and one will be in progress for total release hours not to exceed 63,000 hours

• TAS – TAS typically implements three (3) maintenance releases including both standard maintenance/enhancement efforts in a 12 month periodwith total release hours not to exceed 3,600 hours in a 12 month period. Currently, the duration of each release is not consistent but when planning these maintenance releases, we include a minimum of 300 hours per month of software change requests (SCR) and Problem Ticket Reports (PTR) as a basis for sizing the releases. For the period of performance within this TO, TAS will implement have approximately 1one release and one will be in progress for total release hours not to exceed 12,000 400 hours.

1.1 Project Management Support -

1.1.1 Project Management – The objective of project management for standard releases is to plan, execute, manage and control the delivery of system changes into production for FMS systems. 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.

1.1.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 LOE and the impact) for CCB review and consideration, and capture CCB deliberations and decisions for FMS systems related change requests via meeting minutes.

Commented [SD4]: Updated.

1.1.3 Release Management – There are two main objectives relating to release management for standard releases. The first is establishing a well-planned release process that minimizes the number of releases. FMS systems are highly integrated and in general require common, integrated releases to test changes impacting both systems as well as minimize release cycles. Any release planning must focus on integrating releases to the maximum extent possible. 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 and COOP environments. The contractor will be responsible for managing this process and interacting with appropriate stakeholders to ensure successful releases.

1.1.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. As part of standard releases, the contractor shall review the product of quarterly reviews and incorporate prioritized items into releases given time and effort constraints. LOEs will be reviewed at the time of prioritization and release planning to ensure they remain accurate. If any changes to SCRs or PTRs are identified during the release process, those changes will be reflected in the backlog currently maintained in HP Quality Center. This also included recording any new SCRs or PTRs identified through release testing such as identification of new bugs or enhancements detected that were unrelated to release scope.

1.1.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 releases conducted. 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.

1.1.6 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 for the release

• Updating the FMS Risk Management Plans per system with the release 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.

1.1.7 The Contractor shall provide a weekly status report divided by system for each release/project underway and combined with the system report produced as part of O&M 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/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.

1.1.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.

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 completed successfully.

1.1.9 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.

• 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.

For typical FMS system releases, the following type of meetings should be held:

• Release Planning and Scoping - In addition to change control board meetings, there are typically 2 meetings to discuss scope and discuss items in the backlog to assist CCB and IPT members in understanding the items in the backlog.

• Requirements – In addition to any PWS-identified requirements gathering sessions identified by the contractor in the proposal, typically, there are approximately 4 requirements related sessions to discuss and review requirements, walk through the documentation and review IPT feedback on the document.

• Design – During the Design, there are typically 3 sessions including a demonstration of critical functionality / prototypes and a walk through of the design document feedback with IPT members to reach consensus on feedback and the changes to be made.

• System Integration Test – During system integration testing, there are typically 2 meetings to provide a preview of the test plan and functionality to be delivered to User Acceptance testing. At the end of system integration test, there is a meeting where the contractor outlines the results of testing for a Go/No Go decision to exit system integration test and enter User acceptance Test.

• User Acceptance Testing – During User Acceptance Testing, the team participates in a brief daily conference call to review the status of items identified in UAT. At the end of UAT, the team participates in a Production Go/No Go meeting.

• Deployment – During the preparation for deployment, there are typically 2-3 meetings with system administrators, business areas, ITIOD (and Eagle for TAS) to ensure that all parties understand the deployment plan and their anticipated participation.

• Lessons Learned/Retrospective – Typically, the team will hold an internal lessons learned in preparation for a larger lessons learned with the IPT.

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.

1.2 Systems Development and Engineering – The main objective of this task order is to conduct periodic releases to introduce enhancements or bug fixes to FMS systems.

Releases may be of varying sizes, but must all follow PBGC’s ITSLCM, comply with PBGC standards and be introduced in coordination with FMSD and FOD practices.

This includes the release code along with the processes used and documentation produced for each release. Releases for all FMS systems must be consistently managed and use consistent release practices (i.e. a release performed for PPS must proceed through the same process and gates as MyPAA unless otherwise approved by the COR).

• Releases under this task order will be to continue to use a hybrid waterfall/iterative approach where requirements and design specifications will need to be approved prior to testing and implementation but some construction/proof-of-concept construction work can occur during requirements and design stages. During the TO performance, the objective also includes identifying and beginning to transition to a more Agile model where releases and development are conducted in more iterative sprints.

1.2.1 Requirements Definition, Analysis and Specification – Regardless of proposed development methodology, all releases will have documented requirements and a detailed requirements specification will be produced and approved prior to testing implementation. 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 changes for the system for a given release. The requirements specification will represent what will be implemented and include both functional and non-functional requirements. It will be documented in sufficient detail to map to applicable test scripts.

1.2.2 Design and Design Specification – As part of each release, regardless of proposed development methodology, a detailed design specification will be produced and agreed prior to user acceptance testing and implementation. 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.

1.2.3 Development (Prototyping, Coding and Configuration) – System development must incorporate the industry best practices for software development and demonstrate effective and efficient coding practices. Release 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 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. All code and versioning for code for deployment must be staged in PVCS following development and testing.

1.2.4 Testing - All changes to be introduced to FMS systems will be thoroughly tested prior to release for production. A comprehensive test plan (or plans) will be produced for reach release documenting the test approach and scope. Testing will include unit, system/integration and user-acceptance (UAT) testing. For each release thorough regression testing will also be included and updates made to the regression test script baseline based on contents of the release. 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 each release meets its objectives, requirements are met, and no additional defects are introduced into the FMS system. Any defects identified during testing must be resolved prior to implementation and retested to ensure functionality and that no additional defects were introduced. The current regression test baselines for the systems include the following number of scripts:

• PPS – 259 test scripts

• TAS – 382 test scripts

• MyPAA – 109 test scripts

• 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 for a given FMS system.

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

Detailed and often integrated deployments must occur due to the tight integration of FMS systems. Detailed deployment plans will be prepared with sufficient detail to allow ITIOD staff to conduct implementation of the release using final code and files contained in PVCS. For integrated releases, a master deployment activity spreadsheet will be prepared to coordinate release activities of integrated FMS systems. At a minimum the release activity spreadsheet will include:

• Pre-deployment, deployment and post-deployment activities

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

• 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 include both the production and COOP environments. For TAS releases, coordination with our managed service provider, Eagle Investment Systems, is required.

1.2.6 Operations Turnover – As part of each 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.

Updates to the system operations documentation will be made for each release as appropriate to document changes introduced from the release.

1.3 Program Analysis and Enterprise Architecture (EA) Support – Any changes introduced by releases 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.

1.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 TRB approval received, prior to any deployment of that component in any PBGC environment.

1.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.

1.4 Training – For each release, all appropriate stakeholders will be effectively trained to understand and use the new enhancements or changes being implemented. Training plans and training will be developed as part of the proposed release process.

1.5 System Documentation, Documentation Maintenance and Technical Writing - The contractor shall maintain an up-to-date document repository for releases 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.

1.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.

1.7 Data Quality Management – In addition to the code being impact by each release, the staging and impact 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 should be paid to the financial transactions and auditability of changes to those transactions.

1.8 IT Security

1.7.1 IT Security – As part of the development process, the contractor will ensure that security and NIST security controls are built into release design. A security impact assessment will be completed as part of any release to determine if impacts will be made to any internal controls. All releases 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). Security testing will be included as part of all releases.

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

1.7.2 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.

2.0 PERSONNEL, PERFORMANCE WORK STATEMENT, AND QUALITY

CONTROL PLAN

23.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

Commented [SD5]: Q&A #192 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.

23.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 Acceptable: Greater than 15% and less than or equal to 35% Unacceptable: Greater than 35%

Commented [SD6]: Q&A #192

Requirement

Acceptable Quality Level

(AQL)

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

Exceptional: 10% or less defects Acceptable: Greater than 10% and less than or equal to 20% Unacceptable: Greater than 20%

Post Production High Defect Count Measures quality of code deployed to production based on high severity defects logged after a release

Acceptable: 0 high defect Unacceptable: 1 high defect

Deployment of Defect Free Code Successful deployment of code with no urgent fix releases required to address issues introduced by the current release

Acceptable: No urgent fix releases Unacceptable: 1 or more urgent fix releases

Project Cost Performance Index (CPI) (for

LH/TM TO)

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 Cost Project is delivered on or below cost

Exceptional: Below cost Acceptable: At cost Unacceptable: Above cost

Project Schedule Performance Index (SPI) 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 .90 or greater than or equal to 1.10

Release Schedule Releases are delivered in accordance with their original baseline (unless as required by a change directed from PBGC)

Exceptional: No rebaseline required Acceptable: 1 rebaseline required Unacceptable: More than 1 rebaseline required.

Release Milestones Major release milestones are met at the agreed time as per baselined schedule (i.e.

approved requirements, design, test results, deployment, lessons learned)

Exceptional: 100% of milestones met on time Acceptable: ≤ 99% and ≥ 95% of milestones met on time

Requirement

Acceptable Quality Level

(AQL)

Unacceptable: Less than 95% of milestones met on time

Release Requirements Release product meets documented requirements

Acceptable: 100% of documented requirements met Unacceptable: Less than 100% documents requirements met

Release Testing Completeness of release testing, as documented in test plan and results that includes appropriate:

- Performance testing to identify potential impacts to performance

- Regression testing to identify potential defects in existing functionality introduced via new code

Acceptable: Performance and Regression testing is included as part of test plans and results Unacceptable:

Performance and regression testing not included with release testing

Training Timeliness Training is provided when a release includes changes or enhancements the directly impact the user experience

Acceptable: Training is provided within 20 days prior to production deployment or otherwise agreed with business area.

Unacceptable: Training not provided prior to production deployment

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%

• 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

Commented [SD7]: Q&A #124 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 PBGC Release Management Artifacts per PBGC Release Process

As required.

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.

Interface Specifications or Updates to Interface Specifications As required.

Report Specifications or Updates to Report Specifications As required.

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

As required.

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*

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

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 deliverables 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 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 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)

23.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 program management activities, and specific compliance with IT, acquisition, and security OMB, Federal, and PBGC directives and standards to include PBGC’s ITSLCM. 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

• Performance Testing – Ensuring testing scenarios and data provide full comprehensive results to include the changes performing under different user or transactional loads

• 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

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

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

Commented [SD8]: Q&A #192

ATTACHMENT B

PRICE SCHEDULE

Task Order Pricing Sample

For each task, the vendor should provide a summary and detailed pricing schedule as set out below. This sample represents the minimum amount of information required but does not limit the amount of detail that can be provided by the contractor. Contractors are encouraged to supplement with additional detail such as discounts or other details.

Task 2 Releases - Summary

FMS IT Support Services (FMS-ITSS)

Task 1 – Transition, Operations and Maintenance TOTAL Base Year - 12 months from contract award CLIN 0001 - MyPAA Release Labor (1/1/19-10/31/19)

CLIN 0002 – PPS Release Labor (4/1/19-10/31/19)

CLIN 0003 – TAS Release Labor (2/18/19-10/31/19)

CLIN 0004 – Other Direct Costs (Date of Award to 10/31/19)

TOTAL PRICE $

Task 2 - Pricing Detail Sample

IDIQ Labor Category

Contractor Name

Role Hours Hourly Rate (Fully Burdened)

Direct Labor Cost

Prime Direct Labor CostPrice Project Manager – Level 1

Sarah Smith Project Manager XX $XX $XX

Application Engineer – Level

John Smith Java Developer XX $XX $XX

Total Prime Direct Labor CostPrice

XX $XX

SubContractor Labor CostPrice Business Analyst

– Level 2

Jane Doe Premium Operations Business Analyst

XX $XX $XX

Total Subcontractor Labor Price

XX $XX

Total Direct Labor CostPrice

Total CostPrice $XX

Commented [SD9]: Q&A #3

2.0 Personnel, Performance Work Statement, and Quality Control Plan