20_Solicitation - Attachment 9 - TOR Task Order 01_rev 05 11 2021.docx

RFP 16PBGC21R0010

ATTACHMENT 9 – TOR Task Order 1

Task Order 1: Transformational PIMS (T-PIMS) Minimal Viable Product (MVP)

BACKGROUND

This Request for Task Order Proposal (RFTOP) is issued to support the PBGC’s requirement for the T-PIMS contract. Details of this procurement are identified below.

Telework is permitted in accordance with 52.207-7001, as approved by the COR.

Section C. PWS:

· This TOR includes the requirements in this document (Attachment 9).

· This TOR includes the following attachments:

9 – TOR 1 – T-PIMS Modernization MVP 9-B – T-PIMS Modernization Blueprint 9-C – T-PIMS Product Roadmap 9-D – T-PIMS Future State Requirements 9-E – PBGC T-PIMS 3rd Party Vendors

Task Order 1: Transformational PIMS (T-PIMS) Minimal Viable Product (MVP) Contents

Note: the requirements in this document, TOR 1 (Attachment 9) are in addition to those in the IDIQ PWS.

1.0 BACKGROUND

The Policy, Research and Analysis Department (PRAD) currently utilizes a model over 25 years old to model the Single Employer (SE) program, which protects 30 million workers across 22,500 plans. Known as the SE Pension Insurance Modeling System (PIMS), or SE PIMS, it is a stochastic simulation model used to evaluate PBGC’s exposure and likelihood of future claims and to quantify the amount of risk facing the SE insurance program. During the past decades, it has been modified many times to meet legislative and regulatory needs, resulting in an increase of complexity and decrease of flexibility.

To improve performance, scalability, stability, and ease of maintenance, PRAD and the Office of Information Technology (OIT) intend to develop a modernized PIMS, to be called Transformational-PIMS (T-PIMS), beginning with the SE system. In 2019, PBGC engaged a contractor to develop a blueprint and notional roadmap for a new T-PIMS. PRAD and OIT worked with the contractor to jointly develop these documents, which were approved by both organizations’ executives. The blueprint, as well as the high-level requirements the team solicited in the process of creating the blueprint, are attached to this Task Order (TO). See Attachment 9-B – T-PIMS Modernization Blueprint, Attachment 9-C - T-PIMS Product Roadmap and Attachment 9-D – T-PIMS Future State Requirements.

One of the key components for the new model architecture is cloud-hosted Microsoft Azure technology. PBGC already utilizes Azure and associated DevOps tools, and intends to make these available to the Contractor for this project. In addition, PBGC has begun to implement Agile methodology constrained by federal IT and security requirements, which results in development via sprints, with a one-time deployment after completing all sprints needed for the required product. However, since this is the first modernization effort for PRAD in several decades, and Agile development approaches are new to PRAD, additional support will be required by the Contractor to support the Product Team. Robust program and project management are also needed.

1.1 High-Level Notional Schedule

It is expected that a few months prior to this TO 1 ending, T-PIMS Operations, Maintenance and Enhancement (OmE)) activities will commence under a separate TO awarded under this IDIQ contract. Knowledge transfer from staff working on this TO to the subsequent OmE TO team is under the scope of this TO. It is anticipated that T-PIMS OmE activities will run in parallel with the current legacy SE PIMS for one year, during which time the Contractor must coordinate with the legacy SE PIMS contractor.

The following figure notionally illustrates this PIMS environment: legacy PIMS, T-PIMS (implementation, parallel processing with PIMS, and future OmE via this Task Order and future Task Orders), as well as other PBGC contracted support.

Figure 1: Notional Development and O&M timeline for T-PIMS The modernized solution will have a new architecture based on Microsoft O365 products and Microsoft Azure cloud hosted technology, using cutting-edge technology, a modern programming language, and parameter-driven inputs. During planning for this project, the Modernization Planning team solicited high-level requirements and developed a Modernization Blueprint based upon detailed conversations with PRAD and BISD.

1.2 Agile at PBGC

For modernization projects, BISD has successfully adopted a modified Agile SCRUM approach and envisions that our contractor partner will conduct change management activities to acclimate our business area stakeholder, PRAD, with the contractor’s proposed Agile approach leveraging BISD’s guiding principles of people, process, and technology. A company-level Agile certification is not required.

