PWS for_Yellow_Digitizing Acquisition with Human-machine Teaming and Testing.docx

Statement of Objectives for “Yellow” Digitizing Acquisition with Human-machine Teaming and Testing A Statement of Objectives (SOO) is a government-prepared document incorporated into the solicitation that outlines the overall performance objectives and desired outcomes. It is used in solicitations when the government intends to provide the maximum flexibility to the offeror to propose an innovative approach. That portion of a contract that establishes a broad description of the government’s required performance objectives for acquisition data and its use to advance and inform leaders’ decision making.

(1) Purpose: The purpose of this contract is to provide human-centered design and testing services to the Department of Warfare (DoW) in support of its digitizing acquisition initiative. These services focus on workstream design, workflow modernization, and testing digital and artificial intelligence (AI)-based systems to enhance the acquisition domain’s ability consistently measure and quickly deliver effective capability across the lifecycle, from S&T to decommissioning.

(3) Scope and mission: The scope of this effort is to provide human-centered design and testing services to achieve the defined objectives required for digitizing the acquisition domain, focusing on three key areas: Comment by Curl, Sean E CIV OSD OUSD A-S (USA): Update this to be more objective based. CDRLs are where we can specify deliverables based on this objectives e.g., a roadmap every 30 days, project plans etc. Comment by Bates, Erik C CTR OSD OUSD A-S (USA): @Yiengst, Matthew C CTR OSD OUSD A-S (USA) Take a look at this now. Comment by Bates, Erik C CTR OSD OUSD A-S (USA): @Curl, Sean E CIV OSD OUSD A-S (USA) Do you want to have any CDRL's or anything specific in this? Or put them in a different section.

1. Product Management: the strategic process of defining, developing, and launching a product to meet customer needs and achieve business goals

2. Work Stream and Workflow Design: Map out the large, complex parts of projects into smaller, more manageable components. Then create systems repetitive processes and tasks that occur in a particular order. These are the mechanisms through which people and enterprises accomplish their work.

3. Test and Evaluation:

1) AI T&E: Testing of AI systems around task definitions, technical requirements, computational, AI vulnerabilities and Human-AI performance and interactions.

2) System Testing: a comprehensive process of evaluating a complete and integrated software system to ensure it meets all specified requirements, functionality, and performance.

3) Operational T&E: evaluating whether a process meets the intended needs of users and requirements owners. Do the workflows work?

The scope entails mapping and delivering these capabilities, then testing and evaluating their effectiveness through supporting analysis. This work will show workstream and workflow development, sustainment, and operational support for the data Acquisition suite of capabilities. These areas include front-end applications, data repositories, the underlying data framework, and AI/ML applications. The goal is to provide and maintain high-performance, interoperable systems, and processes that empower the DoW acquisition workforce and its partners with the data and tools necessary to make informed, data-driven decisions. Comment by Curl, Sean E CIV OSD OUSD A-S (USA): Let talk about this, but in the meantime, rework. The flow is: workstream > workflow > system testing Comment by Bates, Erik C CTR OSD OUSD A-S (USA): @Yiengst, Matthew C CTR OSD OUSD A-S (USA) Take a look at this. Comment by Yiengst, Matthew C CTR OSD OUSD A-S (USA): Better The DoW requires timely access to accurate, authoritative, and reliable acquisition data to support insight, analysis, and decision-making. It requires easily accessible front-end applications, data repositories, capabilities, system-to-system integration, and a well-defined and managed data framework to provide perspective and context for the use of Acquisition data. RWS supports the DoW Acquisition community and its partners, by providing an integrated foundation that delivers improved security, performance, reusability, interoperability, scalability, and maintainability for Acquisition data.

