B08_SOL_Attach_A_PWS_A-MSP.pdf

MISSION SERVICES

PLATFORM

INDEFINITE DELIVERY

INDEFINITE QUANTITY

(IDIQ) PERFORMANCE

WORK STATEMENT

(PWS)

June 29, 2023

1. GENERAL INFORMATION.

1.1. Scope. This Performance Work Statement (PWS) requires a mission-driven unified Mission Services Platform solution to include development and operations and maintenance (O&M) support services for the Bureau of Land Management (BLM). The Service Provider (SP) shall deliver solution services that are agile, flexible, scalable, supporting the Bureau’s current componentry and possible future componentry expansion. The SP shall provide application development with operational and maintenance support of released systems and facilitate compliance with federal regulations (OMB, DOI, BLM, etc.). This work shall include software development, integration, test, maintenance, audit support, system analysis, business analysis, impact analysis, documentation, reports, training, and progress monitoring using reporting procedures and measures of performance in accordance with best practices of the IT industry.

The goal is to implement applications utilizing Agile processes that achieve results through continuous capability enhancements, minimal downtime, prompt response to emerging needs, demonstrated reliability, and optimized performance with resource utilization minimized. All services under this PWS are non-personal and not inherently governmental in nature.

1.2. Background. The BLM’s Directorate of Information Technology (HQ500) has a vision to establish a commitment to excellence in delivering quality IT services and systems to its customers the first time, every time. HQ500 supports the BLM's mission by providing collaborative technical leadership, guidance, application development, engineering, and enterprise administration of BLM IT infrastructure to the whole of BLM inclusive of state offices, field offices, national centers, interagency partnerships, and the Washington Office. IT Directorate emphasizes the application of IT to meet specific business processes to improve public service, enhance employee productivity, and improve data quality. The IT Directorate’s intent and commitment are to support the BLM with superior information systems and processes that help serve customers better.

Supporting BLM’s interest in improving its business operations and enhancing its users’ experience through the expansion of new technology-based capabilities, HQ500 has defined a Mission Services Platform architecture to support BLM’s mission. The architecture has been structured around a set of large-scale components, with each component representing a coherent set of capabilities organized to deliver services across the BLM’s lines of businesses. In selecting technologies for its Mission Services Platform, HQ500 will intersect business-level capabilities with potential solutions’ alignment and apply a set of principles to ensure services are continually delivering value to business operations by focusing on delivering differentiating capabilities critical to BLM’s mission.

1.3. Place of Performance. The SP team will be off-site and/or virtual. The SP shall provide its own equipment, software, communications, supplies and other furnishings for their personnel as necessary to perform the contracts that are not otherwise listed under the Government Furnished Property section of this contract.

1.3.1. BLM will provide access to on-site meeting facilities, rooms, and supplies, for meetings, briefings, and other required on-site activities with BLM staff. Program related meetings, briefings, or other activities that are to be at the BLM site must be coordinated at least one (1) business day in advance and must be approved by the Contracting Officer’s Representative (COR). Facility resources are on an as available basis and are shared with the entire HQ.

Availability of meeting space does not relieve the SP from performance of contract requirements.

1.3.2. Core Hours of Operation. The SP will assure that personnel are available during the core hours, Monday-Friday 6:00 a.m. to 6:00 p.m. Mountain Time (MT)f, unless otherwise specified at the order level.

1.4. Federal Holidays. The following Federal Holidays are observed by DIRM which the SP shall take into consideration for coordination purposes. When a Holiday occurs during a weekend, it will be observed either the Friday preceding or the Monday following for Saturday and Sunday, respectively.

o New Year’s Day, January 1st o Martin Luther King’s Birthday, 3rd Monday in January o President’s Day, 3rd Monday in February o Memorial Day, Last Monday in May o Juneteenth National Independence Day, June 19th o Independence Day, July 4th o Labor Day, 1st Monday in September o Columbus Day, 2nd Monday in October o Veteran’s Day, November 11th o Thanksgiving Day, 4th Thursday in November o Christmas Day, December 25th

1.5. Adverse Weather Conditions. During adverse weather conditions, the SP shall continue to provide services that have not been cancelled due to weather. Delayed-reporting or early release (for government employees) in and of itself does not constitute cancellation of requirements or relieve the SP of PWS responsibilities. The SP is responsible to contact the Contracting Officer’s Representative (COR) to see if the planned activity is affected.

1.6. Contract Manager (CM). The SP shall provide point(s) of contact with the authority to deal with matters of contract administration including performance, dispute, negotiation, and other items of contract management.