· People: Tight partnership between BISD’s IT Product Manager, business area Product Owner, and contractor Product Manager & ScrumMaster enabled by the contractor team. Additionally, the contractor’s program manager and corporate executives will function with the IT and business program managers’ team. This three-way partnership (business, BISD and contractor) will lead to successful implementation and overall management of IT systems. Our Federal Product Owners and Product Managers are typically Scrum Alliance Certified, and our Federal Product Managers are also PMI® PMP certified.

· Figure 1: People Diagram

· Process: We successfully adopted a modified Agile SCRUM approach for major modernization projects. Unlike traditional SCRUM and continuous integration practices, Finished Work from each Sprint is queued up with that of other sprints as part of a Release Train. Once all the Sprints in the Release Train have completed and undergone thorough User Acceptance Testing, the Release Train can then be pushed to PBGC’s Production environment. We recognize that Agile neither reduces/eliminates robust and proven PMI® Project Management disciplines and practices nor reduces/eliminates sound systems engineering documentation. All system engineering efforts must comply with PBGC’s IT Solutions Life Cycle (ITSLCM) which provides the overarching framework for implementing IT at PBGC. PBGC’s ITSLCM is included in PBGC Directive IM-05-07 which provides the policies, roles, and responsibilities for IT practitioners. Both the ITSLCM and the IT Management Directive are a part of this contract and available on www.pbgc.gov https://www.pbgc.gov/about/procurement. Although the journey to and tools used for sound systems engineering documentation (e.g., Requirements Document, Design Document) may be quite different on an Agile project than a traditional waterfall project, the rigor and philosophy behind them (e.g., traceability, data modeling) remain the same and necessary artifacts must be delivered in compliance with the ITSLCM, and other PBGC guidelines. Given the Agile approach, the contractor must work with the IT Product Manager and Business Product Owner and key stakeholders to map Agile artifacts with ITSLCM deliverables and utilize PBGC-provided DevSecOps tools. For example, in Agile the design document may be incrementally built but ultimately must provide enough detail to demonstrate how user stories/requirements were translated into functionality and supported by the technical implementation.

Figure 2: Process Diagram

· Technology: Program, Project and Portfolio Management (P3M), PBGC’s Microsoft Project Online and SharePoint IT solution utilized by the IT program and project management community, complemented with PBGC’s DevSecOps tool chain as illustrated in the diagram below (Microsoft on-prem DevOps Server 2019). All the Sprints and artifacts shall be developed and managed in the DevSecOps Tools.

Figure 3: Technology Diagram

1.3 Integrated Project Team (IPT)

In addition to the Product team, PBGC has a larger IPT that includes the Information System Security Privacy Officer (ISSPO), Information System Security Manager (ISSM), Infrastructure Security Representative, Privacy Officer, Enterprise Architect (EA), and Infrastructure Representative. This IPT is led by the Federal IT Product Manager, Contractor Product Manager, and Business Product Owner. The larger IPT must meet regularly, at least bi-weekly, to ensure that PBGC technical requirements are met and to identify and mitigate any risks or issues.

Agile procedures must be followed in maintaining backlogs, planning sprints, standup meetings, showing demos, retrospective meetings. Code review and design meetings shall be established and related IPT representatives invited to the meetings. Future sprints shall be planned based on IPT feedback. During key design decision making time EA, Security, Infrastructure and other key stakeholders need to review and give feedback to the design. Applications must be developed using standard PBGC approved EA standards, and the team must coordinate with the project Product Manager to get TRM approval before using the proposed design. The Contractor shall work with the Product Owner in planning and prioritizing the backlogs and shall map backlogs to Features and Epics, and then organize these into release trains and Production releases.

The Contractor must bring visibility to the customer(s) through the project cycle and get early feedback from users allowing the team to adjust to meet the business needs. The Contractor must use resources as a cross functional team, provide an environment where they are able to mentor one another and focus on the same end goal, delivering a high-quality solution to the PBGC.

2.0 T-PIMS SCOPE and Objective

