Small Spacecraft Technology Program Guidebook for Technology Development Projects 

August 5, 2021 

National Aeronautics and Space Administration 

NASA Headquarters 

Washington, DC 
TABLE OF CONTENTS 

PURPOSE AND AUDIENCE OF THIS GUIDEBOOK...................................................................................................5 

SCOPE AND LAYOUT.........................................................................................................................................................5 

SST PROGRAM CHARTER, GOALS, AND NPR 7120.8 REQUIREMENTS *SST-NC, **SST-PS ...................6 

R&T PROJECT GUIDELINES AND RECOMMENDED PRACTICES........................................................................7 

4.1. SST PROJECT PLANNING – LIFE CYCLE. *SST-NC, **SST-PS ........................................................................................................7 

4.2. PROJECT REVIEWS. *SST-NC, **SST-PS, ***SST-SPACEDEMO....................................................................................................8 

4.3. PROJECT RESOURCES AND COST ESTIMATION RESOURCES AND TOOLS ......................................................................................11 

4.4. RISK, SAFETY, QUALITY, AND MISSION ASSURANCE. **SST-NC ..................................................................................................11 

4.4.1. RISK MANAGEMENT. *SST-NC, **SST-PS, ***SST-SPACEDEMO ..........................................................................................13 

4.4.2. SAFETY. *SST-NC, **SST-PS, ***SST-SPACEDEMO .................................................................................................................14 

4.4.3. QUALITY AND MISSION ASSURANCE. *SST-NC, **SST-PS, ***SST-SPACEDEMO ..............................................................16 

4.5. SYSTEMS ENGINEERING. *SST-NC, **SST-PS, ***SST-SPACEDEMO........................................................................................17 

4.6. CONFIGURATION MANAGEMENT. *SST-NC, **SST-PS, ***SST-SPACEDEMO ........................................................................18 

4.7. SOFTWARE ENGINEERING, ASSURANCE AND MANAGEMENT .........................................................................................................19 

4.8. PROCUREMENT QUALITY ASSURANCE. *SST-NC.............................................................................................................................20 

4.9. TECHNICAL AUTHORITY. *SST-NC .....................................................................................................................................................20 

4.10. OBTAINING A LAUNCH..........................................................................................................................................................................21 

4.10.1. LAUNCH OPPORTUNITIES AND POCS ............................................................................................................................................22 

4.11. VERIFICATION, VALIDATION, AND EXPEDITED SPACEFLIGHT QUALIFICATION TESTING ......................................................22 

4.12. SPECTRUM MANAGEMENT AND RADIO LICENSING. *SST-SPACEDEMO...................................................................................25 

4.12.1. SPECTRUM MANAGEMENT INTRODUCTION .................................................................................................................................25 

4.12.2. LEAD TIMES ........................................................................................................................................................................................26 

4.12.3. REFERENCES: ORGANIZATIONS AND POCS.................................................................................................................................26 

4.13. ODAR AND EOMP...............................................................................................................................................................................28 

4.14. PLANETARY PROTECTION...................................................................................................................................................................28 

4.15. REFERENCES TO S3VI, OTHER PORTALS AND SOURCES FOR BEST PRACTICES .........................................................................29 
 

 

Small Spacecraft Technology Program Guidebook for Rev.: - Technology Development Projects 

REFERENCE DOCUMENTS: 

Doc No SSTP.PP.01 Small Spacecraft Technology Program Plan 

GPR 8705.4 Risk Classification Guidelines 

GSFC-HDBK-8007 Mission Success Handbook for Cubesat Missions 

GSFC-STD-7000 General Environmental Verification Standard (GEVS) 

LSP-Req-317.01 Launch Services Program Program Level Dispenser and CubeSat 

Requirements Document 

NASA/SP-2016-6105 NASA Systems Engineering Handbook 

NASA-HDBK-6022 NASA Handbook for the Microbiological Examination of Space Hardware 

NASA-STD-8719.14 Process for Limiting Orbital Debris 

NASA-STD-8719.24 NASA Expendable Launch Vehicle Payload Safety Requirements 

NASA-STD-8739.6 Implementation Requirements for NASA Workmanship 

NASA-STD-8739.8 Software Assurance and Software Safety Standard 

NID 8020.109 Planetary Provisions for Robotic Extraterrestrial Missions 

NPD 8020.7G Biological Contamination Control for Outbound and Inbound Planetary 

Spacecraft 

NPD 8700.1 NASA Policy for Safety and Mission Success 

NPD 8730.5 NASA Quality Assurance Program Policy 

NPR 8715.6 NASA Procedural Requirements for Limiting Orbital Debris and Evaluating 

the Meteoroid and Orbital Debris Environments 

NPR 2570.1 NASA Radio Frequency Spectrum Management Manual 

NPR 7120.5 NASA Space Flight Program and Project Management Handbook 

NPR 7120.6 Knowledge Policy for Programs and Projects 

NPR 7120.8 NASA Research and Technology Program and Project Management 

Requirements 

NPR 7123.1 NASA Systems Engineering Processes and Requirements 

NPR 7150.2 NASA Software Engineering Requirements 

NPR 8705.6 Safety and Mission Assurance (SMA) Audits, Reviews, and Assessments 

NPR 8715.3 NASA General Safety Program Requirements 

NPR 8735.1 Exchange of Problem Data Using NASA Advisories and the GovernmentIndustry Data Exchange Program (GIDEP) 

NPR 8735.2 Hardware Quality Assurance Program Requirements for Programs and 

Projects 

2 
Small Spacecraft Technology Program Guidebook for 

Technology Development Projects Rev.: -

DOCUMENT HISTORY LOG 

Document 

Revision 

Effective 

Date Description/Name 

- 8/5/2021 Initial Release 

3 
 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Small Spacecraft Technology Program Guidebook for Rev.: - Technology Development Projects 

Introduction 

The Small Spacecraft Technology (SST) program expands the ability to execute unique 

missions through rapid development and demonstration of capabilities for small spacecraft 

applicable to exploration, science and the commercial space sector. SST seeks to embrace 

promising technologies in the public and private sectors, taking advantage of the fast pace of 

developments and driving innovation in the nation’s small spacecraft industry. SST invests in

efforts within the Agency, at academic institutions, private entities, and in public-private 

partnerships. Faster timelines and lower costs allow greater risk tolerance, providing 

opportunities to introduce new technologies and iterate through failures to create new capacities 

or recreate existing capabilities at a fraction of the traditional cost. 

Mirroring an approach pioneered by the Air Force Research Laboratory, SST can employ 

“constraint driven” approaches for small spacecraft missions. In this approach, missions are 

largely driven by technical and non-technical constraints rather than mission requirements. The 

objective in a constraint driven mission is to produce as much of the desired capability as 

possible within a fixed cost and schedule. 

This Space Technology Mission Directorate (STMD) SST Program Guidebook for Technology 

Development Projects (hereby called Guidebook) is a collection of recommended practices and 

ready references to expedite research and technology (R&T) development projects. It offers 

guidance for efficiency, best practices and improved success based on SST and NASA 

experience and SST policies. It does not reproduce or contradict existing requirements nor add 

new requirements. The Guidebook is aimed at projects implemented at NASA Centers as well 

as SST contracts and grantees. Though based on experience and policies at NASA, much of 

the recommended practices here are general and could be useful for technology development 

projects conducted by organizations in academia or the private sector. 

SST Program formulates and manages its projects as outlined in NPR 7120.8 (Chapter 4, R&T 

Project Requirements) and the SST Program Plan (Doc No SSTP.PP.01). Waivers to, or any 

requirements in addition to, NPR 7120.8 must be approved by SST Program. 

7120.8 Program Management is for Research and Technology projects: 

• Research projects: performing basic research or applied research with unpredictable 

outcomes. 

• Technology projects: attempting to solve a specific problem or address a practical need. 

• Technology Gaps: Supports NASA’s strategic efforts to identify future investment.

Success, Failure, Risk: 

• Mission Success can be defined as creating a new capability, investigating the feasibility 

of a new architecture, discovering capability limits, or exploring the trade space. 

• Mission Failure is defined as flight test data not obtained. 

• Independent assessments at key decision points replace reviews in accordance with a 

risk-tolerance approach. Economically appropriate efforts are made to understand risks, 

but cost and schedule are not used to eliminate all uncertainty in technical risks. SST 

invests in projects that have high-risk/high-reward, acknowledging only a minority will be 

transformative. 

4 
 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Small Spacecraft Technology Program Guidebook for 

Technology Development Projects Rev.: -

Purpose and Audience of this Guidebook 

This Guidebook for Technology Development Projects (Guidebook) provides recommended 

practices for the research and technology (R&T) development projects sponsored by NASA 

STMD’s Small Spacecraft Technology (SST) Program. Many of the recommended practices 

derive from lessons learned by small spacecraft developers over the course of many R&T 

projects. Lessons and best practices include such things as: various work processes that help to 

execute projects more effectively, methods and practices that advance technology more reliably 

and affordably, and experiences to help project members recognize, avoid and overcome pitfalls 

commonly encountered in technology development projects. The intent of this Guidebook is to 

capture successful experiences to make them available for the benefit of others. NASA and 

industry have published other excellent standards, processes and guidebooks with the more 

high-profile, costly, and risk-averse robotic and human spaceflight missions in mind. In contrast, 

this Guidebook aims to improve likelihood of project success within the greater risk tolerance 

and tighter budgetary and schedule constraints typical of R&T projects. This Guidebook is not 

intended to contradict existing NASA, legal or contractual requirements nor is it intended to add 

any new requirements; rather, where relevant standards and requirements do exist the 

Guidebook may provide guidance for interpreting and tailoring requirements or may suggest 

waivers where requirements are not relevant to R&T projects. 

The Guidebook is primarily for R&T projects sponsored by NASA’s SST Program. Some R&T 

projects demonstrate technologies in the lab environment, and some R&T projects are 

formulated for technology demonstration in spaceflight. Most recommended practices in this 

Guidebook are relevant to both lab and spaceflight demonstrations. 

Some SST R&T projects are executed at NASA Centers while others are executed under 

contract, grant, or cooperative agreement in the private sector or academia. Where best 

practices are relevant only to projects executed at NASA Centers, those best practices are 

denoted as such, and include the role of Technical Authority and some Safety and Mission 