1.7. Key Personnel. The SP shall identify and appoint the Key Personnel which they deem critical for successful performance of this work. Only those Key Personnel whose resumes are accepted by the Government shall be assigned to perform any task involving key personnel duties.

1.7.1. The firms (SP and sub-contractors, if applicable) key personnel identified in the awarded contract must remain fixed for the duration of the contract unless a change request is submitted in writing to the Contracting Officer (CO) and may be substituted upon authorization by the CO.

During the first 90 calendar days of performance or first deliverable, whichever occurs first, the

SP shall make no substitutions of key personnel, to include subcontractors unless the substitution is necessitated by illness, death, or termination of employment (partnership). A request for change of key personnel, subcontractors, and outside associates or consultants must be made to the CO within 10 business days prior to their departure. After the initial 90-day period, the SP shall submit the information required to the CO at least 5 business days before making any permanent substitutions. SP shall provide a detailed explanation of the circumstances necessitating the proposed substitutions, complete resumes for the proposed substitutes, capabilities or/and any additional information requested by the CO. The proposed substitute(s) shall have comparable qualifications/capabilities to those of the persons (contractors) being replaced. The CO will notify the SP within 5 business days after receipt of all required information of the decision on substitutions. This clause may be modified to reflect any approved changes of key personnel.

1.8. Quality Control. The SP shall provide a Quality Control Plan (QCP). The QCP is the SP internal, routine, and ongoing measure of performance which applies predictable and systematic methods to measure the output and conformance to the PWS requirements. The SP QCP is a living document which may be modified if additional quality control and/or surveillance is/becomes necessary. One copy of the SP’s Quality Control Plan shall be provided to the CO and COR no later than 30 days after contract award. An updated copy must be provided as changes occur. The SP shall provide the updated QCP to the CO/COR within 5 business days following changes. The QCP will include a plan to manage personnel (retention, training, qualifications, proficiency, and certifications).

1.9. Contracting Officer Representative (COR). According to the Inspection of Services Clause, the Government shall evaluate the SP performance under this contract. A COR will be appointed by the CO for monitoring contract performance.

1.10. Service Provider Personnel. The SP shall not employ people for work on this contract who are potential threats to the health, safety, security, general well-being, or operational mission of the installation and its population. The SP personnel who attend meetings, answer Government telephones, or work in situations where their actions could be construed as acts of Government officials shall properly and clearly identify themselves as non-Government/Service Providers.

1.10.1. The SP shall furnish in writing to the CO, and COR the names and phone numbers of all authorized management and supervisory personnel no later than the program pre-performance conference. Provide updates to authorized management as changes are initiated. Included shall be the contract manager, alternate(s) and supervisory personnel.

1.10.2. The SP shall not employ any person who is an employee of the United States Government if the employment of that person would create a conflict of interest, or the appearance of a conflict of interest. The SP shall comply with the Joint Ethics Regulation (JER) regarding the employment of current and or former Government employees.

1.10.3. The Government reserves the right to direct the removal of an SP employee for misconduct or security reasons. This action does not relieve the service provider from total performance of the program tasks specified herein.

1.10.4. Technical Training. In accordance with this PWS and in the performance of work under the task order(s), the SP is required to provide fully trained, personnel to perform the required services.

No direct cost reimbursement will be made by the Government for training or certifying the SP employees. In cases where the Government replaces equipment, systems and software or introduces new equipment, systems and software which are significantly different from those previously supported reimbursement may be considered with the award of a task order. In advance of any training, the SP shall work with the COR to identify the type of training necessary, and the personnel that will be trained. This information will then be provided to the CO for negotiation and modification to the applicable task order(s).

1.10.5. BLM Training. The following training is required to be successfully completed by all SP employees, as applicable to gain access to BLM’s IT accounts and the internal IT network. After initial successful completion, the training is required annually.

1.10.6. SP employees who create, access, or dispose of BLM data or information are required to complete web-based training courses on Records Management, the Freedom of Information Act, and the Privacy Act. This training takes approximately two hours.

1.10.7. SP employees who are given BLM IT accounts, have access to BLM's internal IT network or IT resources are required to complete web-based general IT Security training and web-based role-specific IT Security training for elevated permissions. This training takes approximately ten hours.

1.10.8. SP employees who are given BLM IT accounts, have access to BLM's internal IT network or IT resources may be required to complete a web-based certification of storage of a particular type of data. This certification is required annually and takes approximately 15 minutes.

1.11. Security. The BLM places the utmost importance on IT Security to ensure that assets and information are safeguarded. BLM uses multiple layers of security starting at the Internet gateway down to the individual user's permissions/privileges and their desktop configuration.