The scope of this Task Order is to architect and implement the Minimal Viable Product (MVP) for the new SE PIMS system, called T-PIMS, based on Python and Azure components, within 24-months, not to exceed 27 months, from award. In an effort to further reduce overall project schedule and cost, PRAD is in the process of establishing documentation to define the data inputs, parameter values, algorithms, variables and equations, various types of simulations, interrelationships between various sections of the models, etc. Upon contract award, the final version of the documentation will be made available to serve as a basis for modeling requirements to begin design and coding. Availability of this documentation is expected to reduce the overall project cost and schedule by several months.This system should be built based on new designs documented in the subsections to replace the legacy PIMS. This modeling system should have the comparable outputs to match current SE PIMS systems so that the legacy system can be retired. The MVP must be sufficient in functionality to replace the current SE PIMS system. That is, the MVP must be able to produce PRAD's Projections Report, policy budget projections runs, and respond to technical assistance requests from Capitol Hill. It must also have the ability for future augmentations. It should be designed in a such a way as to allow enhancements to the T-PIMS SE system as well as enhancements to incorporate the Multi-Employer (ME) system.

This procurement focuses on the following activities:

a) Creating a MVP for T-PIMS, to include:

i. Establishing a cloud architecture for T-PIMS;

ii. Working with ITIOD to set up the IT components required for the new system, and identifying new tools as needed;

iii. Setting up the required actuarial modules to process input data, perform all actuarial calculations, and produce the required outputs;

iv. Establishing the user input screens;

v. Develop model outputs via modern reporting tools.

b) Constantly grooming and managing a product backlog of features that are and are not included in the MVP but which should be included in later enhancements to the product under a separate TO.

High level objectives for the system are found in the table below.

Table 1: T-PIMS High-Level Objectives The following sequencing example is envisioned for the project:

· Months 0-6: onboarding, initial tools and environment set-up (to be done in coordination with ITIOD)

· Months 3-24: ongoing environment and tool set-up as needed; delivery of MVP functionality with go-live

· Months 25-27: post-production monitoring and stabilization, user training, transition to O&M As mentioned above, PBGC anticipates that PRAD’s documentation will result in reduction of overall cost and above timelines.

The following are in addition to and further clarify the requirements identified in the IDIQ Performance Work Statement.

Project Management and Agile tools shall be kept up to date to enable status reporting and status views at any time by the PBGC team. This includes user stories, test plans/scripts, sprint planning, and backlog refinement.

The Contractor shall provide the reports outlined below.

2.1.1.1 Sprint Status Report

The Contractor shall providing a report at the completion of each sprint. The Contractor shall modify the format or subject content of the report at the direction of the COR. This report shall include:

· Requirements Traceability Matrix

· User stories planned vs. user stories completed

· Test Results

2.1.1.2 Executive Level Report (Chief Information Officer (CIO)/Chief Policy Officer (CPO)) Due to the high visibility and importance of this effort, the contractor will brief, bi-weekly, PBGC executive leadership on the status of the effort. The briefings will include executive-level content as well as all Agile performance metrics (such as burn-down rate, velocity, etc.) as necessary for executive oversight of the project. PBGC will provide a standard template for these briefings during Sprint 0. An Executive Dashboard Report template shall be refined during Sprint 0.

2.1.2 Agile Product Team and Integrated Project Team (IPT) for the Modernization Effort As an Agile project, the contractor shall propose an Agile Product Team structure with associated roles for management of the project, and clearly identify the responsibilities for those players. This should be inclusive of any stakeholders (generally included in system IPTs) required to participate in sprint reviews, backlog grooming, retrospectives or any other Agile activities in the proposed Agile methodology.

In addition, an IPT will be 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 from the Agile team, related system project teams, PRAD, Infrastructure, Enterprise Architecture, Enterprise Information Security Office, other interfacing project teams, and PBGC functional staff and users as required. As T-PIMS may eventually 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 and collaboration conducted to ensure release work can be completely successfully.

The contractor shall propose the most effective means of communications between the Agile project team and the systems IPT and frequency of updates.

2.2 MVP Requirements and Design Objectives

The Policy, Research, and Analysis Department (PRAD) develops policy for PBGC's insurance programs and conducts related research and modeling. Policy activity encompasses legislative and regulatory analysis and proposal development related to benefit guarantees, employer liability, and premiums. Research addresses actuarial and financial issues to support policy development and involves modeling for forecasting purposes. PRAD is comprised of roughly 15 actuaries and 5 economists. Of this group, it is anticipated that T-PIMS will have three (3) core users and another two-four (2 to 4) additional users. The MVP will be designed solely for PRAD, though the possibility exists that future enhancements may make PIMS available in a limited capacity to other departments at PBGC.

