PMDB_SOW_1.pdf

Statement of Work Research, Development, Test & Evaluation Project Management Database

1.0 OBJECTIVE

The Research, Development, Test & Evaluation (NA-11) organization must establish a program management information (PMIS) system. This system will address NA-11’s requirement to have a system, or tool, that will enable efficient program management by integrating all program management activities within the RDT&E portfolio through the tracking the progress of defined project scope, work packages, and/or priorities within each organizational unit as well as integrating budget requirements across organizations, when necessary.

2.0 BACKGROUND

The Research, Development, Test & Evaluation (RDT&E) portfolio provides the scientific foundation;

the capabilities, tools and components to enable design assessment, qualification, certification, and technology maturation; and balances the most pressing investments needed to meet Department of Defense (DoD) warhead requirements and schedules, along with the critical long-term research and development needed for a robust and responsive future stockpile.

RDT&E is comprised of the following five subprograms:

1. Assessment Science

2. Engineering and Integrated Assessments

3. Inertial Confinement Fusion

4. Advanced Simulation and Computing

5. Weapon Technology and Manufacturing Maturation

The RDT&E organization currently lacks the ability to integrate program management activities with the Planning, Programming, Budget, and Evaluation (PPBE) process throughout the life cycle of a project.

Additionally, it lacks an integrated system to track the progress of defined scope, work packages, and/or projects within each subprogram (listed above) and, where necessary, integrate budget requirements across the subprograms.

The PMIS system will be NA-11’s primary resource for program management. Over the course of the PPBE, it will serve several purposes. In the planning and program phase, the tool will be used to collect requirements from the management & operating labs, plants, and sites (M&Os) with sufficient information for the federal program manager (FPM) and office leadership to make programmatic and budgetary decisions in developing the program’s 5-year Future Years Nuclear Security Plan (FYNSP).

Information from the Project Plans (PPs) will be captured in the PMIS and will facilitate accounting for mortgages for projects over their life cycle. Once projects are funded by the program office, the tool will be used to track execution, develop roadmaps and communicate accomplishments with end users and stakeholders.

3.0 PROJECT SCOPE

The ultimate scope of the project is to design a PMIS system that will allow the NA-11 Principal Assistant Deputy Administrator (PADA) and Deputy PADA to easily track the progress of the NA-11 program. It will also allow the PADA to respond to external stakeholder inquiries from Congress and the White House’s Office of Management and Budget. The development of a Program Management Plan (PMP) will happen concurrently to acquisition and implementation of the PMIS, therefore the initial instantiation may not be what is finally deployed. The following goals and objectives capture the current understanding of what is needed:

• Goal 1 – Standardize program management.

Provide a user-friendly program management system for all members of the NA-

11 community.

Have easy access to information requested from external stakeholders.

Automate routine tasks.

• Goal 2 – Streamline decision making.

Provide transparency in scope, cost, and schedule to NA-11 Leadership.

Allow FPMs to easily coordinate cross-office scope.

Utilize modern analytical capabilities for ease of decision making.

o Provide a change control process for approval of fund transfers during execution.

• Goal 3 – Communicate effectively.

Create standardized reports and presentations for internal and external stakeholders Capture consistent information across subprograms.

• Goal 4 – Scalability.

Allow for other Defense Programs organizations to adopt it in time, should they so choose, through flexibility in construction of the application.

Utilize the information from the variety of existing tools at HQ and the M&Os and have a useable system quickly

NA-11 would like to implement a solution that can be used for the long term. The need is for something that can implemented immediately but can be updated based on user needs and lessons learned from previous instantiations. As the research and development organization of Defense Programs, being at the forefront of using artificial intelligence for efficiency in program management is an important part of this project.

4.0 REQUIREMENTS

General System Requirements

A. Security, Access, and Authorization

• Instance on both the low and high side that are reconciled at a regular interval.

• System developers will require appropriate clearances to support classified implementation.

• Access controls – need to know as well as classification.

o Appropriate interfaces and access restrictions for:

PADA/DPADA

ADAs Office Directors (ODs) FPMs Budget Team Support Service Contractors Labs, Plants, and Sites Offices – may have slightly different data/template/report needs. Should strive to minimize differences as much as possible.

• NA-113

• NA-114

• NA-115

o Appropriate access levels for:

Classified: up to Secret Restricted Data (SRD) Controlled unclassified information (CUI)

B. Version Control

• Have a schedule for updating project information to maintain version control and fidelity of information (Monthly, Quarterly or PPBE cycle).

• Central location for files, documents, user-guides, Standard Operating Procedures, etc. currently housed on DP Biz Ops and/or Shared Drive.

o To be a “dashboard” and not as a duplication of existing methodologies.

• Central repository for data calls.

o Warehouse to collect/store/reference prior year deliverables/Data Calls.

o Current and prior years.

o Pull in Crosscuts from FormEx.

• Allows collaboration on working documents while maintaining version control.

C. End User Operating Environment

• Flexible search capability.

• Main project form user interface for data entry and project review (see example in Figure 1).

• Ability to add, remove and modify data fields as needed.

o Each field should have “other”, “Not Applicable,” and flexibility to update selections.

o Some fields may be dependent on other fields.

• Ability for large data download and uploads in XLS or CSV file types.

• Ability to attach files to individual project entries (text, images, movies...etc.).

• Unclassified and classified instances should look the same. The only difference should be that detailed classified information can be included on the classified instance.

Figure 1 – Main Project Form

D. Implementation

• The system will be available 24 hours a day, 7 days a week, 365 days per year (24/7/365).

Downtimes for maintenance will be scheduled and announced to users in advance. Servers will be monitored 24/7/365.