The BLM also has a very active IT Security monitoring and analysis program in which systems and users’ activities are logged and analyzed. BLM is also responsible for sensitive information.

The SP will be an integral part of the IT Security at all layers.

1.11.1. Contractor Personnel Security and Suitability Requirements. HTHE SPD-12 Requirements:

1.11.1.1. Performance of this contract requires contractor personnel to have a federal government-issued Personal Identity Verification (PIV) credential before being allowed unsupervised access to a DOI [facility and/or information system]. The COR will be the requesting official and will make arrangements through a DOI Access Card the sponsor for personal identity verification and DOI Access Card issuance.

1.11.1.2. At least two weeks before start of contract performance, the SP must identify all contractor and subcontractor personnel who will require [physical and/or logical] access for performance of work under this contract. Physical Access means routine, unescorted or unmonitored access to nonpublic areas of a federally controlled facility. Logical Access means routine, unsupervised access to a Level 3 or 4 federally controlled information system. The SP must make their personnel available at the place and time specified by the COR or DOI Access Card Sponsor to initiate screening and background investigations. The following forms and inquiries, or their equivalent, will be used to initiate the credentialing process:

o OPM Standard Form 85 or 85P o OF 306 o National Criminal History Check (NCHC) (local procedures may require the fingerprinting to done at a police station; in this case, any charges are to be borne by the contractor) o Release to Obtain Credit Information o PIV card application (web-based)

1.11.1.3. Before starting work under this contract, a National Criminal History Check (NCHC) will be initiated to verify the identity of the individual applying for clearance and to determine the individual's suitability for the position. If the NCHC adjudication is favorable, a DOI Access Card will be issued for that individual. If the adjudication is unfavorable, the credentials will not be issued, and the SP must make other arrangements for performance of the work. In the event of a disagreement between the SP and the Government concerning the suitability of an individual to perform work under this contract, DOI shall have the right of final determination.

1.11.1.4. The SP employees must give, and authorize others to give, full, frank, and truthful answers to relevant and material questions needed to reach a suitability determination. Refusal or failure to furnish or authorize provision of information may constitute grounds for denial or revocation of credentials. Government personnel may contact the contractor personnel being screened or investigated in person, by telephone or in writing, and the SP must ensure they are available for such contact.

1.11.1.5. Alternatively, if an individual has already been credentialed by another agency through OPM, and that credential has not yet expired, further investigation may not be necessary. In that case, the SP must provide the COR with documentation that supports the individual's credentialed status.

1.11.1.6. The SP employees who have been successfully adjudicated will be issued DOI Access Cards, which must be activated at a USAccess Credentialing Center. Those the SP employees not located within a reasonable travel time of a USAccess Credentialing Center will be screened and issued alternate credentials, such as temporary access badges.

1.11.1.7. During performance of the contract, the SP must keep the COR apprised of changes in personnel to ensure that performance is not delayed by compliance with credentialing processes. Cards that have been lost, damaged, or stolen must be reported to the COR and Issuing Office within 24 hours. If reissuance of expired credentials is needed, it must be coordinated through the COR.

1.11.1.8. At the end of contract performance, or when a contractor employee is no longer working under this contract, the SP must ensure that all identification cards are returned to the

COR.

1.11.1.9. This requirement must be incorporated into any subcontracts that require subcontractor personnel to have routine unsupervised access to a federally controlled facility for more than 180 calendar days or any unsupervised access to a federally controlled Level 3 or 4 information system.

1.11.2. Other Security Requirements.

1.11.2.1. At the discretion of the Government, higher levels of background investigation may be required for certain positions. (Collectively these background investigation levels will be referred to as National Agency Check with Inquiries (NACI) background investigations herein). The SP is required to take precautions and necessary actions to ensure that submitted personnel will pass a background track and that unnecessary expenses to the government are mitigated. Failure to take steps may result in the government seeking reimbursement.

1.11.2.2. Project Information Non-Disclosure Agreement. Prior to beginning work under the Task Order, the SP shall submit, to the COR and CO, signed Project Information Non-Disclosure Agreements (NDA) from all employees, inclusive of sub-Service Providers that will be working on the contract.

1.11.2.3. Application / Data Security. The SP staff may have access to privileged and confidential materials of the United States Government. These printed and electronic documents are for internal use only and remain the sole property of the United States Government. Some of these materials are protected by the Privacy Act of 1974 (AMENDED) and Title 38 Code of Federal Regulations (Title 38). Unauthorized disclosure of Privacy Act or Title 38 covered materials is a criminal offense. Each the SP employee will be given access to only the information and facilities needed to perform the work associated with the contract.