Assurance (S&MA) practices. Projects executed outside NASA typically follow the entity’s 

internal safety, quality and mission assurance practices as applicable. Federal Acquisition 

Regulations, contractual and various legal requirements apply to projects executed on contracts 

or grants. See the body of the Guidebook for explicit denotation. 

Though this Guidebook is primarily for NASA SST projects, many of the recommended 

practices in it may be helpful for technology development and demonstration projects that are 

sponsored by other NASA Programs, other Government Agencies, or other organizations. 

Scope and Layout 

The SST Program and all of its projects are formulated and executed in accordance with NPR 

7120.8 NASA Research and Technology Program and Project Management Requirements. 

Material captured in this Guidebook will be updated when relevant new topics arise and as the 

experience base grows. 

For each topic in Section 4 of this Guidebook, the following layout is as follows: 

• Brief Purpose for inclusion of the Topic (italic font) 

• Topic background, guidelines, and external references, where applicable 

• List of Recommended Practices (blue-colored font) 

• Applicability Key – best practice relevance for which types of projects 

o * = SST-NC – guidance applies to SST projects implemented at a NASA Center 

5 
 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Small Spacecraft Technology Program Guidebook for 

Technology Development Projects Rev.: -

o ** = SST-PS – guidance applies to SST projects implemented in Academia or 

Private Sector 

o *** = SST-SpaceDemo – guidance applies to SST technologies to be 

demonstrated in space 

SST Program Charter, Goals, and NPR 7120.8 Requirements *SST-NC, **SST-PS 

Purpose of Section: SST project personnel – whether on projects executed at a NASA Center or 

on a grant or contract - need to be familiar with the SST Program Plan and the NPR 7120.8 

NASA Research and Technology Program and Project Management Requirements in order to 

avoid errors due to not adhering to requirements or by applying unnecessary practices not 

needed for NPR 7120.8 projects. This section highlights a few important requirements for SST 

projects under NPR 7120.8 that contrast with NPR 7120.5 and that may be unfamiliar to those 

coming from experience with NPR 7120.5. For other R&T projects that are not sponsored by 

SST Program, this section may be useful especially if the project is formulated elsewhere under 

the requirements of NPR 7120.8. 

The SST Program Plan (Doc. No. SSTP.PP.01) provides projects guidance on the program’s 

policies for project management and execution. SST program and projects are formulated and 

managed in accordance with the structure and requirements of NPR 7120.8 for R&T projects. 

NPR 7120.8 governs all aspects of R&T project formulation, requirements, roles, and 

management principles. See subsequent later chapters in this Guidebook for respective details. 

SmallSat R&T projects typically are formulated with small budgets and short schedules when 

compared to NPR 7120.5 Spaceflight projects, so quality and mission assurance practices 

should be scaled down proportionally and optimized appropriately. SST program has greater 

tolerance for technical and programmatic risk than typical for programs managed under NASA 

NPR 7120.5 NASA Space Flight Program and Project Management Requirements. For its policy 

regarding project risk see SSTP.PP.01 Small Spacecraft Technology Program Plan. 

All SST R&T development projects are managed in consideration of two guiding principles: 

“No Compromise to Safety” - Safety and protection of high-valued assets are paramount. 

Projects adhere to all relevant NASA, or company/university, launch service provider and 

range safety policies and practices. These apply in the lab, to personnel, to property, to 

procured services and elements, and during integration with the launch vehicle, on-orbit 

operations, limitation of orbital debris, and disposal. These policies are frequently referred to 

as “do no harm”. Projects are to comply with all legal, NASA safety, or launch provider 

safety requirements. Projects comply with Quality Assurance requirements for all identified 

safety-critical items. 

“Apply Systems Engineering and Quality Assurance Practices as Informed by Risk” –

For non-safety-critical items, projects apply common industry and/or NASA best practices 

that enhance likelihood of technical success and do so with consideration of programmatic 

and technical risks. Acting as good stewards of the taxpayer’s dollars, SST project 

managers determine the best approach for developing, and demonstrating technologies 

without unnecessarily spending time and money where not likely to enhance technical 

success. Application of every known mission assurance edict at any cost to eliminate all 

technical risk does not support constraint driven missions. SST projects develop and 

demonstrate technology - in the lab or on orbit - using “risk-informed assurance”; i.e. 

projects assess technical and programmatic risks and selectively apply engineering, 

6 
 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Small Spacecraft Technology Program Guidebook for Rev.: - Technology Development Projects 

mission, and quality assurance processes balanced with technical, cost and schedule 

consequences. This approach is sometimes called “right-sized quality assurance”.

Guidance for risk management and quality assurance are given in later sections. 

R&T Project Guidelines and Recommended Practices 

Projects executed under contract, grant, or cooperative agreement are not required to deliver a 

Project Plan, Systems Engineering Management Plan (SEMP), or Safety and Mission 

Assurance Plan (SMAP) unless explicitly required in the terms of the contract, grant or 

cooperative agreement. Unless otherwise stated in the contract, the Systems Engineering, 

Quality, Safety and Mission Assurance standards, processes and requirements should be those 

commonly used within the contractor/grantee organization. Systems Engineering, Quality, 

Safety, and Mission Assurance requirements in the contract/grant take precedent. 

4.1. SST Project Planning – Life Cycle. *SST-NC, **SST-PS 

Purpose of Section: The SST recommended approach to project planning and execution 

according to requirements of NPR 7120.8 is in contrast to the approach of projects formulated 

under NPR 7120.5. SST projects are typically smaller, leaner, executed faster, and require less 

formal documentation. Particularly important is the distinction between R&T project reviews 

versus spaceflight project reviews. 7120.8 project reviews are internal to the project and less 

formal than 7120.5 project reviews. Project managers and members familiar with 7120.5 

process frequently plan projects and their review in ways that are more formal, more complex, 

and with more external reviewers than needed by SST Program. The consequence of this is 

unnecessarily increasing cost and schedule for project plans and reviews. Projects executed 

outside NASA are encouraged to pattern their project life cycle and plan according to NPR 

7120.8 in the absence of other policies at their institution of origin. 

SST projects are formulated according to the R&T project life cycle defined in NPR 7120.8 Sect. 

4.1.2. SST projects typically have a total life cycle of approximately two years. R&T projects 

include three phases: Pre-Formulation and Authority to Proceed; Formulation and Project 

Approval; and Implementation and Closeout. SST projects generally do not include PreFormulation phase and simply begin at Authority to Proceed. SST projects with Technology 

Demonstration in space add an Operations phase. 

The R&T project phases, Key Decision Points (KDPs), reviews and planning documents are 

defined in NPR 7120.8 Sect. 4.1.2.1 (see its figure 4-1 and 4-2) and are fewer in comparison to 

NPR 7120.5 projects. 

During the Pre-Formulation phase, an initial negotiation between the Program and Project 

manager determines the purpose and scope of the project (e.g., type, size, complexity, etc). 

Typically R&T projects capture this determination in a Formulation Authorization Document 

(FAD). Note: SST projects often do not include this step but proceed at ATP. 

R&T Projects develop Project Plans per the template provided in NPR 7120.8 (Appendix G), 

omitting elements that are not applicable to the specific project. Projects executed under a 

grant, cooperative agreement or contract the Statement of Work (SOW) and contractual 

requirements may not require a Project Plan; the contract, grant or cooperative agreement may 

serve as the Project Plan. 

Project Planning Recommended Practices (*SST-NC, **SST-PS): 

7 
 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Small Spacecraft Technology Program Guidebook for 

Technology Development Projects Rev.: -

• Negotiate project expectations early in the life cycle of the project. To understand and 

keep project objectives clear, and to avoid project “scope creep”, document clear 

objectives in the “Purpose” section of the project FAD and/or in the “Goals, Objectives,

and Metrics” of the Project Plan. This will also guide subsequent technical 

implementation trades, risk, and quality management decisions. SST projects typically 

don’t include a Pre-Formulation phase but begin at ATP.*,** 

• Project Plans describe technical and management approach in sufficient detail so 

stakeholders recognize and achieve agreement on just how the project executes the 

project within cost and schedule. Project plans should avoid unnecessary, unimportant 

details or “boilerplate” cut-and-paste to avoid confusion and costly or unnecessary 

practices. *,** 

• Specific goals, milestones, deliverables, a complete schedule of project reviews, and 

relevant policies for each respective SST project need to be defined in the Project Plan, 

for awareness and reference of managers, NASA TAs (for projects implemented at 

NASA Centers) and project members, preventing ambiguity. *,** 

• For clarity and brevity, the project SEMP is preferably included within the Project Plan. 

This reduces replication of objectives and other text. See Sect. 4.5 of this Guidebook for 

SEMP details. *,** 

• An often overlooked but critical element of project plans is quantitative goal (or floor and 

stretch values) of the Key Performance Parameters (KPPs) or Measures of 

Effectiveness (MOEs) to be demonstrated (in the lab or in-space). Stakeholders need 

these metrics to understand the extent the project will fulfill a future purpose or 

technology gap. The values may be updated in the Project Plan in the case the project 

scope or unexpected technical constraints arise. SST program understands that 

according to the nature of research projects, not all planned values (especially stretch 

values) will be achieved. See NPR 7120.8 Sect 4.2.7.7 or NASA/SP-2016-6105 for 

explanation of KPPs and MOEs. *,** 

• Planned dates for ATP and Project Closeout KDPs should be included in the Project 

Plan approved by the SST Program. Keeping these important milestones up-to-date in 

the Plan in case of change is a visible record for internal and external stakeholders. 

• SST may give smaller projects the Authority to Proceed (ATP) without the PreFormulation or Formulation phases. Consult with the SST Program Manager to establish 

KDP expectations and include them in the Project Plan. *,** 

• Closeout KDP and Report - Includes the final (lab or in-space) demonstrated 

performance measures of the research and/or technology under development, lessons 

learned (NPD 7120.6), a measure of the Technology Readiness Level (TRL) 

advancement, list of papers published, and New Technology Reports. *,** 

4.2. Project Reviews. *SST-NC, **SST-PS, ***SST-SpaceDemo 

Purpose of Section: KDPs are “gates” – typically ATP and Closeout – and they are run by the 

SST Program. Project reviews, called “Periodic Project Reviews” (PPRs) in NPR 7120.8, are

