ONRR_IT_MODERNIZATION_PWS_3_4_DRAFT_for_Industry_Comment_02052025_4.pdf

RFI# DOIDFBO250003 Amendment 3 – ONRR IT Mod Contractor Integrator Support Services for ONRR – DRAFT PWS for Industry comment

IT Modernization 5

Contractor Integrator 6

Support Services for the 7

Office of Natural Resource 8

Revenue (ONRR) 9

PERFORMANCE WORK STATEMENT (PWS) 11

Proposed Contract Vehicle Type: Single Award, Indefinite Delivery Indefinite 13

Quantity (IDIQ) 14

VERSION 3.4 [DRAFT FOR INDUSTRY COMMENT] 16

February 05, 2025 17

Contents 1

1 Introduction ........................................................................................................................................................................ 4 2 2 ONRR and IT Modernization Overview ............................................................................................................................... 4 3

2.1 Background .................................................................................................................................................................. 4 4

2.2 MRMSS (2000-Present) ................................................................................................................................................ 5 5

2.3 Business Process Re-engineering (2017-2019) ............................................................................................................ 7 6

2.4 IT Mod Vision & Objectives .......................................................................................................................................... 8 7

2.5 IT Mod Efforts (2021 – Present) ................................................................................................................................... 9 8

2.6 IT Mod Goal Moving Forward .................................................................................................................................... 12 9

3 Description of Services ...................................................................................................................................................... 13 10

3.1 ONRR Product Owner, Product Manager, Project Manager ...................................................................................... 14 11

3.1.1 Product Owner ................................................................................................................................................ 14 12

3.1.2 Product Management/Manager ...................................................................................................................... 14 13

3.1.3 Project Manager (PM) ..................................................................................................................................... 14 14

3.2 Program and Project Management Support .............................................................................................................. 14 15

3.3 Development Support ................................................................................................................................................ 15 16

3.3.1 Product Vision. ................................................................................................................................................. 16 17

3.3.2 Validation and Planning. .................................................................................................................................. 16 18

3.3.2.1 Deliverables and Objectives. ....................................................................................................................... 16 19

3.3.2.1.1 Product Backlog. .................................................................................................................................... 16 20

3.3.2.1.2 Project Kickoff / Initiation Activities & Continued Onboarding of Remaining Personnel ....................... 16 21

3.3.2.1.3 Product Roadmap and Release Plan. ..................................................................................................... 17 22

3.3.2.1.4 Styles Guide. .......................................................................................................................................... 17 23

3.3.2.1.5 Coding Standards Guide. ........................................................................................................................ 17 24

3.3.2.2 Initial Design & Architecture Design Artifacts. ............................................................................................ 17 25

3.3.3 Product Backlog Refinement and Sprint Planning. .......................................................................................... 18 26

3.3.3.1 Product Backlog. .......................................................................................................................................... 18 27

3.3.3.2 Refinement Approach or Methodology Document. .................................................................................... 18 28

3.3.3.3 Sprint Planning. ........................................................................................................................................... 18 29

3.3.3.4 Work Categorization. ................................................................................................................................... 19 30

3.3.3.5 Operations & Maintenance: ........................................................................................................................ 19 31

3.3.3.6 Development: .............................................................................................................................................. 19 32

3.3.3.6.1 User Stories. ........................................................................................................................................... 19 33

3.3.3.6.2 Enhancements........................................................................................................................................ 19 34

3.3.3.6.3 Remediation. .......................................................................................................................................... 19 35

3.3.4 Development Cycle. ......................................................................................................................................... 20 36

3.3.4.1 Sprints ......................................................................................................................................................... 20 37

3.3.4.2 Project Plan Integrated Master Schedule by Sprint ..................................................................................... 20 38

3.3.4.3 Sprint Testing ............................................................................................................................................... 20 1

3.3.4.4 Sprint Review ............................................................................................................................................... 21 2

3.3.4.5 Sprint Retrospective .................................................................................................................................... 21 3

3.3.4.6 Sprint Documentation Requirement ........................................................................................................... 21 4

3.3.4.7 Sprint Governance ....................................................................................................................................... 21 5

3.3.4.8 Story Points ................................................................................................................................................. 21 6

3.3.4.9 Sprint Report ............................................................................................................................................... 22 7

3.3.5 Product Release. .............................................................................................................................................. 22 8

3.3.6 System Deployment & Fielding Activities ........................................................................................................ 23 9

3.3.6.1 Fielding/deploying System Schedule Requirement ..................................................................................... 23 10

3.3.7 Other Development Support ........................................................................................................................... 23 11

3.3.7.1 Communication Requirements .................................................................................................................... 23 12

3.3.7.2 Development Approach Requirement......................................................................................................... 23 13

3.3.7.3 Off-Site Development Requirement ............................................................................................................ 23 14