1.11.2.4. System Security. The SP shall comply with all the Federal, Office of Management and Budget (OMB), and DOI policies, directives, procedures, and memorandums in effect at BLM.

Copies to be provided upon award of the IDV.

1.12. Data. All information generated and maintained under this contract, to include government-furnished information, must be available for Government review upon request. The SP concurs that all information collected as a result of efforts under the task order is the property of the US

Government and shall not be released either formally or informally without the consent of BLM.

The Government has unlimited rights to all data and deliverables under this contract. The Government shall retain custody of all records associated with the SP deliverables and shall have exclusive control in the distribution of all written deliverables. If the SP uses proprietary data in their proposal or in any other communication, it shall be marked appropriately. All data collected or created during the course of the development process will be turned over to BLM at the end of the contract to include agile backlog documentation (e.g., JIRA).

1.13. Standards. In addition to compliance with Section 508 of the Rehabilitation Act, the SP shall comply with Federal and DOI IT policy and procedural guidelines. The SP shall also comply with applicable The Specifications and standards found in the National Institute of Standards and Technology's (NIST) Federal Information Processing Standards Publications (FIPS PUBs) (http://www.nist.gov/itl/fips.cfm) and the use of ANSI/EIA Standard 748 (As Amended) Earned Value Management System (EVMS). http://webstore.ansi.org.

1.14. Travel. Travel will be added per order as a cost reimbursable line item to support this requirement. The SP estimation and reimbursement shall be in accordance with Joint Federal Travel Regulations and Federal Acquisition Regulation cost allowances. http://www.gsa.gov.

1.14.1. Prior to the SP making any travel arrangements, the SP will submit to the CO and COR a written request for travel outlining exactly who will be traveling, the destination of travel, mode(s) of transportation, when the travel will take place and what the travel supports. Upon receipt, the COR will communicate if the requested travel is necessary to the CO; the CO will then issue a final determination of approval/disapproval in writing. The SP is responsible for requesting approval at least 14 days in advance, when possible, to accommodate all necessary approvals. In no instance shall the SP travel without funding on this contract line item and without prior written approval of the CO.

1.15. Property. The SP shall identify in their order proposal all resources necessary for completion of this work to include Government Furnished Property, Contractor-Acquired Property, and Contractor Property. With the exception of BLM provided laptops with standard software configurations, and Contractor Property used to facilitate off-site development services, all other property (i.e., hardware, software, servers, RAM, processors, storage, development tools and platforms, etc.) shall be proposed with the option of being awarded as Contractor-Acquired Property. The Government may, on a line-item basis, select and award those items BLM wants the SP to acquire on BLM’s behalf. Alternatively, BLM may even elect to acquire some items which are identified in the proposal as Government-Furnished Property, which are deemed it in the best interest of the BLM to purchase and implement internally based on existing practices and/or agreements. A list of the existing BLM baseline for software and development tools is provided. While all items on this list have been approved for use, this list does not prevent the SP from proposing alternatives not identified on the list, based on the proposed development approach.

http://www.nist.gov/itl/fips.cfm http://webstore.ansi.org/ http://www.gsa.gov/

1.15.1. Government-Furnished Property. Government-Furnished Property is all property furnished by the Government to which the Government retains title. Work performed off-site or virtually may require access to the BLM network. Currently this can only occur through the use of Government-provided laptops with Virtual Private Network (VPN) connection which is provided by BLM. The SP shall propose only the minimum quantity of laptops and any software installations outside of BLMs standard configuration necessary to facilitate the technical requirement to meet the proposed solution. BLM will not ship any laptops outside of the continental U.S. or Alaska. The SP shall be responsible for complying with all existing BLM practices for maintaining and updating their laptop for which all other BLM virtual employees are required to comply. This may include logging into the computer frequently. Typically logging into VPN frequently to receive all updates will ensure the computer remains secure and available for use. However, there may be instances where shipping or traveling to and logging directly into the network at a BLM facility becomes necessary. The SP shall comply will all requirements to properly use and maintain a BLM laptop.

1.15.2. Contractor-Acquired Property. Contractor-Acquired Property is all property acquired by the SP on behalf of and to which the Government has title.

1.15.3. Contractor Property. Contractor Property is that property acquired by the SP to facilitate successful off-site performance of the contract. The SP retains title to this property upon completion of the contract.

1.15.4. Government Furnished Information. BLM will provide any publicly available data if requested for purposes of reducing burden to replicate all test data for off-site development and testing.

Any data not publicly available will not be provided for off-site environments.

2. DESCRIPTION OF SERVICES.