PRAD’s modeling of the defined benefit pension plan universe is done via PIMS. T-PIMS will help PBGC effectively and proactively guarantee the pension plans that it supports, allowing for responsible and effective fiduciary oversight.

The new T-PIMS model is expected to be freshly built based on key components identified in this document and other attachments. The outputs from the T-PIMS MVP shall be sufficient to produce the annual Projections Report, adaptable so that PRAD can respond to technical assistance requests from Capitol Hill, and be able to produce output used in determining the policy budget.

T-PIMS will be built from the ground up; legacy PIMS will not be remodeled within T-PIMS. The Contractor will need the capacity to recreate all actuarial calculations from scratch, with PRAD’s guidance, along with any economic and bankruptcy calculations. The system should also produce diagnostic outputs to translate the sample calculations for testing purposes. That is, PRAD should be able to isolate and identify all variables within T-PIMS to see how they move throughout the projections.

While PRAD expects T-PIMS to be built from the ground up, a major component to the acceptance of the T-PIMS MVP will be demonstrating and explaining the differences (reconciling) between the results of T-PIMS and the those of legacy PIMS. While the Contractor will rely on PRAD to provide the assumptions for T-PIMS and output from legacy PIMS, if necessary, the contractor must be capable of explaining the differences in actuarial and economic calculations and be able to quantify the changes in any and all variables used throughout the T-PIMS projections. The contractor shall document all actuarial, economic and bankruptcy assumptions and methodologies for the core model at the end of the project.

Throughout the process, the Contractor will work closely with PRAD in the design of T-PIMS. PRAD will take an active role in providing the Contractor with all inputs and/or theories that drive the calculations, and also will review outputs of T-PIMS as completed to validate the accuracy and reasonableness of results. PRAD expects to have input and feedback on every step of the process.

Key components of the T-PIMS MVP are identified below. The Contractor shall review existing high-level requirements for TPIMS and the PIMS Modernization Blueprint (attached), and use expertise to design a future state architecture and realign future phases. The contractor shall create a base line and maintain/update a T-PIMS product roadmap throughout the TO performance period. The product roadmap shall be included as part of the executive level reporting.

Table 2: T-PIMS MVP Activity Descriptions The concept diagram in Figure 2 was created to showcase the general flow anticipated for the final T-PIMS solution (beyond the MVP). The Contractor shall use this as a reference point when creating the final recommended design for T-PIMS. Note that this diagram includes features, such as the cash flow model, that possibly extend beyond the MVP.

Figure 2: T-PIMS Conceptual Diagram In the process of design and architecture, the Contractor must incorporate:

a) A modern supported technology stack and service-oriented design that complies with PBGC enterprise standards. The design must be futuristic and easily adaptable to future infrastructure, software, technology upgrades. Cloud would be a perfect example. Apart from using existing PBGC approved technologies, Contractor must understand the business process, based on the need Contractor must recommend emerging, but proven/stable technologies and processes that would improve the modernization process.

b) Automated processes improving the review, auditing, and reporting activities.

c) A high degree of flexibility in programming to ensure adaptability to new and changing business requirements, supporting the longevity and durability of the solution and associated logic.

d) Web interfaces for internal users to perform authorized functions which include changing numerous input parameters, running models and savings the associated parameters and results; and producing standard reports.

The system should be designed and architected in such a way that when T-PIMS jobs are not running, the cloud services can be downgraded, and the associated fees minimized. Components, e.g. Kubernetes, containerization, and cloud elasticitiy, should be used such that T-PIMS can access maximum computing power when needed, without paying for computing power when it is not in use.

Throughout the completion of this work, the Contractor must work with PBGC to abide by the PBGC ITSLCM and various processes throughout associated stakeholder groups. In addition, the Contractor shall work with PRAD and ITIOD to set up all required infrastructure components and maintain them at the discretion of ITIOD. As needed, the Contractor will prepare presentations for the Technical Review Board (TRB) and respond to any requests for information that come from the EA team.

2.2.1 System Requirements

A comprehensive list of requirements for this system can be found in Attachment 9-D- T-PIMS Future State Requirements. These were compiled after talking with various stakeholder communities prior to generating the Blueprint.

Key high-level requirements include :

· Hosted in PBGC’s Microsoft Azure cloud environment.

· Users may adjust the model via various input parameters.