3.3.7.4 Reporting and Analytics Requirement ......................................................................................................... 24 15

3.4 Operation & Maintenance Support ........................................................................................................................... 24 16

3.4.1 Software Maintenance .................................................................................................................................... 24 17

3.4.2 Operations support to O&M ............................................................................................................................ 26 18

3.4.3 Other O&M Support. ....................................................................................................................................... 29 19

3.4.3.1 Other Perfective Maintenance. ................................................................................................................... 29 20

3.4.3.2 Government Change Requests. ................................................................................................................... 29 21

3.5 Platform(s) Administration & Support ....................................................................................................................... 30 22

3.5.1 ONRR IT Modernization Platform(s) ................................................................................................................ 30 23

3.5.2 Platform(s) Managed Services ......................................................................................................................... 30 24

3.6 Training Support ......................................................................................................................................................... 31 25

3.7 Documentation Support ............................................................................................................................................ 31 26

3.8 Security and Baseline Compliance ............................................................................................................................. 32 27

4 Earned Value Management ............................................................................................................................................... 32 28

4.1 Integrated Baseline Review (IBR): .............................................................................................................................. 32 29

4.2 Performance Measurement Baseline (PMB):............................................................................................................. 33 30

4.3 Monthly EVMS Reports: ............................................................................................................................................. 33 31

4.4 Risk Management Integration: ................................................................................................................................... 33 32

4.5 Compliance Plan: ....................................................................................................................................................... 33 33

5 Reports, Data, and Other Deliverables .............................................................................................................................. 33 34

5.1 Deliverable Instructions. ............................................................................................................................................ 35 35

5.2 Release Documentation Requirements. .................................................................................................................... 36 36

6 Quality Assurance Surveillance Plan (QASP). .................................................................................................................... 37 37 7 Agile Management Development Plan ............................................................................................................................. 39 38

1 Introduction 1

This performance work statement (PWS) specifies critical support services required by the U.S. 2 Department of the Interior (DOI), Office of Natural Resource Revenue (ONRR) to partner with a 3 contractor service provider (SP) to successfully fulfill its Information Technology Modernization (IT 4 Mod) vision and objectives. Task orders issued under this Indefinite Delivery, Indefinite Quantity 5

(IDIQ) contract will be relevant to ONRR’s IT Mod efforts and all software development lifecycle 6 functions necessary for the development, enhancement, operations and maintenance, user 7 support, and systems/cloud administrative and operations support of requested services. In 8 addition to new and future IT Mod services/solutions, the SP will immediately take over and 9 sustain the operations and maintenance (O&M) of partially implemented modules. The O&M work 10 will be issued as the first day task order under the IDIQ. 11

Note: References to Department, Departmental, Management refers to DOI and ONRR. 13

2 ONRR and IT Modernization Overview 14

2.1 Background 15

The U.S. Department of the Interior (DOI), Office of Natural Resources Revenue (ONRR) is 16 responsible for the management of revenues owed for the development of the United States’ 17 energy and natural resources on the Outer Continental Shelf and onshore Federal and Indian lands. 18

ONRR’s primary mission is to provide for the efficient, timely, and accurate collection and 19 disbursement of all royalty payments, rentals, bonuses, fines, penalties, assessments, and other 20 revenue due to the Federal Government, Indian Tribes, States, and the American people from 21 these lands. This effort is one of the Federal Government’s greatest sources of non-tax revenues. 22 In support of its mission, ONRR performs revenue collection and disbursement; distribution; 23 collection and validation of production and royalty reports; compliance and enforcement; and 24 workload management of all case types defined by ONRR to include data validation cases, 25 compliance cases, enforcement cases, and appeals cases. 26

Through the completion of a Business Process Re-engineering (BPR) exercise in the 2017-2020 27 timeframe, ONRR analyzed and documented the current system and process limitations and 28 researched industry solutions that could be considered. As a result of this BPR exercise and 29 recommended next steps, ONRR initiated its ONRR Modernization (IT and Operational) effort to 30 ensure that it is capable of continually fulfilling its core mission efficiently for the benefit of all 31

Americans. 32

In 2021, with these BRP results and recommendations in mind, ONRR kicked off its IT 33

Modernization (IT Mod) efforts with a primary goal of replacing the Minerals Revenue 34 Management Support System (MRMSS) with new solution(s). Section 2.2 of this document 35 provides additional information on the MRMSS. The IT Mod initiative aims to improve operational 36 efficiency by implementing industry best practices, streamlining business processes, and 1 eliminating manual tasks. 2

ONRR stated that its high-level goals for IT Mod are to: 3

• Modernize ONRR systems to simplify industry interactions with DOI for energy and 4 mineral revenue processes and increase overall compliance. 5