The SP shall provide software development and O&M services. All released parts of a given application will be supported concurrently with active development in accordance with the FFP O&M section of this document. The SP must ensure sufficient resources are available to deliver corrective, preventive, and adaptive maintenance concurrently and without degrading development team velocity. This includes the ability to maintain O&M categorized releases of the application independent of application development. While the application is under active development, all O&M perfective maintenance is suspended and instead, carried over to the active development backlog for prioritization and development under that process.

The SP may be required to work cooperatively with other contractors/entities performing their own projects and initiatives that may or may not have impact on this contract (e.g., concurrent development of applications with interface dependencies). If the situation arises where deliverables may be impacted, it is the responsibility of the service provider to bring the situations to the attention of the COR immediately. Contractor advisory and assistance support may be used for technical, engineering, and programmatic support; The SP shall cooperate fully with third party support once non-disclosure agreements between the parties are established in accordance with FAR 9.505-4(b).

NOTE: The Government will purchase necessary software licenses.

2.1. Program and Project Management Support. The SP shall be responsible for Program and Project Management support activities for their technical staff as well as in support of all activities contributing to successful task order performance. These tasks may include but are not limited to:

2.1.1. Developing and maintaining a critical milestone schedule that documents the most important schedule issues for management attention.

2.1.2. Providing recommendations to address any schedule or cost variance associated with project plans.

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

2.1.4. Support the COR in analysis, classification, and prioritization of reported items.

2.1.5. Support issues management and tracking.

2.1.6. Supporting change management and risk management activities.

2.1.7. Coordinating and planning meetings, where appropriate, including program management reviews, and walk-through/design reviews.

2.1.8. Providing project progress reports and other management documents as the specified in project deliverables and as required by the government management.

2.1.9. Ensuring the integration and synergy between interconnecting systems and provide recommendations for simplification of interconnections as they arise.

2.1.10. Facilitate adherence to all departmental and bureau policy.

2.1.11. Provide monthly and weekly status reporting in a format agreed upon by the COR.

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

2.1.13. Coordinate with the Government regarding system outages and hardware/firmware or interface issues that come to their attention.

2.1.14. Create and maintain development information site(s) (e.g., MS Teams, MS OneDrive, or MS SharePoint Site); develop, design, and create page content. Site design and content must be approved by BLM.

2.2. Development. The SP shall analyze, design, develop, configure, test, and release business applications by applying an iterative process utilizing a form of Agile, and/or Hybrid centered methodology (greater emphasis on Agile) which promotes for short incremental time boxed development and a frequent release capability to the maximum extent practicable within policy and resource constraints. The objective of this development approach is to reduce risk, cost, and schedule and improve product quality through increased emphasis on communication, customer collaboration, faster delivery of working code, and an ability to respond and adapt to change. As a general rule, this requires breaking up software development into smaller and manageable iterations (The Sprints) each of which shall produce defined functionality. The process shall include a communication and collaboration approach which enhances the probability of successfully delivering an application that meets end user objectives. The process shall directly involve product owner(s) and/or end user collaboration to a high degree into the sprint development cycles to ensure (1) delivered software produces immediate customer satisfaction, (2) delivered software is usable and does not contain unusable or unwanted features and (3) process provides maximum capability to respond to change with minimal impact on development objectives. For more information on government agile initiatives:

https://techfarhub.cio.gov/handbook/.

2.2.1. Product Vision. All projects (orders) under this PWS will begin with a Product Vision. The Product Vision may come in various forms depending upon the size and complexity of each module and the project planning activities which were conducted prior to requesting development support.

2.2.2. Validation and Planning. The SP shall propose scope and duration for an initial period of Validation and Planning. The objective of this effort is to improve outcomes by placing the project in a position to better plan and execute development activities as well as improve our ability to communicate and manage project expectations. The following deliverables and objectives must be accomplished within this period.

2.2.2.1. Product Backlog. The SP Team shall decompose available Government furnished business requirements documents and deliver the initial Product Backlog using themes, epics, and/or large user stories. This effort is not necessarily intended to create actionable decomposed user stories for development. This level of decomposition will be handled within the agile development process; however, the Product Backlog shall be minimally sufficient to roughly estimate and produce a Product Roadmap and a Release Plan to be delivered at the end of the Validation and Planning period. This effort will involve direct interaction with the PO and user community as needed to successfully complete the objectives of this work. This effort may include meetings, workshops, and other collaborative exercises required for successfully completing the activity as outlined in the SP’s proposal Excessive or unproductive meetings which involve a rehashing of reasonably well-defined requirements is not the objective. This https://techfarhub.cio.gov/handbook/ effort shall also produce an approved Sprint Backlog for the first Sprint. Acceptance criteria and/or definition of done is required for the first Sprint only. This level of story definition is not required for subsequent Sprints and instead is completed as part of the backlog grooming and Sprint planning process.