run by the project for the project. Spaceflight demos typically plan to run SRR/SDR, CDR, and 

MRR/FRR. Lab projects may have very infrequent and informal reviews. Do not conduct project 

reviews with excessive formality or assign reviewers unnecessary approval authority; this costs 

time and money without return on investment. Reviews under NPR 7120.8 are not at all like 

those under NPR 7120.5. 

Periodic Project Reviews are not KDPs. The SST program will schedule ATP and Closeout 

KDPs. See NPR 7120.8 4.1.2 for project life cycle and KDPs. 

8 
 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Small Spacecraft Technology Program Guidebook for 

Technology Development Projects Rev.: -

Periodic Project Reviews (PPR) are scheduled by the project and overseen by the project as 

the project determines beneficial. Understanding the distinction between PPRs of NPR 7120.8 

and NPR 7120.5 may help a project establish and conduct more efficient and effective reviews 

without unnecessary overhead. PPRs for projects executed under NPR 7120.8 may be informal 

discussions or can be in the form of “life-cycle reviews” with entrance and success criteria as 

described in NPR 7123.1, Appendix G. Whether informal or formal, PPRs are planned by, and 

internal to, the Project. They are not approval “gates”. SST projects may also schedule their 

own Independent Assessments if the project determines beneficial. 

NPR 7120.8 R&T projects do not have Standing Review Boards nor are they governed by a 

Program Management Council, unlike NPR 7120.5 projects. 

For definitive information on PPRs and Independent Assessments (IAs), review NPR 7120.8 

Sect. 4.2.10. 

Launch vehicle operators or launch service managers (and some NASA Centers) require a “preship review” (which is not defined in NPR 7123.1) to determine flight readiness for R&T projects 

demonstrating technology in space. The SST Program does not require Certificate of Flight 

Readiness (CoFR) reviews. 

Project Reviews Recommended Practices (*SST-NC, *SST-PS, ***SST-SpaceDemo): 

• R&T projects plan and conduct reviews that include external subject matter experts 

(SMEs) who bring “fresh eyes” to identify risks and issues that may require further work. *,** 

• For SmallSat Technology Partnerships and similar grants (particularly for projects 

involving technology demonstration in the lab), PPRs are typically quarterly or other 

periodic status reviews, conducted by telecon and using a status “quad chart”. ** 

• For large projects, particularly those demonstrating technology in space, PPRs may be 

structured like the technical reviews of NPR 7123.1 Appendix G. Often, new SST Flight 

Demonstration Projects initially plan to exceed the necessary scope for technical reviews 

of R&T projects. This is especially true for projects and managers familiar with review 

requirements of NPR 7120.5. Adhere to the NPR 7120.8 sect. 4.2.10 generic guidance 

for reviews for scope and formality appropriate for R&T projects (even for technology 

demonstrations in space) to avoid time-consuming, expensive, unnecessary review 

formality. *** The SST program recommends these reviews: 

o Combined Systems Requirements Review/Systems Definition Review 

(SRR/SDR) 

o Critical Design Review (CDR) 

o Mission Readiness Review/Flight Readiness Review (MRR/FRR). 

• For projects or elements that involve a rebuild of a previously-flown component, “Delta”

reviews should be held in lieu of CDRs to represent any changes from previous designs 

or manufactures, the past history of success, failures, and anomalies, and any project 

lessons learned. *** 

• In general, the technology under development should be the subject of the review. For 

example, if a new payload will be integrated on a spacecraft bus that has flown, the 

development of the payload and the integration plan would be reviewed. Bus 

characteristics may be reviewed, if necessary in a secondary capacity, from the point of 

view of demonstrating that the bus meets the payload requirements that flow down to the 

bus from the payload. Unique, one-time alterations to the bus may be reviewed as an 

“altered item” of a commercially available bus. *** 

9 
 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Small Spacecraft Technology Program Guidebook for Rev.: - Technology Development Projects 

Phase Activity Output(s) 

Pre-formulation Preliminary planning (NPR 7120.8 Scope, from SST 

Sect 4.2.5). Often omitted from Program 

SST projects which proceed from 

ATP 

ATP (KDP) SST approval of proposed project Approval, Preliminary 

to enter Formulation Phase (NPR Project Plan 

7120.8 Sect 4.2.6) 

Formulation NPR 7120.8 Sect 4.2.7 

Project Approval (KDP) SST approval to enter Approval, Final Project 

Implementation Phase (NPR Plan 

7120.8 Sect 4.2.8) 

Implementation NPR 7120.8 Sect 4.2.9 Life cycle reviews per 

approved Project Plan 

Continuation Assessments (if NPR 7120.8 Sect 4.2.10.3 Continuation approval, if 

in plan/contract/grant, or upon required 

subsequent direction) 

Independent Assessments (if NPR 7120.8 Table 4-1 Independent 

required, or upon subsequent assessments, if required 

direction) 

Status telecons, quad charts NPR 7120.8 Sect. 4.2.10.2 Quad charts (typical) as 

(for small lab demo projects) informal reviews for lab projects planned 

SRR/SDR*** Internal review conducted by NPR 7123.1 success 

(large flight demo projects) project. Tailored from 

NPR 7123.1 Appendix G-4 

criteria, as in approved 

project plan 

CDR*** Internal review conducted by NPR 7123.1 success 

(large flight demo projects) project. Tailored from 

NPR 7123.1 Appendix G-7 

criteria, as in approved 

project plan 

MRR/FRR*** Internal review conducted by NPR 7123.1 success 

(large flight demo projects) project. Tailored from 

NPR 7123.1 Appendix G-13 

criteria, as in approved 

project plan 

Closeout Review (KDP) NPR 7120.8 Sect 4.2.11 Closeout Report, New 

Technology Report 

*** These reviews (“life cycle reviews”) are for flight demonstration projects only. They are

internal reviews, conducted by the project, to review the project cost, schedule, and technical 

performance. Details on these reviews are determined by the project manager in coordination 

with the SST Program and documented in the approved Project Plan. 

10 
 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Small Spacecraft Technology Program Guidebook for 

Technology Development Projects Rev.: -

Table 1. SST Project Life Cycle and Reviews 

4.3. Project Resources and Cost Estimation Resources and Tools 

Purpose of Section: R&T projects benefit by efficient programmatic processes optimized to 

reduce time and cost in balance with their higher risk tolerance, smaller size, and lower 

complexity - in contrast to processes applied to NASA NPR 7120.5 Spaceflight projects. 

The Project Plan should document a high level cost breakdown and costs for each participating 

Center/Org, as applicable, in alignment with the schedule and performance 

parameters/milestones. 

SST projects follow the ideology of constraint driven missions. Once a project is awarded, 

budgets are managed internally by said project. The goal of SST projects are to maintain 

schedule (preferably two years) and to complete the mission at no additional funding from the 

NASA SST program after award funds are granted. The Project Plan should include in-depth 

analysis of how the resources allotted will align with scheduling. 

Project Costing Estimation Resources and Tools: 

• CubeSat or MicroSat Probabilistic and Analogy Cost Tool (COMPACT) 

o Available to NASA users for early lifecycle CubeSat cost estimates. The tool 

currently contains analogs only. The main goals are to provide a sanity check on cost 

estimates and a database of CubeSat and SmallSat cost information. 

o COMPACT is located on the ONCE database website (NASA users only): 

https://oncedata.hq.nasa.gov. Users must apply for access via a NAMS request. 

Instructions to access ONCE can be found at: 

http://www.nasa.gov/sites/default/files/atoms/files/_once_user_access_request_form 

_tagged.pdf. Within ONCE, users can navigate to COMPACT via the left panel tab 

by clicking "ONSET" and then “COMPACT” once the tool has loaded. There is 

currently no option for users outside of NASA to access COMPACT, its data, or its 

models. 

• NASA Instrument Cost Model (NICM) 

o Costing tool for science instruments. 

o Directions to access NICM can be found at: 

https://www.nasa.gov/offices/ocfo/functions/models_tools/nicm. Within ONCE, users 

can navigate to NICM download by clicking “Model Portal” on the left panel, and then

“NICM” at the top of the model portal. Users outside of NASA can access the limited 

version (hidden data but models included) at: 

https://software.nasa.gov/software/NPO-51529-1. 

4.4. Risk, Safety, Quality, and Mission Assurance. **SST-NC 

Purpose of Section: NASA policies for Risk, Safety, Quality, and Mission Assurance are 

frequently conflated, sometimes with unfortunate results for low-cost, risk-tolerant R&T projects. 

For R&T projects, safety requirements are absolute, while mission assurance and quality 

practices need to be evaluated using risk analyses, scaled and applied in proportion to the 

project’s programmatic constraints, goals, and tolerance for risk. Quality and Mission Assurance 

practices must not be applied blindly in a blanket fashion. Doing so would inflate project costs 

and decrease productivity disproportionately relative to the increase in reliability. SST projects 

use “risk-informed quality assurance/mission assurance”. Safety of public, personnel,

11 
 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Small Spacecraft Technology Program Guidebook for Rev.: - Technology Development Projects 

infrastructure, or high-valued equipment shall never be compromised. For the purposes of this 

Guidebook, risk and safety will be discussed separately and quality and mission assurance will 

be combined. 

Risk, Safety and combined Quality/Mission Assurance best practices are given in the three 

subsections. Project personnel should consult source documents (required by NASA and/or 

their home institution). Information and guidance here does not supersede relevant NASA, 

institutional or contractual requirements. 

NPD 8700.1 NASA Policy for Safety and Mission Success establishes NASA’s policies and 

roles for safety and mission success. As stipulated in NPD 8700.1 paragraph f.(1) the SST 

Program establishes safety and mission success requirements within its projects and does so 

conjunction with NASA Center-designated Technical Authority (TA). SST program accepts any 

residual safety and mission success risk for SST projects (see NPD 8700.1 paragraph f.(3)). Per 

this policy, SST requires projects adhere strictly to safety requirements and best practices. Less 

clearly relevant are phrases “Mission success risk” and “mission success requirements” of NPR

8700.1 for R&T projects; NPR 8700.1 references NPR 7120.5 but does not reference NPR 

7120.8. For this reason, this Guidebook does not discuss “mission success” or “mission

assurance” in this context. 

The SST program does not authorize projects to take every effort to eliminate every possible 