• Modernize ONRR systems to improve the accuracy, efficiency, and timeliness of energy 6 and mineral revenue processes. 7

• Reduce energy and mineral revenue data errors, compliance issues, and the need for 8 enforcement. 9

• Modernize ONRR systems to take advantage of IT Automation efforts such as but not 10 limited to Artificial Intelligence/Machine Learning (AI/ML) and Robotic Process 11

Automation (RPA). 12

To achieve these goals, ONRR must modernize not only the MRMSS but also all ONRR IT systems 13 that support revenue collection and disbursement processes. The next step is to acquire a long-14 term contractor partner (IT Mod Integrator) for critical support in the areas of software 15 development lifecycle functions necessary for the development, enhancement, operations and 16 maintenance, user support, and systems/cloud administrative operations support services. 17

2.2 MRMSS (2000-Present) 19

Since the early 2000’s, ONRR has performed the vast majority of its mission work through the 20 Minerals Revenue Management Support System (MRMSS) and various ONRR stand-alone systems 21 and offline processes. 22

The MRMSS system was deployed to operation in the year 2000. MRMSS is a mixed financial 23 system, which includes the hardware and software that ONRR uses to perform its revenue 24 collection, verification, and disbursement-related duties. Over the years MRMSS has come to rely 25 heavily on major customizations of PeopleSoft, including custom-built accounts payable, accounts 26 receivable, and general ledger modules that were built over a decade ago and are updated as 27 needed. Due to its mission-essential function to collect and disburse revenues, MRMSS is 28 considered a high-value asset as defined by criteria established by the Office of Management and 29 Budget (OMB) the Department of Homeland Security (DSH) under OMB Memorandum M-16-03 30 in October 2015. 31

The current number of users within the MRMSS Community is estimated as: 32

User Type # of Approximate Users ONRR and other government users 1,000 External Users 3,000

The MRMSS is comprised of 3 major mission components including: 1

1) Financial component (MRMSS-Financial) 2

a) The strategic goal of the MRMSS-Financial function is to collect, account for, and disburse 3

Federal and Native American mineral lease revenues to the proper recipients in a timely 4 and accurate manner per applicable laws, regulations, and lease terms, approximately $10 5 billion in annual revenues are processed through the MRMSS. 6

b) MRMSS-Financial accounts for all Feder al and most Native American minerals rents, 7 royalties, bonuses and their distribution/disbursement to the U.S. Treasury, counties, 8 States (States generally receive 50% of the revenues collected in their State), and Native 9

Americans (Native Americans receive 100% of their revenues). 10

c) The MRMSS-Financial also issues bills for late payment or non-payment of royalties and 11 other lease term obligations. Most of the input data for MRMSS-Financial consists of 12 royalty reports and production reports received from industry via an electronic reporting 13 contractor. 14

d) MRMSS-Financial relies on major customizations of PeopleSoft®, and Oracle’s Business 15 Process Management SOA Suite (BPM SOA) utilizing Oracle Business Rule (OBR) engine. 16

MRMSS-Financials PeopleSoft® financials is composed of several modules, including 17 Production, Reference, Royalty, Accounts Receivable, Accounts Payable, Billing, Lease 18

Account Balance, Appeals Tracking System (ATS), General Ledger, Distribution & 19 Disbursement, and Exception Processing. 20

2) Compliance components (MRMSS-Compliance) 21

The compliance functions consist of custom-built tools aimed at assuring that ONRR has collected 22 every dollar due and all required reporting. These tools include basic case management tools 23 (tracking assignments and progress by employee and property), targeting tools, electronic work 24 papers, and other specialized tools for analyzing variances between reported and expected 25 values, and documentation. Compliance activities result in coverage of a significant portion of the 26 royalty revenues paid each year. Many of the components are customized utilizing .Net 27 framework. 28

3) MRMSS Analytical and Report Page (MRMSS-MART) 29

The MRMSS MART provides a repository of historical financial and production information used 30 by ONRR users, Bureau of Land Management (BLM), Bureau of Ocean Energy Management 31 (BOEM), Bureau of Safety and Environmental Enforcement (BSEE), other Federal agencies, State 32 and Tribal entities, and Industry. The MART also provides data-mining tools for ONRR, States and 33

Tribes, other government agencies, and industry to run queries and reports and download the 34 results of their royalty and production data and revenues received and disbursed. 35

Most of the input data for MRMSS consists of reference data received from Federal and Indian 36 land management agencies in various formats (e.g., text files, email, and physical mail), and 37 royalty reports, production reports, and payment information received from industry via an 1 electronic reporting contractor (eCommerce). Initial validation of industry reports occurs in 2 eCommerce and MRMSS; additional validation and compliance actions are performed in offline 3 processes and stand-alone systems such as the Volume Comparison Tool. 4