2.2.2.2. Initiation Activities. The SP shall use this time kick off the project with BLM to establish clear roles and expectations within the total team. In addition, the SP shall provide (host) formal Agile Development training with both BLM (e.g., Platform and Project PMs, POs, Key Business Leads, Key SMEs) and SP key members (e.g. PM, SM, BA(s), Lead Developer(s)) to be held with a professional provider for this type of training. Training may be customized for the situation. The training is expected to baseline the understanding of roles and responsibilities within the agile (hybrid) process moving forward with the objective of facilitating an effective team. This time should also be used to complete personnel onboarding and to work on any other dependencies or initial activities which may prevent the success of Sprint One (1) including initial purchasing and implementation of development tools, platforms, and infrastructure.

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

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

2.2.2.5. Coding Standards. In addition to a styles guide, the SP shall develop a coding standards guide for developers to provide consistency in development.

2.2.2.6. Initial Design. The SP shall create initial system and architecture design artifacts and provide an initial design review to the BLM for approval.

2.2.3. Backlog Refinement and The Sprint Planning.

2.2.3.1. Product Backlog. The SP shall effectively communicate with the Integrated Product Team (IPT) to gain a complete understanding of the product vision and to validate the current business requirements in the creation of agile software development artifacts. The SP shall maintain the product backlog containing functional descriptions (e.g., “user stories”) feeding from the product vision and product roadmap in direct collaboration with the PO and stakeholders. The backlog shall contain the prioritized list of features which describe the technical functionality of the system. The backlog will be used for tracking and estimating the development effort.

Estimations shall include considerations of complexity, risk, implementation, deployment, and interdependencies. The BLM shall have final approval authority over all backlog content and prioritization. This backlog will feed into the iterative development cycle and act as a living document used to track the status of all identified functionality delivered or to be delivered. This deliverable shall be approved by the IPT prior to entering into the first development cycle. It is also expected that the process of creating and updating the product or feature backlog is continuous and should not impact the transition between and the execution of development cycles. This backlog shall be made available to the BLM PM and PO for review in real time.

2.2.3.2. Refinement. The SP shall propose the specific approach or methodology for creating and maintaining a successful backlog with BLM. The approach shall, at a minimum address backlog creation, story decomposition, feature identification and product team communication, feature use case or story point effort estimation, prioritization, quality assurance, testing, user acceptance, and establishment/commitment of iterative functionality (working code); within the limitations identified in this document.

2.2.3.3. Sprint Planning. Planning for the first Sprint will be performed and priced as part of initial Validation and Planning activities. Subsequent Sprint Planning will be performed prior to beginning an additional Sprint in accordance with this paragraph as part of the development cycles. The SP shall complete Sprint Planning with the BLM prior to beginning development which involves the approval of the Sprint prior to entering into development. The planning process will scope the delivered functionality to be provided for each development cycle.

Planning shall include consideration in mitigating schedule conflicts and maximizing availability of resources for successful completion of each iterative development cycle. The Development cycle shall be based on user stories/feature descriptions selected by BLM in collaboration with the SP. Each backlog item shall also include acceptance criteria or a “Definition of Done” (DoD) to pre-define the successful completion of the feature and shall be agreed on by the Product Owner/Product Team prior to development. The SP shall be evaluated for their ability to successfully execute each Sprint. The SP shall accurately estimate and efficiently manage The Sprint Planning work.

2.2.3.4. Work Categorization. The SP shall come up with a system to categorize each user story, issue, help desk ticket and any other work within the backlog. This categorization system will be reviewed by the government for approval. Standards in categorization of development is considered critical to project oversight and expectations management. Accurate categorization is required at all times and any questions regarding the categorization of a ticket should be referred to the BLM PM for clarification. The BLM PM shall have final determination on ticket categorization. If the SP disputes that the categorization of a ticket fails to comply with the contract, they are responsible for bringing it to the attention of the CO for resolution. Failure to do so will constitute acceptance of the PM determination. The following categorization, subcategorization, (or tags) and definitions shall be used so that accurate reporting on categorization can be completed on the backlog:

2.2.3.4.1. Operations & Maintenance: (See definitions at section 2.3.1. for subcategorization of O&M tickets). Perfective Maintenance categorization will not be used while the application is under active development.