uncertainty in technical risk, even for technology demonstrations in space. Reasonable and 

informed acceptance of technical risk are an accepted characteristic of R&T development and 

demonstration. 

Below is a summary of the SST Program approach to Risk, Safety, Quality and Mission 

Assurance for SST projects (explained in the next three sub-sections in further detail): 

1. Analyze and identify all safety hazards in the R&T project elements and work processes. 

Document safety hazards in project SMAP. This should be done early as possible in the 

project design phase. At NASA Centers, consult with an SMA TA for inputs and analysis 

regarding safety hazards. 

2. For every safety hazard, identify and document in the SMAP the risk levels and the 

appropriate safety and quality standards and processes to mitigate safety risks to 

acceptable levels. For projects at NASA Centers, consult the Center SMA TA to review 

mitigation processes for safety-critical elements. 

3. Analyze and identify all other (non-safety-critical) technical hazards and hazards to 

project success. These may be documented in a project SMAP or in another risk list. 

4. For identified technical and project hazards that are not safety related, the project should 

quantify the technical and programmatic risk levels, then select and apply appropriate 

quality assurance processes to reduce risks to acceptable to agreed-upon levels. Use 

best engineering judgement to determine which processes to apply and appropriately 

tailor processes to the scale of the budget and technical goals of the project. 

SST program accepts that there will be some degree of technical risk and programmatic risk 

associated with its R&T projects, including technology demonstrations in space. 

12 
 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Small Spacecraft Technology Program Guidebook for 

Technology Development Projects Rev.: -

4.4.1. Risk Management. *SST-NC, **SST-PS, ***SST-SpaceDemo 

Purpose of Section: Aid with establishment and documentation of project risk assessment, 

management, plans and practices. Provides successful examples and guidance on risk and risk 

policies, within the context of the SST (and other) R&T project risk policies. 

The SST Program policies regarding project technical and programmatic risk management and 

mission assurance are given in the SST Program Management Plan Section 3.6. 

SST program accepts that its R&T projects will identify a degree of technical and programmatic 

risk. Some technologies will not perform as expected during flight demonstrations – in fact, this 

is the reason for technology flight demonstrations. Nevertheless, SST program expects projects 

to follow best practices for quality assurance aligned with the available budget, schedule, and 

technical resources. 

SST projects (including those with technology demonstration in space) are executed under NPR 

7120.8 and so are not given an NPR 8705.4 risk classification, as that NPR applies only to NPR 

7120.5 missions. SST technology demonstrations are not “sub-Class D” projects, rather, they 

have no NPR 8705.4 risk classification at all. 

Specific technology demonstration mission hazards can be identified by projects by employing 

reliability analyses, such as Failure Modes and Effects Criticality Analyses (FMECAs) and 

single-point failure (SPF) analyses. The general principle is that all SST projects apply 

appropriate elements of mission assurance with an eye toward “right-sizing” practices 

commensurate with the risk profile, budget and schedule of the technology development or 

demonstration project. This principle for tailoring or requesting waiver of NASA practices is 

called “Risk-Informed Mission Assurance”.

Mission hazards may arise from any of several elements during a project life cycle. Projects are 

encouraged to consider application of standards and processes to mitigate mission risks to 

acceptable levels. Hazards and mitigations to consider: 

• Selection of appropriate materials to increase reliability/robustness 

• Software design, coding and test to mitigate and detect errors 

• Design trades (redundancy, reliability, radiation tolerance) to reduce probability or 

consequence of failure 

• Inspection, measurement and test processes, to detect manufacture and assembly 

errors 

• Workmanship and assembly processes – training and inspection for critical manual 

processes 

• Operations and command and control concepts for manual work-arounds of off-nominal 

conditions 

In accordance with NPR 7120.8 Sect. 4.2.7.9, if a project determines through analysis that it 

does not include elements, systems, or processes that could result in harm to personnel, the 

public, or property, the project is not required to (but may) produce a risk management plan. 

Risk Management Recommended Practices (*SST-NC, **SST-PS): 

• Identify technical and programmatic hazards and quantify risks in a risk management 

list. Projects that actively identify, track and apply appropriate mitigations can increase 

likelihood of technical success within budgets.*,** 

• The formality of NPR 8000.4 and NPR 7123.1 Sect. 3.2.14 Technical Risk Management 

Process are not required but offer excellent guidance. *,** 

13 
 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Small Spacecraft Technology Program Guidebook for Rev.: - Technology Development Projects 

4.4.2. Safety. *SST-NC, **SST-PS, ***SST-SpaceDemo 

Purpose of Section: Never compromise on safety. “Mission assurance” is often conflated with

safety in NASA organizations. But mission assurance practices, like quality assurance practices, 

should be considered separately using analytical risk management processes described 

elsewhere in this document. This section provides successful examples and guidance on safety. 

To reiterate, safe practices are never to be compromised. 

*SST-NC, **SST-PS: All SST projects shall conduct a project safety analysis and document the 

results. The project safety analysis shall list every safety-critical element, or, shall indicate that 

analysis has identified no safety-critical elements if there are none. The safety analysis must be 

completely documented in the SMAP as early as possible and preferably before SRR/SDR 

review. If the project analysis concludes that there are no credible safety hazards, then projects 

are not required to produce SMA Plans or Risk Management Plans (unless otherwise directed 

to do so by the program or determined for some other reason by the project). 

*SST-NC: Projects implemented at NASA Centers must follow NPR 8715.3 NASA General 

Safety Program Requirements. 

*SST-NC: In accordance with NPR 7120.8 Sect. 4.2.7.9, if any technology development project 

is determined to contain elements, systems, or processes that could result in harm to personnel, 

the public, or property, the project plan must include: 

• A SMAP in accordance with NPRs 8715.3 NASA General Safety Program Requirements 

and 8705.6. Safety and Mission Assurance (SMA) Audits, Reviews, and Assessments 

• A risk management plan in accordance with NPR 8000.4. The risk management plan 

must address relevant safety and health risks, but not technical or programmatic risks 

unless determined by the project or directed by SST program. 

*SST-NC: Consult NPR 8715.3 NASA General Safety Program Requirements and the Center 

S&MA office regarding safety reviews and audits. 

**SST-PS: Projects implemented in academia or private sector must follow their respective 

entities’ established safety policies.

*SST-NC, **SST-PS: For all project-identified safety-critical items, the project must comply with 

all relevant NASA or other institutional safety, quality and mission assurance requirements. 

Safety concerns for SST technology development projects are often considered in two areas: 1) 

safety of personnel and property in the lab, and 2) avoiding harm to personnel, launch vehicle, 

or to other payloads during integration, launch pad and operation in space, through end-of-life. 

Typical examples of technology flight demonstration elements that could result in harm to 

personnel or property: 

• Test or shipment of spacecraft bus with stored energy in form of batteries, springs, 

compressed gas 

• Storage or use of caustic or toxic fuel or other toxins 

• Operation of high-powered RF systems or lasers 

• RF transmissions, recontact or other hazards to launch vehicles and their payloads 

• Generation of orbital debris and de-orbit requirements 

*SST-NC, **SST-PS: For the most part, safety-critical items should tie strictly to items in hazard 

reports (or risk-informed safety cases for those who use them instead) or the launch-provider’s 

“do no harm” interface and safety requirements. 

14 
 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Small Spacecraft Technology Program Guidebook for 

Technology Development Projects Rev.: -

*SST-NC, **SST-PS: The SMA Plan and risk management plan, if required, is best incorporated 

into the Project Plan to reduce redundant documentation and to encourage brevity. But standalone plans are acceptable. Plans address credible safety and health hazards. 

*SST-NC, **SST-PS, ***SST-SpaceDemo: Projects that include technology demonstration in 

space must also abide by launch services restrictions and requirements. The particular launch 

vehicle or provider will determine requirements for a the launch, but common examples include: 

LSP-Req-317.01 (for LSP hosted CubeSats), ISS safety requirements (for ISS-launched 

CubeSats), do no harm requirements from other launch providers, orbital debris requirements in 

NASA-STD-8719.14 (as called from NPR 8715.6), and range safety requirements in NASASTD-8719.24 (as called from NPR 8715.3). 

***SST-SpaceDemo: Limitation of Orbital Debris and the End of Mission Plan (EOMP) are 

addressed in Section 4.13 of this Guidebook. 

Safety Recommended Practices (*SST-NC, **SST-PS, ***SST-SpaceDemo): 

• Safety-critical elements are specifically derived in a focused way from a safety analysis 

(hazard analysis, probabilistic safety assessment (PSA), or risk-informed safety case for 

those who use such an approach). Address safety-critical elements and processes in 

accordance with NASA, contractual, legal, and other applicable requirements. (The term 

“focused” is used here to avoid broad determinations such as “the cryocooler has safety 

implications, thus each part inside is safety critical” in comparison to the determination

from a hazard analysis that the inhibits on the cryocooler are controls against a safety 

incident and thus the inhibits (whether hardware or software) and the interfaces of the 

inhibits are safety critical, while other elements of the cryocooler are not). *,** 

• NASA projects should coordinate early with the Center TA to consider the projectidentified safety-critical mitigations and processes. The TA’s role is to ensure that proper

quality practices and attention go to the safety critical items (as opposed to making the 

determination of criticality). * 

• R&T projects should determine (in consultation with the cognizant TA or SMA TA) which 

(if any) NASA quality and mission assurance requirements are relevant to projectidentified safety-critical elements. Quality and mission assurance of non-safety-critical 

items should be considered separately and as informed by risk (discussed in a later subsection). * 

• For R&T projects that are determined by analysis that they do not include safety 

hazards, NPR 7120.8 does not require a SMAP or an RMP; however, it is best practice 

to identify technical and programmatic hazards and quantify risks in a risk management 

list or plan. Projects that actively identify, track and apply appropriate mitigations can 

increase the likelihood of technical success within constrained budgets. The formality of 

NPR 8000.4 and NPR 7123.1 Sect. 3.2.14 Technical Risk Management Process aren’t

required but offer excellent guidance. *,** 

• For projects implemented at NASA Centers, consult NPR 8715.3 NASA General Safety 

Program Requirements and the Center S&MA office regarding safety reviews and 

audits. These independent assessments of safety hazards are considered vital to 

increased confidence in safety. * 

• For projects implemented in academia or private sector, projects are expected to follow 