· At least 10,000 stochastic simulations must be run for each model.

· The system shall enable runs of at least 1,000 SE plans, with the goal of running all plans at scale.

· Python shall be the programming language.

· The user interface role shall be role-base, with the roles of Modeler, Data Scientist, Executor, Client, and Administrator.

· The T-PIMS data structure will utilize a two-tiered approach, outlined by PRAD, with the first tier applying to plans modeled individually and the second tier applying to plans modeled in synthetic plan bundles.

· PRAD determined that the input data stage will use the plan’s summary demographic data provided in the Form 5500 Schedule SB and accompanying attachments to generate a set of plan participant census proxy data profiles, which will form the underlying data for the projection and calculation of liabilities within TPIMS.

A successful MVP will accomplish the following:

· Automated processes improving the review, auditing, and reporting activities.

· Provide a high degree of flexibility in programming to ensure adaptability to new and changing business requirements, supporting the longevity and durability of the solution and associated logic.

· Have web interfaces for internal users to perform authorized functions which include modifying input parameters, running and saving model calculations; producing benefit calculations and estimates; performing data entry, validation, reconciliation, and verification; performing system administration; and producing standard reports.

· Have the ability to interface with other PBGC systems that utilize similar data sets, such as 5500 data forms, leveraging authoritative data sources to avoid data duplication and synchronization.

· Have the ability to integrate multiple models, such as a cash flow model and a bankruptcy model, and the flexibility to incorporate new models as future enhancements.

· Have Application Programming Interfaces (API) capabilities, to incorporate data from both PBGC and third-party vendors.

· Have streamlined data input: capture more fields from 5500 forms attachment; decrease manual time to enter data.

2.2.2 System Design

T-PIMS must be designed to be hosted on a cloud Microsoft Azure environment managed on the behalf of PBGC. It must be designed using PBGC approved Enterprise architecture with an easy data pluggable, and adaptable secure interface. Apart from using existing PBGC approved technologies, the Contractor must understand the business process, and based on the need the Contractor must recommend, propose, and design application using emerging technologies and processes that would improve the modernization process. Any new development module designs must be approved by the TRB. Contractor must plan accordingly and include it in the schedule.

As part of the blueprint and roadmap effort, the following IT building blocks were recommended to best achieve the objectives of T-PIMS:

· Containerization using Docker, Kubernetes, and Azure Container Services, to allow for scalability of the T-PIMS model.

· Databricks and Delta Lake, to increase performance and scalability while simultaneously decreasing maintenance costs.

· Power BI, for flexibility and scalability in reporting, while aligning with PBGC Enterprise IT strategy.

The Contractor shall examine features and functions required for T-PIMS, review the above recommendations, and examine best of breed technology create a futuristic architecture. If the Contractor is in disagreement with the recommendations, they may propose different building blocks. The Contractor shall then work with various IT groups at PBGC to implement the components.

The design must be approved by key stakeholders, including the IPT and TRB.

Significant technical capabilities of the solution must include:

2.2.2.1 Elasticity and scalability

Ability to adapt to increased or decreased workload by building a parallel architecture and reducing dependency on increased memory and other hardware on any given server.

2.2.2.2 Reliability and recoverability

A design that includes loosely coupled components that reduces synchronous dependencies between components. If a single component on a server fails, the architecture will allow for automatic spawning of the component on a different server to pick up the workload. The database must be developed with futuristic approach and data must be secure and able to be pluggable to other systems and portable to other databases based on business needs and EA requirements. The Contractor must recommend, propose, and design the application using emerging technologies. The design will align with PBGC EA standards. If components are not approved in the TRM, the team must coordinate with the PM to get TRB approval before using them. The services developed must be secure and must adhere all the security compliances and guidelines.

2.2.2.3 Security and Authority to Operate

The system must meet security guidelines and requirements per National Institute of Standards and Technology (NIST) and PBGC’s Enterprise Cybersecurity Department (ECD). As of the drafting of this TO, PBGC is working on obtaining and Authority to Operate (ATO) for its cloud-based Azure environments. It is expected that TPIMS will utilize this ATO. As part of this, the Contractor will need to work closely with the security team to make sure all components utilized are covered, and provide information requested by the security team to allow for any updates required. The Contractor must also abide by any security requirements dictated by the Security Team.

2.2.2.4 Architecture and Performance