2.2.3.4.2. Development: (All Changes to the application which are not Corrective, Preventive, or Adaptive maintenance of the released application). This includes all work that would otherwise be classified under Perfective Maintenance. The following three categories of development stories shall be used:

2.2.3.4.2.1. User Stories. Describes new features or new functionality of the application derived from the Product Vision and Product Roadmap. User stories are also derived from the initial Product Backlog created during Validation and Planning.

2.2.3.4.2.2. Enhancements. Requirements for functionality or features that are considered to go above and beyond and/or considered to be a deviation from what was originally outlined in the original Product Backlog. This also includes enhancements to already designed features or functionality which do not otherwise constitute redesign work. Redesign of features and functionality is an area of potential improvement and therefore must be classified under remediation for this categorization to have value. The enhancement subcategory is to help BLM better track and explain changing requirements through development.

2.2.3.4.2.3. Remediation. Work should be completed at a steady pace per Sprint to maximize customer satisfaction by ensuring that a steady rate of new functionality is being completed along with remediation work. The following two subcategories of Remediation shall be used to identify the source of remediation to help with oversight and quality improvement identification.

2.2.3.4.2.3.1. Error. Any fault that causes incorrect or unexpected results in the unreleased application or that causes the application to behave in unintended ways. Errors should be detected as early as possible through testing or developer QA to ensure a steady state of remediation is completed throughout development.

2.2.3.4.2.3.2. User Bug. A user bug is defined as any story that was determined not to meet the acceptance criteria or definition of done. This categorization is not designed to be punitive but instead is intended to help the SP as well as the BLM PM to identify and improve upon our ability to effectively define and refine requirements before development begins and to prevent costly and preventable rework in development.

2.2.4. Development Cycle.

2.2.4.1. The Sprints shall be proposed as three- or four-week fixed time boxed iterations that deliver working code as defined in Sprint Planning. Historically, BLM has been successful with three-week Sprints. The Sprint length and team structure shall be proposed based on company’s best practice approach and balanced within the constraints of allocated resources.

2.2.4.2. The SP shall design and develop identified Sprint functionality. The PO may be involved to facilitate seamless development to the maximum extent practicable by providing quick feedback to developers on business requirements and intent of product features. This feedback is not intended to create additional new functionality within the Sprint or development cycle, but to clarify feature questions when they arise. All new features and/or changes to functionality should be placed back into the product backlog for estimation, prioritization, and Sprint planning.

2.2.4.3. In maintaining best practices of Agile development, the SP shall plan to host frequent short duration meetings during the Sprint cycle to maximize effectiveness of daily activities and to communicate roadblocks to successful development effort to the BLM PM and PO.

2.2.4.4. The SP shall provide an approach to Pre-Functional Quality Testing (Pre-FQT) and/or Quality Assurance-based testing to be accomplished within each Sprint cycle to ensure product functionality meets end-user expectations, and that the new code is not introducing any apparent errors. Automated testing shall be used by the SP and in development. Automated testing shall be accomplished for each Sprint. Testing tools shall be made available to BLM in the SP development and test environment for use and/or verification of successful regression testing. Overall, testing approach should provide TDD to IT (behind the scenes) and the user side (product/FQT). Any changes or bugs identified shall be placed into the product backlog for estimation, prioritization, and Sprint planning. Sprint code shall be made available to users in test with the strategy of increasing visibility, enhancing user involvement in testing early on, improving buy in, and reducing remediation or enhancement requests at the final FQT stage of a release.

2.2.4.5. A Sprint review shall be conducted at the end of each Sprint. The review shall include a product demonstration. Identification of needed changes, modifications, or additions should be fed back into the product backlog for estimation, prioritization, and Sprint planning.

2.2.4.6. The SP shall hold a Sprint Retrospective designed to improve their Sprint cycle deliverables. The BLM PO and PM may also help to provide assistance in removing barriers to optimize success.

2.2.4.7. The SP shall complete documentation deliverables identified in this contract incrementally during Sprint cycles as opposed to waiting until the very end of a release. The intent is to ensure all documentation is priced and completed as part of the Sprint process and does not manifest itself in the form of excessive release costs. Incremental documentation should simplify and shorten the cost and delivery of required release documentation.

2.2.4.8. The SP shall propose an initial estimated Sprint Velocity which represents the total number of story points expected to be completed per Sprint based on the proposed team size and composition. The SP shall include both minimum and target velocity objectives. It is understood that in agile development that this is considered a subjective and potentially fluctuating measure based on each team; therefore, this will only be evaluated to ensure the SP has a realistic understanding of the proposed team size and composition as it relates to a reasonable measure of achievable and repeatable velocity.