ONRR believes that it will, over time, become less effective at its core mission if it continues to 5 invest in heavily customized systems that tend to carry increased technical debt over the years. 6 That said in 2024, ONRR successfully migrated MRMSS to the Oracle Cloud Infrastructure (OCI) to 7 address the aging Exa hardware support concerns. Since OCI went live, ONRR has seen significant 8 advantages, performance improvements, and hosting cost benefits. In addition, it appears 9 barriers to eliminating technical debt/customization in the OCI environment may be much more 10 feasible than prior to migration. It is possible some of the new OCI benefits could assist or 11 streamline modernization initiatives if deemed to be the best holistic fit or value to ONRR. 12

In addition, across the government, flexible cloud-based Enterprise Resource Planning systems 13

(ERPs)/Systems are replacing traditional, on-premises ERPs. ONRR recognizes that simply 14 investing in a modern ERP is not enough, however, as many agencies will not see a return on this 15 investment if they do not have a strong integration governance strategy. Adopting a new 16 approach will require new organizational governance as well as modernized business and system 17 processes. 18

2.3 Business Process Re-engineering (2017-2019) 20

The Business Process Re-engineering (BPR) exercise completed during the 2017-2020 timeframe 21 analyzed and documented the current system and process limitations, as well as researched 22 industry solutions that could be considered. 23

The results/reports of BPR*, as outlined below, are the core foundation of ONRR Modernization 24

(IT and Operational) efforts: 25

• Attachment 1 – ONRR BPR As-Is Final Report.pdf 26

• Attachment 2 – ONRR BPR To-Be State Report Final.pdf 27

• Attachment 3 – ONRR BPR Finalization Report.pdf 28

• Attachment 4 – ONRR IT Modernization Functional Modules Final.pdf 29

• Attachment 5 – ONRR IT Modernization Requirements Document Final.pdf 30

• Attachment 6 – ONRR IT Modernization Requirements Final.xlsx 31

*These six attachments represent the summary-level deliverables from BPR efforts. As alluded to 32 in these documents, ONRR received a process map and narrative for each of the As-Is and To-Be 33 state. (NOTE: which may be made available as part of the larger solicitation reading room.) 34

BPR and the resulting artifacts, recommendations, and process maps represent a significant 1 modernization milestone for ONRR. In the context of the system development lifecycle (SDLC), BPR 2 represents a key component of up-front planning and analysis needed to scope the future system. 3

In addition, the work the BPR team has done to date provides a strong platform for ONRR to 4 modernize its processes and system; ONRR’s core mission of mineral revenue collection, 5 verification, enforcement, and reporting is fundamentally dynamic and ever-changing. The 6 successful implementation of a modernized system will not halt this constant change or fully 7 address every BPR recommendation, as several are nontechnical in nature. ONRR can only achieve 8 lasting success by harnessing a spirit of continuous improvement. 9

Please note that while these documents are slightly dated, ONRR believes they remain a solid 10 foundation of ONRR Modernization efforts (IT and Operational) and commits to continually 11 evaluate, update, and prioritize this foundational information to help set priorities and objectives. 12 Moving forward, an important part of the process and partnership will require ONRR and 13

Integrator(s) to discover/revalidate with Subject Matter Experts (SME’s) and Product Teams (which 14 may be comprised of federal and contract employees) for accuracy and validity prior to pursuing 15 operational changes and/or product development. Not all requirements/recommendations will be 16 technical in nature and may fall outside the scope of IT Modernization 17

2.4 IT Mod Vision & Objectives 19

As previously noted, with the current state of MRMSS, BPR results and recommendations, and IT 20 Modernization Goals, ONRR recognizes without further proactive action, the current MRMSS state 21 poses the following challenges: 22

• Applications are complex and difficult to maintain. Many of the applications are highly 23 customized due to regulations, necessary tasks or business process, and incremental 24 enhancements that have occurred since the inception of the system. ONRR conducted a 25 business process review to revise its processes. 26

• ONRR has an outdated user interface for external and internal users. Users expect and 27 should experience a modern computing experience. With the introduction of new 28 technologies, ONRR can enhance the user experience with a focus on a human centric 29 design. 30

• There is a lack of real-time updates to the system. Nightly batch processing results in a 31 lack of real-time data updates within the system. Such real-time updates will require both 32 technical, business process, and requirement changes. 33

• There is a lack of integration with other DOI systems. Seamless integration with other DOI 34 systems (e.g. Mineral and Land Records System (MLRS), Technical Information 35 Management System (TIMS), Trust Asset and Accounting Management System (TAAMS), 36

Automated Fluid Minerals Support System (AFMSS), etc.) is needed to improve how data 37 can be used, reduce data errors and submission rejections, and streamline processes. 38