• Real-time linkage (communication) with existing systems to limit or avoid duplication of input.

o Regular cadence of updating with other systems (e.g., daily, weekly, monthly, quarterly, or annual document linkages as appropriate).

o Should interface with milestone reporting tool (MRT) and other high visibility tools such as System to Track and Report Spending (STARS), FormEx/CostEx, G2 for infrastructure, SIR, etc. for consistency and to remove redundancy for users.

• Allows cross referencing to catch possible errors in reporting data.

• Facilitate tracking of requirements currently done in MS Teams Pages.

• Utilizes existing instances of the software at HQ and all M&Os as much as possible.

• Implements artificial intelligence (AI) solutions to utilize all available data to inform funding and programming decisions.

• Employ workflows that are scaleable to the part of the organization using them.

• Creates automated alerts for specified items to which various users should be alerted (e.g., an

M&O is 5 days late in updating monthly execution data, so the FPM receives an alert, or a project plan is submitted that has duplicative scope to an existing project in another office, both FPMs should be notified.)

• NNSA owns the data within the system.

• Minimize burden of initial data entry as much as possible.

• Provide and maintain user training and support.

Application Requirements

A. Budget

• Should handle both FYNSP planning and a single FY budget execution.

• Tracking budget with flexibility for scope that is level of effort or in the way of maintenance and operation and user support.

• Able to handle committed funding level and anticipated scenarios (for instance, IF a specific item is demonstrated, THEN we do X, OTHERWISE we do Y).

o This will enable a more realistic planning for the program multiple years out.

B. Schedule

• Able to support FYNSP planning with a five-year FY horizon if not FYNSP+2 for the higher-level DP coordinated work, and link milestones across subprograms, other programs in NA-11, and DP writ large—label designations would be OK but should be unique enough for data calls and searches.

• Should be deliverable based, include interim and final deliverables rather than quarterly updates.

C. Project/Scope Descriptions

• Captures what constitutes a project or scope/work package.

• Allows for storage of discrete tasks within a program, even if a particular task isn’t funded for a particular execution year.

D. Project/Scope Progress

• Will need to track progress based on HQ-defined metrics.

• Metrics will vary by program/office.

E. Priority Tasks/Items which Need Attention

• The ability to order a (by priority, deadline, time etc.) list of activities which need attention, are late for review, coming up for review etc.?

• Can this automatically email a summary at some cadence that a user can select?

• Dashboard and reports that tie programmatic scope and strategic priorities to funding and schedule (see example in Figure 2).

Figure 2 – Projects Roadmap

Data Requirements A. Planning & Programming Phase Data Requirements

In the planning phase, M&Os will communicate their proposed requirements to meet the mission as stated in the strategic plan and planning guidance. This will include requests for unfunded requirements (UFRs) that will be considered in programming. Below is the list of data that will be collected in the planning phase and used throughout the life cycle of a project.

• Program Management o NNSA Work Breakdown Structure (NWBS) down to Level 8 or 9 (one level below B&R) o Project ID# and Title o Site(s) (Identify lead site if multi-site project) o Needs or opportunity o Proposed solution and project scope o Benefits to nuclear security enterprise (NSE) o End use or Transition Organization (Next funding Source) o Target Program of Record o External dependencies (NA-90, NA-12, NA-19...etc.)

o Project dependencies (e.g. Technology dependent on demonstrator for technology readiness level (TRL) advancement or Mod/Sim capability dependent on experiment for Verification and Validation (V&V)) o Partnerships and collaborations o Project risks and potential obstacles o Project linkages o Laboratory Directed Research and Development (LDRD), Site Directed Research and

Development (SDRD), or Plant Directed Research and Development (PDRD) (check box) o M&O Priority (1 – 5 at intervals 20% of budget) o FPM Priority

• Strategic Alignment o Weapons Activities (WA) Integration Areas o WA Process Improvement o NA-11 Priorities o NA-115 Strategic Plan Goals & Ends o Integrated Priorities Roadmap o Requirements Drivers

• Roadmaps and Progression Metrics o Project proposal date o Project start date o Target transition date

Type of project (Progression metrics) TRL/Manufacturing Readiness Level (MRL) Line-Item construction (Critical Decision) Facility and Capability Sustainment (Level of effort) Modeling and Simulation (Level of effort) Experiments and data collection (Execution date)

• Financial Data o Note: Financial data to be collected and reported by site o +1 outyear programmed funding o +2 outyear 5-Year FYNSP o Beyond FYNSP total project cost (Line-Item and Minor Construction)

B. Execution & Evaluation Phase Requirements

The PMIS system shall continue to track data from Planning and Programming phases, as well as execution metrics listed below. The database will be the official record of funded activities and would replace some organizations’ Implementation Plans (IP) Appendix Project Lists.

• Data fields to collect in the Execution and Evaluation phase:

o Technology Transfer Agreement (TTA), Technology Realization Team (TRT), Interface

Requirements Agreement (IRA) and other agreements o Execution year scope with deliverables and milestones o Level 2 Milestones Status o Current progression metric (TRL/MRL, Critical Decision (CD), execution date) o Threats to cost, schedule, or scope o Mitigation strategy to threats to cost, schedule, or scope o Noteworthy accomplishments or information o Financial Data

Allocated site splits included in IP for Work Authorization Carry-in and carry-out numbers

5.0 REPORTING

The vendor will provide monthly status updates to the COR. Technical updates with the customer will be negotiated on an as-needed basis.

6.0 SECURITY REQUIREMENTS

The development team will need adequate personnel with DOE Q clearances to develop the classified instance of the deployed system.

7.0 PERIOD OF PERFORMANCE

Standard five-year base with five one-year renewal options.