the entities’ established safety policies. ** 

15 
 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Small Spacecraft Technology Program Guidebook for 

Technology Development Projects Rev.: -

4.4.3. Quality and Mission Assurance. *SST-NC, **SST-PS, ***SST-SpaceDemo 

Purpose of Section: Provides guidance for establishing and documenting project mission- and 

quality- management. Recommended practices are applied as informed by risk within 

programmatic and risk-tolerance constraints. This section also provides guidance and examples 

of successful quality and mission assurance policies, tailoring and waiver requests where 

appropriate, within the context of the SST (and other) R&T project risk policies. 

The SST Program (and Center TAs) should assume that requirements not explicitly 

described or itemized in the Project Plan, SMAP or RMP will not be applied. 

*SST-NC, **SST-PS, ***SST-SpaceDemo: SST projects select and apply quality management 

and mission assurance requirements when appropriate and as based on quantitative risk 

analysis. Technical hazards may be identified through reliability analyses, such as Failure 

Modes and Effects Criticality Analyses (FMECAs) and single-point failure (SPF) analyses. 

Technical hazards may arise from any of several elements during a project life cycle. 

*SST-NC: NPD 8730.5B NASA’s Quality Assurance Program Policy is relevant to technology 

development projects executed under NPR 7120.8 at NASA Centers. Please note: Language in 

Attachment A of 8730.5B regarding “critical and complex” work may be revised. Please contact 

the relevant SMA authorities regarding questions about potential changes and applicability. 

*SST-NC: NPD 8730.5 Table 2 lists workmanship standards. For elements not identified as 

safety-critical, SST projects are not required to apply workmanship standards but – as informed 

by their project risk analysis – should consider and select specific, relevant workmanship 

practices in from NPD 8730.5 Table 2. SST projects may consider specific and selected 

practices from SAE AS9100 Quality Management Systems – Requirements for Aviation, Space 

and Defense Organizations. As stated above, all the requirements that projects choose to flow 

down from NPD 8730.5 or AS9100 should be explicitly listed and described in the project PMP, 

SMAP, SEMP or RMP. 

*SST-NC: R&T projects implemented at NASA Centers must select relevant requirements of 

NPR 8735.2 NPR 8735.2 NASA’s Hardware Quality Assurance Program Requirements for

Programs and Projects for safety-critical elements. R&T projects may also (but are not required 

to) apply selected requirements appropriate for non-safety-critical hardware and software if the 

project determines beneficial based on technical risk analysis (on a “risk-informed” basis) and 

regard to project goals, risk posture and cost/schedule constraints. See NPR 8735.2 P.1.g. 

**SST-PS: SST projects implemented outside of NASA (in academia or the private sector) 

follow the quality and mission assurance practices at their respective entity. SST program may 

inquire about the entity’s policies and procedures and may include additional quality and

mission assurance requirements in a contract, grant or cooperative agreement. 

Quality and Mission Assurance Recommended Practices (*SST-NC, **SST-PS, ***-SSTSpaceDemo): 

• Avoid assuming requirements on “mission assurance” are relevant to R&T projects. The 

relevance for those requirments may be limited to NPR 7120.5 space flight projects. 

When encountering “mission assurance” requirements, review them selectively for nonsafety-critical elements and considering tailoring or customizing or requesting waiver. 

Consult the cognizant Engineering TA or SMA TA at NASA Centers for further guidance. 

* 

16 
 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Small Spacecraft Technology Program Guidebook for 

Technology Development Projects Rev.: -

• GPR 8705.4 Risk Classification Guidelines and Risk-Based SMA Practices for GSFC 

payloads and Systems Table 1, Guidelines for Safety and Mission Success Activities at 

Each Mission Classification, provides good recommendations for risk-informed mission 

assurance and quality assurance standards and processes relevant to NPR 7120.8 

research and technology projects. *,**,*** 

• Explicitly document all the project-specific implementation of quality practices in either 

the project plan (preferably for brevity of project documentation) or in a stand-alone 

SMAP or Risk Management Plan (RMP) or SEMP. This is so no false assumptions are 

made about risk mitigations to be taken or to be omitted by the project. This will avoid 

causing confusion or worse, requiring re-work or resulting in later problems. *,**,*** 

• SST Program (and Center TAs) should assume that requirements not explicitly 

described or itemized in the Project Plan, SMAP or RMP will not be applied. * 

• Simply calling out a standard’s document number and title (e.g. “NASA STD 8739.4”)

does not imply that the project intends to comply with any of the requirements in that 

standard; particular requirements selected from within a standard must be explicitly 

listed to avoid false assumptions or later confusion or errors. For projects developing a 

series of products, each of which have different hazards or mission assurance 

requirements, the project may append a table to the SMA Plan (or other method of 

denotation) that indicates applicability of requirements to respective products. This can 

streamline the additions and retain relevant information about applicability of 

requirements to respective configurations of an item. *,**,*** 

4.5. Systems Engineering. *SST-NC, **SST-PS, ***SST-SpaceDemo 

Purpose of Section: Systems engineering is defined as a logical approach to systems to ensure 

products meet customer’s needs. Systems engineering processing of NPR 7123.1 are 

methodical and based on NASA’s legacy of spaceflight experience; SST recommend those

processes be utilized for R&T projects in more expedient and less formal ways than for NPR 

7120.5 Spaceflight projects. Guidance is given here. A SEMP template tailored to SST R&T 

projects is planned. 

*SST-NC: NPR 7123.1 NASA Systems Engineering Processes and Requirements is owned by 

the NASA Office of the Chief Engineer. It includes systems engineering policies and 

requirements for NASA projects including R&T projects. It lists requirements for 17 “Common

Technical Processes”. Large and small projects employ these processes in more formal or less 

formal ways. Projects are expected to “tailor” and “customize” (which mean different things) 

depending on project size, complexity or accepted risk posture, as described in NPR 7123.1 

Sect. 2.2 and throughout. 

*SST-NC: The NASA Center's Engineering Technical Authority (ETA) is responsible for 

ensuring risks are considered and good engineering practices are followed in technical 

development and implementation, and assist the program or project in making risk-informed 

decisions that properly balance technical merit, cost, schedule, and safety across the system 

(ref. NPR 7123.1C 1.3.1.c and 2.6.1.2.d). More on balancing risk when considering systems 

engineering processes is found in NPR 7123.1C 1.3.1.c and throughout that document. 

*SST-NC, *SST-PS, *SST-SpaceDemo: NASA Systems Engineering Handbook (NASA-HDBK6105) is a useful reference for details, examples and best practices for implementing systems 

engineering processes. A SEMP template is given in NASA-HDBK-6105. 

*SST-PS: For projects not managed at a NASA Center, the company or university best 

practices for systems engineering apply. 

17 
 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Small Spacecraft Technology Program Guidebook for 

Technology Development Projects Rev.: -

Systems Engineering Recommended Practices (*SST-NC, **SST-PS, ***SST-SpaceDemo): 

• Project life-cycle and technical review requirements are included in NPR 7123.1 Chapter 

5 and Appendix G; SST recommended practices for life-cycle and technical reviews 

(called “Periodic Project Reviews” in NPR 7120.8 for R&T projects) are given in 4.2 of 

this Guidebook. 

• Include a project SEMP within the SST Project Plan (as it encourages brevity and 

reduces redundant descriptions of the project goals and other characteristics). Though 

the SEMP may be prepared as a separate stand-alone document, this is not 

preferred.*,**,*** 

• Tailor and customize systems engineering practices appropriately by considering the 

typically modest budgets, schedules and acceptable risk profile of R&T projects. Efforts 

to document and implement engineering processes that are disproportionately elaborate 

or formal relative to the benefit they provide to the project may not contribute to 

increased success or excellence and may not be best use of resources. Avoid the route 

of implementing processes unnecessarily due to precedence of some other larger, more 

complex, less risk tolerant project. Risk tolerance of R&T projects under NPR 7120.8 are 

typically higher in contrast to NPR 7120.5 Spaceflight Programs and Projects for science 

*,**,*** or exploration programs. 

• Refer to NPR 7123.1 regarding specific guidance on the 17 common technical 

*,**,*** processes. 

4.6. Configuration Management. *SST-NC, **SST-PS, ***SST-SpaceDemo 

Purpose of Section: R&T projects benefit by efficient technical processes optimized to reduce 

time and cost in balance with their higher risk tolerance, smaller size, and lower complexity - in 

contrast to processes applied to NASA NPR 7120.5 Spaceflight projects. 

Projects briefly describe how they will manage configuration of documents and hardware and 

software in the project SEMP, whether the SEMP is stand-alone or an internal part of the 

Project Plan. Entities outside of NASA (universities, private sector, other Government Agencies) 

will use their own best practices for CM. Projects approve configuration changes and track 

configuration items as they determine most efficiently and effectively for the project. 

If there is a discrepancy between project documentation and products, a Non-Conformance 

Report should be created and rework/repair documented. 

CM Guidelines and Recommended Practices (*SST-NC, **SST-PS, ***SST-SpaceDemo): 

• Projects manage configuration items as necessary to ensure assembly, integration, test, 

*,**,*** and operational considerations are correct and traceable, to avoid errors. 

• Test as you fly, fly as you test. Thorough understanding of the configuration changes 

throughout the lifecycle of the project is critical. *** 

• Project closeout should include complete documentation of the final configuration with 

notation of changes. *,**,*** 

• The project plan or SEMP should describe the project’s configuration management

process and identify which documents and products will be placed under configuration 

control. *,**,*** 

• Safety-critical items must be kept under a rigorous configuration control process. *,**,*** 

18 
 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Small Spacecraft Technology Program Guidebook for 

Technology Development Projects Rev.: -

4.7. Software Engineering, Assurance and Management 

Purpose of Section: Software assurance and compliance with NPR 7150.2 is required of R&T 

projects; however NPR 7150.2 requirements are often selected and applied unnecessarily or 

with excessive formality for R&T projects because project personnel who are more familiar with 

complex software development projects or are more familiar with NPR 7120.5 Spaceflight 

projects are tempted to parrot methods used in those projects. R&T technology demonstrations 

often occur in the lab, on suborbital flights, or as secondary payloads on technology 

demonstrations in space with low safety and technical risk. NPR 7150.2 software classifications 

