Encl-2_Project.Structure.Guidelines_ FINAL.docx

ENCLOSURE 2: W900KK-22-R-00XX

PROJECT STRUCTURE GUIDELINES

ENCLOSURE 2: W900KK-22-R-0012

PROJECT STRUCTURE GUIDELINES

Project Structure Terminology Prototype projects supporting the T&E/S&T Program are anticipated to follow a common phased approach with corresponding milestones. Offerors are strongly encouraged to use this document in developing and communicating technology progression in context of contractual or agreement work progressive milestones and activities.

The following details describe the typical stages of technology development using phased progressions with expected Government touchpoints and major milestones for each of the prototype projects. Project stages are conceptual – not contractual – and provide a means for program management to articulate and evaluate the overall technology maturity of an effort (i.e., TRL 3-4, TRL 4-5, TRL 5-6) (https://api.army.mil/e2/c/downloads/404585.pdf) at any point in time and to assess level of progression. Stages of TRL development progression are ‘nested’ within contractual phases and milestones. Depending on the initial TRL of the proposed solution, offerors may need to adapt their approach to relevant elements of the discussion below.

While a project can be segmented into any number of phases, a project typically progresses through three major developmental stages of technology maturation – first focused on requirements refinement and design trade-offs, then focused on core technology development, and finally focused on technology transition with production of demonstration prototypes.

Phases (and subordinate milestones, as needed) are the significant contractual units of a project. Awards under this BAA shall be phased for risk mitigation. Initially, only Phase 1 will be awarded. Based upon Government decisions, subsequent phases/milestones are awarded as executed options of the original or revised contract under a FAR award. Other Transaction agreements will use performance on analogous major and minor milestones for decisions to continue work.

Three Technology Progression Stages Concept Exploration Stage. At the initiation of the project, the majority of effort usually focuses on discerning and refining technical requirements, experimenting with technology alternatives, developing models and simulations, and performing trade-space assessments. In the Concept Exploration Stage, the goal is to complete (or clarify) the system design and increase the confidence in the technology development to be pursued. Normally, the technical efforts in this stage include maturing the technology from TRL 3 to TRL 4. Critical components and sub-components of the design with derived technical requirements should be identified, as well as mitigation options or potential alternative solutions. If the technology development is hardware-centric in the Concept Exploration Stage, a ‘breadboard’ or system components may be developed and tested in a laboratory. If the technology development is more software-centric, use case analyses may be performed with an initial spiral executed effort to develop an early prototype. Although not a requirement (unless specified below), T&E/S&T projects typically address these component activities to address the TRL advancement of this stage:

· ‘Discerning and refining requirements’ is an expected aspect of the first stage (and contractual phase). Refinement of requirements is needed to resolve the potential gap between the published topic requirement and the proposed solution. It also addresses a detailed DoD T&E context for creative solutions from respondents that may not have experience with DoD T&E applications. This enables the performer to adequately contextualize the solution toward practical DoD requirements once both the Government and awardee are able to engage in refining relevant solutions. The requirements refinement entails awardee investigational efforts after collaborative DoD engagement, including DoD stakeholders/transition partners beyond the Executing Agent (EA) managing the effort. Decisions from this refinement may alter the remaining development activities within this stage, later stages, or both, potentially requiring modification of the awarded contract vehicle.

· ‘Conceptual/theoretical trade-space assessments’ is mentioned in this stage from a theoretical perspective using Modeling and Simulation (M&S) as a driver to assess how potential overall performance is affected by varying the level of resolution or granularity across each of multiple parameters that may affect the measurement function. Component breadboard proof of concept may also be required. As some parameters are pushed to greater resolutions/levels of performance, others will demonstrate sensitivities to this change with varying levels of degradation in each of their performance levels. Such is the nature of the ‘trade-space.’ This becomes a critical element of understanding what/how/why the parametric balance should be pursued in successive stages to meet the Government’s best benefit.

· ‘Risk Mitigation Efforts/Alternative Solutions’ are based on typically more than one perceived viable approach to technology advancement, which are identified as alternative candidates for investigation, but the highest confidence one is priced in the submission for execution. The selected path may require iterations for alternatives once a project is underway, due to unforeseen complexities or complications, or it may progress to a point and not ‘bear fruit’ toward the intended objectives.

· ‘Demonstration/completion of exit criteria’ (typically TRL 3-4) are agreed upon prior to award by the Government and/or revised as necessary during stage progression. This activity is performed as a final threshold requirement for the Government to consider project continuation.

· Technical Report completion through end of Phase/Project is required to include all technical/software documentation and relevant technical data (including software products per TRMC Common Terminology definitions) for conclusions made, including approach descriptions, rationale, and findings for all successful and failed efforts during the phase to date (or project completion, if on last awarded phase).

Engineering, Integration, & Experimentation Stage. The Engineering, Integration, & Experimentation Stage is typically when the majority of the technology development is performed. Normally, the technical efforts in this stage include maturing the technology from TRL 4 to TRL 5. If the technology development is hardware-centric in the Engineering, Integration, & Experimentation Stage, a ‘brass board’ may be fabricated to demonstrate the performance of the technology, with components and sub-components integrated into a working system. If the technology development is more software-centric, multiple software development spirals or software scrums could be executed with regular in-progress reviews and early beta-testing. Typically, Engineering, Integration, & Experimentation involves the most significant amount of effort and takes the longest period of time of the three stages. Furthermore, this stage typically includes a S&T design review similar to a critical design review for an engineering development project. Most importantly, prior to concluding this stage, transition partners (at DoD test ranges) must participate to clarify the end application of the test technology and help shape the test environment the technology should be demonstrated during the next stage. Typically, a specific T&E range transition partner is identified for receipt of the prototype after it is satisfactorily demonstrated in a relevant test environment. Although not a requirement (unless specified below), T&E/S&T projects typically address these component activities to address the TRL advancement of this stage:

· ‘Component-level trade space analyses’ extends from the prior stage, where trade-space analysis may be needed beyond M&S efforts. It may take not only component level, but some system level of assembly and testing during this stage to understand the impacts of varying parametric optimizations. This is particularly relevant in matters where material science thresholds are pushed beyond current levels of understanding.

· ‘Transition partner candidate reviews’ are performed once the trade-space paradigm for the project is understandable to determine the Government’s best benefit of continuing project efforts. A prime objective for the T&E/S&T Program is to seek widespread application of the technology developments. During this stage, the degree and breadth to which the technology application is meaningful becomes more evident.

· ‘Technology demonstration prototype fabrication design review’ is a threshold milestone analogous to a critical design review for a capability prototype. This should also resolve the trade-space determinations among the transition partner(s).

· ‘Demonstration/completion of exit criteria’ (typically TRL 4-5) are agreed upon prior to award by the Government and/or revised as necessary during stage progression. This activity is performed as a final threshold requirement for the Government to consider project continuation.

· Technical Report completion through end of Phase/Project is required to include all technical/software documentation and relevant technical data (including software products per TRMC Common Terminology definitions) for conclusions made, including approach descriptions, rationale, and findings for all successful and failed efforts during the phase to date (or project completion, if on last awarded phase) Technology Characterization & Transition Stage. In the Technology Characterization & Transition Stage, the goal is to demonstrate the technology in a relevant test environment, proving the technology has adequately matured and is ready for transition to the identified transition partners, to ultimately support DoD T&E. Normally, the technical efforts in this stage include maturing the technology from TRL 5 to TRL 6. This stage may include the development of a working prototype designed to operate in a representative test environment defined by the potential transition partner(s). If the technology development is hardware-centric, the working prototype would be fabricated to satisfy all electrical and mechanical form, fit, and function requirements, hardened to the degree necessary to perform in the required test environment. Measurements would be made to verify that the values of important parameters meet or exceed the technical objectives of the project. If the technology development is more software-centric, a final prototype would be delivered that satisfies all critical performance requirements, with suitable documentation, and be tested by the transition partner(s). If the prototype directly exchanges data in real-time with other DoD test infrastructure, the prototype should be compliant with the Test and Training Enabling Architecture (TENA) standard, to ease integration and technology transition.

· ‘Interim developmental test plans and verifications’ are typically necessary where the contractor verifies performance of sequential elements of the prototype(s) development and reports to the Government. In some cases, the Government (or supporting subject matter experts) may witness these interim demonstrations. Test plans must be preapproved by the Government. This is particularly necessary where multiple technology advancements must be integrated for the prototype(s). Where feasible each should be independently checked against expected performance. In some instances, these tests must be performed at an operational test range or Government software testbed laboratory.

· ‘Risk mitigation options, technical issue resolution, and/or reduced performance prototype resolution’ may also be required with Government participation. A variety of factors must be considered between the EA and the transition partners(s). In some cases, acceptance of reduced performance may occur if resolution is neither technically or financially feasible. If performance levels do not support the needed technology gap, a decision may occur to find value from an acceptable prototype deliverable to transition partner(s).

· ‘Prototype demonstration test plan development and approval’ requires iteration among EA subject matter experts, transition partner(s) and other test range operations and safety personnel. This may entail a variety of clearance authorizations. In many instances, the prototype for testing requires a system or article under test that must be obtained via a window of opportunity based on range operations test schedules.

· ‘Prototype demonstration in a relevant environment’ is required and is typically performed at a transition partner operational test range (for hardware systems) and a transition partner test bed environment (for software systems). At operational test ranges, existing customer testing requirements are the priority and pending T&E/S&T project test events must be scheduled around the operational needs. This may place the effort on hold until the range can support testing and may cause project duration extensions. Other impacts include the following factors:

· Certain tests require use of other operational program assets that are being tested for other purposes. This is due to the extreme costs of either performing the test or the availability of the needed asset, or both. This requires a flexible window of opportunity for the project to be able to afford the necessary testing to validate technology progression.

· Weather/environmental, and other range factors, such as frequency and safety clearances also affect the ability to conduct the test as planned. This may affect timing and duration of the events.

· Because of the unique nature of some of the testing paradigms, best effort planning shows that once in the test event sometimes the expected test activity does not produce the necessary responses – thus requiring field adjustments and delays and/or rescheduling with a different solution.

· Lastly - if the test validation actually fails, an analysis is performed and the information is fed back for a determination if the project can submit a change proposal for resolution of the issue for approval and execution, or if the project will be terminated with the primary deliverable as a final technical report, detailing the process, the results obtained, and the related learnings and information gained.

· ‘Turnover to transition partner and close-out’ is typically performed after successful demonstration and includes any follow-on range operations training for operation and maintenance with documentation. In some instances, it may involve integration support to the Government when accepting the prototype as a deliverable end item for continued operational evaluation and use. Transition includes providing relevant asset identification and tagging per DoD guidelines and as acceptable by test range property management officials. Close-out includes delivery of a comprehensive final project report discussed below and delivery of all software products associated with development and turnover unless otherwise agreed upon.

Technical Report completion through end of Project addresses details of project development from beginning to end, learnings from risk reduction and alternative paths, and all test results. This requirement includes all technical/software documentation and relevant technical data (including software products per TRMC Common Terminology definitions) for conclusions made, including approach descriptions, rationale, and findings for all successful and failed efforts throughout the execution of the entire project.

TRMC T&E/S&T BAA Enclosure 2: page 1 TRMC T&E/S&T BAA Enclosure 2: page 5