The new solution must be architected in a such a way that PBGC minimizes unnecessary costs associated with operations on the cloud environment. In other words, it must be design so that when PIMS “jobs” are not running, the ‘housing fees’ for using the cloud are cheap. It shall be designed so that when PBGC needs e.g. Kubernetes, containerization, etc. maximum computing power can be obtained, and then shrink down in footprint as needed. If a technology to be utilized is not approved in TRM, the team must coordinate with the IT PM to get TRM approval before using it.

2.2.2.5 Standards

The implementation of the system must follow the project management plan. The project management and project related artifacts must follow ITSLCM guidelines, EA guidelines and ITIOD policies and procedures. In creating requests for change (RFCs) and requesting required software or hardware services, or any other external tools, team requests must be submitted at least 2 to 3 weeks ahead of original service level agreement (SLA) time to make sure that the requests will be approved on time and the resources will be available. All the PBGC mandated standards, policies, procedures, and guidelines must be followed in designing, development and deploying applications.

2.2.2.6 Ease of Use

The new system must be user-friendly and intuitive, including use of its data input screens, model operations, and reporting.

2.2.2.7 Data Transfer Scalability

The design must be scalable, sustainable, and incorporate all the requirements dictated in the requirements with zero fault tolerance. Network issues must be considered in designing the systems and provide necessary solutions to make the systems work without any Network issues. In the event if the architecture does not support eliminating all the network issues, those must be observed and noted in the performance baseline standard document with the consensus of PO, Business Lead, PM, COR and Key stakeholders.

2.3 Systems Development and Engineering

The contractor shall engineer and implement a modern replacement to the SE PIMS system. The contractor shall conduct all development activities and methodology to complete the effort. This includes the project code along with the processes used and documentation produced for the project. The Contractor must have the ability to provision Platform as a Service.

This effort must use an Agile development methodology. While this will be tailored to specific PBGC policies, the overall methodology as proposed will use Agile principles to the greatest extent possible.

2.3.1 Tool and Infrastructure Setup

The contractor shall coordinate with PBGC teams to establish the appropriate environments to develop and implement T-PIMS in the PBGC Azure cloud environment. This will include preparing development, test, production, and disaster recovery environments. The Contractor will be responsible for building out their design in development and test environments, while the production and disaster recovery environments will be built by ITIOD with information provided by the Contractor. In addition, coordination with ITIOD as it relates to connectivity back to PBGC will be essential and early engagement and establishment of necessary connectivity.

The contractor shall identify the appropriate tools needed, work with ITIOD to determine the number of licenses needed (if applicable), provide information and support needed to obtain approval through the control gates (e.g. TRB), and set up the needed tools. If the contractor advises alternatives to the standard PBGC toolset, the contractor shall support the PBGC process and procedures required to add the tools to the PBGC toolset.

2.3.2 Development (Prototyping, Coding and Configuration)

System development must incorporate industry best practices for software/system development and demonstrate effective and efficient coding practices. The proposed methodology shall follow Agile principles to the greatest extent possible. The vendor shall bring visibility to the stakeholders through the project cycle and get early feedback from users allowing them to adjust to the business needs. Agile procedures must be followed in maintaining backlogs, planning sprints, standup meetings, showing demos and retrospective meetings. Agile team and IPT representatives must be invited to relevant meetings. Based on feedback, future sprints will need to be planned.

Proposed quality assurance for development shall be incorporated as part of the Quality Control Plan. 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 sprint 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 the Program Version Control System (PVCS) following development and testing.

Servers hosting the modern 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.3.3 Agile Methodology

The Contractor must use an Agile approach in the development project and effectively managing scope (i.e. prevent scope creep). As part of this, the Contractor must propose an Agile team structure with associated roles for management of the project and clearly identify the responsibilities for those players. The Agile team structure must take into account the stakeholders described in Section C of the IDIQ PWS as well as other parties as directed by PBGC and set up meetings to coordinate between various groups. User stories must be developed in conjunction with PRAD.

It is anticipated that while sprints will be utilized throughout the duration of this effort, these will be bucketed into a small number of releases, called “release trains”, culminating in one large Production release towards the end of the effort. Sprints must consider timeline restrictions from other groups at PBGC (e.g. Security); these constraints will be determined as the contract progresses during meetings with the larger Agile team and IPT.