were not developed with these circumstances at the forefront. R&T projects benefit by efficient 

software assurance processes optimized to reduce time and cost in balance with their higher 

risk tolerance, smaller size and lower complexity - in contrast to processes applied to NASA 

NPR 7120.5 spaceflight projects. 

**SST-PS: SST projects executed in commercial or academic sectors comply with their 

respective internal best practices and software management policies. 

*SST-NC: Software developed or acquired for NASA (internally or externally) is subject to 

Software Assurance Standard NASA-STD-8739.8. SST projects executed at a NASA Center 

that include software will comply with NPR 7150.2 NASA Software Engineering Requirements. 

*SST-NC: SST projects implemented at NASA Centers typically generate a stand-alone 

Software Management Plan to document their methods for compliance with processes of NPR 

7150.2. Software developed for technology demonstration in space is classified as Class C 

Mission Support Software, as defined in the NASA-wide software classification structure of NPR 

7150.2. Note that software Class C is not to be confused with Mission Risk Classification. 

Projects should apply the processes of NPR 7150.2 tailored in accordance to the modest 

budgets and risk tolerant approach of the SST Program. 

Software Engineering Recommended Practices (*SST-NC, **SST-PS, ***SST-SpaceDemo): 

• The software and computing architecture should be designed to minimize or eliminate 

the need of safety critical software. For example, consider maintaining a minimal set of 

software that protects the ability to (1) maintain communication with the ground, (2) 

upload new software, and (3) place and maintain the spacecraft in a safe mode. *,** 

• SST projects that include technology demonstration in space that are executed at NASA 

Centers are classified as Software Class C. *** 

• SST technology development projects demonstrated in the lab at NASA Centers are 

classified as Software Class D or E. *,** 

• Projects executed at NASA Centers should refer to their respective Center’s Process 

Asset Library and the respective repository for resources regarding Software 

Management Plans and NPR 7150.2 compliance. * 

• The GRC software.grc.nasa.gov has examples of Software Management Plans and 

tailoring appropriate for technology demonstration project software. * 

• SST projects are encouraged to develop their NPR 7150.2 compliance matrix (or 

Software Management Plan) to their best effort; then if there are remaining questions 

they may contact their Center software assurance lead or the NASA Software Tech 

Fellow’s designated representative for NPR 7150.2. * 

19 
 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Small Spacecraft Technology Program Guidebook for 

Technology Development Projects Rev.: -

4.8. Procurement Quality Assurance. *SST-NC 

Purpose of Section: Recommended practices for procurement of components, subsystems and 

services for R&T projects – especially for projects to demonstrate technology in space. When 

applying the requirements of the FAR and of NPR 8730.5 and of the previous revision NPR 

8735.2B, NASA projects, procurement personnel and procurement SMA TA often apply 

requirements in ways disproportionate to R&T project size, complexity and risk tolerance. This 

happens in their pursuit of project excellence because of a lack of familiarity with procurement 

requirements for R&T projects and greater familiarity with NPR 7120.5 Spaceflight projects. This 

often results in unnecessary procurement delay, complexity and cost. R&T projects benefit from 

efficient procurement processes optimized to reduce time and cost in balance with their higher 

risk tolerance, smaller size and lower complexity. 

For SST R&T projects demonstrating technology in space that are implemented at NASA 

Centers and that include safety-critical hardware or software delivered to the NASA Center, it is 

NASA policy to prescribe requirements for independent assurance of compliance through 

Government contract quality assurance functions as required by Federal Acquisition Regulation 

(FAR) Part 46, FAR Part 12, NASA FAR Supplement (NFS) Part 1846, and NPD 8730.5, NASA 

Quality Assurance Program Policy. The purpose of Government contract quality assurance is to 

ensure that supplies and services acquired under Government contract conform to contract 

requirements. Procurement quality assurance requirements should be levied only in 

consideration of the project risk, scope, and worst credible consequence of safety-critical 

element failure. This process is called risk-informed quality assurance. 

Procurement Quality Assurance Recommended Practices (*SST-NC): 

• Procurement Quality Assurance personnel at NASA Ames Research Center are in the 

process of establishing a web-based, menu-driven approach to establish appropriate 

mission assurance clauses for procurement contracts. * See 

https://q.arc.nasa.gov/pqa_app/home 

4.9. Technical Authority. *SST-NC 

Purpose of this Section: Technical Authority is defined at the highest level of NASA policy. TA 

serves as independent oversight of projects at NASA Centers. The SST program recommends 

R&T projects executed at NASA Centers read NPR 7120.8 to understand the role of TA in R&T 

projects and avoid confusion with the way TA applies to NPR 7120.5 spaceflight projects. 

Ultimately the SST Program is responsible for the test readiness (for lab) and the flight 

readiness (for orbital or suborbital demonstrations) of its projects, not the Center TA. Projects 

may proceed at risk if SST or its project determine that is in the best interest of the project and 

program while dissenting opinions are resolved. Dissenting opinions between Project and 

Center TA are elevated to the next higher authorities for resolution. 

Technical Authority (TA) for engineering and safety and mission assurance are established 

through NASA’s Office of the Chief Engineer (OCE) and Office of Safety and Mission Assurance

(OSMA), respectively. 

The role of the TAs for technology development projects is identified in NPR 7120.8 Sect. 5.4. 

The SST Program works with each relevant Center TA to articulate the SST Program 

technology demonstration goals, the program’s degree of risk tolerance, and to ensure 

reasonable project oversight that is in line with those goals and risk posture. The SST Program 

understands that (as is stated in NPR 7120.8 Sect. 5.4.4), “Due to the nature of R&T, the 

20 
 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Small Spacecraft Technology Program Guidebook for 

Technology Development Projects Rev.: -

technical authority requirements for R&T projects are not as specific as for projects managed 

under NPR 7120.5.” TA roles are not predefined in NPR 7120.8 because they vary greatly 

depending on the nature and level of effort of R&T programs. 

The mission assurance strategy for SST flight demonstration projects has a different aim 

compared to that of science or exploration missions. SST is chartered to invest in a wide array 

of emerging, high-risk / high-reward technologies and to rapidly mature them to flight with the 

understanding that a minority will prove to be transformative. Economically appropriate efforts 

are made to ensure that space flight demonstrations yield useful results; mission failure in this 

context means that flight test data was not obtained, rather than whether all performance 

metrics were completely achieved. As such, the SST philosophy is to not expend cost and 

schedule to eliminate all uncertainty in technical risk as doing so would jeopardize future 

opportunities for achieving the desired results. 

For SST projects managed at a NASA Center, the Center technical authority may make 

recommendations to the SST program office. Projects may invite TA’s to participate in periodic 

project reviews for efficiency in their oversight roles. TA involvement in project activities should 

ensure that any significant views from the TA be made available to the program in a timely 

manner and should be handled during the normal project processes. However, ultimate 

responsibility for project success, in conformance with governing requirements, remains the 

responsibility of the SST program and the SST project manager. Authority for system 

acceptance for flight resides with the SST Program Office. Unresolved disagreements are 

elevated to the SST Program Executive and STMD Chief Engineer. See NPR 7120.8 Sect. 

5.4.7. 

Technical Authority Recommended Practices (*SST-NC, ***SST-SpaceDemo): 

• For efficiency in TA oversight, Center-designated TAs may be invited by NASA 

technology flight demonstration projects to attend the project’s internal technical reviews.

Projects may accept and disposition TA comments within consideration of the project 

risk posture. Responsibility for project success in conformance with governing 

requirements remains the responsibility of the SST program and SST project manager. * 

• Projects executed at NASA Centers should request their Center Engineering TAs to 

review and approve the project SEMP, or the SEMP paragraphs of the Project Plan. * 

• Projects executed at NASA Centers should request their Center Safety and Mission 

Assurance TAs to review and approve the project SMAP (if the project has determined 

that the project contains safety-critical elements). * 

• NASA technology flight demonstration projects are encouraged to involve a Safety and 

Mission Assurance TA early in the project, for cognizance and oversight of project- *,*** identified safety-critical items. 

• SMA mission assurance TAs should be consulted by NASA projects when tailoring their 

Mission Assurance and Quality processes. SMA TAs must approve waiver of any 

processes required by NASA Procedural Requirements. * 

4.10. Obtaining a Launch 

Purpose of this Section: Useful references to commonly available suborbital and orbital launch 

service providers are given here to aid NASA and non-NASA projects seeking flight 

demonstrations. 

21 
 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Small Spacecraft Technology Program Guidebook for Rev.: - Technology Development Projects 

4.10.1. Launch opportunities and POCs 

• NASA Launch Opportunities: https://s3vi.ndc.nasa.gov/launchportal/ 

• NASA CubeSat Launch Initiative (CSLI): https://www.nasa.gov/content/announcementof-opportunity-for-cubesat-launch-initiative 

• Commercial Lunar Payload Services (CLPS): 

https://www.nasa.gov/content/commercial-lunar-payload-services-overview 

• Science Mission Directorate Heliophysics Rideshare: 

https://www.nasa.gov/sites/default/files/atoms/files/a.mendoza-hillsmd_rideshare_nasatownhall_2020.pdf 

• Space Technology Mission Directorate Flight Opportunities: 

https://www.nasa.gov/directorates/spacetech/flightopportunities/opportunities 

Example of Commercial Rideshare Organizations 

• NanoRacks: https://nanoracks.com/products/rideshare-launch/ 

• SpaceX rideshare: https://www.spacex.com/rideshare/ 

• SpaceX Rideshare Payloads User’s Guide (November 2020): 

https://storage.googleapis.com/ridesharestatic/Rideshare_Payload_Users_Guide.pdf 

• Space Systems/Loral, LLC (SSL): https://www.maxar.com 

• Spaceflight: https://spaceflight.com/services/ 

4.11. Verification, Validation, and Expedited Spaceflight Qualification Testing 

Purpose of Section: Clarify SST Program’s objectives and approach to technology 

demonstration (including demonstration in space) as distinct from NPR 7120.5 Spaceflight 

product V&V. Describe efficient qualification requirements and approaches for technology 

demonstrated in space. 

R&T products under NPR 7120.8, including those demonstrated in space, are not verified and 

validated as would be for an NPR 7120.5 Spaceflight mission. Technology developed for 

demonstration in space should, however, be qualified per the launch service provider’s 

