9k.__Attachment_Q_-_Contract_Data_Requirements_List_.pdf
PDF 719 KB Posted
- Attached to
- Space Exploration Networks Services and Evolution (SENSE) Federal contract opportunity
- Solicitation number
- NNG17588638R
About this file
Attachment Q - Contract Data Requirements List
View the file
Other files for this federal contract opportunity
Show all 50
Space Exploration Networks Services and Evolution (SENSE) has more files on GovTribe.
On GovTribe
Work with this file on GovTribe
- Download the original file
- Contacts named in this file
- Similar government files
- Ask GovTribe AI about this file
Text version
NNG17588638R
CONTRACT TBD
ATTACHMENT Q
Space Exploration Network Services and Evolution
(SENSE)
Contract Data Requirements List
May 2017
National Aeronautics and Space Administration Goddard Space Flight Center Greenbelt, MD
SPACE EXPLORATION NETWORK SERVICES AND EVOLUTION (SENSE)
Contract Data Requirements List Introduction
| The | Contract | Data | Requirements | List | (CDRL) | governs | data | required | by | the | contract. | The | |
| contractor | shall | deliver | data | as | required | by | task | order | Statements | of | Work | (SOWs) | and |
| described | by | the | Data | Requirements | Descriptions | (DRDs) | included | herein | and | listed | on | the | Data |
| Requirements | List | (DRL). | All | data | shall | be | prepared, | maintained, | and | delivered | to | National | |
| Aeronautics | and | Space | Administration | (NASA) | in | accordance | with | the | requirements | of | the | task | |
| order | SOWs | and | CDRL. |
The CDRL uses functional categories to segregate of DRDs as follows:
| Designation | Description | |||
| MGT | Management | |||
| SUS | Sustaining | |||
| OPS | Operations | |||
| MTS | Maintenance | |||
| FAC | Facilities | |||
| SEC | Security | |||
| NI | Network | Integration | ||
| SMA | Safety | and | Mission | Assurance |
| SE | System | Engineering | ||
| DEV | Development |
| Data | Requirements | List | ||||||||||||
| The | DRL | provides | a | listing | of | the | DRDs | that | may | be | required | by | task | orders. |
| For | each | DRD, | the | DRL | indicates | the | following. | |||||||
| • ID | – | DRD | Identifier. | |||||||||||
| • Title | – | DRD | Title | |||||||||||
| • Submission | Requirements | – | The | Contractor | shall | deliver | the | CDRL | item | per | the | timing |
| specified | in | the | Submission | Requirements | field | unless | otherwise | directed | in | the | task | order. |
| • Approval/Review/Information | (A/R/I) | - |
| 1. Approval: | The | Contractor | shall | receive | approval | from | the | Government | prior | to | |||||
| implementing | CDRL | items | designated | with | an | A | code. | If | the | contractor | has | not | received | a | |
| written | response | from | the | government | within | thirty | (30) | calendar | days | of | delivery | of | a | ||
| CDRL | item, | the | contractor | may | proceed | as | if | the | CDRL | item | has | been | approved. | The | |
| Contractor | shall | resubmit | the | document | within | fourteen | (14) | calendar | days | of | receiving | ||||
| written | feedback | from | the | Government. |
| 2. Review: | The | Contractor | shall | implement | CDRL | items | designated | with | an | R | upon | ||
| submission | to | the | Government. | The | Government | will | review | the | CDRL | item | and | may | |
| provide | feedback. | The | Contractor | shall | resubmit | the | CDRL | item | within | fourteen | (14) | ||
| calendar | days | of | receiving | written | feedback | from | the | Government. |
| 3. Information: | The | Contractor | shall | deliver | CDRL | items | designated | with | an | I | to | the | |
| Government | for | Government | use. |
Markings
| The | Contractor | shall | not | deem | any | documentation | produced, | or | other | information | gathered, | as | |
| a | result | of | work | under | this | Performance | Work | Statement, | as | proprietary | to | the | Contractor. |
| Unless | specifically | required, | the | Contractor | shall | not | place | any | corporate | identification | on | |||
| anything | produced | under | this | Performance | Work | Statement | except | for | the | company | name, | |||
| address, | telephone | number, | address | and | website | on | a | single | page | inside | the | cover | of | |
| multi-page | documents | or | a | single | slide | at | the | beginning | of | a | multimedia | presentation. |
Delivery
| The | Contractor | shall | deliver | CDRL | items | to | the | Government | electronically, | through | a | |||||
| communally | used | mechanism | such | as | or | a | web | portal. | The | Contractor | shall | protect | the | |||
| CDRL | data | in | accordance | with | the | information | security | requirements | in | the | contract | task | ||||
| orders. | The | contractor | shall | provide | the | CDRL | items | in | commonly | used | formats | such | at | PDF, | MS | |
| Word, | MS | Excel, | MS | Project, | JPEG, | etc. | ||||||||||
| The | Contractor | shall | notify | the | Contracting | Officer, | Contracting | Officer’s | Representative, | Task | ||||||
| Monitor, | and | configuration | manager | of | CDRL | item | delivery. | The | Contractor | shall | include | |||||
| revision | level, | date, | and | a | detailed | description | of | the | changes | for | updated | CDRL | items. | Where | ||
| available | (i.e., | MS | Word, | MS | Excel, | MS | Visio), | the | Contractor | shall | deliver | updated | CDRL | items | ||
| with | the | track | changes | function | on. |
| ID | Title | Submission | Requirements | A/R/I |
| Management |
MGT-01 Integrated Management Plan Upon update A
| MGT-02 | Task | Implementation | Plan | and | |
| Cost | Proposal | Per | Task | Order | A |
MGT-03 Management Schedule Monthly I
MGT-04 Management Reports and Reviews
| Daily, | Weekly, | Monthly, | Quarterly, | and | as | |
| required, | per | the | submission | table | within | the |
DRD
I
| MGT-05 | Phase | Out | Plan | |||||
| 24 | months | prior | to | contract | end; | with | updates | |
| at | 12 | months, | and | 3 | months | prior | to | contract |
end
A
| MGT-06 | Work | Breakdown | Structure | and | |||
| Dictionary | With | Task | Implementation | Plan | if | required | A |
MGT-07 Contract Financial Reports Monthly I
| MGT-08 | Customer | Mission | Cost |
| Reporting | and | Estimates |
| Mission | Cost | Reports, | Actuals | - | Monthly | |
| Estimate | of | Mission | Integration | Effort | - | Request |
| +1 | week | |||||
| Mission | Level | Cost | Estimate | – | Request | +2 |
weeks
I
ID Title Submission Requirements A/R/I
| MGT-09 | Configuration | Management | |
| Plan | Upon | update | R |
MGT-10 Configuration Control Board Documentation
| Three | working | days | prior | to | the | applicable |
| government | configuration | control | board |
I
MGT-11 Risk Management Plan and Risk List
| Plan | - | Upon | update |
| List | - | Monthly |
R
| MGT-12 | Systems | Engineering | |||
| Management | Plan | (SEMP) | Upon | update | R |
Sustaining
| SUS-01 | Reliability, | Maintainability, | and | |
| Sustaining | Plan | Upon | update | R |
SUS-02 Technical Refresh Plan Task award +6 months R
| SUS-03 | TDRS | Spacecraft | Performance | ||||||
| Trending | Plan | Task | award | +4 | weeks | with | annual | updates | R |
| SUS-04 | TDRS | Spacecraft | Parameter |
| Trending | Report | Weekly | I |
| SUS-05 | TDRS | Constellation | Reliability | |||
| Report | Annually | (October) | and | as | requested | I |
| SUS-06 | TDRS | Constellation |
| Management | Plan |
| Task | award | +6 | weeks | with | annual | updates |
| (October) | and | as | requested |
A
| SUS-07 | Spacecraft | On-Orbit | Anomaly | |||||
| Report | Within | 30 | days | after | any | on-orbit | anomaly | I |
SUS-8 TDRS End of Mission Plans Annually or upon loss of a TDRS R
| SUS-09 | Configuration | Item | Database |
| Reports | Annually | I |
Operations
| OPS-01 | Operations | Manuals | and | ||||
| Procedures | At | task | completion | and | as | requested | I |
| OPS-02 | Continuity | of | Operations | Plan |
| and | Procedures | Upon | update | A |
| OPS-03 | Government | Property | & | ||
| Logistics | Management | Plan | Upon | update | R |
OPS-04 Inventory Reports Annually I
OPS-05 Training and Certification Plan
Task award +4 weeks
I
Maintenance
| MTS-01 | Maintenance | Manuals | and | ||||
| Procedures | At | task | completion | and | as | requested | I |
| MTS-02 | Aggregate | Software | Version | |||
| Description | As | required | by | task | order | I |
| Facilities | |||||||||||
| FAC-01 | Facilities | Management | Plan | Task | award | +8 | weeks | and | upon | update | R |
| FAC-02 | Environmental | Management | |
| Plan | Annual | update | R |
ID Title Submission Requirements A/R/I
| FAC-03 | Environmental | Site | Assessment | As | required, | prior | to | site | activities | and | at | the |
| conclusion | of | site | activities |
R
| FAC-04 | Facilities | Master | Plan | As | specified | in | FAC-01 | R | |
| FAC-05 | Geodetic | Survey | Report | Upon | completion | of | Geodetic | Survey | I |
| Security | |||||||||
| SEC-01 | Security | Management | Plan | Upon | update | A | |||
| SEC-02 | IT | System | Security | Plan | Upon | update | A | ||
| SEC-03 | Security | Reports | and | Records | Submitted | based | upon | events | I |
| SEC-04 | TDRS | Protection | Plan | Upon | update | A | |||
| SEC-05 | IT | Security | Management | Plan | Upon | update | A |
SEC-06
Information Security Plan of
Action and Milestones
(POA&M)
Monthly
I
Network Integration
NI-01
| Service | Agreement | and |
| Requirements | Document |
(SARD)
3 months prior to launch or mission supports
R
| NI-02 | Mission | Operations | Readiness |
| Review | (MORR) |
| 1 | month | prior | to | launch | or | mission | supports |
| 2 | weeks | prior | to | ELV | supports |
I
| NI-03 | Customer | Interface | Control | |||
| Documents | 4 | months | prior | to | launch | R |
NI-04 Network Integration Schedule Monthly I
| NI-05 | Compatibility | and | Risk |
| Mitigation | Test | Plans |
| Draft | 20 | working | days | before | test | start | date |
| Final | 2 | working | days | before | test | start | date. |
I
| NI-06 | Post | Mission | Reports | TBD | I |
| NI-07 | Lessons | Learned | Reviews | TBD | L |
| NI-08 | Network | Priority | List | Quarterly | R |
| NI-09 | SCaN | Communications | Mission | |
| Model | (SCMM) | Database | Weekly | I |
| NI-10 | Architecture | Data | Management | ||
| Plan | Task | award | +8 | weeks | A |
| NI-11 | Post-Test | Data | Packages | and | |
| Reports | Test | completion | +1 | week | I |
| NI-12 | Modeling | and | Simulation | ||||
| Analysis | Report | As | required | in | task | orders | I |
| NI-13 | SN | and | NEN | Users | Guide | Annually | I | |||
| NI-14 | Spectrum | Studies | and | Analyses | As | required | in | task | order | I |
Safety and Mission Assurance
| SMA-01 | Mission | Assurance | |||
| Implementation | Plan | (MAIP) | Upon | update | A |
| SMA-02 | Mission | Assurance | Compliance | |||
| Matrix | With | Mission | Assurance | Management | Plan | A |
SMA-03 Reporting of F/ARB Actions
| Initial | submission | to | the | project | office | within | 24 | ||
| hours | of | occurrence | |||||||
| Notice | of | a | change | in | status | within | 24 | hours | of |
occurrence
A
| ID | Title | Submission | Requirements | A/R/I | |||
| Proposed | closure | to | the | project | office | prior | to |
closure
| SMA-04 | Emergency | Preparedness | and | ||
| Disaster | Recover | Plans | Upon | update | A |
| SMA-05 | Request | for | a | Waiver | Within | 5 | working | days | of | identifying | the | need |
| for | a | waiver |
I
SMA-06 System Safety Program Plan Development task award +8 weeks A
| SMA-07 | Hazard | Analysis | |||
| Preliminary | – | development | task | award | +8 |
weeks Final – development task award +16 weeks
I
SMA-08 FMECA and Critical Items List Development task award +16 weeks I
SMA-09 Fault Tree Analysis
Preliminary – development task award +8 weeks
| Final | – | development | task | award | +16 | weeks |
| Upon | update |
I
| SMA-10 | Limited-Life | Items | Analysis | Development | task | award | +16 | weeks |
| Upon | update |
I
SMA-11 Software Assurance Plan
Preliminary – development task award +4 weeks
| Final | – | development | task | award | +12 | weeks |
| Upon | update |
R
SMA-12 Software Assurance Status Report
Monthly beginning development task award +8 weeks
I
| SMA-13 | Version | Description | Document | With | each | system | delivery | I |
| SMA-14 | Safety | Report | Monthly | I | ||||
| SMA-15 | Laser | Safety | Manual | Upon | update | A |
| System | Engineering | ||||||||
| SE-01 | Studies | and | Analysis | As | required | in | task | orders | I |
| SE-02 | Project | Definition | and | Concept | |||||
| Review | (PDCR) | package | As | required | for | development | task | orders | TBS |
SE-03 Operations Concept (OpsCon) As required for development task orders TBS
SE-04 Systems Requirements Specification
As required in task order TBS
SE-05 Interface Requirements Specifications
As required in task Order TBS
SE-06 System Design Document As required for development task orders TBS
| SE-07 | Internal | Interface | ||||||
| Requirements | Specifications | As | required | for | development | task | orders | TBS |
SE-08 Interface Control Documents As required for development task orders TBS
| SE-09 | Systems | Software |
| Requirements | Specifications |
As required for development task orders TBS
| SE-10 | Modeling | and | Simulation | Plan | As | required | for | development | task | orders | TBS |
| SE-11 | Technical | Reviews | As | required | for | development | task | orders | R |
| Development | |||||||||
| DEV-01 | Design | Description | As | required | for | development | task | orders | TBS |
ID Title Submission Requirements A/R/I
| DEV-02 | Element | and | Infrastructure |
| Design | Documents |
As required for development task orders TBS
DEV-03
Software Management and
| Development | Plan | |||||
| As | required | for | development | task | orders | TBS |
| DEV-04 | Software | Design | Descriptions | As | required | for | development | task | orders | TBS | |
| DEV-05 | Software | Delivery | Package | As | required | for | development | task | orders | TBS | |
| DEV-06 | Database | Design | Descriptions | As | required | for | development | task | orders | TBS | |
| DEV-07 | Integration | and | Test | Plans | As | required | for | development | task | orders | TBS |
Management
| DATA | REQUIREMENTS | DESCRIPTION | (DRD) | 1. | IDENTIFIER: | MGT-01 |
| 2. | TITLE: | Integrated Management Plan 3. | DATE: | 6 February 2017 | ||
| 4. | DESCRIPTION/PURPOSE: |
Describes the contractor's integrated management processes, organization, and standards for overall management of all SENSE task orders.
5. DATA REQUIREMENTS:
CONTENT:
The Integrated Management Plan shall address the contractor's process for work definition and authorization, schedules and scheduling, budgeting, data accumulation, health and safety, mission assurance, corrective action, subcontract management, indirect cost management, baseline control, organization structure identifying critical positions, and information and data management.
The plan shall describe the comprehensive integration of all management processes of the prime, subcontractors, and major vendors, and interaction with the Government.
The plan shall identify:
• Interoperability standards applicable to the contractor’s Government interaction.
• Systems specifically required to accomplish the Statement of Work
• Systems and procedures that are to be set in place by the contractor.
The plan shall include:
• Interrelationships of technical management, business management, and subcontract management.
• An organizational chart identifying all managerial positions by title, position qualifications, and physical location.
• An Operations Plan that includes a detailed description of the responsibilities and authorities for operation and management of this program, from lower levels through intermediate management to top-level management.
• Management elements such as the span of control, degree of autonomy, and lines of communication.
• All interfaces with NASA personnel, and major subcontractors shall be clearly delineated.
The plan shall provide a process to ensure all services are in a state of operational readiness at all times, including preparations for mission launches and sustaining levels of performance throughout mission lifetimes. The plan shall provide for regular monitoring of all activities under this contract and provide visibility to NASA.
The plan shall show interrelationships with more detailed plans and procedures for assuring the operational readiness of all services required by task orders. This plan shall reference more detailed plans, as applicable, such as those for configuration management, risk management, systems engineering, security, continuity of operations, property management, facilities management, safety, and mission assurance.
| DATA | REQUIREMENTS | DESCRIPTION | (DRD) | 1. | IDENTIFIER: | MGT-02 |
| 2. | TITLE: | Task Implementation Plan and Cost Proposal 3. | DATE: | 1/26/17 | ||
| 4. | DESCRIPTION/PURPOSE: |
To provide a contractually binding response to a Government Task Order
5. DATA REQUIREMENTS:
CONTENT:
The Task Implementation Plan shall include all information required to determine the reasonableness of the Contractor's proposal in response to the Task Order.
The Task Implementation Plan shall include as a minimum the following:
• The technical approach for the specific requirements of the task;
• The schedule for completing the effort, including key milestones, the flow of activities from start to completion (including timeline), and approach for meeting milestones and documentation requirements;
• Period of performance;
• Elements of your organization involved;
• Task management, including configuration and cost control by work breakdown structure (WBS);
• External and internal organizational interfaces, both Government and
Contractor;
• Staffing plan and skill mix consistent with the technical approach and schedule; identifying key/critical labor categories;
• Subcontracting arrangements and commercial service providers;
• Resources, such as facilities and equipment, including GFE/GFP, necessary to successfully accomplish the task;
• Identification of potential technical challenges, critical issues, including specific risk identification and mitigation;
• Any assumptions made in preparing a response to the Task Order must be clearly stated and described in detail.
The Cost Proposal shall include time phased cost information by element and any other information required to determine the reasonableness of the Contractor's proposal in response to the Task Order, to include the Basis of Estimate.
APPLICABLE DOCUMENTS:
a. Individual IDIQ Task Order/Modification
REFERENCE DOCUMENTS:
a. User Guide for National Aeronautics and Space Administration Task Order Management System
| DATA | REQUIREMENTS | DESCRIPTION | (DRD) | 1. | IDENTIFIER: | MGT-03 | |
| 2. | TITLE: | Management | Schedules | 3. | DATE: | 1/26/17 | |
| 4. | DESCRIPTION/PURPOSE: | ||||||
| To | provide | schedules | necessary | to | manage | contract | work |
| 5. | DATA | REQUIREMENTS: |
CONTENT:
The management schedules shall identify and track significant internal and external activities and milestones to provide management insight into key initiatives.
The schedule shall include:
• Top Level Sense Schedule that addresses all Task Orders and captures tasks, milestones, and external events that are interdependent and/or inter-related across contract tasks and activities
• Network(s) Integration Schedule
• HSF Network Schedule
• Operations Plans
• Sustaining Engineering and Implementation Plans
• Schedule information for each major ongoing activity in the contract, including test and development events as well as mission operations.
• Logically linked activities as appropriate with predecessors and subsequent tasks to show individual activity completion.
• Internal and external dependencies.
• Critical milestones for each activity; critical path for all system development and facility design/construction/commissioning phases
• Float against each critical path.
The schedule shall be resource-loaded to the extent practical; loading shall be traceable to labor hours expenditures and forecasts presented in management and cost reviews.
Note detailed SN operations schedule information shall not be disseminated outside SN organizations.
Individual task schedules (e.g., the HSF Network Schedule) shall be tailored to the needs of the individual tasks
APPLICABLE DOCUMENTS:
• NASA-SP-2010-3403, NASA Schedule Management Handbook
• Approved SENSE Integrated Management Plan (MGT-01)
• Task Implementation Plan and Cost Proposal (MGT-02) for each active SENSE task order
• Approved SENSE Work Breakdown Structure (WBS) and WBS Dictionary (MGT-06)
| DATA | REQUIREMENTS | DESCRIPTION | (DRD) | 1. | IDENTIFIER: | MGT-04 |
| 2. | TITLE: | Management Reports and Reviews 3. | DATE: | 23 January 2017 | ||
| 4. | DESCRIPTION/PURPOSE: |
To provide government management insight into contract activities, accomplishments and performance
5. DATA REQUIREMENTS:
CONTENT:
The contractor’s reports and presentation material for reviews shall include the status information required for overall management of the SENSE contract as well as for management of individual Task Orders and organizational elements, nominally depicted within the Table of Submissions, below. For example, separate detailed monthly reviews are required for the SN Project, NEN Project, Networks Integration Management Office (NIMO), and for each additional task order.
All reports and reviews shall be of sufficient depth and clarity to permit understanding and evaluation of progress made. Supporting data in the form of charts, graphs, schedule depictions, etc., shall be included as appropriate. Reports shall include relevant issues and concerns with corresponding action plans. For reports including action items, action items shall include list of actions, actionees, due dates and status.
Reports and reviews shall contain the specific content requirements as defined for each type of report or review in the Table of Submissions, below.
APPLICABLE DOCUMENTS:
The following Applicable Documents apply to mishap and anomaly reporting:
a. NPR 8621.1, NASA Procedural Requirements for Mishap and Close Call Reporting, Investigating, and Recordkeeping
b. NASA Form 1627 (NASA Mishap Report)
c. 400-PG-8621.1.1 Anomaly Notification System For Code 400 Programs And Projects
TABLE OF SUBMISSIONS:
Title Frequency Content Daily Operations Summary Reports
Daily Describe the customers and time supported, support anomalies, special event status, equipment status, and upcoming events (e.g., tests, Engineering Changes, training) for SENSE in a daily e-mail.
The Daily Operations Summary shall contain:
• Total number of events scheduled for SN, NEN or CTA, the total number of customer events scheduled for each resource, and o SN: Total forward and return service time scheduled and total data loss per customer and totaled for the SN.
o NEN: Subtotaled for the NEN resource, the customer, and totaled for the NEN.
• An itemized listing of Customer Events describing any anomalies that affected customer services. Other significant operations problems that did not affect customer services shall be described separately.
• An itemized listing of supported activities or tests which contains a description of each scheduled activity’s objectives and results
• An itemized listing of Services and Equipment Status that provides a list of equipment that has failed or is currently inoperable o SN: Spacecraft Activities section, which contains a description of any TDRS activities and results.
• Forecast Schedule o SN: A listing of upcoming TDRS spacecraft operations, engineering, maintenance, test, and customer launch activities for a period of one week into the future.
• NEN: An itemized listing of STDN Launch Forecast.
Weekly Status Reports
Weekly Status of contract activities provided weekly
Monthly Status Review
Monthly The review content shall describe accomplishments against metrics and goals; status and plans for changing customer requirements; and status and plans for operations, maintenance, engineering, and support functions, as applicable. Issues, risk identification and tracking, and problem areas shall be highlighted. Technical status, metric performance (as applicable), cost performance, and schedule performance shall be presented. Discussion of problems shall include proposed solutions. Maintenance status shall include the status of any new equipment requests. For NIMO, the review shall include an integrated status of NEN and/or SN readiness to support new customers. For any SENSE contractor responsibilities for mission project customers’ sustaining engineering, the review shall include issues and status of problems pertaining to that customer. Reports including security status shall include IT metrics, system inventory changes, and updates to security risks and Plan of Action and Milestones. These reviews shall include quantitative and qualitative assessments regarding the State of Health (SOH) of the hardware and software baselines. At the overall SENSE level, the review shall include current status, health and safety, cost estimate at complete for all task orders, and upcoming major events.
Quarterly Technical Reviews
Quarterly The review material shall be scoped for a single all-day review.
These reviews shall include general content of the monthly reviews, but in more depth in site-specific areas. These reviews shall include quantitative and qualitative assessments regarding the State of Health (SOH) of the hardware and software baselines, along with a software and software license inventory report. These reviews shall include depictions of schedules, as well as spares status for each network/site, as applicable.
Service Accounting and Resource Utilization Report
Monthly Data service units (e.g., Single Access and Multiple Access minutes, orbital NEN passes, etc.) scheduled and delivered to each customer mission. Note: This report is used for the purposes of customer billing, audit and investigation, trending, and cost reporting.
Configuration Change
Monthly Summary of all proposed and completed changes to configurations and Operations and Maintenance procedures.
Summary Report
Significant Event Report
Upon occurrence
Brief e-mail description of significant events as they occur, both positive and negative (such as service outage, mishaps, close calls, successful lunches, etc.). Reporting shall cover all operational elements, including the contractor operated tracking stations, and commercial/foreign tracking stations.
Safety Summary Report
Monthly A summary report of the current month’s Close Calls, Mishaps, Vehicle accidents, OSHA recordable and a lost time incidents, etc.,.
Maintenance Activity Report
Bi-weekly Bi-weekly report of any repairs, new equipment added or decommissioned
| DATA | REQUIREMENTS | DESCRIPTION | (DRD) | 1. | IDENTIFIER: | MGT-05 |
| 2. | TITLE: | Phase Out Plan 3. | DATE: | 30 January 2017 |
4. DESCRIPTION/PURPOSE:
To establish and document plans to close out the SENSE contract and transition SENSE equipment and information to follow-on contractor(s).
5. DATA REQUIREMENTS:
CONTENT:
The Phase-Out Plan shall establish cost effective mechanisms to ensure the smooth and orderly transition of SCNS systems.
The Plan shall address:
• How ongoing work will be maintained and handed-over,
• The Phase-Out management organization,
• Phase-Out schedules with key milestones, checklists, status reporting, orientation and training of successor personnel.
• The approach for security, logistics and property management function transition.
• The schedule for inventory and delivery of the government furnished property, databases, hardware and software configuration items, documentation and procedures, etc.
The Plan shall include and provide for the actual transfer of all information produced or maintained under the SENSE contract that would be necessary for uninterrupted continuation of services, including operations procedures, training materials, and as-installed system configuration information. This information shall be made available to the government in sufficient time for it to be included in the bidders’ library for the follow-on contract competition.
| DATA | REQUIREMENTS | DESCRIPTION | (DRD) | 1. | IDENTIFIER: | MGT-06 | |
| 2. | TITLE: | Work Breakdown Structure and Dictionary | 3. | DATE: | 23 January 17 | ||
| 4. | DESCRIPTION/PURPOSE: |
Organize and track costs of task order work.
5. DATA REQUIREMENTS:
CONTENT:
The WBS shall encompass all the services required to achieve all the requirements of the SENSE contract. The WBS shall subdivide the work to be accomplished against the task order work statement tasks that serve as the basis for detailed planning and control, and in addition, permit collection of cost and schedule data for each element.
The WBS shall graphically depict the WBS tree. The Dictionary shall contain a concise description of contract activities to be performed and products to be delivered, subdivided by WBS element. A WBS element may represent an identifiable product, a set of data, a service, a task, or a budget function. The initial WBS submittal shall display the WBS elements as they are associated with the respective RTOs.
The structure shall be at least at one level of detail lower than that specified in the RFP Section L with additional levels as required by the contractor. Lower levels of detail, which the contractor uses for its own management purposes to validate information reported to NASA, shall be compatible with NASA requirements and be accessible by NASA. The relationship between the WBS and the contractor's internal organizations and processes shall also be provided.
APPLICABLE DOCUMENTS:
a. NPR 9501.2, NASA Contractor Financial Management Reporting
b. 48 CFR, Chapter 18, NASA Federal Acquisition Regulation (FAR) Supplement (NFS)
c. Financial Management Manual (FMM) Volume 9000 Chapter 9060 and Volume 9100 Chapter
9060 (https://www.hq.nasa.gov/fmm/fmmintro.htm)
| DATA | REQUIREMENTS | DESCRIPTION | (DRD) | 1. | IDENTIFIER: | MGT-07 | |
| 2. | TITLE: | Contract Financial Report | 3. | DATE: | 13 January 17 | ||
| 4. | DESCRIPTION/PURPOSE: | Provide regular SENSE contract financial status to SENSE and Task |
Order management staff.
5. DATA REQUIREMENTS:
CONTENT:
The required reports are identified below. With the exception of the 533M and 533Q, formats will be determined by the contractor.
Overall costs shall be reported at the contract level. The reports shall address all financial activity for every Task Order, and clearly identify the Task Order(s) within each report.
• The SENSE Contract Funds Status Report shall provide the initial amount of funds received, time remaining in the contract period, the remaining amount of funds and the percentage utilized versus the percentage remaining. Details regarding expenditures against labor and materials shall be provided in the Cost Review Report and Package delivered with the 533M and 533Q.
• The Financial Forecast shall identify anticipated expenditures through the next 3 reporting periods, along with any potential or anticipated funding shortfalls by WBS element/Task Order and provide labor and material financial information.
• The Financial Reports, 533M and 533Q shall be submitted in accordance with the Attachment H – Financial Management reporting Requirements.
• The Cost Review Report shall provide an in depth review of the most recently delivered NASA Form 533M. The report shall include costs of efforts for all contract Task Orders. Material shall be tracked separately from labor costs. Documents to be included as part of the report shall include:
1) A narrative variance report by each WBS element/Task Order in a document format that explains the variances between the forecast and actual charges for each month.
2) The value of the open commitments for each month by WBS element/Task Order.
3) Staff Month (SM) phasing plan by WBS element/Task Order, by resource category (to follow monthly proposed staffing plan).
4) Monthly cost trend analysis for the overall contract, by WBS element/Task Order. This analysis shall cover a rolling 12 month period. It shall include:
a) A graphical representation by WBS element/Task Order of data to include the value of the planned budget, cumulative actuals, cumulative forecast, monthly plan, monthly forecast, and monthly actuals. The graph will be formatted to include two Y axis scales, chosen such that the values for the cumulative data and the monthly data can be easily determined on the graphic.
b) Tables of cost elements that include the labor hour by prime and subcontractor, labor cost by prime and subcontractor, materials, facilities, travel, other direct charges, etc. The data shall include planned budget, cumulative actuals, cumulative forecast, monthly plan, monthly forecast, monthly actuals, variance from plan, and EAC for each cost element identified above.
APPLICABLE DOCUMENTS:
d. NPR 9501.2, NASA Contractor Financial Management Reporting
e. Title 48 CFR, Chapter 18, NASA Federal Acquisition Regulation (FAR) Supplement (NFS) (https://www.hq.nasa.gov/office/procurement/regs/nfstoc.htm
f. NASA FMM Volume 9000: Principles and General Policies, NASA Financial Management Manual (FMM) Volume 9000 Chapter 9060 (https://www.hq.nasa.gov/fmm/fmmintro.htm)
g. NASA FMM Volume 9100: Agency Coding Structure, NASA Financial Management Manual (FMM) Volume 9100 Chapter 9060 (https://www.hq.nasa.gov/fmm/fmmintro.htm)
| DATA | REQUIREMENTS | DESCRIPTION | (DRD) | 1. | IDENTIFIER: | MGT-08 |
| 2. | TITLE: | SENSE Customer Mission Cost Reporting and |
Estimates
3. DATE: 30 January 2017
4. DESCRIPTION/PURPOSE:
Provide actual costs for SENSE support to specific missions, in addition to cost estimates for advanced planning and mission integration efforts.
5. DATA REQUIREMENTS:
CONTENT:
Mission Costs Report Actuals Provide actual monthly costs for individual missions broken out by lower level line items to be defined (example: Advanced Planning, Coverage Assessment, PSLA, NRR, Network Test Plan/testing, OPSCON Document, MORR, Compatibility Testing). The reporting will be used for costing at the mission level.
1. WBS
2. Mission Name
3. Line Item Level
4. Month/FY
5. Total
Estimate of Mission Integration Effort Work shall be estimated in order to pass potential cost information along to the customer for Mission Planning and Integration (MP&I) planning.
1. Cost estimates to be developed upon Government request
2. To include both SCaN, ESC and mission related costs, following the Mission and Planning and
Integration approach, per fiscal year for the duration of the pre-launch effort
Mission Level Cost Estimate Provide Rough Order of Magnitude (ROM) Cost Estimates for individual missions broken out by lower level line items to be defined (example: Advanced Planning, Coverage Assessment, PSLA, NRR, Network Test Plan/testing, OPSCON Document, MORR, Compatibility Testing). The Cost Estimates will be provided to the customers for planning purposes.
1. WBS
2. Mission Name
3. Line Item Level
4. FY
5. Total
| DATA | REQUIREMENTS | DESCRIPTION | (DRD) | 1. | IDENTIFIER: | MGT-09 |
| 2. | TITLE: | Configuration Management Plan 3. | DATE: | 1/23/17 | ||
| 4. | DESCRIPTION/PURPOSE: |
To describe and enforce the contractor’s approach for accomplishing the configuration requirements of the contract for all SENSE sites, systems, and test facilities as defined in the awarded RTOs, throughout the project lifecycle, to include hardware, software, firmware, operations/test configurations, and documentation
5. DATA REQUIREMENTS:
CONTENT:
The CM plan shall describe how CM will be conducted throughout the project lifecycle. The plan shall cover all hardware, software, firmware, operations/test configurations, and documentation for all ESC sites and systems as defined in the awarded task orders. Documentation includes drawings, facilities documents, operations and maintenance documentation, test documentation, training/certification documentation and other records as required by task order.
The plan shall prescribe the configuration management processes to be implemented and methods to be used for configuration identification, interface control, change control, documentation control, status accounting, and configuration verification.
The plan shall describe the contractor’s CM organization, policies, roles and responsibilities, configuration management (CM) definitions, procedures, implementation approach, and control systems that are to be used to ensure proper performance of all required contract CM activities.
The plan shall describe the NASA participation in the contractor Configuration Management process.
The plan shall describe the process for providing a brief description of all proposed changes to be prepared and transmitted to the designated NASA engineering representative prior to each configuration control board or forum meeting held by the contractor.
The contractor’s configuration management processes and control systems shall include maintaining configuration information in a form and structure such that configuration information is available to the government as needed.
The Plan shall include the following documentation trees to provide a reference for the primary ESC documentation to be managed under SENSE. These trees shall be organized and identified to serve as a ready reference list. Updates to these trees shall be delivered when changes are implemented.
ESC Networks Document Tree shall depict the hierarchy and interrelationships of the Government and contractor documents and deliverables on the contract, and shall contain a graphical illustration of project management, system engineering, facilities, integration, test, maintenance, operations, and sustainment documents for each ESC network, their hierarchy, and interrelationships, as appropriate.
The Networks Document Tree shall:
• Include all documents for the ESC networks and show relationship(s), delivery phasing, and maturation phasing.
• Incorporate, through and as directed by ESC, document tree contents provided by GFP vendors.
• Identify documents by name and number.
• Include a brief description defining the scope of each document.
ESC Networks Drawing Tree shall provide a reference list for all ESC Networks drawings, and shall:
• List all drawings for ESC Networks.
• Incorporate, through and as directed by ESC, any drawing tree information provided by GFP vendors.
• Identify drawings by name and number.
• Include a brief description of each drawing.
ESC Networks Specification Tree shall provide a reference list for all ESC Networks specifications, and shall:
• List all specifications for ESC Networks.
• Incorporate, through and as directed by ESC, any specification tree information provided by
GFP vendors.
• Display traceability relationships among the specifications
• Identify specifications by name and number.
• Include a brief description of each specification, design description, and interface control document
APPLICABLE DOCUMENTS:
a. 450-PG-1410.2.1K, 450/ESC - Configuration Management Procedure
b. NASA-STD-2804: Minimum Interoperability Software Suite
c. NASA-STD-2805, Minimum Hardware Configurations
d. SGP-MGMT-PROC-0002, Space Geodesy Project Information and Configuration
Management Procedure
REFERENCE DOCUMENTS:
a. NENS-SNE-E-PM10-0009, Document Tree
| DATA | REQUIREMENTS | DESCRIPTION | (DRD) | 1. | IDENTIFIER: | MGT-10 |
| 2. | TITLE: | Configuration Control Board (CCB) Change |
Package
3. DATE: 30 January 2017
4. DESCRIPTION/PURPOSE:
To enable the configuration control board members to review and approve configuration changes
5. DATA REQUIREMENTS:
CONTENT:
The CCB Change Package shall include the following elements, as a minimum, consistent with the change control process prescribed in the CM Plan:
• Identification of all changes to hardware, software, and documentation necessary to implement the requested change, cross-referenced to the existing configuration documentation
• Rationale for and impacts of the change, including risks, cost impacts, and any mission or customer impacts
• Description of any other items or personnel affected by the change, including, but not limited to, such considerations as: test procedures, test configurations, facilities, training, security or safety measures, operations procedures, maintenance procedures, or sustainment costs.
a. Approved SENSE Configuration Management (CM) Plan (DRD MGT-09)
| DATA | REQUIREMENTS | DESCRIPTION | (DRD) | 1. | IDENTIFIER: | MGT-11 |
| 2. | TITLE: | Risk Management Plan and Risk List 3. | DATE: | 30 January 2017 | ||
| 4. | DESCRIPTION/PURPOSE: | |||||
| To | describe the Contractor’s process for identifying and managing risk. | |||||
| 5. | DATA | REQUIREMENTS: |
CONTENT:
The Risk Management Plan (RMP) shall:
• Describe the overall process, procedures, roles and tools that will be used.
• Specify the contractor risk objectives and policy toward risk.
• Explain the purpose, scope, assumptions, constraints, key ground rules, and policy pertaining to the SENSE risk management process.
• Provide an overview of the SENSE risk management process and information flow; describe how the process integrates and relates to other operations, maintenance, sustaining, development, project management and system engineering activities.
• Include risk mitigation strategies to be employed throughout the contract term.
• Show the organization, roles, and responsibilities of the SENSE Contractor and subcontractors with regard to risk management, and NASA’s involvement in the contractor’s process.
• Document how team members will be trained in the application of risk management methodology.
• Provide process details and related procedures, methods, tools, and metrics.
• Include here, or in an appendix, the specific methodologies to be used for risk identification, analysis, planning, tracking, and controlling.
• Include the process to be used for continual assessment of the risk profile.
• Describe how risk information will be communicated both internally to the contractor staff and throughout the NASA management chain.
• Specify the format and data elements (the contractor shall use “GSFC 5x5 Risk Matrix for
Class A-C Type Missions” likelihood and severity definitions for risks and their categories) that will comprise the SENSE Risk List, how configuration control will be applied, and how the list will be used and updated.
• Specify how NASA and contractor team members will be able to access the current Risk List at any time.
• The Risk List shall be current, and the current version accessible to the government, as of the contractor’s cut-off date for creating any reports or reviews that contain risk information, such that the status report or review is consistent with the Risk List.
The initial risk list, provided with the initial Risk Management Plan, shall include in the initial set of identified risks and the action plan (for research, acceptance, tracking, or mitigation) for each risk.
APPLICABLE DOCUMENTS:
a. NID 8000.108 (interim directive to NPR 8000.4A), Agency Risk Management Procedural Requirements
b. GPR 7120.4, Risk Management
c. 450-PLAN-0007, Exploration and Space Communications (ESC) Projects Division Risk
Management Plan (RMP)
d. GSFC 5x5 Risk Matrix For Class A-C Type Missions (NASA provided definitions of likelihood and severity for risks and their categories)
| DATA | REQUIREMENTS | DESCRIPTION | (DRD) | 1. | IDENTIFIER: | MGT-12 |
| 2. | TITLE: | Systems Engineering Management Plan |
(SEMP)
3. DATE: 1/31/17
4. DESCRIPTION/PURPOSE:
To describe the contractor’s systems engineering methodology, which once approved, will become an Applicable Document for systems engineering tasks performed on the SENSE contract.
5. DATA REQUIREMENTS:
CONTENT:
The Systems Engineering Management Plan (SEMP) shall be coordinated with the Integrated Management Plan (MGT-01) for integration of the technical planning and modifications related to the allocated resources, including cost, schedule, personnel, facilities, and deliverables required.
The SEMP shall:
1. Specify the systems engineering processes and procedures as applied to development of new systems and modifications to existing systems, including control boards, operational concepts, operational requirements, system requirements, functional analysis, system analysis, trade-off strategies, configuration management, and system test and evaluation strategies. Separate processes and procedures shall be tailored according to the scope of the development effort.
2. Identify systems engineering activities associated with concept development including needs analysis, concept exploration, concept definition and Technology Readiness Levels (TRL).
Items to be addressed shall include the processes associated with the identification of operational deficiencies, technological opportunities, system trade studies, feasibility experiments, system operational requirements, system requirements definition, system performance requirements, and functional architecture definition.
3. Identify systems engineering activities associated with engineering development including TRL, advanced design, engineering design, and integration and test. Items to be addressed include risk abatement through the development of proof of concept and prototype articles, the development of reliability engineering, requirements verification and validation, integration, and operational evaluation.
4. Identify systems engineering activities associated with the post development operation and support phase. The focus shall be on the role that systems engineering will play in achieving a seamless transition to an operational environment without impacting current operational activities. Items to be addressed shall include the transition activities required for transition from a development to operational environment including system preparation, configuration management, documentation, training and continued sustainment through enhancements.
5. Specify how the areas of specialty integration are to be integrated into the system design and development, including reliability, maintainability, and availability engineering, producibility engineering, safety engineering, and human factors engineering.
6. Show the organization, roles, and responsibilities of the SENSE Contractor and subcontractors with regard to systems engineering function and NASA’s involvement in the contractors’ process and boards. Document how team members will be trained in the application of systems engineering methodologies.
7. Describe the process the approval and maintenance of decisions attained pertaining to systems engineering activities.
8. Identify all active participants in the process and their prospective roles and responsibilities to one another.
9. Provide the systems engineering process details and related procedures, methods, tools, and metrics. Include here, or in an appendix, the specific methodologies to be used for systems engineering activities identification, analysis, planning, tracking, and controlling.
10. Describe how systems engineering information will be communicated both internally to the contractor staff, externally to subcontractor staff and throughout the NASA management chain.
11. Provide an overview of the systems engineering process and information flow; describe how the process integrates and relates to other operations, maintenance, sustaining, development, and project management activities.
12. Describe how technical performance measurement; risk management, and program management activities will be incorporated with systems engineering strategies as they pertain to the development of SENSE wide systems.
The SEMP shall incorporate a Transition to Operations (T2O) Plan which shall define in detail the procedure for transitioning the ESC Systems into Operations. The T2O Plan shall include:
• The Transition to Operations Plan.
• The conditions to be met prior to transition, any phasing of transition, inclusion of over-the-shoulder monitoring on the part of both the Government prior to transition and the Contractor personnel just prior to Government acceptance.
• The initial transition of the ESC Systems capabilities into Operations and the subsequent transition of the operations support and sustainment.
• The steps taken to ensure that the safety of ESC Systems is maintained through the transition process.
• A transition and operations support schedule including milestone events, consistent with the IMP/IMS, detailing the entrance, success, and exit criteria.
• A document overview that summarizes the purpose and contents of this document and any security or privacy considerations associated with its use.
• The relationship of the T2O plan to other plans.
• A list containing the number, title, revision, and date of all documents cited within.
• The resources needed to support the deliverable hardware and software, including items needed to control, copy, and distribute the software and its documentation, to specify, design, implement, document, test, evaluate, control, copy, and distribute modifications to the software and to maintain, trouble shoot, repair, replace, and upgrade hardware.
• The purpose of the facilities needed to support the ESC Systems deliverables, including special buildings, rooms, mock-ups, building features such as raised flooring or cabling; building features to support security and privacy requirements, building features to support safety requirements (smoke alarms, safety glass, etc.), and special power requirements. Diagrams may be included as applicable.
• The delivered hardware and associated documentation, which may include computers, peripheral equipment, hardware simulators, stimulators, emulators, diagnostic equipment, and non-computer equipment.
• The Hardware description which shall include specific models, versions, and configurations, rationale for the selected hardware, reference to user/operator manuals or instructions for each item, as applicable, information about manufacturer support, licensing, and data rights, including whether the item is currently supported by the manufacturer, whether it is expected to be supported at the time of delivery, whether licenses will be assigned to the Government, and the terms of such licenses, and security and privacy considerations, limitations, or other items of interest.
• The software and associated documentation needed to support the deliverable software, including specific names, identification numbers, version numbers, release numbers, and configurations, as applicable; rationale for the selected software; reference to user/operator manuals or instructions for each item, as applicable; information about vendor support, licensing, and data rights, including whether the item is currently supported by the vendor, whether it is expected to be supported at the time of delivery, whether licenses will be assigned to the Government, and the terms of such licenses; and security and privacy considerations, limitations, and other items of interest.
• Any other documentation needed to support the deliverable hardware and software including, for example, plans, reports, studies, specifications, design descriptions, test cases/procedures, test reports, user/operator manuals, and support manuals for the deliverable hardware and software. This Other Documentation shall provide names, identification numbers, model and serial numbers, version numbers, and release numbers, as applicable; rationale for including each document in the list; information about licensing and data rights; and security and privacy considerations, limitations, or other items of interest.
• The personnel needed to support the deliverable hardware and software, including anticipated number of personnel, types and levels of skills and expertise.
• Any other resources needed to support the deliverable hardware and software, including any consumables together with an estimate of the type and number that should be acquired.
• The interrelationships of the components identified in the preceding requirements, using diagrams as appropriate.
• All procedures, including and reflecting lessons learned, for supporting the deliverable hardware and software and associated support capabilities.
• Contractor’s plans for training, including the schedule, duration, and location for the training;
the delineation between classroom training and "hands-on" training; and the provision (either directly or by reference) for familiarization with the operational hardware and software and familiarization with the support hardware and software and host systems.
• Anticipated areas of change to the deliverable hardware and software.
• All activities to be performed to transition the deliverable hardware and software to the
Government, including planning/coordination meetings; preparation of items to be delivered to the Government; packaging, shipment, installation, and checkout of the hardware and software support environment; packaging, shipment, installation, and checkout of the operational hardware and software; and training of support personnel.
• Roles and responsibilities for each transition and operations activity, the resources needed to carry out the transition and operations support activities, and the source from which each resource will be provided
• Activity schedules and milestones, consistent with the IMP and IMS, for conducting the transition and operations support activities.
• The proposed Operations Support metrics and the process for utilizing the metrics to adjust the operations support and logistics support activities based on cost and mission performance considerations.
a. GPR 7123.1 - Systems Engineering
b. Approved SENSE Integrated Management Plan (MGT-01)
Sustaining
| DATA | REQUIREMENTS | DESCRIPTION | (DRD) | 1. | IDENTIFIER: | SUS-01 |
This is the start of the file's text. The full file is on GovTribe.
File details come from the government source that posted it. Updated .