As a result, ONRR initiated its IT modernization effort to implement alternative technologies to 1 ensure that it is capable of continually fulfilling its core mission efficiently for the benefit of all 2 Americans. It is expected this will result in the following: 3

1) Reduced technical complexity of business rules, business processes, and data. 4

2) Reduced costs to the agency for equipment, development, business operations, 5 information technology, and staffing. 6

3) Reduced customization of technical solutions/products. 7

4) Increased Operations & Maintenance capabilities and flexibilities related to functional 8 modules. 9

5) Reduced burden to energy and extractive industry participants (mining, oil, and gas 10 sectors), most importantly the reporting community and revenue payors. 11

6) Clarified and streamlined data needed for ONRR and for sharing with other Department 12 of Interior (DOI) and external entities and stakeholders. 13

7) Improved business process flow significantly reduced customized coding and maximized 14 delivered software. 15

8) Gained advantages from automation to reduce or eliminate duplication and errors, 16 unnecessary business functions, external stand-alone databases, and the manual 17 manipulation of data external to the system of record. 18

9) Implementation of commercial software to eliminate custom coding in favor of a 19 simplified system with a low-code platform to address the to-be functional modules. 20

2.5 IT Mod Efforts (2021 – Present) 22

Building upon the BPR Module recommendation, a vision for using the best-in-class platform(s) to 23 form the ONRR product(s) foundation was pursued. An ONRR Product overlay to BPR Modules is 24 depicted in Figure 1, with each ONRR Product being built on best-in-class platforms/applications 25 to sustain the foundation of ONRRs future modernized state: 26

Figure 1 - ONRR Product overlay to BPR Modules 27

Over the last 3 years (12/2021-Present), ONRR has conducted several stand-alone procurements 3 to select system development partners and best-in-class software tools/platforms to deliver 4 module/product specific capabilities. The results of these efforts to date have been three 5 different/independent contract/contractor partners (one per ONRR Product) building and 6 integrating simultaneously on three separate platforms utilizing the Scrum/SAFe framework with 7 ONRR acting as the main ‘integrator’. 8

A brief overview of the Product progress to date includes: 9

• ONRR Connect 10 o Salesforce: The Salesforce Software as a Service (SaaS) tools were selected for 11 their robust Customer Relationship Management (CRM) capabilities, Self Service 12

Portal for industry/community access, and the operational/mission interaction 13 between the two. 14

Active development since 2022 leading to successful deployments of CRM 15 initial operating capability/minimal viable product (MVP) (September 16

2023) and many subsequent value features releases (R1.1 November 2023, 17 Release 1.2 December 2023, Release1.4 February 2024 etc.). 18

Developed and supported to date by Accenture Federal Services, LLC 19

• ONRR DASH (Data Analytics Solutions Hub) 20 o Snowflake, Power BI, Qlik, and Azure Data Lake: The Snowflake application, 1 coupled with Azure Data Lake and Power BI tool, was selected for the DASH 2 requirements. 3

Active development since 2021, leading to successful deployment in 4 September 2024 of initial operational capabilities. 5

Developed and supported to date by CGI Federal Inc. 6

• OFMS (ONRR’s Financial Management System) 7 o SAP S4HANA: After studying the industry, ONRR intended to integrate/build upon 8 the DOI Financial Business Management System (FBMS), which is a configured 9 version of SAP S4HANA. The financial processes in FBMS are comprehensive and 10 encompass broad business functions, both financial and mission, across DOI, e.g., 11 disbursements through the Treasury, federally compliant fund management 12 capabilities, and many bureaus' mission-specific capabilities. Some of these 13 features presented attractive foundational architecture for ONRR’s OFMS vision, 14 leading to the initial partnership/exploration. That said, ONRR-specific 15 requirements not currently configured or operational in FBMS would require 16 shared service configuration and customization unique to ONRR. In the end, ONRR 17 did not implement FBMS but did explore prototypes of S4HANA. These prototypes 18 showed great promise in S4HANA ability, meeting ONRR’s OFMS requirements. 19

Active prototyping and exploration since 2023. No true development. 20

Support to date by CACI Inc.-Federal and DOI Business Integration Office 21

(BIO) 22

To date (October 2024), ONRR has only partially implemented some of the recommended 23 modules. Table 1 below further outlines the status of each: 24

Table 1 - Functional Module Implementation Status as of October 2024 25

Functional Module Implementation Status as of October 2024

# Module Description Partial Not Started

1. Customer Relationship Management Organizes stakeholder contact and relationship information and tracks interactions with them

X

2. Self-Service Portal Provides a digital interface for ONRR and its stakeholders to access and submit information

3. Mission Inquiry Management Funnels the majority of ONRR inquires to a centralized, tiered location for resolution

Functional Module Implementation Status as of October 2024

# Module Description Partial Not Started

4. Financial Management Facilitates the accounting, verification, disbursement, and reporting of mineral resource revenues