2.3.4 User stories, Requirements Definition, Analysis and Specification User stories must be documented with a detailed requirements specification delivered as part of the final solution. The contractor shall detail how this requirements specification will be built over the life of the project. Creative and industry standard methods will be used to elicit user stories/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 contractor will identify how user stories will be incorporated into sprints and provide a traceability from user story to implemented functionality and how that functionality was tested. Additionally, the product owner will be supported in his/her duties to ensure success of his role.

In keeping with the Agile methodology, the scope may be articulated in a capabilities list, user stories, and/or a product roadmap, as appropriate, at an appropriate level. And in keeping with the Agile methodology the specific capabilities and functions will be selected, detailed, prioritized, refined, and elaborated throughout the execution of the project, and modified as circumstances change and priorities shift as decided by the product owner.

The product roadmap will be reviewed as per Agile practices at the end of each release. This review will take into account product owner priorities and what features will be included in the next release.

Sprint 0 will be used to onboard personnel, solidify the high-level design, work with ITIOD to configure environments, acquire and stand up various tools needed by the developers, and plan a high-level project roadmap with key milestones laid out for the duration of the project.

As this effort will require establishing a new development and production environments in the Azure Cloud, the contractor shall coordinate with PBGC-ITIOD teams to establish the appropriate environments to develop and implement T-PIMS. ITIOD will be responsible for providing all environments, however the Contractor will be responsible for building out designs in development and test environments. The Contractor will carefully identify the necessary Microsoft components needed and in what quantities to allow ITIOD sufficient time to complete the environmental setup. In addition, coordination with ITIOD as it relates to connectivity back to PBGC will be essential. This work will be included in a project-definition phase (e.g. Sprint 0 or early Sprint Planning) of the work plan.

The Contractor will work with PRAD to analyze the list of products and services required for this effort, and support PBGC in its procurement. A preliminary list of tools is provided in Attachment 9-E– PBGC T-PIMS 3rd Party Vendors . Working with PRAD, the Contractor shall validate the list is accurate and complete, and for each item identify how many licenses are needed and an associated timeline. The Contractor shall work with PBGC to obtain any approvals and provide information necessary for procurement. Those that are needed to commence work shall be obtained during Sprint 0.

There will be high-level planning activities related to the user stories and requirements definition at the start of Sprint 0. A High-level scope for a MVP is to be articulated in the first months, so that the government can track and manage the engagement throughout the contract.

Sprint 0 is to be completed within six (6) months of task order award. PBGC recommends Sprint 0 includes the activities identified in the table below.

1. Kickoff Meeting

· Agile-Scrum Delivery approach presentation