1. Document the workstream and workflows. What data systems are involved? Processes? Policy? Data? What and why are we doing it? Comment by Curl, Sean E CIV OSD OUSD A-S (USA): I'm confused here. These are CDRLs. I recommend that you rework and think of objectives based on the sequence in my comment above and the "building blocks' strategy I sent you guys (and briefed Obviant on. Comment by Curl, Sean E CIV OSD OUSD A-S (USA): Step 1: Document the workstream and workflows. What data systems are involved? Processes? Policy? Data? What are we doing it? Comment by Curl, Sean E CIV OSD OUSD A-S (USA): Step 2: Redesign the workflow based on the bottlenecks and gaps. Comment by Curl, Sean E CIV OSD OUSD A-S (USA): Step 3: Design the data ecosystems/architecture based on the future workflows. Comment by Curl, Sean E CIV OSD OUSD A-S (USA): Step 4: Measure. We need metrics for data, analytics, and AI capabilities. We need a team doing this based on the workstreams/workflows. Comment by Curl, Sean E CIV OSD OUSD A-S (USA): Think about what Bull Runs task would be for the overall approach. What are the objectives for those tasks?

2. Redesign the workflow based on bottlenecks and gaps.

3. Design the data ecosystems/architecture based on the future workflows.

4. Measure: DoW needs metrics for data, analytics, and AI capabilities. A team is needed for metrics and analysis of workstreams and workflows.

This is a process to deliver testable processes and infrastructure.

3.1 Objectives

a. Software: Utilize DoW software tools within already established infrastructure and enclaves such as ADVANA or GovCloud. The software will be built on Government owned infrastructure however commercial tools that are needed can be brought as necessary to achieve the best possible outcomes.

b. Systems Engineering Process:

1. The required structure will leverage the commercial industry’s existing tools and products as much as possible. However, recognizing that there will be limits to this as much of DoW’s data has not been used or trained on commercial systems, modifications will need to be made to make the data and its outputs meaningful. The following work areas will need to be addressed to fulfill user needs.

2. System mapping with performance objectives, architectures, data system flows, and needs.

c. Human Center Design:

3. UI/UX team mapping out user workflows using Human Center Design (HCD) Principles and creating a user experience roadmap and need statements to drive product development. The work here will be the government's IP and treated as key to product development. Clear workflow descriptions, diagrams, and explanatory artifacts to describe the needs of users and systems. To include User and work models, stakeholder identification, UI Mockups, system descriptions, and objectives.

4. Within the HCD process, mission engineering produces key artifacts, including system architectures, system performance objectives, user models, data models, implementation plans, and test plans. The intent is to produce efficient and operationally meaningful test plans. The test plans and other artifacts are used to verify the validity of a business or technology concept. Even with potential shortcomings, success is defined by producing lessons learned documentation in a shareable format.

d. Product Owners:

5. The Product Management Team will be overall in charge of the product development and use a cross matrixed structure from the other teams to define, build, and deliver the tools required

6. Build user-based workflows to enable key Acquisition processes including but not limited to CPM, MEIA, and other Acquisition reform efforts.

e. Test and Evaluation:

7. Test and Evaluation will be required of all work to ensure performance and other critical metrics are met. Testing will be conducted throughout to measure the impact of new systems and processes and to determine the best design for the acquisition methodologies.

8. Test and Evaluation start at the planning and human center design stages. The project plan, its artifacts and prototypes must include test plans emulate from these definitions' requirements, objectives. Was this concept or prototype effective and what did we learn from it? T&E Plans will be delivered as a starting point for measuring success for acquisition data reform and to inform the learning process and feedback loop. This is vital for success and closely aligned with metrics.

f. A&S Strategy Development:

9. As the workflows are analyzed, a future strategy of what can and should be done with acquisition data workstreams and workflows will be developed. This can be done conjunction with a university or other affiliated research institutes. This will result in a white paper and briefing on findings and recommendations with prototyping a new acquisition decision support platform. This effort will be used to support and further acquisition reform

(4) Performance objectives: The performance objectives allow the offeror the maximum flexibility to innovatively manage the projected schedule, performance, risks, warranties, subcontracts, and data to provide the goods or services that satisfy the government’s performance requirements. These objectives address the DoW need to modernize its acquisition processes and systems. This will transition from compliance based legacy systems to a more agile, data driven approach. As outlined in the SECWAR Acquisition Transformation Plan, this requires an understanding of the current challenges/data silos, unreliable data, outdated risk avoidant structures, and instead proposes solutions that include measurable transformation.

4.1. Sustainment and operations

a. Maintainability: Deliver an integrated foundation that improves the maintainability of acquisition data and the acquisition planning process for the DoW community. This includes ensuring the long-term viability and adaptability of all systems and processes developed, enabling the DoW to adapt to evolving requirements and emerging technologies. The integrated foundation should also facilitate the seamless incorporation of new capabilities and updates, minimizing disruptions to ongoing operations.

4.2. Design and Assess

a. Innovative solutions: Propose and implement creative, cost-effective solutions for system enhancements, leveraging industry best practices. This includes a focus on human centered design to ensure that the solutions meet the needs of the DoW acquisition workforce. Build out a project plan and update it every quarter with deliverables every month related to the plan. This revised plan should reflect the findings and inform prototype planning and building for the acquisition decision platform and data.

b. Modularity and interoperability: Develop a modular open systems architecture that enable easy integration of new capabilities and ensures interoperability with the Global Information Grid and other DoW systems. This architecture should be designed to facilitate seamless data exchange between different systems and applications, breaking down data silos and enabling a more holistic view of acquisition data.

4.3. Data management and access

a. Data quality: Ensure the accuracy, reliability, and authority of all data within data acquisition related capabilities.

b. Data framework support: Continuously mature the user workflows to inform the Data Governance process and ensure data standards and alignment. This will support the work stream and workflow design to meet the changing needs of the DoW acquisition workforce. They are to provide outputs and assessments to other vendors to provide the needed guidance/data.

4.4. Analytics and decision support

a. Analysis capabilities: Deliver enhanced capabilities that support strategic analysis, insights, and data-informed decision-making for DoW leadership.

b. Documentation: Produce clear, concise, and professionally written deliverables and documentation. Included in this will be comprehensive documentation of all systems, processes, and solutions developed with training materials.

4.5. Contract Data Requirements List

Note: Days listed are based on business days and start once the contractor team is on-site and has sufficient credentials.

a. Possible CDRL’s for these objectives include:

i. Project Roadmap: Within 30 days of reporting on site and receiving credentials along with access the vendor will deliver a Project Roadmap and provide regular updates at least quarterly.

ii. Test implementation plans: Within 20 days, the vendor must provide a wireframe for their test implementation plan and provide bi-weekly updates after gaining more guidance from stakeholders.

iii. User and Work models: Within 15 days of reporting on site and receiving credentials, along with access to the vendor will provide current and future user and work models and provide updates every month

iv. Stakeholder identification and Mapping: After 20 days of holding the kickoff meeting, the vendor needs to identify internal and external Stakeholders by having intro calls, and create a RACI matrix and identification and mapping

v. System architectures- (legacy and proposed new): initial current (legacy) architecture within 30 days of reporting on-site; initial future (new/objective) architecture within 15 days after legacy architecture. Associated updates as items change and at least quarterly.

vi. Data Descriptions and mapping: initial current (legacy) data dictionary/mapping within 45 days of reporting on-site; initial future (new/objective) data dictionary/mapping within 15 days after legacy delivery. Associated updates as items change.

vii. Human –machine Work System concepts: Within 30 days of on-site and access, develop an initial draft Human-machine Work System concept of operation and associated concept diagrams, with monthly updates.

viii. User Interface Mockups: Within 30 days after delivery of the initial future architecture, develop User Interface Mockups. Review and update monthly as needed.

ix. System descriptions and objectives: Within 30 days of delivery, provide system descriptions and update monthly as needed.

x. Lessons learned: Within the first two months, the vendor must hold its first Lessons Learned Ceremony and establish a cadence for regular lessons learned ceremonies. Additionally, a Lessons Learned ceremony should occur within 30 days of contract end.

xi. White Paper topic: Within 30 days of initial future architecture delivery, develop an initial Project White Paper topic and complete the white paper within 120 days

xii. Acquisition System Prototype: Within 10 days, the vendor must provide a mockup of the Acquisition System Prototype and provide updates monthly

xiii. Phase 2 Project Plan: No later than 180 days, develop a Phase 2 Project Plan and Budget

(5) Operating Constraints.

Legacy systems and code may need to be modified or eliminated. The new system must allow and enable current operations during the transition. Human Centered Design must be used to help usher in change within the institution, in terms of workflows, how people use the system, and to drive product development. Data Governance is not in place, and these products and services should help inform these efforts and provide a feedback loop as these processes mature. This work should also inform other efforts, applications, and platforms.

1. Project will be executed in accordance with Ethical AI principles and the Agile Software Acquisition Pathway.

2. Project must consider and inform evolving defense acquisition guidance.

3. Key personnel and select engineers must be CUI-eligible.

4. Project will develop and sustain relationships with stakeholders for the delivered software system.

5. Vendor will require CACs, NIPR Net Accounts, and a DD-254 for classified discussions with stakeholders.