Prototypes X

5. Case Management Organizes relevant information collected and streamlines workflows from initiation to resolution

6. Data Management Supports all ONRR processes by providing a single consistent and accepted source for all data items

7. Business Intelligence Enables reporting and analytics across ONRR data to generate meaningful business insights.

8. Risk Analytics Applies data science tools to quantitatively identify potential compliance cases.

In addition to these IT Mod activities, ONRR successfully migrated its MRMSS operations to the 2

Oracle Cloud Infrastructure (OCI) and upgraded to the latest PeopleSoft Update Manager and 3 People Tools (PUM 50 /PT8.6) versions. 4

2.6 IT Mod Goal Moving Forward 6

Application development (often called software development) is the process of developing 7 software products that directly meet a need of the customer's business responsibilities/mission. 8

The process can include a single mobile application, a stand-alone application/product, an ERP 9 system, and everything in between. While there isn’t a single set definition, most agree on the 10 common best practice activities of requirements gathering, design, implementation, testing, and 11 maintenance performed using methodologies/approaches such as Agile, Scrum, Waterfall, etc. 12

The objective of ONRR's future requirement will be to obtain a contractor as a single IT Mod 13 Integrator/Service Provider (SP) to support full systems development lifecycle services for ONRR 14

IT Modernization that will include, at a minimum: 15

1) Immediately take over and sustain the Operations and Maintenance (O&M) of partially 16 implemented modules. 17

2) Complete Application Development and implementation of modernized solution(s). 18

3) Maintain the implemented solution(s) 19

It shall be noted while ONRR believes it has selected and partially implemented best-in-class 20 platforms that can sustain the full vision of modernization, ONRR is open to further discussion and 21 recommendations for best-value solutions (i.e. not utilizing Connect/DASH current platforms, 22 partially using the existing platforms, and or single ERPs) that could potentially lead to better 1 holistic value to the ONRR mission and IT Modernization goals. 2

3 Description of Services 3

In order for the Service Provided (SP) to successfully partner with ONRR in fulfilling its Information 4 Technology Modernization (IT Mod) Vision & Objectives the SP will be expected to perform 5 services across all software development lifecycle functions necessary for the development, 6 enhancement, operations and maintenance, user support, and systems/cloud administrative & 7 operations support of such services. Additionally, in support of the IT MOD effort, the SP will 8 immediately take over and sustain the Operations and Maintenance (O&M) of partially 9 implemented (ONRR Connect & DASH) modules through an initial first day task order. 10

The primary SP areas of support services under this IT MOD effort are: 11

1. Program and Project Management Support 12

2. Development Support 13

3. Operation & Maintenance Support 14

4. Platform(s) Administration & Support 15

5. Training Support 16

6. Documentation Support 17

7. Security and Baseline Compliance Support 18

The SP shall provide Software Development and Operations and Maintenance (O&M) services. All 19 released parts of a given application will be supported concurrently with active development and 20 in accordance with the terms of the contract and resulting task order. The SP must ensure 21 sufficient resources are available to deliver corrective, preventive, and adaptive maintenance 22 concurrently and without degrading development team velocity. This includes the ability to 23 maintain O&M categorized releases of the application independent of application development. 24 While the application is under active development, all O&M perfective maintenance is suspended 25 and instead, carried over to the active development backlog for prioritization and development 26 under that process. 27

The SP will be required to work cooperatively with other contractors/entities performing their own 29 projects and initiatives that may or may not have impact on this contract (e.g., concurrent 30 development of applications with interface dependencies). If the situation arises where 31 deliverables may be impacted, it is the responsibility of the service provider to bring the situations 32 to the attention of the COR and the CO immediately. Contractor advisory and assistance support 33 may be used for technical, engineering, and programmatic support and are required to sign and 34 submit under their contract(s) non-disclosure agreements in accordance with FAR 9.505-4(b). 35

Additionally, all contractor personnel assigned under this contact shall be required to sign a non-1 disclosure agreement as detailed in the terms and conditions of this requirement. 2

3.1 ONRR Product Owner, Product Manager, Project Manager 4

3.1.1 Product Owner 5

The Product Owner (PO) is is the ‘voice of the customer’ on the AgileTeam, representing the needs 6 of end-users and the business. An effective PO manages relationships, synthesizes data, maintains 7 business alignment in the team backlog, and communicates with various stakeholders. Their goal is 8 to obtain insights and deliver results quickly. Together with Product Management, they ensure that 9 product strategy and implementation remain connected across teams. (Scaled Agile, Inc) 10

3.1.2 Product Management/Manager 11