requirements. The SST Program may also impose requirements, which should be documented 

in the project plan or SEMP. Technology demonstrations in space typically undergo 

environmental qualification for the expected range of storage, transport, launch and space 

operational environments. Particular qualification requirements depend on the characteristics of 

the launch vehicle and launch providers generally establish qualification requirements, with 

Thermal Vacuum testing (TVAC) parameters generally driven by the expected on-orbit 

operational environment. Launch providers also give safety and interface requirements design 

requirements which must be verified as being met by the project. Launch providers require 

verification artifacts provided by the project that qualification requirements have been met 

before delivery or may approve certain waivers in some circumstances. 

Other than the R&T product, hardware and software that will support the technology (spacecraft 

bus or spacecraft subsystems not part of the R&T technology under development) can be 

verified and validated for the space environment. If multiple copies of the bus or subsystems are 

built to be re-flown without configuration change, they only need to be verified and qualified 

once, with the first unit typically undergoing (proto-)qualification testing, and subsequent ones 

22 
 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Small Spacecraft Technology Program Guidebook for Rev.: - Technology Development Projects 

acceptance testing. In some instances a dedicated non-flight qualification unit can be used to 

qualify the design, with all flight units undergoing acceptance testing. 

Differences Between Verification, Qualification, Acceptance and Certification 

Crosscutting with Verification are the Acceptance and Qualification processes. Below are 

excerpts from the NASA/SP-6105 NASA Systems Engineering Handbook. 

Verification: Verification is a formal process, using the method of test, analysis, inspection or 

demonstration, to confirm that a system and its associated hardware and software components 

satisfy all specified requirements. The Verification program is performed once regardless of how 

many flight units may be generated (as long as the design does not change). 

Qualification: Qualification activities are performed to ensure that the flight unit design will 

meet functional and performance requirements in anticipated environmental conditions. A 

subset of the verification program is performed at the extremes of the environmental envelope 

and will ensure the design will operate properly with the expected margins. Qualification is 

performed once regardless of how many flight units may be generated (as long as the design 

does not change). 

Acceptance: A smaller subset of the verification program is selected as criteria for the 

acceptance program. The selected Acceptance activities are performed on each of the flight 

units as they are manufactured and readied for flight/use. An Acceptance Data Package is 

prepared for each of the flight units and shipped with the unit. The acceptance test/analysis 

criteria are selected to show that the manufacturing/workmanship of the unit conforms to the 

design that was previously verified/qualified. Acceptance testing is performed for each flight unit 

produced. 

Certification: Certification is the audit process by which the body of evidence that results from 

the verification activities and other activities are provided to the appropriate certifying authority 

to indicate the design is certified for flight/use. The Certification activity is performed once 

regardless of how many flight units may be generated. 

See also NPR 7123.1 for more formal definitions of Verification and Validation. 

Proto-Qualification is a hybrid strategy between Acceptance and Qualification; it consists of 

testing the first flight hardware to Proto-Qualification requirements to verify design while 

maintaining its flight worthiness, then testing subsequent flight hardware (if any) to acceptance 

levels to screen workmanship defects. 

The following figure is provided as an example of the Integration and Test (I&T) Flow. This 

particular sequence is not mandatory but should serve as an adequate case of speedy 

qualification testing and is tailorable. 

23 
 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

-

-

Small Spacecraft Technology Program Guidebook for 

Technology Development Projects Rev.: -

Final SC 

Assembly 

Bakeout Mass/CoM/MOI 

Measurements 

Random 

Vibration Test 

Mission Sim Final FSW Load 

ADCS Testing Comprehensive 

FPT 

Final 

Mass/CoM/MOI 

Measurements 

Final Dispenser 

Integration 

SC Delivery to 

Launch Site 

Comprehensive 

FPT 

Comm Testing 

Final Compre 

hensive FPT 

SC Assembly Conformal Coat Dispenser 

Fit check 

Subsystem Level 

Testing 

Regression 

Testing 

In Dispenser 

Checkout LV integration 

SC Disassembly 

EPS Testing 

Final EPS 

Testing 

Final ADCS 

Testing TVAC E2E Comm Testing 

CAC = CubeSat Acceptance Checklist 

CoM = Center of Mass Measurement 

E2E = end-to-end testing with groundstation 

FPT= Functional Performance Test 

TVAC = Thermal Vacuum Test 

MOI = Mass Moments of Inertia 

Figure 1. Generic I&T Flow – Baseline 

Expedited Qualification Sequence – a.k.a. “Minimum Compressible Test Flow”

This represents a baseline set of tests to be performed to meet launcher and mission 

requirements by a project within the acceptable risk posture of the program, that a project will 

revert to if it needs to free up schedule margin. It is good practice for teams to establish this set 

prior to the start of the I&T campaign and get concurrence from applicable stakeholders, to 

ensure that this minimum set does indeed meet all the necessary requirements. 

The General Environmental Verification Standard (GEVS) for GSFC Flight Programs and 

Projects (GSFC-STD-7000) is frequently used for flight projects at NASA Centers as well as the 

private and academic sectors. The Mission Success Handbook for CubeSat Missions (GSFCHDBK-8007) also includes a version of the GEVS that is tailored for CubeSats in Appendix A, 

“Environmental Test for CubeSats”. Both of these references may be on the conservative side

for small spacecraft technology demonstration flights and developers are encouraged to tailor 

the environment and test plan appropriately for the scope and risk profile of the flight project. 

However, developers are also reminded that small spacecraft are predominantly launched as 

secondary payloads, and a conservative approach on launch loads and environments is often 

warranted to preserve the greatest set of launch opportunities. 

Verification, Qualification, Acceptance and Certification Recommended Practices: 

• “Test as you fly, fly as you test”: following this philosophy helps ensure that the testing

campaign and planned operations are commensurate with one another and the 

expected environments, increasing the likelihood of success. 

24 
 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Small Spacecraft Technology Program Guidebook for Rev.: - Technology Development Projects 

• Plan early (during system concept, preliminary and detail design phases) and follow a 

schedule for tests to be conducted during spacecraft element procurement, fabrication, 

assembly and integration phases to screen and ensure hardware and software function 

as intended. Finding problems early gives more time for correction or alternatives. 

• Schedule margin and contingency should be planned for each test to ensure sufficient 

time, budget and alternatives to mitigate unplanned test results. Tests are meant to 

detect problems; neglecting contingency plans may result in schedule problems. 

• Nominal values and margin for thermal, vibration, and shock environmental qualification 

should be selected depending on the anticipated environments for launch, ascent 

environment of the particular launch vehicle, and expected on-orbit environment. If the 

particular launch vehicle is unknown at the time of qualification testing, the generic 

GEVS environment may be used. Even if the launch vehicle is known, it may still be 

prudent to use the generic GEVS environment as the majority of SST missions to date 

have switched launch vehicles at least once during development to mitigate the effects 

of changes in launch vehicle schedule or availability on the mission schedule and cost. 

(On rare occasions – such as for atypical launchers and/or launch configurations – the 

launch envelopes can sometimes exceeed that of the typical GEVS profiles; projects 

should be on the lookout for such circumstances and use best engineering judgement 

when proceeding forward). 

• Environmental stress during storage and during shipment to the integration or launch 

site can damage hardware just as the launch environment would. Include design test for 

all known environmental exposure for qualification. 

• Qualify your batteries for ISS deployment as that is the most restrictive case and will 

drive LV selection. Refer to the NanoRack Battery Guidance/requirements for ISS 

requirements. 

• End (pusher) plate switches are, typically, preferred over rail switches. 

• LV’s will require materials lists for various purposes, such as the Orbital Debris 

Assessment Report (ODAR), and Outgassing assessments. These are NOT typically 

the same list as they have different criteria. 

4.12. Spectrum Management and Radio Licensing. *SST-SpaceDemo 

Purpose of Section: SST projects to be demonstrated in space need to be aware of approval 

authorities and long lead times for radio licensing. Projects implemented at NASA Centers 

typically are licensed through NTIA. Projects implemented in the private sector and academia 

typically are licensed through FCC. For both licensing agencies, licensing process may take 

more than a year after application. 

4.12.1. Spectrum Management Introduction 

Domestic (U.S.-based) small spacecraft radio licensing and documentation differ depending on 

whether the spacecraft operator is a federal (military or civilian) agency, or non-federal 

(commercial or academic) entity. In the US, two federal agencies have responsibilities for 

management of spectrum. For federal spectrum, the National Telecommunications and 

Information Administration (NTIA) is the lead authority. For non-federal spectrum, the Federal 

Communications Commission (FCC) has regulatory purview. 

A. Projects Managed by Universities or other Non-Government Entities 

For spacecraft managed, developed, and operated by non-government entities, the FCC will 

approve spectrum allocation and license the space station and any non-government25 
 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Small Spacecraft Technology Program Guidebook for Rev.: - Technology Development Projects 

operated ground stations. In addition to licensing the radio, the FCC will not grant launch 

approval without Orbital Debris Assessment Report (ODAR) approval. Radio licensing will 

include requirements that spacecraft command and control include a provision for silencing 

the spacecraft radio in case of radio interference. 

B. NASA and Other Government Agencies (OGA) Demonstrations in Space 

NASA Center Spectrum Management Offices coordinate spectrum allocation and interface 

with the NTIA. For NASA missions that are being operated by non-government entities, the 

NTIA requires that NASA maintain “effective control” through contractual or other means to

silence the spacecraft radio in case of radio interference. 

4.12.2. Lead times 

Begin planning for spectrum allocation as soon as possible, even before the project has 

selected the exact radio models and settled on a choice of spectrum. Inputs from NASA 

spectrum management, FCC and other licensing authorities may influence design trades. It’s

also best to give the authorities notice of the upcoming mission so they can begin their planning. 

Typically, the licensing authorities should be contacted at least two years in advance of delivery 

of the spacecraft for launch. This is a challenge for the rapid tempo of small spacecraft and SST 

missions should start the process as soon as the project is in pre-planning (Pre-Phase A). 

Many projects hire experienced consultants, or spectrum engineers, to guide them through the 

licensing process. Consultants may have access to points of contact within the licensing 

agency, insight derived from previous missions, as well as experience and understanding of the 

types and details of data needed for the RFA Application or spectrum filing form. 

4.12.3. References: Organizations and POCs 