· Team Structure (Roles & Responsibilities

2. Product Delivery Management Planning

· Review ITSLCM governance requirements

· Create plan for P3M - communication, budget tracking and risk and other artifacts.

· Draft the Executive Level Report

3. Product Vision and Stakeholder Dependency Planning

· Initial Design document

· Network topology diagram

· UI Guidelines document

· Solution Architecture

· Functional and Non-functional Requirements

· Cybersecurity and Privacy Dependencies

· Tools and Infrastructure Dependencies

· Change Management Dependencies

· Enterprise Architecture Dependencies

· Work with PRAD in Sprint 0 in defining and conducting PRAD code reviews during the development effort

· Validate 3rd party vendor list, determine licensing needs and timelines, and work with PBGC on imminent procurements

4. Initial Product Backlog and Delivery Roadmap

· Initial Delivery Roadmap

· Document known Risks and Dependencies

· Story Estimation

· Initial Product Delivery Roadmap

· Technical Risks and Mitigation Plan

5. Delivery Team Readiness

· Sprint Cadence

· Scrum Schedule

· Sprint Planning Schedule

· Sprint Review Schedule

· Retrospective Schedule

· Team working agreement

· Definition of Ready (DoR)

· Definition of Done (DoD)

· Scrum Colocation Room

· Engineering Standards

6. Development Readiness

· Initial sample Data

· Complete Initial Solution Design

· Local Developer Environment setup

· Code Repository Setup

· Setup Automated Testing Environment

· Setup UAT/Integration Test Environment

· Setup Continuous Integration Pipeline

· Setup Automated Deploy Pipeline

· Initial Sample Data

· Develop Sample Functionality

· Test Sample Functionality

· Fix and Verify Bugs in Sample Functionality

· Document Sample Functionality

7. Sprint Zero (0) Review

Table 3: PBGC Recommended Activities and Deliverables for Sprint Zero (0)

2.3.5.2 Continuous Updating of Development Cloud Infrastructure It is not anticipated that infrastructure development, including obtaining all tools needed, will be completed in Sprint 0. Concurrent to Sprint 1 and beyond, the Contractor shall continue to identify tools and support the TRB and PBGC processes (see 2.3.1 above) , as well as continuously refine the cloud architecture to enable successful completion of T-PIMS MVP. Any components that would require acquisition by ITIOD, must be identified and requested at least 2-3 months in advance.

2.3.5.2 Sprint 1 and Beyond

It is expected that Sprint 1 will start approximately three (3) months after the contract start date. Thus, the team should prioritize the first 3 months to setup components needed to begin Sprint 1, at a minimum. The remaining 3 months of Sprint 0 can continue to setup components for beyond Sprint 1. It is recommended that the application team run three-week sprints; however, the Contractor may propose another length in their response. The product delivery roadmap and release train report shall be kept up to date.

2.3.6 Transition Timeframes

It is anticipated that onboarding for this contract may take up to two (2) months. It is expected that this will occur as part of Sprint 0; however, the contractor may detail another plan in their response.

Towards the end of the TO, it is anticipated that another contract will be stood up for OmE, and that T-PIMS will be run in parallel to legacy SE PIMS for one year. The TO1 team will be responsible for knowledge sharing with the OmE TO team to prepare them for taking over production access of the new system.

2.4 Training

Training for this effort will include perspectives for the Agile development effort itself and for user and support training of the new solution.

2.4.1 Agile Training

The Federal Product Owner and Federal Product Manager are typically Scrum Alliance Certified. The contractor should be prepared to deliver an introductory briefing to the entire product team on their specific Agile methodologies and approach to the modernization effort. This should include Product Team members’ roles and responsibilities, resource time commitments, and how they will engage all the stakeholders involved; and, if needed, to ensure other stakeholders and management understand specific Agile progress reporting (i.e. burndown and velocity charts).

2.4.2 T-PIMS Training

For the new solution, all appropriate stakeholders (internal and external to PBGC) will need to be effectively trained to understand, use, administer, and support the new system or changes being implemented. The contractor will provide sufficient training and sufficient training materials to train the internal stakeholders and support them, as they in turn train the external users (train-the-trainer model). Training plans and training will be developed as part of the proposed project plan and approach and should include a description of when training occurs.

2.5 Quality Assurance and User Acceptance 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. The contractor will identify when all the testing activities occur and the approval process for signing off on test results. 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. A Requirements Traceability Matrix (RTM) will be produced. Test results are approved by product owner.

As determined during Sprint 0, time for PRAD code review and feedback must be built into the schedule.

The contractor will support a UAT that is separate, in addition to, sprint testing. The product team should define an agreed to category/classification for Defect Severity (e.g., Critical, Major, Minor, Trivial) so that any defects identified during testing can be properly categorized. The product team should also define an agreed to set of go/no-go criteria that takes existing/remaining defects, if any, into consideration along with other key decision-making criteria.

2.6 End to End Performance Load Testing

The new solution will undergo a managed end-to-end performance load test to make sure there is no degradation during period of high run volumes.

2.7 Third Party Collaboration

A collaborative environment shall be maintained across PBGC contractor teams, including technical teams and business partners, to exchange information, solicit agreement on system-related decisions, testing integration with other systems, and following all security and enterprise architecture guidelines to ensure a seamless, full-service solution to PBGC. This includes supporting FISMA compliance activities across the T-PIMS solution and/or third parties for evidence as part of continuous monitoring.

The Contractor may also need to collaborate with parties outside of PBGC when setting up APIs for T-PIMS, and will be responsible for maintaining a working relationship with needed entities.

2.8 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, notes and other documents as recommended by internal procedures and in accordance with standard industry best practices. Any documentation edited or produced for this task order will be quality reviewed to ensure they are accurate both from a technical perspective but also grammar, spelling and formatting.

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. These will be sourced from the IDIQ staffing matrix as 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

Performance Standards for the IDIQ are found in Attachment 8. The table below indicates which Performance Standards in the IDIQ will be invoked for this TOR 1 PWS. For the full description of the standards, and how they are monitored, please refer to Attachment 8.