Product Management is the function responsible for defining desirable, viable, feasible, and 12 sustainable solutions that meet customer needs. They lead product innovation across the ART. 13 Product Managers usually fulfill this function. Within ONRR this position is typically filled by ITGB 14 with support from Mission Program Managers. They often have mixed backgrounds in the 15 organization’s business, emerging technologies, product design, and market research. (Scaled 16

Agile, Inc) 17

3.1.3 Project Manager (PM) 20

The Project Manager provides the vision and roadmap to the overall scope of Modernization 21 effort. The PM also tracks risks, manages the schedule, and assist with required and routine PM 22 activities to make the program successful from a management perspective. 23

3.2 Program and Project Management Support 25

The SP shall be responsible for Program and Project Management support activities for their 26 technical, functional and administrative staff as well as in support of all activities contributing to 27 successful task order performance. At a minimum, these tasks may include: 28

1) Developing and maintaining a critical milestone schedule that documents the most 29 important schedule issues for management attention. 30

2) Developing and maintaining and end to end Integrated Project Plan and Integrated Master 31 Schedule 32

3) Providing recommendations to address any schedule or cost variance associated with 33 project plans. 34

4) Support management requirements for OMB major system acquisitions (e.g. EVMS in 35 accordance with OMB Circular A-11 Part 7 and FAR Part 34). 36

5) Support the COR in analysis, classification, and prioritization of reported items. 1

6) Support issues management and tracking. 2

7) Supporting change management and risk management activities. 3

8) Coordinating and planning meetings, where appropriate, including program management 4 reviews, and walk-through/design reviews. 5

9) Providing project progress reports and other management documents as the specified in 6 project deliverables and as required by the Government PM/COR. 7

10) Ensuring the integration and synergy between interconnecting systems and provide 8 recommendations for simplification of interconnections as they arise. 9

11) Facilitate adherence to all departmental policy. 10

12) Provide monthly and weekly status reporting in a format agreed upon by the COR. 11

13) Report on ticket reviews, analysis, solution design and time estimating as request by COR. 12

14) Coordinate with the Government regarding system outages and hardware/firmware or 13 interface issues that come to the SPs attention. 14

15) Create and maintain development information site(s) (e.g., MS Teams, MS OneDrive, or MS 15 SharePoint Site); develop, design, and create page content. Government PM/COR must 16 approve site design and content before publication. 17

3.3 Development Support 19

The SP shall analyze, design, develop, configure, test, and release business applications by applying 20 an iterative process utilizing a form of Agile and/or Hybrid centered methodology (greater 21 emphasis on Agile), which promotes short incremental time-boxed development and a frequent 22 release capability to the maximum extent practicable. This development approach aims to reduce 23 risk, cost, and schedule and improve product quality through increased emphasis on 24 communication, customer collaboration, faster delivery of working code, and an ability to respond 25 and adapt to change. As a general rule, this requires breaking up software development into 26 smaller and manageable iterations (The Sprints) each of which shall produce defined functionality. 27 The process shall include a communication and collaboration approach which enhances the 28 probability of successfully delivering an application that meets end user objectives. The process 29 shall directly involve product owner(s) and/or end user collaboration to a high degree into the 30 sprint development cycles to ensure: 31

(1) Delivered software produces immediate customer satisfaction, 32

(2) Delivered software is usable and does not contain unusable or unwanted features 33 and 34

(3) Process provides maximum capability to respond to change with minimal impact on 1 development objectives. For more information on government agile initiatives: 2 https://techfarhub.usds.gov/get-started/. 3

3.3.1 Product Vision. 5

All task orders issued under the resulting IDIQ will include a product vision statement. The product 6 vision may come in various forms depending upon the size and complexity of each module and 7 the project planning activities which were conducted prior to requesting development support. 8

3.3.2 Validation and Planning. 10

The SP shall propose scope and duration for an initial period of validation and planning. This effort 11 aims to improve outcomes by placing the project in a position to better plan and execute 12 development activities and improve our ability to communicate and manage project expectations. 13

3.3.2.1 Deliverables and Objectives. 14

The following deliverables and objectives must be accomplished within the specified period 15 established at the task order level. 16

3.3.2.1.1 Product Backlog. 17

The SP Team shall decompose available Government-furnished business requirements documents 18 and deliver the initial Product Backlog using themes, epics, and/or large user stories. This effort is 19 not necessarily intended to create actionable decomposed user stories for development. This level 20 of decomposition will be handled within the agile development process; however, the Product 21

Backlog shall be minimally sufficient to roughly cast the customer/product owner's full vision to 22 estimate and produce a Product Roadmap and a Release Plan to be delivered at the end of the 23

Validation and Planning period. This effort will involve direct interaction with the Product Owner 24 (PO) / Product Manager and user community as needed to successfully complete the objectives 25 of this work. This effort may include meetings, workshops, and other collaborative exercises 26 required for successfully completing the activity as outlined in the SP’s proposal. Excessive or 27 unproductive meetings which involve a rehashing of reasonably well-defined requirements is not 28 the objective. This effort shall also produce an approved Sprint Backlog for the first Sprint. 29