2.2.4.9. To ensure development, speed is weighed against development efficiency; therefore, the SP shall propose a Development Efficiency Factor. This metric is calculated as the percentage of remediation completed in comparison to total development (e.g., 10 story points of remediation per 50 story points completed in a The Sprint = 20%). This metric will be considered as cumulative throughout development for performance measurement purposes; however, the SP’s ability to successfully capture and spread-out remediation over each Sprint will be considered in the qualitative evaluations of performance. The Sprint Efficiency Factor will be part of the quality metrics the government will use to assess the efficiency of development.

2.2.4.10. The Sprint Report will be provided after the completion of each Sprint. The Sprint Report should include at a minimum information on the stories and story points developed, total cost of development, total cost per story point, and ticket categorization metrics including both Sprint and cumulative percentage of remediation.

2.2.5. Product Release.

2.2.5.1. The SP shall support all activities associated with security, analysis, testing, documentation, review, and other activities required for successful product release(s) on a Labor Hour basis.

2.2.5.2. The SP shall conduct a review with the BLM prior to each release. The SP shall provide complete user testing and analysis support for the release. Final acceptance for the overall product and release is contingent upon the acceptance of the Final Operation Baseline Release Report (OBRR) and Formal Qualification Testing (FQT) which shall incorporate the associated system functionality identified in the Specifications for release. The SP shall support the BLM test team in user acceptance. Release testing is required in addition to the Sprint review demonstration provided to the Product Team.

2.2.5.3. The SP shall conduct security, stress, and performance testing prior to release.

2.2.5.4. The SP shall provide implementation support and shall be completed in direct coordination with the Implementation Team. This support includes release deployment, initial training, initial training materials, change management support, and communications support.

2.2.5.5. The SP will ensure all applicable documentation is delivered for each release. Complete documentation deliverables are defined in Section 3.

2.2.5.6. The SP shall provide all minimally acceptable initial training for each release with the intent of delivering development quickly and efficiently. Training and training materials are expected to be improved over time within the scope of the O&M process.

2.2.6. Other Support.

2.2.6.1. The SP shall propose communication resources for successful collaboration with BLM as applicable to the approach. Communication resources shall include voice, video, and/or online collaboration tools necessary for project success.

2.2.6.2. The SP shall utilize a development approach which includes development resources necessary to successfully conduct off-site development activities. This may include off-site localized code development so long as the approach allows for frequent integration and/or continuous integration of code back into the BLM environment for backup and security purposes.

2.2.6.3. The SP shall provide BLM with off-site development and test environment resources which mirrors BLM’s production environment. The SP shall create and maintain test data for testing not otherwise provided or publicly available. All other development tools necessary for collection of business requirements and completion of work shall be supplied as well as part of the cost of development services provided. The SP shall propose a strategy for checking in code to BLM daily to ensure BLM owns, controls, and protects the most current code base on-site.

2.2.6.4. Reporting capabilities is available on the Platform. The SP shall maintain its capability to support reporting and analytics development for these key integrated technologies to maximize value for users of built systems.

2.3. Operations & Maintenance Support. The SP shall deliver operation & maintenance support for developed and released systems. O&M may require system release(s). O&M activity requires the SP to keep the system running and up to date with current standards, policy, DOI approved system-wide software updates, technology, and other system changes. The SP shall ensure the application is available for use and shall resolve problems and incidents when identified. Fixes to problems and incidents may include modification of executable code. In the event of such changes, the SP shall execute software testing and configuration management efforts in accordance with the government process. The SP shall maintain existing interfaces to other applications. The SP shall coordinate with the government regarding system outages and hardware/firmware, or interface issues come to their attention. The SP shall manage and complete customer software maintenance requests and manage ticket requests for system enhancements. The SP is responsible for providing all services identified under paragraph 2.3 Operation & Maintenance support, at the firm fixed price amount.

2.3.1. Software Maintenance.

2.3.1.1. Software Maintenance is fully covered under this scope. The International Organization for Standardization (ISO) defines and divides software maintenance into the following categories:

corrective, preventive, adaptive, and perfective.

Source: ISO/IEC 14764:2006

2.3.1.2. The SP shall use these classifications for classifying O&M work. The SP shall support the following software maintenance activities:

2.3.1.2.1. Corrective. Reactive modifications of the application to correct problems identified through ticket request or as otherwise detected. Examples include:

2.3.1.2.1.1. A bug, error, flaw, defect, failure, or any other fault in the system that causes incorrect or unexpected results in the released application or that causes the released system to behave in unintended ways. May include modifications to databases or executable code.

2.3.1.2.1.2. Emergency/patch fix release

2.3.1.