ITU - International Telecommunication Union is the United Nations specialized agency for 

information and communication technologies (ICTs). 

https://www.itu.int/en/about/Pages/default.aspx 

NTIA - National Telecommunication and Information Administration is the Executive Branch 

agency that is principally responsible for advising the President on telecommunications and 

information policy issues. NTIA’s programs and policymaking focus largely on expanding

broadband Internet access and adoption in America, expanding the use of spectrum by all 

users, and ensuring that the Internet remains an engine for continued innovation and economic 

growth. 

https://www.ntia.doc.gov 

FCC - The Federal Communications Commission regulates interstate and international 

communications by radio, television, wire, satellite, and cable in all 50 states, the District of 

Columbia and U.S. territories. An independent U.S. government agency overseen by Congress, 

the Commission is the federal agency responsible for implementing and enforcing America’s 

communications law and regulations. 

Part 25- CFR-2015-title47-vol2-part25.pdf 

FCC Office of Engineering and Technology, Experimental Licensing System (ELS) 

https://apps.fcc.gov/oetcf/els/index.cfm 

https://www.fcc.gov 

26 
 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Small Spacecraft Technology Program Guidebook for 

Technology Development Projects Rev.: -

NASA Center’s Spectrum Managers -

For projects executed at NASA Centers, the updated list of NASA Center Spectrum Managers is 

found at: 

https://www.nasa.gov/directorates/heo/scan/spectrum/txt_NASA_Spectrum_Personnel.html 

• NPR 2570.1 – NASA Radio Frequency Spectrum Management Manual 

• Spectrum Considerations for Interplanetary SmallSat Missions, William Notley, 

Interplanetary Small Satellite Conference, Santa Clara, CA, April 2015 

• Spectrum 101 - An Introduction to National Aeronautics and Space Administration 

Spectrum Management, February 2016 

• Spectrum Guidance for NASA Small Satellite Missions, Version 1.0 (2015.08.27) 

Spectrum Management / RF Licensing Recommended Practices (*SST-NC, **SST-PS, 

***SST-SpaceDemo): 

• For projects managed at a NASA Center, during pre-Phase A, before a project has 

authorization to proceed (ATP), or as soon as possible after ATP, contact the local 

Center Spectrum Manager to discuss spectrum management issues and regulations that 

could influence / be influenced by mission design, choice of orbit, and technical trades 

for transponder(s).*,*** 

• For projects managed outside NASA Centers, during pre-Phase A, before a project has 

authorization to proceed (ATP), or as soon as possible after ATP, consult an FCC 

licensing consultant, review the FCC ELS web site, and make initial contacts with the 

relevant FCC authorities to discuss spectrum management issues and regulations that 

could influence / be influenced by mission design, choice of orbit, and technical trades 

for transponder(s). **,*** 

• The lead time for planning and licensing spectrum can take a year or longer. The NTIA 

process is time consuming. The process involves coordination with other missions, 

NASA-wide coordination, interagency coordination, coordination with international 

authorities; aspects of the spectrum management process cannot be expedited by a 

project or NASA line management. *,**,*** 

• Projects should identify a member of the project team who will serve as the project’s 

spectrum engineer (i.e. the project’s single point of contact to the spectrum management

authority). The spectrum engineer will coordinate with the Center Spectrum manager (or 

with the FCC) as the single POC for communicating project design information impacting 

spectrum management. The spectrum engineer should be embedded within the project 

to facilitate timely dissemination of latest mission design information. *,**,*** 

• Considerations include orbit selection (or, range of orbit considerations in the case of a 

ride-share launch that has yet to be identified). *,**,*** 

• It is best for projects to include a spectrum engineer experienced in the process, who 

understands the detail of the data required, and how it needs to be formatted, and the 

importance of providing complete and precise design data in planning and in the 

spectrum filing form. *,**,*** 

• Projects managed at NASA Centers communicate to their Spectrum Management Office 

the design information needed for spectrum management in a standardized “RFA

Application” spectrum filing form. *,*** 

• The NASA RF Allocation and Assignment Process and Procedures is found in NPR 

2570.1C Chapter 3. *,*** 

27 
 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Small Spacecraft Technology Program Guidebook for 

Technology Development Projects Rev.: -

4.13. ODAR and EOMP 

Purpose of Section: Convey ODAR and EOMP lessons-learned. Reminder that all projects 

submit ODAR and EOMP. Explanation of submittal routing (from project through SST Program 

approval; Program relays them to NASA OSMA). 

To ensure compliance with international law, all SST projects implemented at a NASA Center or 

in the private sector or academia must follow the orbital debris requirements in NASA-STD8719.14 Process for Limiting Orbital Debris, NPR 8715.6 NASA Procedural Requirements for 

Limiting Orbital Debris and Evaluating the Meteoroid and Orbital Debris Environments, and the 

Orbital Debris Mitigation Standard Practices (ODMSP). 

ODAR and EOMP Recommended Practices: 

• For secondary payloads, a full ODAR package may require approval at PDR or a PDRequivalent. Teams are encouraged to have the ODAR package pre-reviewed by the 

NASA Centers OSMA Representative. 

o For LSP launches, ODARs should be consolidated and submitted by LSP for all 

its payloads prior to FRR. There is no ODAR responsibility from payloads to 

OSMA in this scenario. 

o For commercial launch vehicles licensed by the FAA or orbital vehicles licensed 

by the FCC, there are currently no ODAR responsibilities from payloads to 

OSMA. However, OSMA still reviews the abbreviated debris assessment when/if 

NASA contributes an instrument or other element to a mission led by another 

space agency, to ensure that the agency does not deliver hardware known to 

violoate orbital debris mitigation principles. 

To accelerate the process, ODAR and EOMP templates are available in NPR 8719.14 Appendix 

A and B, respectively. Note that ODAR sections 9 through 14 for the launch vehicle are typically 

not covered for CubeSat Secondaries. 

4.14. Planetary Protection 

Purpose of Section: For SST technology demonstrations beyond Earth orbit, the project shall 

take measures to address forward contamination (transmittal from Earth to a targeted Solar 

System body) and backward contamination (transmittal to Earth from the targeted body) with 

respect to other Solar System bodies. 

The following documents apply: 

• NPD 8020.7G, Biological Contamination Control for Outbound and Inbound Planetary 

Spacecraft 

• NID 8020.109, Planetary Protection Provisions for Robotic Extraterrestrial Missions 

• NASA‐HDBK‐6022, NASA Handbook for the Microbiological Examination of Space 

Hardware 

Planetary Protection Recommended Practices: 

• Note that forward contamination is of particular concern for Mars, Europa, Enceladus, 

and other icy satellites with possible liquid water bodies within. 

• For additional information, developers should contact the NASA Planetary Protection 

Officer while the requirements are in development. 

28 
 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Small Spacecraft Technology Program Guidebook for Rev.: - Technology Development Projects 

4.15 References to S3VI, other portals and sources for best practices 

• The Small Spacecraft Systems Virtual Institute (S3VI): www.nasa.gov/smallsat-institute 

• S3VI Reliability Initiative:https://www.nasa.gov/smallsat-institute/reliability-initiative 

• Space Mission Design Tools: https://www.nasa.gov/smallsat-institute/space-missiondesign-tools 

• The SmallSat Parts On Orbit Now (SPOON) database: https://s3vi.ndc.nasa.gov 

• Trajectory Design and Optimization Tools: https://trajbrowser.arc.nasa.gov 

• The Astrogator's Guild: https://astrogatorsguild.com 

• General Mission Analysis Tool (GMAT): 

https://opensource.gsfc.nasa.gov/projects/GMAT/index.php 

• Debris Assessment Software (DAS): https://orbitaldebris.jsc.nasa.gov/mitigation/debrisassessment-software.html 

• Copernicus: https://www.nasa.gov/centers/johnson/copernicus/index.html 

• Mission Analysis Low-Thrust Optimization program (MALTO): 

https://www1.grc.nasa.gov/space/?ref=spaceSSPO/ISPTProg/LTTT/ 

• Spacecraft Planet Instrument Camera-matrix Events (SPICE): 

https://naif.jpl.nasa.gov/naif/toolkit.html 

• Open Mission Control Technologies (MCT): https://nasa.github.io/openmct/gettingstarted/ 

• Space Environment Information System (SPENVIS): https://www.spenvis.oma.be 

• NASA Tech Transfer Program: https://software.nasa.gov 

• NASA Engineering Network communities of practice: 

https://www.nasa.gov/content/nasa-engineering-network-communities-ofpractice/index.html 

• NASA Launch Services Program (LSP) Performance Web Site 

https://elvperf.ksc.nasa.gov/Pages/Default.aspx 

• State of the Art of Small Spacecraft Technology 

https://www.nasa.gov/smallsat-institute/sst-soa-2020 

• NASA and Smallsat Cost Estimation Overview and Model Tools 

https://www.nasa.gov/smallsat-institute/nasa-and-smallsat-cost-estimation-overviewand-model-tools 

• NASA Public Lessons Learned System 

https://llis.nasa.gov/ 

• Government-Industry Data Exchange Program (GIDEP) 

https://www.gidep.org/ 

• NASA Online Directives Information System (NODIS) Library 

https://nodis3.gsfc.nasa.gov/main_lib.cfm 

• NASA Technical Standards System 

https://standards.nasa.gov/ 

• NASA Software Engineering and Assurance Handbook (living document) 

https://swehb.nasa.gov/display/SWEHBVC 

• ODARs and EOMPs 

https://orbitaldebris.jsc.nasa.gov/mitigation/debris-assessment-software.html 

https://sma.nasa.gov/news/articles/newsitem/2018/06/26/complying-with-od-mitigationrequirements 

29 
 

 

 

 

 

 

Small Spacecraft Technology Program Guidebook for Rev.: - Technology Development Projects 

https://www.federalregister.gov/documents/2020/08/25/2020-13185/mitigation-of-orbitaldebris-in-the-new-space-age 

The following sections may be incorporated in future revisions of the Guidebook: 

• Technology Transition – Demonstration in Space, NASA Infusion, and Commercialization 

• Streamlined Procurement, COTS Elements and Commodity Items including Spacecraft 

Bus – NASA 

• Cybersecurity and Command Link Protection 

• Launch Provider’s Safety and Interface Requirements Compliance 

30