Acceptance criteria and/or definition of done is required for the first Sprint only. This level of story 30 definition is not required for subsequent Sprints and instead is completed as part of the backlog 31 grooming and Sprint planning process. 32

3.3.2.1.2 Project Kickoff / Initiation Activities & Continued Onboarding of Remaining Personnel 33

The SP shall use this time to kick off the project with ONRR to establish clear roles and expectations 34 within the total team. 35

In addition, the SP shall provide (host) formal Agile Development training with both ONRR (e.g., 36

Platform and Project PMs, POs, Key Business Leads, Key SMEs) and SP key members (e.g. PM, 37 https://techfarhub.usds.gov/get-started/

Scrum Master, Lead Developer(s)) to be held with a professional provider for this type of training. 1

Training may be customized for the situation. The training is expected to baseline the 2 understanding of roles and responsibilities within the agile (hybrid) process moving forward with 3 the objective of facilitating an effective team. This training is not to be conducted during the kick-4 off meeting. This training must occur prior to the actual start of the agile activities or sprint. 5

This time should also be used to continue to complete remaining personnel onboarding and to 6 work on any other dependencies or initial activities which may prevent the success of Sprint One 7

(1) including initial purchasing and implementation of development tools, platforms, and 8 infrastructure as specified at the task order level. 9

3.3.2.1.3 Product Roadmap and Release Plan. 10

The SP shall create and maintain a Product Roadmap and Release Plan for each requirement and 11 is responsible for keeping it current with ongoing development and constantly changing 12 requirements. The documents shall logically group functionality into potential major release 13 points and estimate the potential schedule of those releases using current system understanding 14 of estimates and assumptions. Completed reviews and updates of these documents shall be 15 delivered no less than quarterly, or at the request of the PM/COR, and shall represent the evolving 16 understanding of the developed system. The SP may combine these documents or use other 17 formats as proposed in the SP methodology without changing the intent of these documents. 18

3.3.2.1.4 Styles Guide. 19

The SP shall draft a Styles Guide. The ONRR is a highly decentralized organization with diverse 20 stakeholder groups that will be assisting the PO in delivering functionality that meets the 21 requirements. To ensure the development process begins with and is able to maintain consistent 22 user expectations, the SP shall create a styles guide document. This document will provide the 23 user's insight as to how the screens will look and work, such as buttons, error messages, online 24 help, search features, etc. This document will facilitate clear up-front expectations in the 25 development process so that developers will have a better understanding of what the users want 26 and minimize future change requests. 27

3.3.2.1.5 Coding Standards Guide. 28

In addition to a styles guide, the SP shall develop a coding standard guide for developers to provide 29 consistency in development. 30

3.3.2.2 Initial Design & Architecture Design Artifacts. 31

The SP shall create initial system and architecture design artifacts and provide an initial design 32 review to the ONRR for approval. 33

3.3.3 Product Backlog Refinement and Sprint Planning. 1

3.3.3.1 Product Backlog. 2

The SP shall effectively communicate with the Integrated Product Team (IPT) to gain a complete 3 understanding of the product vision and to validate the current business requirements in the 4 creation of agile software development artifacts. The SP shall maintain the product backlog 5 containing functional descriptions (e.g., Epics, Thems, “user stories”) feeding from the product 6 vision and product roadmap in direct collaboration with the PO and stakeholders. The backlog shall 7 contain the prioritized list (prioritization the responsibility of the ONRR Product Manager or 8 designee) of features that describe the functionality of the system. The backlog will be used to 9 track and estimate the development effort. Estimations shall include considerations of complexity, 10 risk, implementation, deployment, and interdependencies. While working the backlog is a team / 11 integrated product team (IPT) effort, the ONRR Product Owner shall have final approval authority 12 over all backlog content and prioritization. This backlog will feed into the iterative development 13 cycle and act as a living document used to track the status of all identified functionality delivered 14 or to be delivered. This deliverable shall be approved by the IPT prior to entering into the first 15 development cycle. It is also expected that the process of creating and updating the product or 16 feature backlog is continuous and should not impact the transition between and the execution of 17 development cycles. This backlog shall be made available to the ONRR PM and PO for review in 18 real time. 19

3.3.3.2 Refinement Approach or Methodology Document. 20

The SP shall propose the specific approach or methodology for creating and maintaining a 21 successful backlog with ONRR. The approach shall, at a minimum, address backlog creation, story 22 decomposition, feature identification, and product team communication, feature use case or story 23 point effort estimation, prioritization, quality assurance, testing, user acceptance, and 24 establishment/commitment of iterative functionality (working code); within the limitations 25…