c

GHB 7150.1 A
APRIL 1972
/--.',',5 35/

GODDARD SPACE FLIGHT CENTER

M 9 0- 7055 1
P91JJttT

uncl a s
oo/tjl 0255352

PROJE.CT MANAGER'S
HANDBOOK
 FOREWORD

T'his handbook sets forth the practices and procedures to be

followed in carrying out all scientific, applications, and launch ve-
hicle projects at the Goddard Space Flight Center. This document
reflects GSFC policy and e'xperience, and should be followed unless
exceptions are appropriate in the view of the Project Manager'.
Project Plans will delineate those areas where there a r e exceptions
from this handbook.

Donald P . Hearth
Deputy Director

iii
 C 0NT E AUTS

.
Part Page

1 INTRODUCTION ............................................. 1-1

1.1 Scope and Applicability * ........................... 1-i

12 Origination and Revision ................................ 1-1
1.3 Authorization .......................................... 1-2
1.4 Distribution ........................................... 1-2

2 PROJECT MANAGIhlENT ....................................... 2-1

2.1 Introduction ............................................ 2-1

2.2 Project Planning ....................................... 2-1
2.3 Functions and Authorities of Program Managers
and Project Managers ................................... 2-4
2.4 Project Organization and Responsibilities ................. 2-4
.
25 Management Information Systems ......................... 2-11
2.6 Functional Support ....................................... 2-16
.. 2.7 Inter-Center Support .................................... 2-18
2.3 Interface Documentation ..... : ........................... 2-19
2.9 Configuration Management ............................... 2-22
2.10 Documentation Management System ....................... 2-22
.
2 11 Flight Mission Objectives and Success Criteria ............ 2-24
2.12 Applicable Instructions and Guidelines .................... 2-26
2.13 International Cooperative Project Management ............. 2-35
2.14 Experiments ............................................ 2-36

3 SYSTEM TESTS ............................................. 3-1

3.1 Ph~osophy ............................................. 3-1

. 3.2 Basic Concepts of System Testing . . . . . . . . . . . . . . . . . . . . . . . . 3-1
. 3.3 System Testing ......................................... 3-2
3 .I, General Environmental Test Speclfications . . . . . . . . . . . . . . . . 3-3
3.3 Detailed Environmental Specifications and Test Plans . . . . . . 373

4 . OPERATIONAL REQUIREMENTS ............................. 4-1

. .
4.1 General . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-1
4.2 Lnterfaces ............................................. 4-2
-
..
.
V
 CONTENTS (continued)

.
Part Page
.
4.3 Documentation .......................................... 4-3
4.4 Simulations and Tests ................................... 4-8

5 PROJECT REVIEWS .......................................... 3-1

5.1 Project Manager's Reviews .............................. 5-1

58 GSFC Design Review Program ........................... 5-1
3.3 Tracking and Data Systems Readiness Reviews ............. 5-2
5.4 Mission Failure Investigations ........................... 5-2
5.5 Mission Evaluation Review ............................... 5-3

6 RELIABILITY AiND QUALITY ASSURANCE .................... 6-1

6.1 Reliability.............................................. 6-1

62 Quality Engineering ..................................... 6-2
6.3 Malfunction Reporting (Failure Reporting) ................. 6-3
6.4 Parts Program ......................................... 6-3
6.5 NASA Reliability and Quality Assurance Publications ....... 6-4

7 DATA UTILI2 ATION Ai MANAGEMEANT

m ..................... 7-1

7.1 Experiment Data Analysis. Utilization. and Reporting ....... 7-1

72 Principal Investigator ................................... 7-1
7.3 Funding ................................................ 7-1
7.4 Data Use ............................................... 7-1
7.5 Data Requirements Review Committee .................... 7-2
7.6 Headquarters Reviews ................................... 7-2
7.7 NASA Policy Documents ................................. 7-3

8 PROCURE.E. .............................................. 8-1

8.1 Procurement Functions and Organization .................. 8-1

82 Procurement Relationships............................... 8-3
3.3 Procurement Cycle and Lead Times ...................... 8-4
8.4 Preprocurement Request Stage ............................. 8-7
. 8.5 Precontract Stage., ...................................... 8-11
8.6 Postcontract Stage. ..................................... 8-22
8.7 Special Areas of Interest ................................ 8-25

vi
 CONTENTS (continued)

Page
.
Part .
* 9 FINANCIAL MANAGEMEANT................................... 9-1

9 .I NASA Funding Policy . Direct to Project .................. 9-1

9.2 Technical'and Business Responsibility .................... 9-1
9.3 Project Approval Document (PAD)........................ 9-1
9.4 Resources Authority Warrant iForm 5 0 6 ) .................. 9-2
9.5 Subauthorizations ....................................... 9-2
9.6 Reimbursables .......................................... 9-2 '

9.7 Budget Development and Review .......................... 9-3

.
98 Program Operating Plan (POP) ........................... 9-9
9.9 Continuing Resoiution ................................... 9-10
.
9 10 GSFC's Job-Order Structure ............................. 9-11
9.11 Approval Levels for Procurement Request and
Internal Reprogrammings ................................ 9-11
9.12 Reprogramming (External-Headquarters) ................. 9-11
9.13 Commitments ........................................... 9-12
9.14 Obligations ............................................. 9-12
9.15 Accrued Cost ........................................... 9-12
9.16 Uncos t ed Obligations (Forward Funding) ................... 9-13
9.17 Encumbered Funds ...................................... 9-13
.
9 18 Disbursements .......................................... 9-13
9.19 Test and Evaluation Division and Quality Assurance
Division Fund&- .................................... ..... 9-13
920 Space and Earth Sciences (SES)Directorate
Computer Funding....................................... 9-14
921 Fabrication Charges..................................... 9-15
92 2 Project Job Order Status Reparts ......................... 9-15

vii.
 _-

CONTENTS (continued)

APPENDIXES

Appendix -
Page

A FUNCTIONS AiW AUTHORITIES O F PROGRAM

MANAGERS AND PROJECT MANAGERS ON OFFICE
O F SPACE SCIENCE AiUD APPLICATIONS FLIGHT
...........................................
P R O G ~ ~ S A-1

B GENERALIZED P R O J E C T ORGAiWATION.. ............ B-1

C OUTUUE OF MODEL SYSTEMS SAFETY PLAN ......... C-1

D SUPPORT INSTRUMENTATION REQUIREMENTS

DOCUMENT (SIRD) RELEASE PROCEDURES ............ D-1

E EXAMPLES OF MEMOFKLWA OF AGREEMENT ......... E-1

viii
 ’ ILLUSTRATIONS

Figure Page
2-1 Documentation Inventory Report ............................. 2-25

8-1 Procurement Division Organization Chart .................... 8-2

8-2 Procurement Administrative Lead Time ...................... 8-8

9-1 AManpower Budgeting Milestones .............................. 9-5

.
 PART 1
INTRODUCTION
, 1.1 SCOPE AND APPLICABILITY

The Project Manager's Handbook of practices and procedures defines the

primary guidelines to be followed in carrying out all scientific, applications,
or launch-vehicle projects of the Goddard Space Flight Center (GSFC).

The policies stated herein should be followed unless exceptions a r e deemed

necessary by the Project Manager. Such exceptions will be delineated in the
Project Plans.

This document consists of eight basic parts:

1. Project iManagement (Part 2)

2. Systems Tests (Part 3)

3. Operational Requirements (Part4)

4. Project Reviews (Part 5 )

5. Reliability and Quality Assurance (Part 6)

6. Data Utilization and Management (Part 7)

7. Procurement (Part 8)

8. Financial Management (Part 9)

.I

1.2 ORIGINATION AAW REV'ISION

Any GSFC employee may o r i g h i t e a request for preparation of new procedures

o r review of existing procedures by writing to the Deputy Director of Projects,
who will serve as chairman of a permanent committee for project practices and
procedures. The committee will consist of representatives from the Systems .
Reliability Directorate, the iMssions and Data Operations Directorate, the
Space and Earth Sciences Directorate, the Network Directorate, the Space
Applications and Technology Directorate, and the Administration and Management

1-1
Directorate. Revisions must have the approval of the Deputy Director of
GSFC .
1.3 AUTHORIZATION

The Director, GSFC, has authorized publication of this handbook. After initial
release, the Office of the Director will approve additional o r revised procedures.

1.4 DISTRIBUTION

The Project Manager's Handbook, normally distributed to branch heads and

above, w i l l be issued to any individual whose request has the approval of his
Division Chief o r Project Manager. Copies of the handbook a r e available from
the Management Support Branch, Code 233, X5341.

1-2
 PART 2
PROJECT MANAGEME8T
2 . 1 INTRODUCTION

At GSFC, the Project Manager is the highest line official solely concerned with
a particular project. After a project is formally approved, he is the final au-
thority for saying "yesfrto a critical proposition. For example, in launch op-
eration, many officials can properly say "no" to the firing, but the Project
Manager. must be completely satisfied before the button is pushed. Goddard in-
vests full responsibility for mission success in the Project Manager. Within
the confines of established policies and procedures, full authority and accounta-
bility go with this.responsibility. However, because each Project Manager is
concerned primarily with his own project, the equitable distribution of available
resources is a function of Center general management. GSFC policy is to house
basic project personnel together, where practical.

2 . 2 PROJECT P U N N I N G

It is the policy of NASA that the implementation of major research and develop-
ment projects will b e done on the basis of plans and analyses that define the
effort to be accomplished. This policy is set forth in NiMI' 7121.1 (presently
being updated) and GHB-7121.3, GSFC Project Planning Handbook. (See also:
Management Study of HA% Acquisition Process dated June 1971, Letter to Dis-
tribution from Deputy Administrator dated June 9 , 1971, Subj : NASA Acquisition
Study Report). It should be remembered that the concept of Phased Project
Planning requires that a Project o r Study Manager take the time to plan the
effort such that the mission objectives can be accomplished for the minimum
expenditure of Government resources. This requires then that a Project Plan
(PP) (see para. 2.2.3) be formulated and approved prior to the initiation of
significant project effgrt. This plan then becomes a control document and is
in essence the "contract'! between GSFC and Headquarters:for the scope of
effort outlined.

2.2.1 GSFC Implementation of Project Planning

GHB 7121.3 prescirbes detail format for Project Plans, and the following de-
scribes briefly how this effort is implemented at GSFC.
The GSFC effort w i l l usually be accomplished in DNo -phases, rather than the
four phases in superseded NHB 7 1 2 1 . 2 . The phases now are: (1)Feasibility
and Systems Definition, (2) Execution. The output of Feasibility and Systems
Definition will, in many instances, be used to justify Congressional approval of
development funds. Thus, it is essential that this redefined first phase activity
be expanded somewhat so that various programmatic options a r e developed in
depth. This will permit a more reliable estimate of scope, cost, and schedule
for new projects. It is important also that this effort be in concert with the
Congressional and Office of Management and Budget approval cycles in order to
eliminate "dead time" while awaiting for approvals.

Where sufficient resources a r e available, it is desirable to conduct the Feasi-

bility and Systems Definition phase (including Systems Design) in-house and then
go directly into a single competition for the selection of the Execution phase
contractor.

In those cases where the Feasibility and Systems Definition activity has provided
a firm understanding of project objectives and requirements, but has identified
many system options and thus too great a n effort for in-house support, a compe-
tition should be initiated for multiple contractors to perform the Systems Design.
Subsequently a single contractor w i l l be selected for the Execution from the Sys-
tems Design effort contractors.

2 . 2 . 2 Initiation of New Project activities

GHB 7121.3 describes the documentation and procedures required when a new
activity -
which might become a full project -
is started at GSFC.

Projects conducted at the Center will generally be conducted in a number of se-

quential steps and, in general, will be preceded by a preliminary study of lim-
ited scope (known as a Candidate Study Effort) which can be conducted in any
organizational entity at the Center.

2 . 2 . 2 . 1 Candidate Study Effort. A preliminary study will be conducted and in-

clude mission identification with the scientific o r application objectives, alter-
native approaches, and a prelimicary engineering assessment. The preliminary
study will be concluded with a report and presentation to the Office of the Direc-
tor recommending whether or not the study should be e.xtended into Feasibility
and Systems Definition.

2 . 2 . 2 . 2 Study Management System. With an affirmative decision by the Deputy

Cente r Director, a Study Manager and Study Scientist w i l l be appointed and the
Feasibility and Systems Definition activities w i l l be initiated in accordance with
GHB 7121.3.

2-2
 In general, the Study Manager will conduct the Feasibility Study, produce an
Analytical Report at the completion of the Feasibility activity. Where there is
an affirmative decision for continuation of the effort, the Study Manager will
continue with Systems Definition and prepare a Project Plan in accord with the
timing and guidelines sanctioned by the Deputy Center Director.

2.2.2.3 Project Plan for the Next Phase. With an affirmative decision by
Center and Headquarters elements to proceed into System Definition, the Study
Manager will initiate these activities. A s early as feasible during the System
Definition activities the Projects Directorate, o r other responsible Directorate
w i l l recommend to the Management Council a Project Manager for the Execution
effort.

2.2.3 Project Plan

In a research and development (R&D) environment the executives who manage

aerospace programs a r e consistently confronted with the need to encourage
creativity while maintaining a degree of control; therefore, the need arises to
provide visibility to management on imminent issues, requirements, and actions.
The NASA vehicle for the conveyance of this information is the Project Plan.
That management document constitutes. the Project Manager's charter as well
. as GSFC's comprehensive master plan for accomplishing the effort. The Proj-
ect Plan is approved by the Center Director and submitted to Headquarters.
Once approved and signed by Headquarters, it becomes the basic working agree-
ment with the Center. The plan describes, in specific t e r m s , the technical,
financial, procurement, and management arrangements identified with any one
o r all of the phases. The Project Plan also includes a clear assignment of
managerial responsibility, authority, and statements of funding, manpower,
facilities and support which the field installation is furnishing to the project.
Project Plans must be coordinated with all cognizant offices and should be re-
viewed for necessary updating to reflect any major changes in the project.

The scientific, technical, managerial and administrative substance in Proj-

ect Plans mu&. be approved by the GSFC Deputy Director for all steps prior to
submission to NASA Headquarters. Those approvals must ,be obtained prior to
the release of resources and before the significant st3rt of operations described
in the Project Plan for a particular study or project phase; thus, the Project
Plan is part of a planning system and a sequential function in the life cycle of a
project.

As established in XASA Management Instruction 7120.1 Cpresently being re-

vised), each project is responsible for preparing, and modifying, as substantive
changes occur, a Project Plan.

2-3
 Implementation of the concept at GSFC involves the following steps:

A. New Project Ideas - Candidate Study Effort that surfaces ideas and
concepts within the Center that could culminate in development of a
spaceflight system (described in GHB 7121.3)

B. GSFC Study Management System; comprising two efforts of the first

phase identified as Feasibility and Systems Definition (described in
I GHB 7121.3)

C. Project Management System; comprising the Execution phase which in-

cludes detailed design and development (also described in GHB 7121.3)

The resident Program Support Specialist w i l l arrange for administrative inputs

and working assistance with the Technical Information Division and the Program
Support Division.

2.3 FUNCTIONS &VD AUTHORITIES OF PROGRAM 3WXAGERS

AND PROJECT MANAGERS

Appendix A , of this Handbook, w a s generated by the Office of Space Science

(OSS)when it was combined with the Office of Applications and known as OSSA. .
It contains guidelines for the functions and authorities of Program Managers
and Project Managers. OSSA prepared these guidelines with Center participa-
tion to provide a clear understanding of the relative role of Program Managers
at Headquarters and the Project Managers at field centers. It is assumed that
the same intent and definitions a r e applicable to OA.

2 . 4 PROJECT ORGANIZATION AND RESPONSIBILITES

This section does not prescribe detailed project organizational structures ; but
Appendix B does indicate, in general, a project organization that is used on
most GSFC projects in Code 400. The smaller, in-house projects located in the
E.xplorer Project Office and International Projects Office (Code 700) a r e usually
structured on a similar basis. Although the following sections a r e outlined by
titles, emphasis is on responsibilities that must be assigned as applicable. The
scope and size of a particular project may require, o r make it desirable, to
assign more than one specific responsibility outlined here to a single individual.
The PP should illustrate individual project organizational structures showing.
responsibilities and line authority. Official a p p r o v i of such organizations de-
rives from approval of the P P .

2 -4
2.4.1 Overall Management Responsibility

GSFC is assigned project management responsibility under the overall direction

of the Associate Administrator OSS o r OA. In addition to project management
responsibility, GSFC may be assigned systems-management responsibility f o r
systems such a s spacecraft, ercperiments , tracking and data-acquisition sys-
t e m , or Delta launch-vehicle system.

2.4:2 Project Manager

-
The appropriate Oirector of nominates a i d the Center Director's office ap-
proves the Project Manager. If the project has "Division" status, Headquarters
must concur in the appointment. The Project Manager is responsible for as-
suring the performance of alI functions necessary for management of the project.
In particular, he is responsible f o r projectwide planning and evaluation, systems
engineering and design, systems integration, test, reliability and quality assur-
ance, scheduling, budgetary and financial planning, techrucal monitoring of con-
t r a c t s , and project reporting. He has full authority to c a r r y out these functions,
subject to limitations established by the Director's Office, GSFC. He also coor-
dinates project requirements with other activities of the Center as well as keep-
ing the Headquarters Program Manager apprised of project status (see Appendix
A). The Project Manager discharges his responsibilities with the assistance and
support of individuals and organizations assigned either administratively o r func-
tionally to the project management organization.

2.4.3 Project Scientist

The appropriate Director of -, usually Space and Earth Sciences o r Space Appli-
cations and Technology Directorates, nominates and the GSFC Director approves
the selection of the Project Scientist. The Project Scientist is responsible for
assuring coordination between and satisfactory accomplishment of the scientific
objectives of the mission and its individual experiments. He participates in the
formation of the specific mission objectives; reviews the implementation of in-
dividual experiments to ensure that their objectives a r e consistent with the pro-
posal upon which the selection w a s based; reviews the spacecraft weight, power,
space, the telemetry assignments among e.xperiments , operating plans, data
acquisition and processing requirements all to ensure that the total system plan
is consistent with the overall mission objectives. He provides leadership in
assuring that the e-xperiment data a r e effectively used and the scientific results
of the mission are e-xpeditiously produced. The project scientist evaluates all
impacts on the scientific productivity of the project and provides scientific
guidance to the Project Nanager and others involved in the program.
2.4.4 Principal Investigator

The Project Plan will list the experiments to be performed on each spacecraft.
Experiments may be primarily scientifically, technologically, o r applications
oriented. The appropriate Associate Administrator selects all scientific ex-
periments and their associated principal investigators.

The Principal Investigator (PI)is responsible for assuring that the objectives
of the e.xperiment are met, managing the e.xperiment, publishing the results of
the experiment, and submitting the e-qeriment data to the National Space Science
Data Center (NSSDC) in a form usable by other e.qerienced investigators in the
field.

2.4.5 Deputy Project Manager

The Deputy Project Manager, when the position is required, is selected by the
Project Manager and his Director of -.
Approval by the Center Director's
office is required. The Deputy Project Manager is the alter-ego of the Project
Manager and as such may act for the Project Manager with respect to all the
Project Manager's responsibilities.

2.4.6 Assistant Project Manager

The Project Nanager selects with the concurrence of his Director of -, and the'
Center Director approves the Assistant Project Manager. The Assistant Proj-
ect Manager represents the Project Manager on all matters with the Project
Manager's cognizance to the e4xtentauthorized and assigned by the Project Man-
ager. As directed by the Project Manager, he may from time to time devote
full time to critical problems, assist in negotiating major contracts, etc. The
position of Assistant Project Manager is optional with the Project Manager.

2.4.7 Project Coordinator

The Project Coordinator is responsible to the Project Manager for coordinating

the activities of the various individuals and organizations involved in the project.
Duties and line of authority shall be defined by the Project Manager.

2 . 4 . 8 Systems 3f;LIanagers

Each Systems Manager is responsible to the Project Manager for ensuring

'
timely accomplishment of technical, procurement, budgetary, planning, and
other actions necessary to design, develop, fabricate, integrate, test, and de-
Liver or operate a particular system. In addition, the Systems Manager must
resolve coordination problems arising between his system and other systems.
Each Systems Manager i s responsible for keeping the Project Manager fully
informed of all actions taken in support of the project.

2.4.8.1 Spacecraft Systems Manager. The Spacecraft Systems Manager is

responsible f o r the design, integration, and test of the complete spacecraft
being adequate to give high confidence in mission success. Subsequent to launch
he is responsible for evaluating' and reporting the spacecraft performance. He
is also responsible for integrating the e,qeriments. The Spacecraft Systems
Manager has prime responsibility for spacecraft development and procurement.
He may carry out this responsibility through a number of subsystem-development
and flight-hardware contracts with private industry.

2.4.8.2 Edxperiment Systems Manager. The Experiment Systems Manager

monitors the progress of the experimenters to assure compliance with perfor-
mance, schedule, and cost requirements. If applicable, he serves as Techni-
cal Officer of all contracts with the e.qerimenters. He coordinates interface
problems with the other Systems Managers and the Project Scientist (see para.
2.4.3).

.
2.4.8.3 iMission Operations System Manager (MOSM) The MOSM is respon-
sible to and normally administratively assigned to the Project Manager for all
flight mission support and operations. This includes validating, and generating
project requirements, assuring adequate resources a r e committed and over-
viewing the implementation by the OTDA elements. He must have a complete,
detailed knowledge of the spacecraft including experiments and its operations,
capabilities, and limitations. The MOSM is responsible for preparing the op-
erations plan, beginning with the first elements of that plan as soon as the Proj-
ect Manager approves i t , and for refining and detailing the plan throughout the
life of the project. With the assistance of the Mission Support Manager and the
Network Support Manager the MOSivI will supervise, instruct, train, conduct
simulations with, and exercise the operations team to establish and assure a
performance capability consistent with the mission requirements. The MOSM
ensures that all equipment supplied by the project o r e.xperimenters for instal-
lation at any network station conforms to the.General Specifications for Network
Equipment Design and Construction, and is provided with the necessary spare
parts, manuals, and training.

2.4.8.4 Mission Support Xanager (3ISM). The M S M (Code 500) is the primary
contact for the Xission & Data Operations Directorate (ZYI&DOD)activities in

2-7
support of the project. He is responsible to the NOS31 for accepting and as-
sisting in the generation of project requirements, committing M&DOD re-
sources, and imp1ementh.g I\/Z&DOD support. He is responsible for preparing
the 42 &DOD inputs to the NASA support plan and the publication of the coordi-
nated plan. He is the prime contact for the Network Support Manager concern-
ing M&DOD National Directorate (ND)operational interfaces in support of the
mission.

2.4.8.5 Network Support Xanager. The Network Support Manager (Code 800)
is responsible to the Mission Operations Systems 3lanager for all network sup-
port to the project. He is responsible for accepting and assisting in the genera-
tion of project requirements and obtaining the commitment of network resources.
He is responsible for the committed network resources, preparation of the Net-
work Support Plan, including the launch vehicle tracking and data systems re-
quirements, implementing network operational support plans, and readiness
testing. He is the prime contact for the Mission Support Manager concerning
ND/M&DOD operational interfaces in support of the mission.

2.4.8.6 Launch-Vehicle Systems Manager. Although another center may be

assigned systems-management responsibility for the launch-vehicle system,
being adequate to support the mission, the Launch-Vehicle Systems Manager is
responsible for technical, procurement, budgetary, planning and scheduling,
and other actions necessary for designing, developing, fabricating, testing,
modifying, launching, and t r a c h g the launch vehicle through injection into the
transfer ellipse. This responsibility includes launch-vehicle systems engineer-
ing, i. e., assuring the integrity of the launch vehicle and the engineering com-
patibility of the launch vehicle and the spacecraft.

2.4.8.7 Test and Evaluation Support Xanager. For each project, the T&E
Division will assign an individual to support the Project Manager on all test
matters. The Support Manager advises the Project Manager on test require-
ments, prepares o r reviews the spacecraft test specification for approval of the
Project Manager, coordinates. the test program, and reviews test results. The
Support Manager's duties also include liaison with the T&E Division on techni-
cal, manpower. and fiscal matters.

.
2.4.8.9 Quality Assurance Support Nanager For each project, a Quality
Assurance Support 4fanager from the Quality Assurance Division, Systems Re-
liability Directorate, shall be assigned responsibility for assisting the Project
3Ianager in the project reliability and quality assurance effort. He also provides
liaison with the Quality Assurance Division on manpower and fiscal matters.

2-8
Specific responsibilities of the Quality Assurance Support Ganager on the proj-
ect staff a r e identified in Py-t 6, para. 6.2

2.4.9 Technical Staff

The scope and size of the technical staff will depend on the size, type, and
management approach of each particular project. Personnel, such as subsys-
tem engineers, will in general be assigned from the Space Applications & Tech-
nology Directorate (Code 700). There must be an engineer responsible for each
spacecraft subsystem.

2.4.10 Project Administrative and Management Staff

Personnel from the Administration and Management (A &i) Directorate shall

support each project in the area of procurement, scheduling (PERT), and finan-
cial analyses. The degree and scope of this support will depend on the size and
requirements of the project. The X&M staff will be housed with the project
when practical. X typical staff shall include:

A. X business representative, serving as a "single interface" for all

A&M Directorate support to the project, who will be administratively .
' staff
responsible for resident functional A &?bv l activities.

B. A Procurement Officer, either the Contracting Officer o r his represen-

tative, who will act as contract negotiator and manager for the project.
He shall be responsible for the timely accomplishment of all procure-
ment activities, and shall give assistance and advise on source-
selection justification, type of contract, negotiations. fees, etc.

C. Personnel to perform project-schedule analyses, using program eval-

uation and review technique (PERT), MICS, and other scheduling
techniques.

D. Financial Analysts, who shall be responsible for cost analyses budget

compilations, cost accounting, etc .

8.4.11 Project Systems Engineer

Each Project Manager shall name by direct and specific assignment to a par-
ticular individual (perhaps himself) the responsibilities of systems engineering.

2-9
 This includes not only system design but the assurance that all interfaces a r e
adequately specified and reviewed. These interfaces shall include not only those
between the spacecraft and e.xperiment systems but also those between the com-
plete observatory o r satellite and the launch vehicle, ground complexes, and
operational requirements. Specific responsibilities and authorities of this posi-
tion depend upon the individual project organizational structure. This position
is a staff function to the Project Manager.

2.4.12 Integration and Test Engineer

An Integration and Test Engineer may be assigned for each flight mission. The
scope of this position will depend on the method of project implementation; i.e.,
in-house integration and test, or contractor integration and test. This function
may be assigned to the Spacecraft Manager. The Integration and Test Engineer
shall be responsible for the preparation of plans and procedures for the final
assembly, integration, and flight acceptance test of the spacecraft system plus
experiments, and for the execution of those plans and procedures.

2.4.13 Configuration-LManagement Officer

The Project Manager shall designate a Configuration-Management Officer

(perhaps himself) for the project. GMI 8040.1 states the responsibilities of
this position.

2.4.14 Systems Safety Officer

The Project Manager shall designate a Systems Safety Officer (perhaps himself)
to implement a Systems Safety Plan (see 2.12.20 and Appendix C ) .

'2.4.15 Documentation-Management Officer

The Project Manager shall designate a Documentation-Management Officer

(perhaps himself). Paragraph 2.10 states the responsibilities of this position.

2.4.16 Environmental Committee

At his discretion, the Project Manager may establish a Project Environmental

Committee; appointment of such a committee is highly desirable in all large
projects.

Responsibilities of this committee should include assessment of requirements

for environmental testing (ref. General Environmental Test Specification S-320-
G-1), approval of environmental test specifications, and coordination and

~
--
I
2-10
 evaluation of facilities and tests necessary for project requirements. The
environmental committee will evaluate results and will certify thar; results
'
meet the specifications and that the test program is adequate to meet the
mission objectives.

2.5 MANAGEMENT INFORMATION SYSTEMS

2.5.1 Management Information and Control System (iWCS)

As required by NASA Handbook 2340.2, November 1966, projects must submit

monthly reports designed to:

A. Keep management at all levels informed on the status of the project.

B. Define responsibilities for accomplishment and approvals at all levels.

C. Interrelate the technical, schedule, and cost aspects of the project.

D. Provide the Project iManager with an opportunity for assessing the

status of the project.

E. Provide a mechanism for identification of decisions that are required

and for positive feedback of decisions made.

The monthly Project Managers' Report (PMR's)provide internal reporting within

the Center, as well as the official Center report to Headquarters. The structure
of the MICS, by level of detail, provides meaningful data for management pur-
poses throughout the organization. The Project Manager must use the Level 2
iMCS data for an oral briefing to Center management on the project status and
on the content of the report submitted to Headquarters.

Appropriate elements of the Program Support Division, w d l provide assistance

in the techniques of preparing the PMR's, if needed.

2.5.2 . Work Breakdown Structure

The Work Breakdown Structure (CVBS) is a basic management tool which is used
to systematically subdivide discrete blocks of work. A WBS, when properly
structured, can provide for: relating the specifications to the end item; identi-
fying controllable work packages for estimating resources ; budgeting and pricing;
work assignment and authorization and reporting.

2-11
*
It is a product-oriented family tree composed of hardware, software, services,
and other work tasks, which result from systems engineering and management
planning processes, and which completely defines the program/project. A W B S
displays and defines the products to be developed and relates the tasks to be
accomplished to each other and to the end product.

The structure represents how the work will be managed by the Project Office
and the contractor and is made up of work blocks arranged by level.. Blocks of
related and consistent work effort form a branch of the structure. Each block
is sub-divided into smaller elements down' to a control point which represents
the lowest level of controlled effort. by the project. .A WBS handbook has been
written at GSFC (GHB 7120.1; dated August 1971, Subject: Handbook for Prep-
aration and Implementation of Work Breakdown Structures).

2.5.3 Program Evaluation and Review Technique (PERT)

Basic elements of any scheduling system are:

A. hitial planning

B. Correlation of the interrelationship of project activities

C. Periodic reports on the status of the plans

D. Identification of critical paths of activity

E. .4ssistance in reprogramming project activities when necessary,

through its ability to simulate potential solutions to problems.

The size and complexity of project activities dictate whether the scheduling
activity can be covered by "bar charts" o r whether machine processing and the
p r o g r a m e d logic of PERT will be required. Where appropriate, consideration
should be given to the relationship of the schedulirg matrix with the W B S a s
there should be a continuity between all reporting requirements.

The scheduling technique that a contractor has implemented should be reviewed

for acceptance before any other technique is imposed. Only if it is reasonably
sure the contractor does have qualified personnel to properly implement PERT
and is required by the project, should GSFC impose it on a contractor. Other-
wise, PERT will only be a reporting system not a planning system. Assistance
in developing a PERT system is available from the Program Support Division.
Implementation and maintenance support is available from the applicable Pro-
gram Support Representative.

2-12
2 S.4 Contractor Financial Management Report (533)

Contractors must submit financial reports on all cost-plus contracts in excess

of $100,000. Cost contracts of a l e s s e r value may also require financial reports.
(Fixed-price contracts with cost incentives can require 533's also.)

Financial data are used as follows:

a. The contractor must develop a time-phased cost plan and must report
against that plan.

b. The,data serve as a basis for developing funding requirements for

budget preparation.

C. The data help to monitor contract progress by identifying manpower

application and material commitment.

d. The WBS subdivides the contract into manageable units which en-
hances resource plannjng and control and permits detail work flow
analysis.

e. The data serve a warning system for detecting potential cost overruns.

f. The data assist in pricing of future buys.

XASA Handbook 9501.2A, October 1971, provides additional details on the use of
contractor financial reports. The Program Support Division, will assist Project
Managers in making financial reports and in analyzing data received.

Again there should be a correlation with the WBS for consistency and
continuity.

2.5.3 PERT and Companion Cost -

Xany techniques can be used to interrelate and correlate schedule and cost data
received, ranging from PERT cost (a'technique used by the Department of De-
fense @OD). in costing out all activities included in.a PERT netu;ork) to a simple
comparison that total technical effort is percent complete and total
costs a r e percent expended.

NASA has selected PERT-Compznion Cost for developing a system that provides
a common framework for both cost and schedule reportiing. The total PERT
network is structured into "fragnets ' I (fragments of a network) which clearly

2-13
. identify a unit of work that also becomes a basis for collection of costs. On a
meaningful segment of the project activity schedule; therefore, cost can be re-
viewed on a common and meaningful basis.

Regardless of the reporting technique finally selected, the common work-

breakdown structure should be understood and used in initial project planning
because proper structuring can enhance the ability to assign responsibilities
and to select levels of detail for reporting requirements. These concepts and
techniques appear in the NASA PERT.and Companion Cost System Handbook,
October 1962. .4dditional assistance is available from the Program Support
Division.

2.5.6 Project Operating Plans

NASA Headquarters requires submission of the Project Operating Plans (POP)

in July and February. The July submission coincides with GSFC's grass roots
budget and updates GSFC's operating plan for the current fiscal year. The Feb-
ruary submission coincides with GSFC's mid-year update and provides the
budget information of the Congressional submission for the ne.* fiscal year and
approval of revisions for the second half of the current fiscal year. It also
provides the Office of Management and Budget (OMB) with a preliminary look
at subsequent FY requirements.

The project must review its funding requirements by fiscal year and for project
completion, as well as for the type of procurement envisioned and the estimated
date of availability of the procurement request. These data must be reafistic,
because compliance with the submitted POP becomes the measurement of the
effectiveness of the project's management of its resources.

The monthly Level 1 Headquarters Management Report constitutes a continuing

update of the latest Headquarters POP data. The current estimate, contained
in a GSFC Project Manager's PMR, is an information-only assessment of the
validity of the current POP.

The subject is discussed at greater length in Procurement (Part 9) and Finan-

cial Nanagement (Part 9). Information and support in preparing the POP a r e
provided by Program Support Division.

2.5.7 Business Data Reports

Information on the project's resource status is available from reports issued

on a periodic basis by the Business Data Branch, Program Support Division.
Funding status information oncurrent budget allocations, resource commitments,

....

2-14
obligations, and disbursement status is also available, a s a r e detailed'project
manpower application data. A machine-reporting register prepared by the
Business Data Branch constitutes a complete list of report frequency and avail-
ability. Assistance in interpreting and analyzing these reports is available
from the Program Support Division.

2.5.8 Director's Weekly Reports

Each project should submit a weekly report to the Director. The objects of
this report are:

A. A means for Project Managers, Division, Laboratory, and Office

Chiefs to communicate problems and major happenings directly and
openly with Center 'Management.

B. An updating of information (such as computer usage, special events,

X-document reports, etc .) of general interest to Center Management
and to other elements of the Center.

Guidelines for the reporkare as follows:

Directors Weekly Report

A . A concise summary of -
1. Major and important happenings.

2. Problems that cannot be resolved at the Division level.

'3.- Contr'oversial items -do not hide them under the rug. Get them
out in the open where management can deal with them.

B. Reports a r e to be provided by each Division/Laboratory Chief and

Project Manager, and certain office heads. The report is to reflect
his personal message.

2-15
 C. Each report should be one page in length, with a Wo-page Limit. Flag
problems - do not t r y to e.xplain them in detail.

D. Weekly reports a r e encouraged. Reports are e.xpected at least once

a month. Negative reports should be submitted if there a r e no major
problems and/or happenings.

E. Functional and project offices may report on the same item if both the
functional Division Chief and the Project &Tanagerhave personal mes-
sages on that item.

These reports are intended for information and communication and do not nec-
essarily.reflect official Center position.

2.6 FUNCTIONAL SUPPORT

2.6.1 Purpose

A l l administrative and technical support requirements supplied by functional

Directorates should be clearly defined and estimated to effectively plan the
most efficient use of the Center's resources and to ensure a complete under-
standing between the project and the functional area.

2.6.2 Applicability

This section shall apply to all organizational elements providing significant

amounts of functional support to the project and to in-house e.xperimenters.
(For the Mission and Data Operations and Networks Directorates, this section
refers to additional support beyond that specified in the Support Instrumentation
Requirements Document, paragraph 2.8.4.4. )

2.6.3 Memoranda of Agreement

Xemoruncla of Agreement for functional support shall be used unless '3 Project
>Imager decides to the contrary. They shall be prepared in the faliowing
manner.

2-16
 P r i o r to the release of the guidelines for semi-annual project involvement in
manpower POPS (grass roots and mark-up) the Project &Imager (PPI) o r Prin-
cipal Investigator (PI) shall prepare or update a statement of support require-
ments for each Division from which support is required. and fonvard it to the
pertinent Division Chiefs. This statement must be consistent with or modifica-
tions to other official agreements, particularly the Project Plan and the SIRD
(see para. 2.12.15). It should also include the Project Manager's latest asses-
'
sment of critical dates which affect planning requirements. The Division Chiefs
through discussions with each Project Manager or Principal Investigator shall
estimate the manpower required to be responsive to the Project Manager's
statement.

If, after assimilating all the inputs from the PM/PI, the Division Chief finds
that he has sufficient resources to support all projects, he and the Project
Managers sign memoranda of agreement in the format of Appendix E which shall
include a designation of both the man-years as well a s the identification by name
of those key individuals deemed essential for performance of the task. In deal&=
with Code 800 (Networks Directorate) all Memoranda of Agreement shall be be-
tween &e Project and the Xetworks Directorate, Requirements and Plans Office.
If the Division Chief has insufficient manpower to support all projects, he pro-
vides a.memorandum to his Director of- which (a) validates the requirements,
(b) reports the critical skill shortage, and (c) indicates the impact on his organi-
zation if required to support at the desired level. Copies of these memoranda
are supplied to the appropriate Director of- in which the project or experiment
is located.

At the same time, the appropriate Project Manager will prepare a memorandum
-
for his Director of which (a) validates the requirement and (b) indicates the
impact on the project of support at the level proposed by the functional Division
Chief. Copies of these memoranda a r e supplied to the appropriate functional
Director of -. Resolution should be attempted by the Directors of - prior to the
Director's manpower review. It is e4xpected that critical shortages and the im-
pact of such shortages as well as agreed upon requirements will be identified
through this process at the Director's review of the manpower POP for eventual
resolution.

Substantive changes in requiremerits between the POP exercises shall be handled

in exactly the same manner as described above.

Between POP' s the .PM/PI and the Division Chiefs have collective responsibility
-
for t e s t i q the validity of the estimates in executing the requirements was the
estimate too high o r too low so that manpower usage can become increasingly
effective through each succeeding POP. The PM'PI will be e-xpected to track
the actual vs the estimates at the' MICS reviews.

2-17
 2.6.4 Management Responsibility

It is the intent of Center management:

A. To apply adequate technical expertise to the Center's flight projects

and ,

B. To involve the functional managers (Branch and Division Chiefs) in the

review of their personnel's efforts on flight projects.

The relative responsibility of the Project Manager and the. Division Chief varies
with the nature of the task:

a For tasks accomplished at the functional location the Division Chief

has the responsibility for supervision and execution. The Project
Manager, in this case, only reviews the technical and fiscal progress
of the task, as well as the manpower e-upended.

0 For tasks requiring full time, collocation of functional personnel with

the project, the Project -Manager is responsible for the day-to-day
supervision of the functional personnel unless specified to the contrary
in the Memoranda of Agreement. The administrative responsibility
must be shared between the functional division and the project. It is
'

expected that the PM/PI will advise the functional supervisor on the
performance of those functional personnel residing with the project.
However, the Division Chief is responsible for periodic reviews of the
adequacy of the technical performance of their co-located personnel.
Differences of judgment between the project and functional personnel
can and should be appealed with the burden on the Project iManager and
the functional Division Chiefs to resolve such differences if possible.
I
0 In those cases where one functional man is assigned only part time to
a project o r splits his time between two projects, the functional chief's
responsibilities a r e greater. It is his responsibility to supervise the
time spent in the applicable areas and resolve any conflicts arising
from concurrent project. requirements.

2.7 INTER-CESTER SUPPORT

When project goals can best be attained by using the capabilities, equipment, o r
other resources of an installation other than GSFC, the'office of the Director
wdl, at the request of the Project &Maaager,initiate each new request for such
support.
 2.7.1 Project Manager's Responsibiiity

The Project Manager will submit requests for inter-Center support to the Office
of the Director with complete detailed justification. The justification shall in-
clude each of the following, if applicable:

a. Type of support (e.g., name of test o'r type of analysis to be conducted,

o r equipment to be used)

b. If similar support is available at GSFC, why request is desirable.

C. Funding limitations/ resources

d. Dates requested

e. Consequences if support is not received

f : Other pertinent factors

~ t e the
r request has been approved, the Project Manager will provide liaison
with the other installation.

2.7.2 Request for GSFC Support

Requests by other centers o r Headquarters for GSFC support will be channeled

through the Director's office.

2.8 IiWERFACE DOCUMENTATION

2.8.1 Purpose

To provide a medium of communication among agencies, experimenters, and

individuals responsible for the various interfaces in a project, a system shall
be established f o r documenting and updating all interfaces.

. .2.8.2 Applicability

The requirement for interface documentation applies to all GSFC projects.

2.8.3 Responsibility

The Project Manager shall be responsible for establishing and updating a system
for interface documentation. The Project Manager may delegate this responsibility

2-19
to another individual such a s the Project Documentation Manager. Formal sign-
off procedures for each document must be established.

2.8.4 Scope

Interface documents shall specify all interface items required to adequately

define t&e integration m d operation of:

a. ' Spacecraft subsystems and e.xperiments

. .
b. Spacecraft and launch vehicle

c. . Spacecraft and special ground-support equipment

-
d. Tracking and data-acquisition support (Support Instrumentation Require-
ments Document)

e. Launch vehicle, mission requirements, and launch range

, f. Spacecraft and launch site

g. Spacecraft-to-ground Interface Control Document

.
2 A4.1 Spacecraft Systems, Subsystems and E.xperiments Interface documents
shall specify all interface items required to define the complete integration of
a l l spacecraft systems, subsystems, and experiments, including;

a. Method of installation

b. Electrical input and output characteristics

c. Thermal (environmental)

d. External mechanical constraints on configuration

-
e. Power
r

f: Special test equipment

g. Mechanical and electrical operating restraints

2.3.4.2 Spacecraft and Vehicle. Each launch vehicle (Delta, Atlas-Xgena, Titan,
Atlas-Gentaur , Thor-Xgena, and Scout) has interface documentation which is
-
- * .

.. 2-50
e-

-
 required of a spacecraft project. These documents control the mechanicai,
electrical, and operational interfaces for these vehicles. A'spacecraft con-
straints document f o r the Delta vehicle defines the interfaces of the vehicle and
spacecraft, in general. To augment this, a vehicle/spacecraft integration and
documentation schedule lists the detailed interface information which must be
exchanged by the spacecraft and the vehicle projects.

For Agena, a mission requirements and restraints document sets forth the.
Agena restraints. An interface planning and scheduling document serves as the
interface control medium for the spacecraft and'vehicle.

For Centaur, an interface control document serves as interface control.

F o r Scout, the GSFC mission interface data book serves as the interface control
document.

2.8.4.3 Spacecraft and Special Ground Service.. This documentation shall specify
d1 interface items between the spacecraft (including experiments) and the
ground-support equipment (GSE), including project-unique. ground stations and
project-unique equipment at existing ground stations. Typically, it includes
electrical and mechanical. input and output characteristics, operational restraints,
and computer hardware and software interfaces.

2.8.4.4 Tracking and Data- Acquisition Support. The Support Instrumentation

Requirements
- Document (SZRD)serves to document and submit requirements
for support according to NASA Management Instruction 5430.1A, Sept. 12, 1969.
The implementation plan to the SLRD is the NASA Support Plan (NSP). Center
approval and concurrence procedure is given in Appendix D.

2.8.4.5 Launch Vehicle, Mission Requirements, and Launch Range. NASA

3Ianagement Instruction 8430.U, Sept. 12, 1969, lists the documentation for %e-
quirements and responses for the national ranges. The Program Requirements
Document (PRD) describes requirements for support and the Program Support
. Plan (PSP) outlines plans for meeting the requirements.

3.8.4.6 Spacecraft and Launch Site. The PRD shall outline requirements for
spacecraft support at t h e launch site (such a s space, clean-room facilities,
power, a i r conditioning, and personnel facilities).

2.9.4.7 Spacecraft-to-Ground Interface. The Spacecraft-to-Ground Interface

Control Document defines the electrical interface between the spacecraft and
the network. This document will be prepared by the Nehvorks Directorate in
consonance with the project during the project system design phase. Any

2-21
 subsequent changes will require the joint conc.urrence of the Networks Direc-
torate and the project. Component and subsystem tests will be performed to
verify compliance with this document. These tests will be performed on engi-
neering models early in the spacecraft implementation schedule. The Interface
Control Document will utilize the Aerospace Data Systems Standards as' a guide-
line in establishing the interface between the spacecraft/launch vehicles, and the
network.

2.9 CONFIGURATION . .
2.9.1 Policy

GSFC policy is to use Configuration Management Procedures (GMI 8040.1) on all

GSFC satellite and satellite-orbiting vehicle projects , including unique support
equipment and e.xperiments.

2.9 2 Definition

Configuration management is defined as the identification, documentation, ac-

counting, systematic technical evaluation, and approval of changes to all end-
. items of hardware (down to the black-box level) and software (down to the
subroutine level).

2.9.3 Summary of GMI 8040.1

This instruction defines, and indicates requirements for, a configuration control

board, configured article list, and configuration freeze date. Exhibit 1 shows
. the format for submitting changes to higher management. Exhibit 2 is an example
'
of a configuration control board directive indicating the scope and authority of the
Configuration Control Board and other elements of the documentation required for
, both the configured article list and the configuration accounting and Identification
system.

2 .lo DOCU3IENT.ATION iMrlXAGEMENT SYSTEX

r

2 J0.1 Objectives

Objectives of the GSFC Documentation Management System are:

a. To assure that required documentation is generated for both technical

I and administrative manag5ment
-
l
2-22' - .
-
 . b. To assure that adequate procedures are used for controlling report
redundancy and superfluous distribution

c. To systematically administer documentation from identification of

requirement through acquisition, storage, and use

d. To evaluate the quality of documents by assessing their adequacy for

. intended use

e. To provide within the project a central source of information (documents

and data availability) for maximum u s e

f. To analyze on a Center-wide basis the effectiveness of the total docu-

mentation process -identification, acquisition, distribution, and storage

2 J0.2 Applicability

The provisions of the Documentation Management System apply to all GSFC

projects and include contractor documents and formal documents generated
within the Center.
2 J0.3 Responsibilities . .

The Project Manager will appoint a Project Documentation LManager responsible

for establishing and maintaining the formal Project Documentation Management
System. The Project Documentation Manager will:

a. Establish all policies and procedures within the framework of this

instruction to implement the system in the individual projects .

b. Approve all project work statements for documentation requirements

c. Develop'the distribution list for all project documents

d. Review documents received for quality, timeliness, and conformity to

GSFC Specification S-250-P-l? January 1967, and any additional project
instruction

e. Nainfain the status records of documentation (including all reports re-

quired, frequency of issues, distribution of documents, and estimated
cost per issue)

f. Maintain current library file of required project documents

2-23
 g.' Submit a documentation inventory report (Figure 2-1) to the Chief,
Technical Information Division, on July 1 and January 1. (This report
should include all significant scientific and technical papers published .
by the project and e'xperimenters.) Send to the GSFC Library a copy
of each document listed on the inventory report.

2.11 FLIGHT MISSION OBTECTIVES AhD SUCCESS CRI'fERIA

Statements of objectives for individual missions a r e to be consistent with mission

objectives established by formal NASA Headquarters documentation, such as
Project; Approval Documents (PAD). Such statements a r e the only set of words
that may be used as' "Mission Objectives" in all project documentation.

Approved objectives statements will be included in initial guideline instructions

from OSSA for implementation of each project, and will be incorporated into the
Project Plan and PAD verbatim. These statements should be established in an
iterative manner between GSFC and OSSA. The final statement requires the
approval of the GSFC Deputy Director. Mission performance will be rated a s
"successful" o r "unsuccessful" by AA/OSSA, based upon achievement of primary
mission objectives. It is recognized that, in almost a l l cases, valuable addi- .
tional information is ob.tained if the mission exceeds this success criteria; i.e.,
the primary mission objectives. Every effort should be made to maximize the
return from each mission consistent with the resources a v d a b l e .

The wording of the mission objectives statement should be simple and concise
and should reflect the true project goals and maturity. As indicated above, the
mission objectives should be established and agreed to by GSFC and OSSA early
in the implementation cycle. If, during implementation, circumstances dictate a
basic change in p1ans;the mission objectives statement should be e&xaminedto
determine if a change in wording is required. Such changes require the approval
of the GSFC Deputy Director and the &OSSA.

Approximately one year before launch, the GSFC Project Manager and the OSSA
Program ,Manager should review the mission objectives statement and either -
certify to GSFC and OSSA management that the statement is valid o r recommend
appropriate changes . r

Exceptions by the Project Manager to PAD mission objectives can be accommo-

dated by negotiation with the appropriate Program Office, and subsequent P.4D
updating should a change be approved.

In every case, the ,Division Director will schedule a specif3 review of mission
-
objectives about one year prior to launch readiness. The Project Manager will .
--
2-24 . -
e-

.
c
 c
b
a
Q
t
z
r
C
Q

->
e .
0". .
5
Y
.-
c
0
CL c
C
;
a
r
t 8"

2-25
display such a milestone on Level 2 milestone charts prepared for PXR sub-
mittal to Headquarters.

2.12 APPLICABLE INSTRUCTIONS AND GUIDE LmES

The following briefs of instructions and guidelines state the general content of .
each as it relates to project management. If itemized, specific responsibilities
of the Project Manager will appear in the brief.
The intent is not to answer all questions that may arise nor to duplicate detailed
procedures, but to refer the Project Manager to a source that can help prevent
o r solve his problems.
2.12.1 Planning and Implementation of XASA Projects (IMI 7120.1, presently
being revised)
a. Summary of the overall NASA planning structure including long-range,
intermediate range, and current planning
b. Policies and procedures for initiating a project, project approval,
project implementation, and organization for project management
C. Procedures for actions following project approval, including revisions
to approval documents
d. Procedure for resolving disagreement between a Project Manager in
one center and a System Manager in another center
e. Project Manager's responsibility: direct responsibility for project
e.xecution
2.12.2 GSFC Project Planning Handbook (GHB 7121.3, April 1972)
These guidelines provide guidance for understanding and using the preferred
Goddard project-planning concept.
2.12.3 NASA Quality and Reliability Publications
NASA quality and reliability publications contain'general guidelines which apply
to many situations. Each p d e l i n e or publication must be implemented to the
.e.xtent required for accomplishing project activities (see para. 6.6).
2.12.4 GSFC Malfunction Reporting Procedure (GMI 5310. LA)
c

a.. Applicabilitx. This procedure is required for all flight projects.

b. General Content. The means of reporting and documenting deficiency
data on materials, parts, components, subassemblies, assemblies,
subsystems, systems ,. processes, and procedures.
c. Project 31anager's Responsibility. The Project Manager shall have the .-
.*

overall responsibility for malfunction reporting on his project.

c
2-26
2 -12.5 GSFC Engineering Standards Design Manual (X-Document 6 73-64-1)

a. General Content. Practices and procedures to be followed by engineering

and drafting personnel in the preparation, revision, and release of engi-
neering drawings.

b. Project Manager's Responsibility. These standards should be used with

those for procurement of items, procurement source control, and field
modifications.

2.12.6 NASA Design Criteria, NASA Policy Directive 8070.1, August 17, 1967

Design Criteria Monographs are to be regarded a s guides to design and not as

NASA requirements except as may be specified in formal project specifications.
-
These monographs are published in four technological areas Environment;
Structures; Guidance and Control; and Chemical Propulsion. Project Managers
should consider citation of these monographs where applicable a s references in
GSFC contractor specifications. The criteria documents published as of this
date a r e as follows:

a. Environmental Criteria:

SP-8005 - Solar Electromagnetic Radiation, revised May 1971.

SP-8010 - Models of Mars Atmosphere (1967), under revision.
SP-8011 - Models of Venus Atmosphere (1968),under revision.
SP-8013 - Meteoroid Environment Model (1969)
- (Near-Earth to Lunar Surface), iMarch 1969. .
SP-8017 - Magnetic Fields - Earth and Extraterrestrial, March 1969.
SP-8020 - Mars Surface Models (1968),May 1969.
SP-8021 - Models of Earth's Atmosphere (120 to 1000 km),under
revis ion.
SP-8023 - Lunar Surface Models, May 1969.
SP-8037 - Assessment and Control of Spacecraft Magnetic. Fields,
September 1970.
SP-8038 - Meteoroid Environment Xodel - 1970
(Interplanetary and Planetary), October 1970.
SP-8049 - The Earth's Ionosphere, October 1970.

2-27 '
b. Structural Criteria:

SP-8001 - Buffeting During Launch and Exit, May 1964.

SP-8002 - Flight-LoadsMeasurements During Launch and Exit,
December 1964.
. SP-8003 - Flutter, Buzz and Divergence, July 1964. .
SP-8004 - Panel Flutter, May 1965.
SP-8006 - h e a l Steady Aerodynamic Loads During Launch and Exit,
LMay 1963.
SP-8001 - wlckling of Thin-Walled Circular Cylinders, revised
August 1968.
SP-8008 - Prelaunch Ground Wind Loads, November 1965.
SP-8009 - Propellant Slosh h a d s , August 1968.
SP-8012 - Xatural Vibration Modal .Analysis, September 1968.
SP-8014 - Entry Thermal Protection. August 1968.
SP-8019 - Buckling of Thin-Walled Truncated Cones, September 1968.
SP-8029 - Aerodynamic and Rocket-Exhaust Heating During Launch
and Ascent, May 1969..
SP-8031 - Slosh Supression, May 1969.
SP-8032 - Buckling of Thin-Walled Doubly Curved Shells, August 1969.
SP-8035 - Wind bads During Ascent, October 1969.
SP-8040 - Fracture Control of Metallic Pressure Vessel's, May 1970. .

SP-8046 - Landing Impact Attenuation for Non-Surface-Planning

Landers, March 1970.

c. Guidance and Control Criteria: ,

SP-8015 - Guidance and Pavigation f o r Entry Vehicles, November 1968.

SP-8016 - Effects of Structural Flexibility on Spacecraft Control
Systems, April 1969:
SP-8018 - Spacecraft Magnetic Torques, March 1969.
SP-8024 - Spacecraft Gravitational Torques, May 1969..
SP-8026 - Spacecraft Star Trackers, July 1970.

2-28
 SP-SO27 - Spacecraft Radiation Torques, October 1969.
SP-8028 - Entry Vehicle Control, November 1969.
SP-8033 - Spacecraft Earth Horizon Sensors, December 1969.
SP-8034 - Spacecraft Mass Expulsion Torques, December 1969.
SP-8036 - Effects ofStructural Flexibility on Launch Vehicle Control
Systems, February 1970.

d. Chemical ProDulsion Criteria:

SP-8025 - Solid Rocket Metal Motor Cases, April 1970.

2.12.7 Aerospace Data Systems Standards (X-Document 520-63-2 a s modified)

a. Applicability. The GSFC Aerospace Data Systems (ADS) Standards

apply to all projects using the GSFC Network o r the GSFC data handling
and processing facilities, and to all projects managed by GSFC. They
are binding unless specific waivers are requested and granted.

b. General Content, The stan&&ls govern interfaces between major parts

of aerospace data systems; i.e.:

0 Telemetry
0 Command
0 Tracking
0 'Communications
0 Data Processing
0 Associated Systems

They impose constraints o r boundary conditions at the interface and

establish minimum acceptable levels of performance which the user
may expect through conformance to the Standards.

C. Project Manager's Responsibility. GMI 3070.1 (establishing the

authority of the Data Systems Requirements Committee and the Xero-
space Data Systems Standards) requires that each Project Manager
assure conformance to the staadards if feasible. If conformance is not
feasible, a waiver for each deviation for each mission is required.
Procedures for obtaining waivers a r e outlined in the introduction to the
-4erospace Data Systems Standards (X-32 0-63-5). It is recommended

2-29
 that the standards be cited a s applicable documents in procurement
actiond whenever appropriate.

2.12 .s Experiments Specifications (Dr . Townsend memo, October 14, 1966)

a. General Content

(1) Project Manager's right to concur in all final Goddard and outside
e.xperiment specifications

(2) Procedure to be followed if e-xperimenters and Project Managers

fail to agree on any part of the experiment specifications

b. Project Manager's Responsibility. To immediately refer to higher

authority for resolution any disagreement concerning experiment
specifications.

2.12.9 Reliability and Quality Assurance Guidelines for Experiments

(Dr. Townsend memo, October 14, 1966)

a. General Content. Policy is that the project organization must maintain

cognizance of the reliability and quality-assurance aspects of experi-
ments without removing these aspects from the experimenter's basic
responsibility.

b. Project Manager's Responsibility. Inform Goddard management of any

matter on which, in the Project iLIanager's judgment, a major com-
promise is being made. Ensure that appropriate Goddard elements
advise experimenters concerning:

(1) Any pitfalls that might jeopardize their scientific o r technological

objectives

(2) The sensor, its calibration, and specifically selection of component

parts, fabrication techniques, circuit reliability assessments, sub-
system testing, and handling

2.12.10 Tips To Experimenters (published by Quality Assurance Division,

Systems Reliability Directorate)

.Tips to Experimenters describes some of the accumulated experiences encoun-

.tered in preparing spacecraft for flight during the early years. >lost of the items
I discussed were observed first-hand at GSFC. The chief objective of this publi-
cation is to prevent the recurrence of problems observed.

~ 3-30
 a. General Content

(1) Considerations in experiment design

(2) Hardware procurement; contracting for quality assurance

(3) Inspection and fabrication techniques

(4) Testing and experiments

b. Project Manager's Application. This publication contains useful infor-

mation for implementing the policy on advice to experimenters (see
' para. 2.12.11).

2.12 .ll NASA Complementary Manuals

Complementary manuals a r e the basic NASA references in the functional areas

of personnel, financial management, and procurement. Although other guidelines
exist, the major publications are:

a. N A S AProcurement Regulation (NHB 5101.2)

b. NASA Financial Management'Manual

c. Procedures for Contractor Reporting of Correlated Cost and Perform-

ance Data (NHB 9501.2A, October 1971)

d. A Guide to Initiating Procurement. Requests (GHB 5150.1C)

2.12.12 NASA Contract- Administration Publications

The NPC-400 series of NASA publications set forth basic contract-administration

guidelines in specialties of this functional area.

2.12.12.1 XASA Policy and Procedures for Use of Contracts for Nonpersonal
Services (NPC-401). This publication is used in conjunction with NASA Procure-
ment Regulation (NHB 5100.2). It does not apply to contracts for
- c
experts covered by existing regulations.

2 J2.12.2 NASA Source Evaluation Board Manual (NFC-402). Establishes

requirements for all NASA management and technical personnel involved in
source-evaluation processes for major competitively negotiated contracts as
follows:

2-3 1
 a. The basic policy requiring use of source-evaluation boards for com-
petitively negotiated processes

b. Regulations for establishing source-evaluation boards

c. Procedures which govern the evaluation and selection of contractors

for performance of NASA's major competitively negotiated contracts

2.12.13 Budget Execution and Review at the Goddard Space Flight Center
(X-Document 210-67-80)

a. General Content. Documentation of the system used at GSFC for

reviewing and executing its detailed operating budget, including the
application of computer technology to the process ; describes both the
overall NASA budgetary process and the GSFC system.

b. Project Nanager's Responsibility. To participate in the preparation,

review, and execution of the budget for the project.

2.12.14 Funds Control a t GSFC @-Document 210-67-353)

This document describes the system used at GSFC for ensuring funds control at
job-order, project-appropriation, fiscal-year. and total Center level. It de-
scribes both the overall X G A system and the GSFC system.

2.12.15 Documentation of Tracking and Data Acquisition Support for NASA Un-
manned Space Flight Projects (mlI8430.1A. September 12, 1969)

a. General Content. X common means of delineating project support

requirements and of planning the necessary facilities to meet such
requirements (see Appendix D and para. 4.3.1).

b. Project Manager's Responsibility

(1) To prepare the Support Instrumentation Requirements Document

(SIRD)

(2) To initiate, through the Launch-Vehicle Systems Zilanager, the

preparation of the Program Requirements Document (PRD)

2-32
2.12.16 Xanagement Procedures for Automatic Processing Equipment
(NHB2410.U)

General Content -Establishes policies, procedures. and guidelines for the

acquisition and management of automatic data processing equipment.

These regulations apply to all ADP (computer-related) equipment systems,

components, o r attachments, for whatever use, and whether purchased o r rented,
by NASA o r by a contractor o r subcontractor, for a new installation o r for a
modification o r reassignment. X special path of review and approval is re-
quired before the acquisition of such equipment. This includes a XASX Head-
quarters approval of the individual action in most cases. An ADP Acquisition
Plan must be prepared, including a technical Feasibility Study, for approval
prior to issuance of an RFP by NASA o r a contractor for any item of ADP equip-
ment. For competitive procurement the RFP and specifications must be re-
viewed, a technical panel established, evaluation criteria defined :and the final
selection made in accordance with GSFC ADP procedures.

A brief definition of the range of equipment designated as ADP is given in para-

graph 8.5.2, but determination of the category must be made by NASA ADP
management. The designated official for ADP matters at GSFC is the Assistant
Director of Mission and Data Operations (Center Automatic Data Processing).
Code 302. Procurement of ADP .equipment by GSFC is assigned to the Procure-
ment Division, Network and Data Systems Branch, Section C (Code 244.3).

Specifications for Phase B, C , and D contracts must include the GSFC ADP
procedural requirements in anticipation of possible inclusion of ADP equipment
f o r such uses as integration and test, simulation, displays, recording, control '

centers, o r telemetry processing. Specific guidelines must be given to the con-

tractor, particularly when the contractor is involved in total system design and
pricing. GSFC project personnel (or consultants) should be assigned to study
and coordinate all project AJ3P use areas, and to maintain contact with Code 302.

2.12.17 Systems Safety (NHB 1700.1 (V3) 3/6/70)

a. Outline of techniques that a r e useful in .the planning, implementation.

and administration of a system safety program (also see NHB 1700.1
(Vl)entitled "Basic Safety Requirements," July 1969).

b. It is the policy of this Center to have a System Safety Plan for all flight
projects. The implication of ,WB 1700.1 (V3) is that system safety
assess the risk associated with space flight hardware systems with a
purpose of avoidance of injury to people and property loss regardless

2-33
 of cause and this policy extends to post-launch operations. At GSFC it
is the policy on unmanned flights to concentrate our attention on the
avoidance of injury to people. Therefore, Systems Safety is defined as
those engineering and management practices and procedures necessary
to avoid personnel injury and property loss to the maximum extent
practical. Systems Safety includes the protection through launch of
flight hardware from loss o r damage from extrinsic factors, but does
NOT include property loss o r damage to flight hardware due to internal
component malfunctioning. The latter is considered a design reliability,
a n d o r quality responsibility.

Systems Safety does not e.xtend into post-launch operations. Appendix C

gives an outline of a model Systems Safety Plan. This outline should be
used to the e'xtent applicable on all projects. It should be noted that it is
not the intent to duplicate existing document with a ''systems safety"
cover on it.

c. Project Manager's Responsibilities. To implement a Systems Safety

program. It should be noted that advise and consultation can be obtained
from the Health and Safety Engineering Office in the drafting and imple-
mentation of the Systems Safety Plan. Each Systems Safety Plan shall
be approved prior to implementation by the cognizant Director of -.
2.12.18 Photographic Coverage

The Project Manager will e n s u e that required photographic coverage of project

activities is recorded f o r technical and administrative documentation purposes.
In addition to in-house coverage, this includes suitable requirements in contracts
to meet project needs. The GSFC Photographic Section will provide consultative
support, as required, in formulating contractual requirements and prescribing
photographic specifications.

2.12.19 General Specifications for Nebvork Equipment Design and Construction

a. General Contents. Establishes policies, procedures, standard inter-

faces, and guidelines for design, construction, and installation of
equipment in a network station.

b. Project Manager's Responsibility. The Project Manager shall have the

responsibility for the conformance of project supplied ground station
equipment with the General Specifications for Network Equipment Design
and Construction.

2-34
.

2.12.20 Indexes to NASA and GSFC Management Instructions

a. The table of contents to the GSFC Management manual, published

quarterly and distributed to manual holders, contains a listing of the
complete GSFC issuance system.

b. Table of Contents of NASA Management Issuances, NHB 1410.4 'series,

lists all NASA issuances.

2.13 INTERNATIONAL COOPERXTIVE PROJECT 4WAGESIENT

The international activities of the National Aeronautics and Space Administration

are planned to demonstrate the peaceful purposes of space research and e'xplora-
tion by the United States, to provide opportunities for the participation of scien-
tists and agencies of other countries in the task of increasing man's understanding
and use of his spatial environment, and to support operating requirements for the
launching and observation of space vehicles and craft. Because of their very
nature (initiation, execution, etc.), international cooperative projects a r e man-
aged in a manner slightly different from their domestic counterparts. Proposals
for cooperative satellite projects a r e generally initiated by the foreign country
as a result of preliminary discussions between their representatives and NASA
Headquarters personnel. The foreign proposal is reviewed by appropriate HASA
Centers and a technical/scientific evaluation is submitted'to NASA Headquarters.
If the proposal satisfies the standard NASA guidelines, i.e., civilian agency,
specific project, scientific o r applications validity, mutual interest, and open
availability of.'results, then a Memorandum of Understanding is prepared by
NASA Headquarters and signed by the Administrator and his foreign counterpart.
The project management responsibility is then assigned to a NASA Center (six-
teen have been assigned to GSFC and one to LeRC).

In general, NASA is responsible for providing the launch vehicle, support by the
T&DA facilities, one o r more U.S. experiments, spacecraft advice, and unique
test facilities. The foreign country generally provides the spacecraft, the ma-
jority of the scientific experiments and most of the data processing. Therefore,
the principal project maqagement efforts on an international project a r e directed
towards insuring on behalf of the United States that the various Centers respon-
sible for the three areas of "3.4 responsibilities (spacecraft advice/ experiments,
launch vehicle. T &DA) perform satisfactorily within the written n,ords and spirit
of the Memorandum of Understanding. This generally results in active manage-
ment of the US. effort and directing the passive advice and counsel provided on
the foreign effort (usually limited to a general surveillance of the foreign effort,
culminating in a joint flight-worthiness approval of its efforts).

2-35 .
e
In all cooperative projects the principal mechanism for coordination and infor-
mation exchange and transfer is the Joint Working Group (.JlI’G). This group is
co-chaired by the U.S. and foreign project managers and consists of working
representatives of each system and major subsystem. It usually meets semi-
annually in alternate countries and exerts a major influence on the successful
execution of an international cooperative project.

Formal reviews a r e held during the life of an international project by a design

review team composed principally of technical e-xperts from the Project SIanage-
ment Center and co-chaired by a representative from the Systems Zeliability
Directorate and his foreign counterpart. These reviews a r e similar in f u c t i o n
as those described in Part 5.

2.14 EXPERIMENTS

2.14.1 Experiment Selection

Space flight e.xperiments a r e selected and approved by NASA Headquarters based

upon a proposal submitted in response to a specific solicitation in Opportunities
for Participation in Space Flight Investigations, NHB 8030.1X. Proposals define
objectives, the technical plan for the achievement of these objectives, nanage-
ment plan, program scope, and cost. (For GSFC proposals, see GJlI 5030.2
dated October 14, 1970.) As part of the e.qeriment selection process, Project
Managers will review the proposed ercperiments in order to assess mutual com-
patibility, ability of the spacecraft to accommodate the individual instruments,
and instrument complement, and realism of the management plan including cost. .
Results of this review a r e provided to NASA Headquarters prior to final selec-
tion of the experiment complement for the given mission.

2.14.2 Project Experiment Requirements

The Project Manager shall establish project requirements and schedule mile-
stones for all e-qeriments. These shall include:

a. Delivery dates for prototype and flight e-xperiments

b. h t e rfac e documentation r e quir ements

c. Environmental and integration test requirements

d. Configuration management

e. Re1iabilit.y and quality assurance

2-36
 f. Progress reporting

g. Interface liaison with spacecraft contractor

h. Design reviews

Through formal and informal means, the Project Manager shall monitor the
progress of the experiment effort.

The establishment of uniform requirements upon all e'qerimenters, both in-

house and out-of-house, is necessary for the conduct of a successful space flight
program. These requirements a r e implemented a s follows:

'a. GSFC E.xperiments. A Memorandum of Agreement, if deemed neces-

s a r y by the Project Manager, between the Project Manager and the in-
house e'xperimenter forms the basis for project requirements. This
agreement shall include total budget and manpower requirements by
fiscal year in addition to requirements listed in paragraph 2.14.2.

b. Gut-of-House Experiments. Project requirements listed above plus

total e.qerimenter program costs Lhrough launch a r e agreed to in the
formal contractual document between GSFC and the eAqerimenterrs
institution. The data reduction and analysis phases of the e.xperiment
program a r e discussed in P a r t 7 of this handbook and a r e called-out
specifically in the contractual agreement between the project and
investigator.

c. Foreign Experiments. The official agreement with foreign experiments

is handled by X M A Headquarters. The details of project requirements
a r e handled by mutual agreement between the Project Manager and the
Foreign Investigator.

2.14.3 Application Experiments

The term ''e.qerirnents" when applied to some application projects, such a s

. ERTS has a W e c e n t connotation than when applied to the scientific projects.
It refers primarily to the analysis and ibterpretation of the data and not to the
sensor hardware per se. Thus, in contrast to the classical role of the Principal
Investigator, these investigators a r e essentially "Guest Observers."

In general, the requirement f o r the sensors and the format of the data output a r e
generated by means of working groups representing the e.xperimenters, (guest
observers) who will ultimately make use of the data and project personnel. It is

2-37
the responsibility of the Project Scientists to chair the working group and to see
that these requirements a r e generated early in the program.

Once the requirements a r e established, the Project and the Technical Officer a r e
responsible for the procurement of the sensor hardware and any ground equip-
ment necessary to present to the experimenters the sensor output in a usable
format. The Technical Officers for the sensors will in general be provided by
the Earth Observations Systems and Systems Engineering Division and assigned .
to the project.

2-38
 PART 3
SYSTEM TESTS
3.1 PHILOSOPHY

Because spacecraft a r e not oniy "one-shot" but are also fyone-of-a-kind,ff

statistical approaches to testing developed f o r mass production of consumer
goods and weapons a r e not applicable. Actual flight hardware must b e e'xposed
to a reasonable simulation of the expected operating environment to assure a
high probability of successful performance in space.

The six objectives of the spacecraft test program are:

a. To verify that system, subsystem, and component designs meet per-

formance requirements

b. To verify that particular hardware samples meet performance

requirements

c. To eliminate defects in material and workmanship

d. .To discover une.xpected interactions between subassemblies, particu-

larly when the system is exposed to environmental s t r e s s

e. To verify that ground-support and data-processing equipment are

compatible with the spacecraft (see para. 4.4)

f. TO train spacecraft operations and data-processing personnel

3.2 BASIC CONCEPTS O F SYSTEM TESTING

GSFC has endorsed the full-system test approach, in which the entire system is
tested under conditions as realistic as possible. Systems tests senerally fall
into one of two categories:

a. Functional tests to establish that each subsystem is doing its desig-

nated job in conjunction with the other spacecraft subsystems. This
category includes calibrations which consist of actually calibrating
any spacecraft sensors o r instrumentation, a s well a s establishing a

3-1
 performance baseline with which the spacecraft can be compared
throughout the environmental test phase.

b. Compatibility testing, considered here in its broadest sense, refers to

all testing directed primarily toward evaluation of the various space-
craft interfaces. This category includes electromagnetic compatibility
(EMC) assessments and electromagnetic interference (EJLI) evaluations,
as well as magnetic moment determinations.

EMC and E311 measurements a r e necessary to ensure that the space-

craft electrical and electronic equipment operate satisfactorily not only
as independent systems but also in conjunction with the launch vehicle
and ground support equipment, and in the proximity of launch range
equipment. In short, the spacecraft should not be adversely affected
by electromagnetic interference reaching it from any e.xterna1 sources.
Conversely, the spacecraft itself should not be a source of interfering
signals which might adversely affect its own operation, vehicle opera-
tion, other spacecraft, o r ground monitoring and control equipment.
Because of the criticality of spacecraft functions whose operation is
dependent upon electro-e?cplosive devices (deployment, separation, etc.)
the susceptibility of these devices to interfering signals should be of
particular concern.

To determine mechanical compatibility of the spacecraft with the launch

vehicle and aerodynamic fairing, matchmates may be advisable.

Components and subsystems of the spacecraft communications and data

subsystems shall receive preliminary compatibility testing a s early in
the implementation schedule a s possible - preferably on the engineering
model - in order to minimize the potential impact on the ground support
elements.

Finally, the flight spacecraft shall be tested with the ground-support

and data-processing equipment, personnel, and procedures that w i l l be
used to operate the spacecraft in orbit.

3.3 SYSTEM TESTING

System testing is performed at GSFC o r monitored at contractors' facilities by

the project with the aid of the Test and Evaluation and the Quality .Assurance
Division of the Systems Reliability Directorate.

3 -2
 3.3.1 Environmental Test

These tests determine the ability of components, subsystems, and the entire
spacecraft to withstand environmental rigors that may be experienced before
and during launch, and during orbital operation. The tests may be conducted at
any o r all levels of assembly, but a r e required at the spacecraft Level. The
severity and duration of the tests are related to the purpose of the tests a s indi-
. cated below. At times it is difficult to distinguish between functional testing
and environmental testing, particularly when a specific environmental, e;g.,
high vacuum, is required for the performance of a functional test (see para. 3.4).

3.3.1.1 Flight Acceptance Testing. All flight hardware is ground-tested in the

expected flight environment. The hardware is e.xposed to simulated loading con-
. ditions produced by temperature, pressure (vacuum), and vibration during the
launch and the orbital phases of the flight. Functional tests appropriate to the
conditions simulated a r e conducted. Test levels a r e chosen such that, in theory,
there is one chance in twenty of their being exceeded in flight.

3.3.1.2 Qualification Testing. A prototype model (i.e., the actual flight con-
figuration) is e'xposed to an environment intended to produce loading conditions
and stresses in excess of those errpected in flight. The purpose of prototype
testing is to ensure a margin in the design to provide for uncertainties in areas
such as analyses, materials, and workmanship. For qualification, test levels
are chosen such that, again in theory, there i s one chance in one hundred of
their being exceeded in flight.

3.3.1.3 Proto-Flight Testing. A s programs mature, cases arise of spacecraft

based primarily on previously flown hardware but somewhat different in design
and performance. In these .cases a prototype spacecraft may not be required.
Flight acceptance and qualification testing a r e combined and performed on the
flight spacecraft. The amount of qualification testing required is made con-
sistent with the magnitude of the hardware changes.

While the establishment of test levels is defined above in terms of overall risk,
the paucity of applicable data makes this task one which does not yield exact
numerical values.

3.3.2 Subsystem Testing

The full-systems test approach does not eliminate the desirability, o r in some
cases the necessity, of black-box and subsystem qualification and acceptance
testing. Several inherent limitations of systems testing are best overcome by
testing at the subsystem o r black-box level:

3 -3
 a. Lf only systems tests a r e run,marginal conditions e.xisting at subsystem
o r black-box interfaces may remain undetected. Only information on
the input/output characteristics of the individual black boxes can estab-
lish the presence of adequate control margins.

b. Systems tests seldom run long enough to detect wear-out problems.

Wherever a fatigue o r wear-out potential e-xists (chiefly in electro-
mechanical devices), the "life" characteristics should be investigated
on a component o r subassembly basis. Great care must be taken to
assure that the sample is truly representative of the flight hardware.
. .
C. After a spacecraft is completely assembled, devices may no longer be
realistically operable during systems testing. In some cases this oc-
curs because the spacecraft cannot be operated in all possible orbital
modes on the ground, primarily because the orbital environment cannot
be precisely simulated. 3Iaximum assurance that devices are still
working after systems testing must be obtained without invalidating test
results by extensive spacecraft disassembly. In some cases, such a s
the power subsystems, comprehensive testing may be the best way to
gain confidence in the ability of that subsystem to perform satisfactorily
in all its anticipated operating modes.

d. Because systems testing is costly, judicious testing of individual black

boxes and/or subsystems should be accomplished before final assembly
and full-systems testing. A conscious compromise is necessary be-
tween complete black-box and early systems testing. Black-box testing
provides a hedge against failures of these elements in the full-systems
test, while the early systems test verifies the basic design and uncovers
systems problems.

3.3.3 Experiment Testing

Where ail edxperiment is one of many in a spacecraft, and where its failure will
not endanger the mission requirements, it may be treated the same a s a sub-
system (see above). Where an e-xperiment is essential to the accomplishment
of the mission or costs $2,000,000 (approx) o r more, the mandatory testing
program called out in the General Environmental Specifications w i l l be required
before assembly into the spacecraft. In cases when two models of the e-xperi-
ment are available, one can be used for qualification and one for flight accep-
tance. In cases where constraints permit only one experiment to be made, it
must be subjected tc protoflight level tests at the e'xperiment and spacecraft
(observatory where applicable) configuration levels.

3 -4

c
' 3.4 GENERAL EXVIROXXESTAL TEST SPECIFICATIONS

A single document, General Environmental Test Specification for Spacecraft

and Components, S-320-G-1, describes the environmental and functional tests
anticipated for GSFC spacecraft. The tests, generally common to all spacecraft,
are presented in the main body. The appendices contain the structural dynamic
test levels that are appropriate for the launch vehicle being used.

.Mandatory tests a r e listed in paragraphs 1.6.4 and 1.6.5 of the general test
specification and careful consideration should be given to other tests listed in
those paragraphs and in paragraph 1.6.6 on the basis of spacecraft design and
mission. The test program is not rigid but provides for alternate methods for
satisfying test requirements, including the mandatory tests. Deviation from
mandatory tests, or the recommended alternate, requires prior approval from
the Director of Systems Reliability as well as the cognizant Director of -. The
general test specification serves as a model in format and as a source document
in content for the writing of particular test specifications for individual projects.

3.5 DETAILED EWIRONMENTAL SPECIFICATIONS AND TEST P U N S

Detailed requirements for environmental tests for a specific project appear in

specifications and plans developed for that project and issued by the Project
Nanager. The scope of the project's effort will appear in the reliability assur-
ance program plan; approval of that plan means approval of the scope of the test
effort. The Project Manager calls principally on his Test Support Manager
(para. 2.2.8.7) for preparing detailed specifications and plans.

3.5.1 Environmental Test Specifications

The Project Nanager is responsible for approving project specifications that

define requirements and levels for spacecraft tests and plans. These specifica-
tions shall reflect the basic requirements and intent of the General Environ-
mental Test Specification for Spacecraft and Components using launch environ-
ments dictated by the particular launch vehicle.

. Environmental testing shall be conducted in accordance with the terms of an

approved Environmental Test Plan. This plan shall relate the objectives,
philosophies, test requirements, management schemes, and schedules which
apply to the program.

3 -5
 PART 4
OPERATIONAL REQUIRMEiVTS
4.1 GE'NERAL

The operational requirements covered by this section are principally those

which come under the program .responsibility of the Office of Tracking and Data
Acquisition, NASA Headquarters, and a r e concerned with the on-orbit support
to flight missions. The basic policies and procedures for establishing, docu-
menting, and controlling requirements for tracking and data-acquisition (T&DA)
support of unmanned missions a r e outlined ig 1W118430.1A dated September 12,
1969.

It is the Project Manager's responsibility to ensure timely submission of oper-

ational requirements for implementation by T&DA support organizations.
These requirements involve engineering and operations in the major areas of
network(s), control centers, communications, orbit determination, support com-
puting (attitude determination, launch window and lifetime analyses, etc.), and
data processing. These areas have been defined as a result of recognition
of the operational elements common to project support, the scope and nature of
those elements, the identification of the networks and associated facilities as a
NASA and a national resource, and the manner in which these large common
user facilities are controlled and funded. This functionally organized T&DA
support is frequently different from that provided to flight projects by many
other organizational elements at GSFC. The efforts involved do not deal with
any single specific part of the satellite per se but, for the most part, the policies,
procedures, practices, rules, etc., under which the mission will be operated.
The result is specific instructions, procedures, etc. for the operation of the
major ground facilities for each mission in a multimission environment.

It is axiomatic that as much as possible of the technical capability required f o r

each new mission should be available from existing capability by simple addition,
reallocation o r redefinition. The recognition and identification of the truly mis-
sion unique requirements and the determination of those items that can be o r
will be supported from existing capabilities, whether hardware, software, o r
procedure, is a most important and difficult task. It must be accomplished
expeditiously in order to permit initiation of design and development of the truly
unique items and to allow for the adjustment and testing of the established way
of operating. That part of the support drawn essentially intact from existirg
capabilities cannot be considered experimental and dedicated. Only that truly
unique to a mission can be placed in that category. Even then, as such items

_.
. 4-1
are proven and incorporated into standing capability, they become part of the
resources each following new mission may draw upon. In this manner, each
new operation contributes to the development and improvement of ground oper-
ations and ground systems.

4 . 2 INTERFACES

4.2. I Studies and New Project Activities

The development of operational requirements is an iterative, interactive, proc-

.ess involving the four principal steps of (1)operational concepts, (2) require-
ments definition, (3) support definition and commitment, and (4)mission opera-
tions planning. These steps roughly correspond to the sequence of project
events. The first two steps a r e important and essential activities and should be
consciously and e'xplicitly executed in-line and in-balance with all other aspects
of the mission (i.e.- science, spacecraft, launch vehicle, etc.). It is impor-
tant that each feel the influence of the requirements and constraints of all other
areas as early as possible in the definition and development of the mission, in
order to avoid significant and unnecessary discrepancies between mission pa-
rameters and ground capabilities and/or constraints in flight mission operations.
This is especially true for the first mission of a series where precedence has
not been established nor e.xperience gained. These steps a r e normally executed
by the Study Manager and his assigned staff. A t this time the definition of the
operational requirements is necessarily not detailed o r precise because Sys-
tems Definition has not been reached. One of the first actions by the Project
;Manager should be a review of the results of the studies and the preparation of
the Support Instrumentation Requirements Document (SIRD)required under
mLI 8430. W . This document and its counterpart, the NASA Support Plan (NSP),
should be completed well before the end of the Systems Definition. These formal
documents are intended to be periodically reviewed and revised as the system
design, development, and planning proceed. To accomplish this, the Project
Manager should establish a Missions Operations Planning Group, chaired by the
Mission Operations Systems Manager (MOSM) and consisting of the Mission
Support Manager and the Network Support Manager, representatives for each
experiment, representatives for the spacecraft and major subsystems, and
others from both the project staff and support areas to ensure adequate coverage.

4.2.2 T &DA Support

The execution of the third and fourth steps a r e the responsibility of the Project
Manager and are accomplished in parallel with the other principal elements of

4-2
 the mission. The objective in these steps is to prepare specific and detail plans
for the day-to-day, orbit-to-orbit, flight operations and is done by the 31OSM and
the Mission Operations Staff (310s). These requirements should define overall
functions and performance including each support area. This definition cannot
consist of simple demands for specific equipments by model number o r name,
however, this type of detail must be recognized as the ttlinguafrancaflof the
business'. The members and participants of the MOS from the support areas
must be prepared and capable of providing detailed information about the facili-
ties: what each consists of; what each will consist of; how they function individu-
ally and collectively; etc. Once established, the requirements and commitments
must. remain reasonably fixed.

Functional support in the T&DA program a r e a s is provided by the Mission and

Data Operations Directorate (M&DOD)and the Network Directorate (ND). There
are two principal points of interface. The Mission Support Manager from the
M&DOD is responsible (see para. 2.2.8.4) for the control centers, support com-
puting, data processing, non-real time operational orbit determination, and
definitive o r precisive orbit determination for the mission. The Network Support
Manager (see para. 2.2.8.5) is responsible to the MOSM for obtaining commit-
ments for network, communications, and real-time orbit determination.

A project support cadre is estalilished in the M&DO Directorate and consists of

a member of each support&= element as necessary. In the Networks Directorate
an "Ad Hoc" Committee is formed and chaired by the NSM to ensure full network
support. These groups are expected to prepare specific plans for the utilization
of techaical resources in support of the project and identify any real discrepancies.
Each member is responsible for the technical matters in his area, and is expected
to participate a s required as a f u l l member of the group, and in close liaison
with the designated project personnel. The commitment of resources are estab-
lished and approved thmugh normal functional channels. Within the scope of this
agreement, the cadre member is free to exercise his technical judgment and is
expected to operate in the best interests of the project and the Directorate. He
cannot commit additional resources without the concurrence of his line supervisors.
He is e.xpected to identify promptly any problems that occur o r which he antic-
- ipates will occur in such areas as scheduling and use of facilities; operational
policies, practices and/or procedures; new requirements; etc. He is e.upected
to provide X&DO management a thorough knowledge of the project and its require&
ments, bring to its attention any problem areas, offer an opinion as to a possible
solution and alternates, and provide estimates of impact as appropriate. There
are established functional groups in each division for each element of operations
and the cadre member is given substantial freedom to use the services, skills,
and knowledge of these groups.
4.2.3 JIission Support Manager (&ISM) and Xetwork Support &lana,ger (h5M)

The Mission Support (para. 2.4.8.4) and Network Support Manager (para. 2.4.8.5)
a r e e.upected to have an acquaintance with operations in all areas they represent.
The utilization of technical capability of the M&DO cadre, and the other support
personnel and the resources they represent a r e , to a great extent, dependent
upon the practices and desires of the project management. At times, the hlSM
and the iUSM are used as a single point of contact by the Mission Operations
Systems Manager (MOSM) and at other times f u l l interplay with all support
personnel is exercised. No restriction is placed by management other than that -
outlined above. The M&DO cadre is considered an integral part of the project
team, and is expected to participate to the fullest extent possible in the project
operations by providing substantial knowledge and skill in ground operations.

4.2.4 Frequency Authorization

The Radio Frequency Management Manual (formerly NPC 102-1, presently being
revised) sets forth the procedures covering management requirements for the
control of radio frequencies for NASA. These procedures a r e adhered to by all
NASA frequency users and Field Installation Frequency %a, mers.

NAMI1138.6 assigns the authority for management of radio frequencies for NASA
to the Associate Administrator, OTDA, NASA Headquarters.

The Radio Frequency Management Manual (NPC-102-1) will be issued under the
authority of NMI 2570.2A, which establishes the policy and responsibilities in
,radio'frequency management.

The following NMI's outline additional NASA policies involving frequency

management:

NMI 2570.2A Sets forth the policy and responsibilities f o r management of

NASA radio frequency requirements and states NASA policy re-
garding the control of radio frequency transmission from space
vehicles under NASA cognizance, and incorporates in the XASX
. Management Manual the "Manual of Regulations and Procedures
for .Radio Frequency Management of the Office of Telecommuni-
cations Policy."

NMI 5104.2 Establishes the NASA policy for ensuring that no equipment
radiating radio frequency energy is acquired prior to obtaining
frequency support for its operation.

4-4
N M I 1052.25 Establishes procedures relative to the coordination of frequencies
in NASA projects requiring range support.

NMI 1052.111 NASA-DOD Memorandum of Understanding provides for air/

space-ground telemetering in the 225 to 260-MHz band.

The above policy documents contain e4xplicitconstraints on project management,

such a s , the requirement that a NASA Frequency Authorization (license) be ob-
tained prior to the procurement of a transmitter. It is important that the Project
Manager identify frequency requirements for the project on a mission-by-
mission basis a s early a s possible and submit a Frequency Application (XASA
Form 566) to the GSFC Frequency Manager in order to’avoid unnecessary
delays.

4.3 DOCUMENTATION

4.3.1 SIRD/NSP

The SlRD is NASA Form 987 revised and dated January 1965. The elements
covered by this document can be categorized as follows:

0 . Mission description and support information

0 Mission technical parameters

0 Requirements:

Information flow
Orbit determination accuracy
Telemetry data acquisition
Ground command
Support computing
Communications
Data processing

It is important that the requirements be statements of functional and performance

specifications rather than equipment specifications so that the assessment of
existing and planned capability can be useful and meaningful. The NSP is a
page-for-page reply to the SIRD and as such is not carried as a NASA form.
Revisions to both documents a r e controlled and wherever possible should be on

4-5
 a single page basis. GSFC forms and procedures Bre given in Appendix D of this
handbook. bfemoranda and "understandings" play a role in the interplay and
dynamics of support preparation, however, they do not and cannot replace or
eliminate the formal, approved (Center and Headquarters) statement of require-
ments that these documents represent.

Study/Project managers should plan and schedule the issuance of an initial SIRD
(Support Instrumentation Requirements Document) concurrent with the Project
Plan. This first SIRD should meet the minimum requirements established in
the SIRD preparation instructions and contain the new m d continuing require-
ments placed by the Tracking and Data activities of the project. It is attached
to the Project Plan and sent to OSS o r OA, a s appropriate for approval purposes,
and after their action, it is sent by the program office@) to OTDA for informa-
tion, review and commitment of support and future resources. Additionally,
GSFC sends OTDA information copies of the project plan and SIRD concurrent
with the transmittal of the same documents to the OSS o r 0.4 program approving
office.

4.3.2 Operations Plans

As preparation f o r flight mission operations progresses, and the requirements

and technical data become' firm, an operations plan and procedures a r e prepared.
This i s in reality a set of coordinated, overlapping, documents prepared by the
individual(s) responsible for the conduct of operations in the principle project
and functional support organizations for each identifiable functional operational
element of support.

4.3.2.1 Mission Operations Plan (MOP). The MOP is the governing document
covering the mission specific plans arid procedures for each mission. A s such,
it relies heavily on the related documents prepared for the T&DA support facili-
ties outlined below. It should reference these documents and only duplicate their
content where necessary for complete understanding of the e.xpected reader. All
aspects and phases of flight mission operations should be covered from the point
of view of the MOSM. The MOP is prepared by the 310s with the assistance of
the support elements and approved by the Project Manager. It should be pub-
lished at least 90 days prior to the e=q>ectedlaunch date of the mission.

4.3.2.2 M&DO Operations Plan (OPPLXN). The M&DO O P P L t i is a summary

I
document covering the coordinating, interfacing Mission and Data Operations
support operations and activities. It relies heavily on both the MOP and support
element documents including the NOSP (para. 4.3.2.3), and should duplicate the
material contained therein only where necessary for complete understanding.
Where operations of a support element a r e sufficiently routine o r simple, the

4-6
 appropriate section in the OPPLAN may suffice. The M&DO O P P U N is pre-
pared by the MS31 and the support cadre, with the assistance of the operational
elements and approved jointly by the Project blanager and the Associate Director
of Mission Operations, Mission and Data Operations Directorate. It should be
published at least 60 days prior to the expected launch date of the mission.

4.3.2.3 Nebvork Operations Support Plan (NOSP). The NOSP is the governing
document which directs the network during support of a specific mission. NOSP's
a r e prepared for each mission and define the station configuration and operational
procedures along with project peculiar items a s derived from mission require-
ments. The NOSP is prepared by the Network Support Manager and will nominally
be published 60 days prior to the expected launch date of the mission.

4.32.4 Major Facilities Operations Plans (MFOP). Each of the operating,

'\ mutliple user facilities (i.e., Network, Communications, Support Computing,
Orbit Determination, Control Center, and Data Processing) prepare specific
explicit control procedures f o r providing support to each mission while guar-
anteeing continued support to their other users. In preparation for the mission
under consideration, the interfaces, conflicts, and influences of a l l missions
e.xpected to be supported concurrently a r e analyzed, tested, and discussed and
agreements reached in the contextof each facility. Items of importance in one
.
are often of no o r little direct concern in another, but secondary effects some-
times reflect throughout the system. The MFOP's e-Tress these agreements
and define the actions to be taken in as many circumstances a s practical.
The previous document - M&DO O P P M - is'in part a summary of these
effects and constraints for the purpose of overall understanding and consistency.
These documents rely upon the detailed procedures existing and specially
developed o r modified in each operating element a s well as the MOP. Minimum
duplication between all of these documents should be the rule, and only material
needed for the understanding of the expected reader/user should be included and
references made to a l l other operations and reference documents as appropriate.
The MFOP's a r e prepared by the operating organizational element and approved
by the responsible functional supervisor. These documents should be prepared
as early as possible so that the impact of the expected operations can be under-
stood and tested. h any event, the final docliments should be published no later .
. than 60 days prior to the e.xpected Iaunch date of the mission to which they apply.'
4.3.2.3 Network Operating Procedures (NOP), Pass Support Requests, Post
Pass Reports. Etc. These documents, and there a r e many, a r e e'xplicit. detailed
directions to the sub-elements of each operating facility. They a r e prepared by
the operating line management according to the policies and practices established.
They a r e intended to provide for the orderly acceptance of specific requirements.
execution of delegated authority, and reporting of results for both line and project

4- 7
management. The various operations plans may specify the detailed require-.
ments for these documents. They a r e prepared as required and necessary 3s
the operations a r e executed.

4.4 SISlU LATIONS AND TESTS

A s preparations for flight mission operations progress, the operating elements

conduct individual and cooperative tests, simulations, analyses, and assessments
to validate technical capabilities, support commitments ,-and operating policies
and procedures; and to identify problem areas and required changes. The re-
sults are continuously fed back into the system for consideration and action.
The objective is to enter actual flight operations with the necessary certified
capability and full understanding and evaluation of constraints and effects on all
missions to be supported concurrently consistent with the priorities, objectives,
and current status of each and the center and agency programs (see para. 3.1).

4.4.1 Equipment and Subsystem Tests

These tests are conducted throughout the mission preparation o r pre-flight

phase to determine technical capability such a s receive threshold, bit e r r o r
rate, format compatibility, etc. These tests are performed by the support
elements and culminate in system and subsystem certification.

4.42 System Tests and Simulations

These tests and simulations a r e started somewhat after the previous tests
mentioned and use certified o r conditionally certified segments of the system to
enlarge upon the scope of technical certification and to introduce the expected
time dynamics of the mission. They a r e typically cooperative o r joint exercises
between operating elements and include the appropriate interfaces. They cul-
minate in system simulation as realistic as practical, such a s network data flow,
command execution, etc., but do not deal directly in mission contingencies o r
full system interaction; since the objective is to validate and certify the capabil-
ity to support any given support phase -and the interactions, interrelationships,
and effects unique o r peculiar thereto. These tests and simulations. a r e the
responsibility of the operating elements, however, the Mission Operations Staff
(310s)should participate and cooperate in these activities. They should be
completed 3 to 6 months before the expected launch date.

4.4.3 Mission Simulations

These simulations a r e the final exercises intended to fully show flight readiness
from a ground operations/ground system point of view. A s such, they should
,culminate in operations involving f u l l mission time dynamics for a period of
time sufficient to allow all significant normal situations and conditions to occur,
and mission contingencies to a reasonable practical extent consistent with mis-
sion objectives, anticipated inter-mission constraints and conflicts, and resources.
Mission simulations shall involve all participatam elements and operating personne
(project and support elements) including all shifts where applicable. They a r e
the responsibility of the MOSltI and the BIOS and shall be conducted for a period
of 90 to 120 days before the expected launch. A minimum of two full simulations
will be carried out - one approximately 30 days before launch and one 3 to 7
days before launch.

4.4.4 Compatibility Tests

These tests are intended to verify mission technical parameters where they
relate to the interface with the operational ground system. They are designed
.to establish feasibility of the intended ground operational support configurations
and to evaluate areas of potential support difficulty. They also verrfy compliance
with the Spacecraft-to-Ground Performance Interface Control Document and with
the GSFC Aerospace Data Systems Standards (see para. 2.12.10).

These tests are not design validation or proof tests of either the spacecraft o r
ground equipment; but, they a r e a thorough evaluation of the.degree to which
support requirements can be met when the spacecraft and ground equipment,
each meeting their respectit-e performance specifications, are interfaced.

The tests will be conducted by the Networks Directorate using standard ground
support equipment and flight hardware to the maximum extent possible. A sep-
arate compatibility verification test is required for each spacecraft in a multiple-
launch program. The test results will be the primary basis on which the Director
of Networks and the Director of blission and Data Operations will verify f i d l
compatibility o r identify interface limitations. Compatibility verification tests
will be conducted as early in the program as possible after the flight spacecraft
tracking, telemetry, and command subsystems a r e finalized. The compatibility
verification tests must be completed prior to the Network Readiness Test (NRT).

4-9
 PART 5
PROJECT REVIEWS
3.1 PROJECT MANAGER'S REVIEWS

The Project Manager shall formally review and document the status of the
hardware at times coincident with the key milestones in the design and develop-
ment of the items. These Project Ma-uer reviews will, in general, focus on the
spacecraft subsystems. Reviews a r e recommended f o r components and black
boxes of subsystems that a r e either unique o r particularly vital to the mission.

The Project Slanager shall review e.xperiments, launch-vehicle system, and

ground-support and operational equipment. He should invite the Systems Review
Office to participate in these reviews.

The primary objective of these reviews is to evaluate the design and performance
of the subsystem o r component. They also provide an opportunity to evaluate
and update the interface specifications.

3.2 GSFC DESIGN REVIEW PROGRAiM

5 2.1 Definition

The GSFC design review program is composed of a series of systematic, tech-

nically-oriented and documented evaluations of a project by a team of specialists
not directly involved with the project. The design is administered by the Systems
Reliability Directorate.

52.2 Purpose

The purpose of the design review program is to enhance the probability of success
of GSFC spacecraft and launch-vehicle missions.

3.2.3 Implementation

G M I 8010.1 prescribes policies and general procedures of the design review

program. h summary, it requires each project to undergo a series of reviews
by a team of technical specialists selected on a GSFC-wide basis. The number
of reviews required depends on the specific mission and on considerations such
as mission comple?rity and number of previous flights. A new project will probably
undergo a design review program as follows:

3- 1
 a. Conceptual Design Review. This review, keyed to the end of the study
phase, will evaluate the preliminary design and design approaches which
resulted from the study.

b. Detail Design Review. This review usually takes place after the design
is frozen and before assembly begins. Emphasis is on the implementation
of the design approaches which result from the study and the plani for
the systems and prototype testing.

C. Flight Qualification Review. This review takes place after qualification

testing of the prototype, o r before acceptance testing if no prototype is
used. The primary purpose of this review is to determine the qualification
status of the hardware and to evaluate flight-acceptance test plans.

d. Flight Readiness Review. This review usually takes place before the
flight spacecraft is shipped to the range, and emphasis should be on the
performance of the flight spacecraft during acceptance testing.

e. Flight Operations Review. This review, keyed to the availability of a

flight operations plan, will evaluate the plan for orbital operations and
the interface between the flight spacecraft and the ground-support
equipment. This review is often combined with the Flight Readiness
Review.

In addition, to the foregoing reviews, the review team will include on its agenda
safety aspects of flight systems.

5.3 TRACKING AND DATA SYSTEiW READINESS REVIEWS

Several reviews of the project's tracking and data systems will be conducted
before each flight. The primary purpose of these reviews is to determine the
state of readiness of supporting personnel and systems for the impending flight.
The Project Manager should normally use these reviews to fulfill his reqyire-
ments for establishing the readiness of tracking and data systems.

3.4 MISSION FAILURE IiiESTIGATIONS

NASA Management InstAction 8621.1 states that NASA's policy is to investigate

and document the causes of all major mission-failures.

3-2
L€ serious in-orbit o r operational failures occur in GSFC missions, the Director,
GSFC, may conduct, at his discretion o r at the request of the cognizant Head-
quarters Program Office, independent investigations to determine causes and
make recommendations (see G X I 8621.1, dated June 28, 1971).

5.5 MISSION EVALUATION REVIEW ' '

On some projects there has been a review after the spacecraft has been in orbit
for an appreciable period to assess its performance. For some projects this
review has only covered e?cperiments, while for others all the spacecraft sub-
systems have been reviewed. Reviews, a s complete as practical, provide infor-
mation on how to conduct future projects and are encouraged.
 PART 6
RELIABILITY AND QUilLITY ASSURANCE
6.1 RELIABILITY

Key factors emphasized in GSFC's reliability program are:

a. Reliability considerations in original design

b. Quality assurance

c. Design reviews (see Part 5)

d. Systems testing (see Part 3)

The Project Plans for the individual projects describe in some detail the project
and supporting functional organizations which implement the reliability proam r a m .
At GSFC, the term ffreliabilityffis considered to be design-oriented; it is Center
policy to place responsibility for the design on the same group from start to
finish. Accordingly, on large projects, the reliability engineers on project staffs
report administratively to the Projects Directorate.

Discipline control in the area of reliability is sometimes achieved by using a

reliability contractor who is independent of the company which produces project
hardware. These contractors have worked primarily in reliability assessment
with the project reliability engineer directing the work. When there is no reliability
engineer, this responsibility rests directly with the project engineering s t a f f ,
with support from Quality Assurance Support Managers and Test and Evaluation
Support Managers assigned by the Systems Reliability Directorate. The effec-
tiveness of the overall program of design, testing, reliability, and quality assur-
ance activities is periodically reviewed and judged in a series of formal design
reviews administered by the Systems Reliability Directorate (Part 3). . Technical,
review teams, as independent as possible of the indirect project staff, conduct
these reviews. This review program serves a s primary discipline for the over-
all reliability program at GSFC.

Individual members of the Systems Reliability Cirectorate serve a s consultants

on the reliability and quality assurance program in their areas of competence.
The Systems Reliability Directorate prepares the required policies and manage-
ment instructions.

6-1
6.2 QVALITY ENGIXEERIXG

At GSFC, quality assurance is administered by the Quality Assurance Division

which guides, counsels and assists the project in this field. X Quality Assurance
Support Manager is co-located and assigned directly to the Project Manager's
staff to assist in project-related matters that affect quality assurance, such as:

a. Developing appropriate quality and reliability requirements

b. Reviewing purchase requisitions, procurement plans, contractor

proposals, and contracts to ensure the irclusion of proper quality and
reliability requirements

C. Surveying prospective contractors' plants to ensure that they a r e capable

of producing hardware of a specified quality level

d. Arranging for Government monitoring of contractors' quality programs

by delegation to other agencies o r by NASA/GSFC personnel a s appro-
priate

e. Evaluating contractor quality program plans and recommending approval

or disapproval

f. Inspecting or arranging for Government inspection of hardware from a

technical and design-intent perspective

g* iMaintai&g control of the specified configuration

h. Ensuring the establishment and operation of an effective parts program

i. Arranging for performance of failure analysis work

j. Closing out malfunction and corrective action reports

All quality-assurance policy and procedural matters, which impact other NASA
Centers, XASA Headquarters, o r Government inspection agencies, a r e coordi-
nated by the Project Quality Assurance Support &-mer through the Quality
Assurance Division Off ice.

6-2
6.3 SLALFL7CTION REPORTIZG (Failure Reporting)

GSFC policy is to use a uniform malfunction reporting system for all GSFC
spacecraft projects. GSFC Management Instruction 5310.M describes this
system and the procedures to be followed.

This reporting procedure shall be used for all prototype and flight hardware on
all spacecraft projects. . Malfunction reportbg shall begin with the f i r s t functional
test of an assembly (subassembly if it exists) and continue throughout the mission
until spacecraft power is turned off. Hardware level, not contractor level, shall
define the starting point f o r reporting. Malfunction reports shall be submitted
on GSFC Malfunction Report Form (GSFC 4-2,June 1970) and shall be closed out
by the Project Manager. GSFC Specification for Contractor Malfunction Re-
porting, s-312-P-1, shall be used on GSFC contracted programs.

6.4 PARTS PROGRAM

6.4.1 Preferred Parts Lists and Parts Selection Policy

It is GSFC policy to use reliable electrical, electronic, mechanical, and electro-

mechanical parts in all launch vehicle, spacecraft, and experiment efforts that
the Center manages. To accomplish this end, the use of the GSFC Preferred
Parts List (PPL) has been made mandatory as described in GSFC Management .
Instruction 5330.5.

6.4.2 Scope

The GSFC P P L must be used on all flight and prototype launch vehicles, space-
craft, and e.xperiments of new design. The P P L may be required on equipment
of existing design and critical ground support equipment at the option of the
Project Manager. Non-PPL parts may be used in they a r e approved in accordance
with GMI 5330.5.

6.4.3 PPL Contents and Distribution

The GSFC PPL, updated on an "as-needed" basis, lists recommended parts and
their respective procurement specifications. Each part listed has a history
either of satisfactory qualification testing o r of e.xtensive past usage in GSFC
flight programs. The appendix of the GSFC P P L contains nominal screening .
tests and derating f o r electronic parts. Additional parts bformation appears in
the document, Application Noted for Preferred Parts and Materials, Volume 1,
February 1967.

6-3
The PPL may be distributed to NASA contractors and foreign e.qerimenters on
NASA programs o r to the Project Manager of International Cooperating Programs.

6.4.4 Non-PPL Procurement

Many procurement and screening specifications, that were written locally, a r e

available for the procurement of parts such a s nonmagnetic connectors, relays,
diodes, and microcircuits. Specifications for unique project procurements may
be developed upon request for the purchase of electronic parts and materials. '

The Quality Assurance Support M b a g e r assigned to the project will be familiar

with the procedures on initiating these procurements.

6.4.5 Inspection and Test

The GSFC Project Manager may use the facilities and manpower of the Inspection
Section for the performance of electrical, electro-mechanical, and mechanical
inspection of parts and assemblies to ensure compliance with the requirements
of the procurement specification. In addition, screening and evaluation tests can
be performed by this organization on both planned and emergency basis.

6.4.6 Failed Parts Analysis

The Project ,Manager may use the facilities and manpower of the Failure Analysis
Section to perform analyses and evaluation of failed parts and components. He is
encouraged to do so.

6.5 NASA RELIABILITY AND QUALITY ASSURAiVCE PUBLICATIONS

XASA has developed and published a series of reliability and quality assurance
publications setting forth stringent requirements for space program procurements
from research and development concepts to space operations. These publications
implement NASA policies and should be utilized to the extent necessary for hard-
ware procurements a s contractor, subcontractor, and Government agency control
documents.

Official NASA policy and detailed procedure for implementing these NASA publi-
cations a r e set forth in NASA Procurement Regulation NHB 5100.2, Part 1, Subpart
50, "Integration of Quality Requirements in NASA Procurements," and Part 1,
Subpart 51, "Integration of Reliability Requirements into NASA Procurements".

The present NASA publications relevant to quality assurance and reliability

functions a r e a s follows:

6 -4
a. NH.B 5 3 0 0 . - ~ ( l B )"Quality
, Program Provisions.for Aeronautical and .
Space System Contractors,'' April 1969. This publication sets forth
broad quality system requirements for prime contractor quality pro-
grams necessary to ensure that flight equipment and associated ground
support equipment meet the quality requirements of the program.
Complete implementation of this document requires control from initia-
tion of design to operational use; however, variations in detailed control
elements should be tailored to the circumstances of individual procure-
ment s.

b. NHB 3300.4(lC), "Inspection System Provision for Suppliers of Space

Materials, Parts, Components, and Services, April 1962. This
)'

publication sets forth the minimum requirements for subcontractors'

or suppliers inspection systems for those suppliers operating below
the system level (i.e., suppliers of materials, parts, and components,
including certain classes of "off-the-shelf" items).

c. NHB 5300,4(2B), "Quality Assurance Provisions for Government Agencies,"

June 1964. This publication is f o r use by Government agency quality
assurance and inspection representatives at contractors plants who
perform quality assurance (including inspection functions a s delegated
by NASA installations.

d. NHB 5300.4(1X), "Reliability Program Provisions for Aeronautical

and Space System Contractors , f fApril 1970. This publication establishes
general guidelines for designing reliability into space hardware and
preventing degradation of design reliability during the succeeding steps
from fabrication to end use. The document requires the contractor to
develop a reliability program plan for submission.

e. NHB 5300.4(3A), "Requirements for Soldered Electrical Connections ,)'

May 1968. This publication provides specific guidelines and procedures
for effective control of soldering operations to obtain confidence in the
reliability of soldered electrical connections for NASA space systems,
including ground support equipment. A companion document NASA
SP-5002, "Soldering Electrical Connections offers approved techniques
for space flight hardware.

f . "Tips to Experimenters ,'' A candidly written booklet, describes a great

deal of accumulated trouble e-xperienced with space hardware and high-
lights these problem areas.

6-5
g. Quality Assurance Brief. A monthly issuance of the Parts Branch,
Quality Assurance Division, discusses current parts problems, alerts,
failed part analyses completed, and recently published parts specifica-
tions which have come to their attention during the month. These pub-
lications a r e widely distributed to both GSFC personnel and approved
NASA contractors and e'xperimenters, including foreign e.xperimenters
in cooperating NASA programs.

6-6
 PART 7
DATA UTILIZATIOIV AND MAl\iAGEMEST
7.1 EXPERIMENT DATA ANALYSIS, UTILIZATION, AND REPORTING

The Project Plan describes the complement of experiments to be carried on

each spacecraft. Experiments may be primarily scientifically, technologically,
-
o r applications oriented.

7.2 PRINCIPAL INVESTIGATOR

A Principd Investigator should be assigned to each experiment. He is normally

selected by the Associate Administrator for Space Science and Applications (see
para. 2.4.4). The Principal Investigator is responsible for assuring that the ex-
periment's objectives a r e met, for managing the experiment properly, f o r pub-
lishing the results of the experiment, and for submitting the experiment data to
the National Space Science Data Center (NSSDC) in a form that other experienced
investigators in the field can use.

7.3 FUNDING

The project will fund the Principal Investigator so that he can meet his responsi-
bilities (para. 7.2). Funding will normally cover the period from e.qeriment
approval to submission of data to the NSSDC. The project will not fund the
Principal Investigators for data analysis after the data.are in the NSSDC without
specific approval by the Office of the Director. The data will normally be sub-
mitted to the NSSDC within two (2) years of the date they a r e taken.

7.4 DATA USE

The Principal Investigator will receive processed data o r recovered material

from an experiment a s soon as possible after they a r e received. He will have
sole use of these data o r materials for a period which he and the Associate Ad-
ministrator f o r Space Science and Applications will decide upon before launch.
He will submit the e.qeriment data to the NSSDC at the end of this period.

7-1
 7.5 DATA REQLTREMEXTS REVIEW COhIlIITTEE

The GSFC Data Requirements Review Committee has been established by the
Director to review and approve for him the requirements for data reception
and processing, including telemetry, orbit and attitude data, established by
each GSFC flight project. Reviews are carried out at various stages of the
project a s follows:

a. Pre-launch. At least one year before the launch readiness date, 3

review shall be held of the requirements for post-Launch data recep-
tion and processing.

b. Immediate post-launch. Between launch and 6 months, a review

shall be held of the requirements and results of the data reception
and processing operations.

c. Periodic post-launch. At approximately 1-year intervals, reviews

shall b e held of the requirements and results of each project's data
reception and processing operations. At the discretion of the
Committee, the 1-year interval may be modified as desired.

At a l l post-launch reviews, spacecraft status, scientific output, and

the prospects for the continued production of worthwhile science will
be reviewed. The Committee has the authority on behalf of the
Director to modify the requirements levied by the project on functional
support elements of the Center. The C h a i r m a n of the GSFC Data
Requirements Review Committee must concur on all SIRD revisions.

7.6 HEAEQUARTERS REVIEWS

Approval for the continuation of satellite operations is given by Headquarters.

Concerning those satellites under the direction of the Physics and Astronomy
Program Office at Headquarters, before the expiration of such approval, each
space science satellite will be reviewed by the Headquarters Director of Physics
and Astronomy Programs to determine whether continued spacecraft operation
is desirable. These reviews a r e expected to be held no more frequently than
~

annually. The review will be organized and prepared for Headquarters by the
Data Requirements Review Committee. In it, the Project Manager will be
e-xpected to provide the statement of spacecraft status and prospects for
continued satisfactory operation. The Project Scientist will be expected to
review the scientific output of the spacecraft and its prospects for continued
production of good science, and the Data Requirements Review Committee will
 address the question of the requirements levied by the mission on Center
facilities.

7.7 XASX POLICY DOCUMENTS

Additional information on this subject appears in the following documents:

a. Memo for Record, Goddard/NASA Headquarters Responsibilities

. . ConcernirSa Data Analysis Items, Revision 1 (by D r . G. F. Pieper,
December 9, 1965)

b. Policy Concerning Data Obtained from Space Science Flight Experi-

menters (NPD 8030.3, January 7 , 1967)

c. GSFC Announcement No. 1310, April 29, 1970, Subject: Data

Requirements Review Committee

d. Memorandum for Project Managers, Project Scientists from

Chairman, Data Requirements Review Committee, October 7, 1970,
Subj: Reviews for Headquarters of Operating Space Science Satellites

7-3
 PART 8
PROCUREMENT
.8.1 PROCUREiMENT FUNCTIONS AlW ORGANIZATION

The functional statement in the GSFC Organizational M a n u 1 is that the

Procurement Division ??. .. organizes and directs (the) procurement functions
and related.activities in support of the Goddard Space Flight Center and its
assigned responsibilities in space science and applications, rocketry, and
tracking and data acquisition." Implicit in this rather encompassing statement
is the quality of the procurement by contractual means. Note that required
services o r material can be procured othemise than by contract. Some
examples are:

a. Federal Standard Requisition Issuance Procedure (FEDSTRIP)ad-

ministered by the GSFC Property Branch, for chemicals, hand-tools,
paper, etc.

b. iWitary Standard Requisition Issuance Procedure (MILSTRIP)

administered by the GSFC Property Branch, for vacuum tubes;
resistors, transformers, etc.

c. Goddard Store Stock Systems @roperty disposal) administered by

the GSFC Property Branch, for excess property of NASA Centers
o r Government agencies

d. Consultant services obtained through temporary civil-service

appointments arranged by the Placement Branch of the Manpower
Utilization Division

The Procurement Division's Facilities support Branch (FSB), located in building

16, through its organized functions provides essential hardware support to the
-institutional facilities of this Center and its research programs. Materials,
supplies, and equipment typically required by a small municipality o r fairly
large manufacturing operations a.re purchased from a wide variety of sources.
All Center requirements f o r off-the-shelf type items a r e purchased by this
Branch, and normally any hardware not otherwise acquired through major flight
programs, Generally, procurement of a service nature a r e acquired through
other Branches of the Division.

Figure 8-1 is an organization chart of the Procurement Division.

 U

,,
17
iif
J
C
.-0In
.->
a

I
Q)

8-2
 8.2 PROCC'REJIENT REWTIOKSHIPS

A Contracting Officer is the final signatory authority on all contractual docu-

ments issued by the Center and is the only person acthorized to contractually
bind fhe agency. Many constraints a r e placed upon the exercise of that authority.
The usual initial effort after establishment of the requirement is the preparation
of a determination and finding setting forth facts and circumstances to establish
that formal advertising is not practicable. The Contracting Officer must inter-
face with the personnel of several other divisions and offices (e.g., the Project
Support Representative (business rep), Financial Analyst, Technical Representa-
-
tive,'and the Office of Chief Counsel). On most all large csnter projects the
Procurement Division, through the cognizance Negotiation Branch, assigns a
Contracting Officer to the project to furnish detailed assistance and provide
coordination on procurement related matters i. e., noncompetitive justifications,
establishment of a procurement action schedule, evaluation of existing and re-
quired facilities, statement of work, and technical data for reprocurement.

Moreover, a number of functional interfaces must be coordinated. For fiscal

matters there is the Financial Management Division. Contract documents and
other legal matters a r e concurred in by the Office of Chief Counsel. The Office
. of Patent Counsel will advise on matters relating to patents, technical data and
copyright, and prepare special contract provisions where appropriate. The
Transportation Branch assists in packirg and crating, methods of shipment, cost
of transportation, etc. The Quality Engineering Branch of the Quality Assurance
Division provides early assistance to the Purchase Request initiator by the
recommendations of realistic quality requirements, and reviews the Negotiator's
Procurement Plan for appropriate technical application of the NASA Quality pub-
lication to be included in the solicitation and contractual documents. The Policy
and Review Branch reviews each document for compliance with overall procure-
ment policy. The Manpower Utilization Division reviews N P C 401 justifications
involving nonpersonal services to ensure compliance with applicable directives
and laws. The Health and Safety Engineering Office advises on inclusion of
clauses covering special health o r safety problems. The Technology Utilization
Office advises on the "New Technology Clause," which is mandatory f o r research
and development contracts& excess of 51,000,000 and in contracts of lesser
dollar amounts where significant advances in the state of the a r t a r e anticipated.
c

To avoid delays in procurement actions, the Contracting Officer should attend

early project planning sessions to assure that document requirements a r e fully
explored. Because many people d e up the team and it is necessary to move
quickly, early coordination with all interested parties is essential.

.-
-
c
. - 8-3
c
8.3 PROC'LRELIENT CYCLE A+XD LEAD TIJIES

The procurement cycle is the total elapsed time from the initiation of a project .
(by formally submitting a project approval document) until the hardware is de-
livered and the contract is complete. In many cases, this cycle covers several
years. The term "procurement administrative lead time'' is frequently confused
with the term "procurement cycle.'' Lead time refers to the span between the
receipt of a Procurement Request (PR) by the Procurement Division and the issu-
ance of a signed contractual document. The following is a list of the steps in a
sample l'procurement cycle" of a new competitive procurement of $2,500,000
from receipt of the PR to contract award and distribution.

Actions required in a typical $2,500,000 competitive procurement are:

a. --Ahead, to Request for Proposals (RFP)

(I) Headquarters program go-ahead

(2) Draft of work statement and .specifications
(3) In-house estimate begins
(4) Procurement request received
(5) Determination and findings written
(6) Procurement plan prepared
(7) GSFC counsel comments
(8) RFP preparation started
(9) Preliminary source list prepared
(10) SEB and tech committee nominations requested'
(11) SEB and bus committee nominations foxwarded
(12) Proc. plan review GSFC mgmt.
(13) D&F approved by Hdqts. - proc. plan approved by Hdqts.
(14) SEB tech and bus comm. established
(15) SEB approved by Hdqts.
. (16) Technical specifications complete
(17) Approval of specifications
(18) RFP complete and SEB Epproved
 (19) CSFC estimate complete
(20) To chairman SEB
(21) Preparation of tech and bus eval criteria
(22) SEB approves eval criteria
(23) SEB approves source list and R F P release
(24) Final editing and printing
. .
(25) RPF mailed and synopsized

b. R F P to Selection

(1) Preproposal conference held

(2) Proposed received
(3) Proposals separated into bus. and tech.
. (4) Technical evaluation begins
(5) Business evaluation begins
(6) Price analysis begins

(7) Preliminary technical, bus eval and comparative price analysis

complete
(8) Tech and bus comm. chairman make prelim. presentation to source
evaluation board (SEB)
(9) SEB preliminary presentation to GSFC mgmt.
(10) Selection of serious contenders
(11) Preparation of critique for orals
(12) Preparation of questions to offerors
(13) Review of questions by SEB -
(14) Contractor responses to questions
c

(15) O r a l s complete
(16) final technical evaluation
(17) Final business evaluation
(18) Final BMC-TAC presentation to SEB
(19) SEB first presentation t_o GSFC
--
. -
e-

* 8-5
c
 (20) Review by Director A&M
(21) SEB final presentation to GSFC
(22) SEB presents to NASA administrator Hdqts.
(23) Source selection
(24) Prepare statement of source selection (GSFC)
(25) Sign off of statement by Administrator ,

(26) Preparation of OPA release

(27) Hdqts approval of release
(28) TWX's to all offerors

c. Selection to Award
(1) Price analysis requested
(2) Price analysis received
(3) Preparation of prenegotiation plan
(4) Prenegotiation plan. approved
.
( 5 ) Start negotiations
(6) Complete negotiations
(7) Prepare memo of negotiations
(8) Draft contract and prepare file
(9) Policy and regulation review
(10) Legal office review
(11) Changes and preparation for transmittal
(12) To contractor for signature
(13) Signed contract returned
' (14) GSFC review of any changes
(15) Forward contract to Hdqts.
(16) Hdqts review and approval
(17) A m r d spopized
(18) Contract distributed

8-6
NASA Procurement Regulation (NHB 5100.2) establishes approval levels. for
various contractual matters to be performed at Field Installations. For GSFC,
-
this level is generally established 3t $2,500,000 above which NASA Headquar-
t e r s approval is necessary.

Figure 8-2 is the current procurement administrative lead time usually neces-
s a r y for 'a specific requirement. Lead time standards are also included in the
GSFC publication, Procurement Request Handbook, GHB 5150.1C.

Because yarious Acts of Congress require many of the steps shown previously
it is difficult to shorten the time cycle. However, the lead-time cycle can be
shortened by influencing action in several key areas:
a. Ensure that procurement request packages are complete (i. e. , specifi-
cations, required justifications, o r approvals)
b. Exercise active control over the technical evaluation being conducted
within the project and, where possible, appoint someone to monitor
the overall effort
c . Schedule requirements realistically and use emergency procurement
action when necessary
d. Most important, .promote early coordination among the Technical
Representative, the Negotiator, the Financial Analyst, and the Project
Support Business Representative

A number of open-end contracts already e.&t which may be used to speed up the
placement of contract coverage:
Quick-reaction work-order contracts
a. Contracts for Off-Site Engineering Design Supporting Fabrication and
. Associated Technical Writing Services (see GMI 5104-lB)
b. Contracts for Off-Site Fabrication Services (GMI 5104.3)
c. Off-Site Computer Programming and Systems Analysis. These con-
tracts provide for performance of off-Center requirements in: orbit
determination; ground system operations ; satellite control; and scien-
tific data processing (see GMI 5104.1B as revised). -The Technical
Services Branch will assist in the use of these contracts.

8.4 PREPROCURESfENT REQUEST STAGE

This sectipn covers the procurement cycle from the time initi'ator begins rout-
ing the PR through his own management, financial management, other groups
+
. -
8-7 e-

c
Type ?mcurement
Action Code

CONTRACT m I
I
I I ' I ! I 1 I
1
I
!
1
I
R x u L 9 P / N O ? ! ~ @ N LA I I I 1 i 1 1 ; .
sx<vxm I I 1 I t 1 1 1 *I 1 I
S2.W and over ' 9 - 7 - 1-6-7 -1-2-3- I.-N!h-2
SloOM t o f2*5E! . 7 - 5- 1-5-5 -1-2-3- l-![/A-Z
JiooK t o SLOM 6- S- 1-5-5 -1 --1-2- 1- 2 - 2
S2.5K t o 31ooK L- 3- 1-3-3 -l-l-.l- 1- 1 - 2
f 0 to S2.5ii 1- 1- 1-1-1 -1-1-1- I- 1 - 2

NOTE: a. As fsr as d o l l a r levels a= concerned, base your choice o f lead time ? I a n

the total estimated c o s t o f the prncurment ar.6 no', upon t h e PP. value.

bo Should you need a lead t i m e f o r a contract type aot mentioned above, such
W: Construction, A r r h i t e c h t u e ' & Wineer-24 Sexvices, teases, or
.
Automatic 3aLa Processing Scuipment Contracts, contact procurement bxanch
pc=onnel
C. Use only t k e t n e p n c u n n e n t action codes fobnd above.

Figure 8-2. procurement Administrative L e a d Time

8-8
necessary because of any special approvals, the Property Branch for certification
of nonavailability from stock, and Center management when the dollars involved
warrant it, until the Procurement Division receives it for processing. The pre-
planning and control of PR's during their early life is a vital element of a re-
sponsive, successful project procurement program.

8.4.1 Budget Planning

The Project Operating Plan (POP) is a valuable tool for procurement planning.
Requirements should be carefully planned, not only as to their technical content
but also as to the availability of a complete package: procurement request,
specification, work statement, and any required justification. If availability data
and type of procurement action a r e accurately forecast and e'upressed in the
POP, the Procurement Division can, in coordination with the project, plan con-
tractor go-ahead dates.

The POP is used as a measurement of the fiscal responsibility of the project in

planning and using its resources, and the Procurement Division's ability to effi-
ciently contract the technical requirements of the Center. Unless the POP is
carefully planned, documented, and coordinated, the project and procurement
cannot meet their goals.

8.4.2 Processing Procurement Requests Within the Project

The centrai recording of PR's within a project is strongly recommended to

promote accuracy as well as control.

8.4.3 Initiating Procurement Requests

The Project Manager should be familiar with the Procurement Requests Hand-
book, GHB 5150.1C, to supervise the assembly of the PR package. If time per-
mits, he should discuss with the assigned negotiator the detail of the PR before
starting the papers through the approval cycle.

The specification is the most important part of a procurement package. An

inadequate specification will delay the procurement.

Things to watch for include:

a. Each contract schedule must include a list of deliverable items. To

avoid redundancy and corrflicting language, the specification should con-
tain technical descriptions of line items only, and should omit refer-
ences to quantities.

8-9
 b. The package should include provisions for preservation and packaging.
NHB 6000.1 o r Military specifications on this subject can be refer-
enced for the necessary coverage.

c. Specifications should confgrm to GSFC Specification Manual TID-1,

August 1964, which contains an excellent checklist for reviewing the
document.

Each R&D procurement over twenty-five ($25,000) dollars requires a valid in-.
house estimate, that may be prepared in accordance with the ,guidelines set forth
in GHB 3150.1C, para. '2-4, a s revised. The estimate is required for several
purposes, one of which is to evaluate prospective offerors' proposals when ade-
quate e.xperience o r competition is lacking.

Gal1 5310.2A (para. 2-34) establishes the policy that all PR's for material, sup-
plies, and equipment intended for space flight use will be reviewed by Quality
Assurance Division personnel to assure that adequate reliability and quality
requirements a r e included commensurate with program needs, the intended ap-
plication of the item, and NASA and GSFC policy. Quality Assurance Division
personnel will, when requested, assist the PR initiator in developing R&QA re-
quirements f o r all spaceflight hardware procurements? ensuring the compati-
bility of these requirements with the needs and intended use of the equipment.

8.4.4 Funding of Special Procurement Requests

Special PR's include planning PR's and blanket PR's. Planning PR's (planning
I stubs, as they a r e frequently called) a r e used to minimize the impact of fiscal
I constraints by allowing concurrent processing of the procurement action while
I the funding problem is being resolved. They a r e used primarily when fiscal
constraints a r e present but w i l l be alleviated.

The negotiator, upon receiving a planning procurement request, be,cins the

procurement process by the accumulation and preparation of required documen-
tation such as: the source list, small business coordination, procurement plan,
and request for proposal. Except in unusual circumstances such a s critical pro-
gram schedules,'and invitation f o r bids, request-for prbposals a r e not issued .
until there is' a certification that funds a r e available. However, the cognizant
negotiation branch head may authorize (with the approval of the Director of A d m i n
& mgmt) a l l actions necessary up to the point of contract award, where program
authority has been issued, and he has further assurance that funds will be
provided.

TO the Project >Ianager, planning PR'S , a r e effective weapons against fiscal con-
straint. Planning PR's should be used for large procurements which require

8-10
extensive administrative planning and work which, if carried on while the funding
problem i s being overcome, can lessen procurement lead time.

The blanket PR provides a source of funds within the Procurement Division for
mandatory immediate changes, pursuant to GHB 5104.2% (paragraph 7 . 7 ) . The
advantage is that the individual PR's go directly to the negotiator who draws the
necessary funds from the blanket PR already processed. A new blanket PR is
issued when the available balance is exhausted. Because they w i l l be obligated
as a series of actions over a prolonged period, blanket PR's must be handled
carefully in the Project Operating Plan.

8.4.5 Keeping Track of Procurement Requests

Various Automatic Data Processing (ADP) reports issued by the Business Data
Branch may be useful in keeping track of PR's. Project Managers and PR
Initiators receive copies of these reports regularly. Among the most important
are:

a. Report 1051.4 - Status of Procurement Request in initiating Division

sequence, and within Divisions, by PR number (bi-weekly)

b. -
Report 1233A Status of PR's in fiscal year/program-project/PCN
sequence (bi- w eekly)

Information contained in these reports includes:

Buyer Description
Procurement control number Type PR (routine/emergency/planning/
Job order number oblig. authority)
Budget line item Date PR received
Fiscal year of funds Type procurement action
Commitment dollars Next milestone due
No. of days hence
Milestone is due o r is late

8.5 PRECONTR-4CT STAGE

-This section deals with procurement administrative lead time, which begins
when the Procurement Diviqion receives the procurement request and ends with
the award of the contract.

8-11
 1, 8.5.1 Types of Contracts

The proper business environment requires the selection of the appropriate type
of contract. The objective is to negotiate a type of contract and a price that in-
cludes reasonable contractor risk, and provides the Government a means of
achieving maximum technical return from the dollars being invested. During
the preparation of the procurement plan the Contract Negotiator with the assis-
tance of the Project Manager makes some preliminary decision on what type of
contract that will be specified within the solicitation document. Technical input
must consider matching the nature of the requirement with the ability of the
Government to describe the end-product required. Generally, the spectrum from
basic research to production in the requirements end, affords an opportunity to
'
choose from a range of standard cost-reimbursement contracts to firm *fixed
price. '

The GSFC practice is to utilize a firm fixed-price and/or an incentive type con-
tract to the e.xtent feasible and practicable. If the Contract Negotiator and the
Project Manager (or his representative) believe that there are possibilities for
incentive contracting they should secure the advice of the Special Assistant for
Incentive Contracting early in the planning stages of the procurement process.

I 8.5.2 Procurement Plans

The NASA Procurement Regulation, NHB 5100.2 (formerly NPC 400), 3.852, .de-
scribes procurement plans in detail. A procurement plan outlines the method by
which the Contracting Officer expects to accomplish the procurement task. The
procurement plan must be approved before a request for proposal can be issued.

The procurement plan is also a means of justifying a particular approach and of.
obtaining management approval of the proposed action. Usually, procurement
plans a r e required when a contract estimate exceeds $100,000. Procurement
plans a r e particularly significant to the Project Manager because of the admin-
istrative processing time r e w i r e d for coordination.

The Procurement Officer (Procurement Division Chief) approves plans for amounts
up to $ 1 , 0 0 0 , 0 0 0 ; the Installation Director approves those over-$1,000,000; the..
Associate Administrator for Organization and Management approves those of
32,300,000 and above. It now takes appro.ximately 30 days to process aplan from
receipt of the PR to approval by the Associate Administrator For more informa-
tion. refer to "Contents of the Procurement Plan, " SHB 5 1 0 0 . 2 , part 3 . 9 5 2 - 3 .

A Computer-Acquisition Plan, a special version of the Procurement Plan, is re-

quired for any acquisition by the project, prime Contractor o r any sub-contractor
of:

9-12
 a. Any electronic digital computer, regardless of use, and any peripheral
or auxiliary equipment used with it o r in support of it.

b. Punched-card electric accounting machines.

c. Data-transmission o r cdmmunications equipment selected and acquired

solely o r primarily for use with an electronic digital computer.

The requirements s e t forth in NASA Handbook 241O.l.A, "Management Procedures

for Automatic Data Processing Equipment (ADPE)," a r e mandatory for NASA
Headquarters, field installations, and NASA-owned contractor-operated facilities.
The Procurement Division's Procurement Instruction, 210-71 , provides a
listing of regulatory material affecting ADPE acquisition plans.

8.5.3 Determination and Findings (D&F's)

A fundamental distinction must be made in any discussion about Government

procurement which has a particular application in reference to D&F's. It is
axiomatic that in non-Government fields, the business official proceeds to do
whatever he is not prohibited from doing by law. The Government official,
however, can do only what he is expressly authorized to do.

Basic legislation on Government procurement states that all contracts shall be

let by the formally advertised bid method. In the research and development
(R&D)environment, this policy seems particularly restrictive. The ori,o;inal
legislation w& passed shortly after the Civil War because of Congressional
reaction to a number of scandals involving nepotism and graft in the purchase
of w a r materials. For a long time thereafter, the Government bought almost
everything by formal advertising. Over the years, as things became more com-
plex and less defined, certain exceptions were made to the basic law: for ex-
ample, the first exception was legislated to solve the problem of procuring
services and supplies quickly in time of a national emergency declared by
Congress. Since that time, sixteen exceptions have been added to the list.
Therefore, a negotiator must have an approved D&F citing.one of the exceptions
before he can negotiate a contract.

When it falls within the authority of the Contracting Officer, a D & F does not gen-
erally present a time problem. However, for an R&D contract, estimated at over
$100,000, the law e'xpressly states that the Administrator o r Deputy'Administra-
tor of NASA must approve the D&F. The administration lead time for this
process will be 4 to 6 weeks o r more. When GSFC authority can review and
approve the D&F, the process will usually be less than 1week.

8-13
8..3.4 Request for Proposals, Request for Quotations, 'and lnvitations for Bids

5.5.4.1 Request for Proposals (RFP's). R F P ' s a r e formal documents sent to

prospective contractors by a Contracting Officer to provide information they
need to prepare a proposal, and solicit from them information that procurement
and technical personnel need to evaluate the proposals. X RFP is used for a
negotiated procurement and is particularly appropriate for R&D situations.
RFP's result in both price o r cost proposals and technical proposals. The R F P
is particularly sensitive because it establishes the format for these proposals
which c m yeacly aid evaluation, culalysis, md coiyinrison. Their s r r e q t h and
i v d a e s s stem from the same characteristic - flesibiiitj-. One of the problems
is proper emphasis to the prospective offerors that contractual requirements
must be conformed to and all mandatory requirements complied with; the more'
complicated the "scope-of-work" the more possibilities exist that the Re, t iat ed
contract may not faithfully reflect all terms and conditions contemplated.
Severtheless, RFP's a r e appropriate in a true R&D situation.

. preproposal conference is sometimes held with industry after the R F P is

A
released, in order to provide e-qlmation by the Cavernment and permi: industry
in open session to request clarification of any part of the R F P they do not under-
stand. This conference, if held, is not less than ten (10) days after release of
the R F P in order to enable prospective contractors adequate time to analyze its
contents.

8.5.4.2 Request for Quotations (RFQ's). RFQ's a r e informal means of obtaining

price and delivery information, and their use is usually confined to small pur-
chases, the aggregate amount of which does not exceed $2,500. The buyer o r
negotiator may use a standard form to request a quotation o r m a y telephone
the vendor to obtain the quotation and place the order at the same time, sub-
ject to an approved Purchase Order being forwarded and accepted. However,
RFQ's a r e also used for Solicitations for Wormation o r Planning Purposes
under certain circumstances regardless of the dollar amount of the contemplated
procurement. The NASA Procurement R e e a t i o n (XHB 5100.2), 1.309 reads a s
follows: "It is the general policy of the XASA to solicit bids, proposals o r quo-
tations only where there is a definite intention to award a contract or purchase
order. However, in some cases solicitation for informational o r planning gur-
poses may be justified.. .Request for quotations may b e issued for informational
o r planning purposes only with prior approval of the Procurement Officer. In
such cases, the request for quotation shall clearly state its -purpose
- and, in addi-
tion, the following statement in capital letters shall be placed on the face of the
request. "The Government does not intend to award a contract on the basis of
this Request for Quotation, or otherwise pay for the information solicited." The
uncontrolled use of R F Q ' s would impose a considerable hardship on industry,

3-14
and place the Government in a position to be justifiably critized. Goddard has
adhered strictly to the NASA policy on the matter of RFQ's; therefore, none a r e
to be utilized except with the prior approval of the Procurement Officer.

8.5.4.3 Invitations for Bids (IFB's). IFB's are used when the sealed-bid
method of procurement can be utilized. Very definitive specifications a r e re-
quired. One of their distinct advantzges is the speed with which large amounts
of orders may be placed. GSFC edxperience has been to use the IFB primarily
for large quantities of developed items, off-the-shelf equipment and supplies,
construction of facilities, o r standard commercial ser;ices such as printing.
Technical discrepancies must be kept to a minimum in order to avoid official
protests when the contract award is made.

A less restrictive sealed-bid procedure is two-step formal advertising. The

first step resembles RFP negotiation. First-step proposals a r e submitted
without reference to cost; an evaluation ensues which, from a technical point of
view, either eliminates the proposal as completely unacceptable, determines
that the proposal does not meet the government's minimum requirement but may
be revised, o r determines that the proposal is fully acceptable as submitted.
Discussions are generally held with contractors whose proposals may be cor-
rected by suitable revision.

In a two step formal advertisement, after each technical proposal is declared

either acceptable o r unacceptable, the second step begins. Each acceptable
proposer submits a sealed bid incorporating the technical aspects of his first-
step proposal. The contract is then awarded on the basis of price only. This
usually follows closely upon receipt of the-bids, and delays occur only for a
pre-award survey when doubt exists as to the capacity of the contractor. When
only one acceptable proposer remains after the technical evaluations, the pro-
cedure must be converted to a negotiated procurement as described previously.
This does not mean that proposals are resolicited, but that the procurement i s
negotiated from the point at which the technical evahation a r e complete.

8.5.5 Technical Evaluations

lhitial judgments must be based on technical merit only, without reference to

cost information. Cost tradeoffs will be made later. All RFP's must include a
work breakdown statement to correlate the technical and business evaluation,
and a statement covering special technical capabilities which offerors must
possess. Technical evaluation of the proposals shall be based upon the criteria
contained in the request by the "Source Evaluation Board M a n u d , " the G l f I on
"Evaluation and Selection Policies and Procedures, I' and the "YASX Procure-
ment Regulation, " NHB 5100.2, 2.503-l(c) and 3.304-2. Xs a minimum, each
evaluation should consider the following:

8-15
 a. Contractor's understanding of the scope of the work, as shown by the
proposed scientific and technical approach
. b. Availability and competence of experienced engineering, scientific, o r
other technical personnel

C. Availability of necessary research, test, and production facilities

d. E-xperience of pertinent novel ideas in the specific branch of science

o r technology involved

e. Contractor's willingness to devote his resources to the proposed work

with appropriate diligence

f. Contractor's proposed method of achieving t h e required reliability

NASA Handbook NHB 5 1 0 0 . 2 , 3.804-qb), states : research arid development

contracting, awards should usually be made to those companies that have the
highest competence in the specific field of science o r technology involved, al-
though awards should not be made on the basis of research and development ca-
pabilities that exceed those needed for the successful performance of the work. I'
Reduced to its essentials, technical evaluation of an offeror's technical proposal
results in ranking proposals according to their merit and acceptability. At this
point there is a marriage of the technical proposal with the business proposal;
the first step may simply be the setting forth of the technical score and to cate-
gorize the several offerors' proposals as acceptable o r unacceptable. At this
point selection of a contractor is weighted heavily by merit of technical compe-
tence when compared with the Government's stated minimum requirement. To
be remembered, however, is the above regulatory admonishment to always be
observed against "never buying more than is needed. I' Consistent with this rule
is the basic policy of NASA to procure supplies and services frm responsible
sources at fair and reasonable prices, calculated to result in the lowest ultimate
overall cost to the Government. Therefore, once having decided one offeror has
technical superiority over another and that certain advantages will be obtained by
the Government, all other things being equal, a contract award can only be made
to an offeror that has a higher price if there i s something tangible to be gained
in the trade-offs. Unless an award can be made without any discussion with any
competitor in negotiated procurement, it is necessary to hold written or oral
discussions with all contractors whose proposals a i e in the "competitive range"
(those proposers whose technical scores and price/cost factors give them 3 rea-
sonable chance of winning the competition). The purpose of these discussions
are to point out the uncertainties and ambiguities in the proposal in order that
the offeror may support or clarify his proposal and thus enable the Government

3-16
,

to more effectively evaluate the proposal. Following oral discussions all

offerors, with whom discussions were held, are given the opportunity to submit
revisions to their proposal which will clarify or support their original proposals.
(See Procurement Regulation Directive No. 70-15 dated 12/1/70. )

The prospective contractor comes to the "oralsftwith the advance understanding

that he will be interrogated with regards to certain parts of his proposal, and
that the Government will provide him with an opportunity to amplify his proposal,
and demonstrate his depth of understanding of the Government's requirement
and the company's ability to provide it.

See the GSFC publication entitled "GSFC Source Evaluation Board Handbook -
July 1971."

8.5.6 Analysis of Labor, Hours, iMaterials, etc.

The number of labor hours required to perform a job and the span of time over
which these hours will be applied, are factors that assist in determining whether .
or not the company has an understanding of the job. Also, the list of a a t e r i a l s
and equipment, including Government- Furnished Equipment (GFE), a r e important
and both labor hours and materials will measurably assist in the technical evalu-
ation. However, aside from that, a technical analysis considers the quantities
in relation to each task proposed by the offerors or their subcontractor, and
compares these and other elements with the Government's estimates, other
offeror's proposals, and historical information, if available. Technical analysis
occurs usually in the later phases of technical evaluation when it is certain, o r
fairly certain, which prospective contractors will be in the competitive range.
Some type of technical analysis is usually required even on noncompetitive
procurements.

A good technical analysis will cover the following points and comment on areas
which require further clarification, e.uplanation, o r revision:

0 Man-hours or man-months by category of labor

0 Premiumtime
0 Sfaterials and purchased parts
0 Special equipment
0 Special testing
0 Special tooling
0 Computer use

8- 17
 Subcontracts
Travel expense
Transportation: Number of persons travelling, and number of trips
from where to where
Per diem: Number of persons and number of days
C a r rental: Number of days and estimated mileage
Other direct costs
Consultants
Freight

Comments a r e not required on labor, overhead, and G&A rates, because the
price analyst will review and recommend the rates that make up the Government's
position. The price analyst is also responsible for using the technical analysis
and rate data to assist the negotiator in establishing the negotiation objective.

8.5.7 Business 3fanagement Evaluations

Business management evaluations produce a go/no-go type of result. The evalu-

ation determines whether o r not the areas evaluated a r e acceptable for t p - -
posed contract and relative merit is not a strong factor.

Factors evaluated a r e generally'as follows:

a. qualifications of the people who will administer the contract f o r the

company

b. Effectiveness of the systems to be used fo-. , control, schedule

control and progress reporting

c. Overall resources available for the contract, such a s number of pro-

, fessional and technicians available, bac.klog of work for key facilities,
and funds available vs those required

d. Previous e'xperience with the company with regard to meeting commit-

ments and being responsive

Business evaluations a r e not scored, but a r e generally given an adjective rating

such a s "fairt', ttgoodttor "superior."

8- 18
8.5.8 Preaward Surveys and Fact Finding

Before an award i s made, it is sometimes necessary to conduct a survey of a

prospective contractor's capability to perform under the terms of the proposed
contract. This survey is useful to evaluate the prospective contractor's financial
capability and workload capacity. The preaward survey may be accomplished by
use of (1)data on hand, (2) data from another Government agency o r commercial
source, (3) an on-site inspection of plant and facilities to be used for perfor-
mance of the proposed contract, or (4)any combination of the above. Preaward
surveys a r e sometimes conducted by Source Evaluation Board Members; the
Contracting Officer with the assistance of financial and technical personnel;
other XASA installations; a military department; o r Defense Contract Adminis-
tration activity as may be appropriate for a particular procurement.

8.5.9 Selection of Successful Proposers

When Source Evaluation Board procedures a r e utilized a source selection

statement is prepared, and signed by the Source Selection Official for initiation
of final contract. negotiations with one o r more proposers. Similarly, though less
formal, procedures apply in competitive selections between $100K and S1,OOOK
(see G&LI5150.8). Successful proposers in other negotiated contracts of $100K
o r less are selected with less formality, and the selection factors a r e noted
within the "background" section of prenegotiation plans. In addition, one of the
following procedures a r e usually followed: .

a. A separate selection statement is not usually prepared and approved if

the contractor to whom the award is to be made has the highest tech-
nical rating and the lowest cost/price proposal. The Contracting Officer
usually makes the required decision and documents the selection within
the summary of negotiation.

b. The Technical Evaluation Report, when approved and signed by the

appropriate Technical Representative, serves as the basis for the
selection statement provided it includes a recommendation for an
award, and is concurred in by the Contracting Officer, o r other higher
procurement head o r supervisor.

C. In sole source situations the Justification for Noncompetitive Procure-

ment serves as the selection statement when properly signed and con-
curred in by appropriate authority. The negotiator usually places a
memorandum in the file to indicate that the situation with respect to
sole. source has not changed from receipt of the Procurement Request
to award of the contract.

8-19
8.5.10 Prenegotiation Plans

A prenegotiation plan draws upon all information and facts developed during the
evaluation process and establishes a firm negotiation position with respect to
each segment of the contractor's proposal. Prenegotiation plans a r e required
for all procurements over $10,000 and must be approved at the following levels:
0 $10,000 to $100,000 - Procurement Section Head
$100,000 to $500,000 - Procurement Branch Head
$500,000 to $1,000,000 - Procurement Division Chief
0 $ 1 , 0 0 0 , 0 0 0 and over - Procurement Division Chief with the concur-
rence of the Director .A&M
The technical representative is usually requested to review, concur in, o r com-
ment upon prenegotiation plans over $500,000. Incentive arrangements included
in prenegotiation plans must be approved By the NASA Director of Procurement
when the proposed contract exceeds $2.5 million except when approval authority
has been delegated to GSFC under the Master Buy Plan Procedures (see para.
8 . 3 , above).

8.5 .I1 Negatiations

No matter how carefully the negotiation position w a s developed, a negotiator

will achieve o r fail to achieve his objective a t the conference table on the basis
of the way in which he presents his case, Principles which should guide all
members of the negotiation team are:

First, the contract negotiator, as lead member should be regarded as captain

of the team and he will present the Government's position, o r designate a "mem-
ber of the team" to speak in support of the agreed position as reflected in the
prenegotiation plan, as the various points to be discussed come under considera-
tion. Other members must support the preagreed position. At no time should
the company negotiator be allowed to feel that the Government's position does not
accurately reflect the true feelings of all the team members. A member who
feels he must take issue with the position during formal negotiations should ask
for a recess. and do it in'private.

The GSFC contract negotiator should ascertain from the company negotiator the
e?ctent of his authority to bind the company, a s it is futile to reach agreements
'that will later be set aside,

Negotiation constitutes give and take, consideration of the opposition argument,

and compromise. Where the Government's position is well founded, firmness is

8-20
appropriate and one should not hesitate to break off negotiations when disagreeing
on a key point. When the disagreement concerns a nonessential point, defer the
discussion and proceed to the next point. As the opposing positions move closer,
the points of earlier disagreement usually diminish in significance. In all fair-
ness to the company negotiator, if he inquires he should be advised that if the
amount negotiated exceeds GSFC authority, the amount and other terms will re-
quire ratification by Headquarters authority. .

Occasionally, the agenda for the negotiation is established prior to the confer-
ence when it appears that such a procedure may be necessary to conduct the nec-
essary business within a specified time frame. However, the agenda when estab-
lished is rather general in order that the Government does not divulge its position
with regards to the total matters it may wish to consider. Discussions with con-
tractor personnel should be businesslike, and only one member of the Govern-
ment's team should speak at a time.

Generally, it is appropriate for the contract negotiator to call a prenegotiation

meeting of the GSFC negotiation team to brief the members on the Government's
position, and to inform them in general just how he intends to approach the dis-
cussions with the prospective contractor. If such a prenegotiation meeting has
not been called by two (2) days prior to the scheduled conference, and the Tech-
nical Officer believes that a meeting should be held, he should inform the as-
signed contract negotiator, or the cognizant Procurement Branch Head.

8.5.12 Award

M e r negotiations a r e concluded, the contract must be written in f i n a l form, re-

viewed, and forwarded to the contractor for signature. If the contractor objects
to some portion of the document, negotiations may have to resume. E the Direc-
-tor of Procurement at NASA Headquarters must approve the contract (contracts
-
of $2.5 million o r more and not delegated under the Master Buy Plan see para.
8 . 3 above), changes and further negotiations may still be required. The Head-
quarter's review will take approldmately 15 days. I€ the contractor takes no ex-
ception and Headquarters review is not required, the document will b e distrib-
uted upon signature of the Contracting Officer, usually s h r t l y after. it is re-
turned to the Center.

8.5.13 Source Evaluation Boards

This subject is adequately e.xp1ained in the.following documents: .

a. Source Evaluation Boards, Advisory Committees, Negotiation Teams,
and Consultants (G;M 1152.1C)

. .

8-21
 b. SXSA Source Evaluation Board Manual (NPC-402, .August 2964)

c. GSFC Source Evaluation Board Handbook, July 1971

Because of the sensitive nature of source evaluation in g.eneral, and the applica-
bility of the principles used in formal boards to lesser procurements, the fore-
going documents are suggested reading for the Project Manager.

8.6 POSTCONTRACT STAGE

The postcontract stage of the procurement cycle spans the period from award of
the contract through delivery of the hardware o r services and successful com-
pletion of all related items of work. This period continues until the contractor
is paid in full and the contract file is closed out.

8.6.1 Change Order Procedure

Contract Modification Handbook, GHB 5104.21, Oct. 7 0 , describes the proce-

dure for amending contract specifications to reflect necessary changes in the
technical approach. This handbook defines mandatory, mandatory immediate,
highiy desirable, and optional changes, and tells how to implement each.

8 .G .2 Technical Direction

Technical direction is a means whereby a contractor is instructed to pursue a

particular line of endeavor within the existing scope of the contract. (See "Scope
of Work" in GHB 5104.2A "Contract Modifications Handbook", for a definition of
the t e r m '?scopeff.) If properly used, this procedure will eliminate many con-
tractor claims for so-called "implied changes" (i.e., claims for increased cost
o r time because of inadvertent or informal out-of-scope changes). Because these
claims for adjustment a r e not discovered until after the fact, all direction must
be accomplished in w r i t a m and the contractor must acknowledge that either
(a) the direction is within the current scope and will not entail additional time
and money, or (b) he cannot accept the new work without a formal change order.
In any event, both parties will b o w e'xactly where they stand at all times.
Technical Directions, GMI 5150.5, contains ,@dance for use of this procedure.

8.6.3 Contract 31-gement

The Departmgnt of Defense has established the Defense Contract Administration

Service ( D C M ) with a wide network of field offices to perform various functions
of contract management including quality assurance specialists resident at o r

8-22
 assigned to contractor and supplier plants to perform Government quality
assurance functions. NASA has an agreement with DOD for use of these field
offices, and has established a policy to make m a x i m u use of the contract-
administration services and related field-support capabilities of DOD. It for-
bids the assignment of NASA personnel to a plant site to perform contract-
administration services without justLfication to the Institutional Director and
Director of Procurement. The directive lists the functions to be delegated
and, generally, the functions to be retained (see NASA P R 51-310). Many
agencies become involved in enforcing statutory provisions (e.g., Department
of Labor for compliance with Davis Bacon, Walsh Healy, and Service Contract
Act, the Health and Safety Act of 1970, and the Equal Employment Opportunity
Program).

Other provisions of the contract can be enforced by DOD field offices, which a r e
usually under the Defense Contract Administration Services of the Defense
Supply Agency. A limited number a r e U d e r the Department of A i r F0rc.e and
Navy. A Defense Contract Audit Agency is widely used in gathering negotiation
data and auditing cost-reimbursable contracts and fixed-price contracts which
involve progress payments.

After the award of a contract, the Contract Management Branch of the GSFC
Procurement Division reviews the contract in coordination with the Project
Manager and prepares the necessary letters to DOD field offices delegating
functions which include contract administration, property administration, pro-
duction SweiLlance, quality control, security, health and safety, small business
monitoring, engineering, and audit. It arranges for any necessary post-award
conference with the DOD field offices which is encouraged by NASA and manda-
tory for all contracts over 5 million dollars. It is to the interest of the Project
Manager o r the Technical Officer to participate in such conference.

Contract administration includes purchase system surveys, price analysis, rate

approvals, subcontract approval, monitoring of make-or-purchase procedures,
. and salaries and wage approval.

DOD quality assurance specialists perform in-plant quality assurance functions

in support of projects as assigned by the quality assurance attachment to the
delegation letter. This attachment is prepared at the direction of the Project
Manager by the Quality Engineer assigned to the project. Specific tasks which
may be assigned to the DOD quality assurance specialist include: quality sur-
veys, monitoring of contractor and supplier quality programs and inspection
systems, workmanship inspections, material review board representation,
monitoring of tests, quality status reporting, and acceptance of contract items.

8.- 23
 The Property Administrator monitors the contractor's control of Government
property. A Technical Officer should ship property to the contractor with ap-
propriate documentation to the Property Administrator, in order to ensure that
. it is received under a control system and recorded as Government inventory.
The Property Administrator can be helpful in ensuring proper use of GSFC prop-
erty on the GSFC contract.

I The auditor verifies the contractor's costs and helps to maintain regularity of a
contractor's books of accounts.

DOD staff engineers have proven useful because of their e.qerience with design
drawings and material review boards. When these engineers a r e available in a
plant, advantage can be taken of their talents on the spot and they can save many
project trips.

The Contract Management Branch. has available for consultation, staff counter-
parts for administration of contracts, property, and production surveillance.
The Branch is also the focal point for receiving complaints concerning the per-
formance of DOD activities with respect to GSFC contracts.

8.6.4 Quality Assurance

Three phases of quality assurance (a planned and systematic pattern of actions

necessary for providing adequate confidence in the satisfactory performance of
end items) govern procurement actions, and the Project Manager is responsible
for all three. The initial phase, the quality-engineering function, covers build-
ing quality standards, characteristics, design features, and production proc-
esses into the requirements of the end item. The second phase, quality control,
is the management function of overseeing production of an item to conform to
quality standards. The third phase is the inspection of the end item by exami-
nation and test to determine its conformity to requirements.

4 quality engineer from the Quality Assurance Division will assist the Project
>Imager in the foregoing activities.

8.6.3 Expediting Work Under NASA Prime Contracts &d Subcontracts

Work under NASA contracts can be expedited in various ways: if a subcontractor

fails to deliver a part on time, the Defense Material System Program of Priorities
is sometimes helpful. This will not work, however, if the delay is caused by the

. 8-24
pre-emption of project work by a higher DOD priority. Help may also be ob-
tained through the Defense Contract Administration Service group assigned to
the particular contract (see para. 8.6.3, Contract Management). X limited
e.xpediting capability exists within the Contract Management Branch of the
Procurement Division. Whatever is done, the Project Support Representative
and the Project Negotiator must be aware of the difficulty.

8.6.6 Receiving and Acceptance

This function is handled in several ways. Two points should be emphasized

because of their impact on the successful administration of the contract:

a. First, where acceptance takes place within the project, it should be

done promptly. Completed Receiving and Inspection Reports should be
processed expeditiously in accordance with GMI 4520.1A and returned
to the Property and Supply Branch for distribution.

b. Secondly, the negotiator should be informed if an item is not acceptable

or is accepted under a waiver or deviation. Therefore, familiarize
yourself with the provisions of GMI 4520.1A on the procedure to be
followed in rejecting an item or acceptmg an item which does not meet
the contractual requirements to protect the Government's interests.

If there is any doubt a s to what action should be taken in regard to either a

delinquent o r deficient delivery, contact the Senior Project Ne,aotiator o r Con-
tracting Officer.

Parts, materials, and electrick instruments ordered for project use may be
tested and inspected by the Incoming Inspection Facility managed by GSFC's
Quality Assurance Division.

8.6.7 Invoices and Payment

Timely payment to vendors is an important aspect of contract administration.

Be sure that your project has an active means of controlling its part in the
payment cycle.

8.7 SPECIAL AREAS O F INTEREST

This section includes references to, or discussion of, specialized procurement

topics of particular interest to the Project Nanager.

8-25
 8.7 .I Relationships with Industry

This subject is covered in Standards of Conduct for NASA Employees, NHB

1900. LA, October 1967. A more detailed discussion from a contracting point of
view appears in YASA Procurement Regulation NHB 5100.2, P a r t 1, and the
pamphlet on conduct. A l l Government personnel a r e required to maintain the
highest standards of conduct in connection with dealings on behalf of the Govern-
ment, and must conduct themselves in such a manner to avoid criticism o r dis-
credit to SXSX or the Government. If the Project Office receives any inquiries
from any prospective contractors regarding RFP's or proposed-procurements ,
their inquiries should be diverted to the assigned negotiator. During the course
of evaluation proceedings, whether o r not a Source Evaluation Board is utilized,
XASA personnel participating in any way in evaluating proposals shall not reveal
any information concerning the evaluation under way to anyone who is not also
participating in the same evaluation proceedings.

8.7.2 t'nsolicited Proposals

Procedure for Handling Vnsolicited Proposals Received by GSFC , GHB 5150.2B,

May 1972, sets forth the policy and procedures for handling unsolicited proposals.

8.7.3 Contracts for Nonpersonal Services

When it has been determined that contracting for services is proper and essen-
tial, it is imperative that requirements for either new contracts, or e.xtensions
to eAsting contracts, be initiated at the earliest possible date. A review of the ,

Justification for Nonpersonal Services, the need for a staffing plan, and a Cost
Comparison study, takes considerable processing time. The policy and proce-
dures relating to support service contracts are set forth in NASA Document
NPC 401 and GHB 5150.1,C.

8.7.4 Summary c

This part of the Project 3lanager's Handbook is not the last word on matters of
'
procurement; it merely zssembles information and points out some important
a r e s for consideration. Changes in language, practice, and interpretation a s
a

to what can be done a r e a way of life. If you have a unique procurement prob-
lem, ask procurement personnel to discuss it and assist in the matter.

3-26
 PART 9
FINANCIAL MANAGEMENT
9.1 NASA FUNDING POLICY-DLRECT TO PROJECT

To the maximum extent possible, all charges w i l l be made directly to a research

and development project. This also applies to general purpose equipment if the
initial need for the equipment is to MiLl a research and development requirement.

Salaries and travel e.qenses of Goddard employees, rental of business informa-

tion automatic data processing equipment, and cost of telephones, water, elec-
t r i c , etc., are chargeable to an annual Research and Program Management
(overhead) allotment.

9 2 TECHNICAL A i W BUSINESS RESPONSIBILITY

The Project Manager is responsible for the business mnnn-pement of his project,
including the review, approval, o r disapproval of all dollar, civil senrice and
contractor personal support manpower budgets submitted as part of the Center's
semiannual grass-roots budget call for financing of support of his project. If
the Project Manager disapproves dollar o r manpower budgets for work to be
performed on his project, he must prepare a memorandum to the Division Chief
affected, with copy to the Chief, Financial Management Division (FMD),of all
revisions made to the budgets. Changes to the grass-roots budgets will not be
made without such memoranda. The Chief, FMD,will be responsible for deter-
mining whether the affected Division Chief concurs in the change. If the Division
Chief does not concur, then the Chief, FMD, is responsible for bringing the
problem to the attention of the appropriate Directors of-. Any problems they
cannot resolve will be brought to the attention of the Director.

9.3 PROJECT APPROVAL DOCUMEiW (PAD)

A PAD is written authorization, signed by the Deputy Administrator. This dacu-

ment is submitted annually by the Associate Administrator to cover on-going
activity and authorizes NASA Centers to apply resources to new projects after
appr'oval by the Deputy AMrninistrator. This document in summary form covers
specific project objectives, technical plans, major support interfaces, procure-
ments, launch schedules, resources, management, and ?USA Headquarter's
controlled items.

9-1
The PAD summarizes the results of previous flight missions apd mission objec-
tives for spacecraft to be launched. It also specifies the Center responsible for
project management, the number of spacecraft, the type of booster, and the cur- '

rent approved plan for dollars and manpower.

9.4 RESOURCES AUTHORITY WARRANT (Form 506)

The resources authority warrant is the official dollar authorization to the field
center by individual projects, which allows the Financial Management Division
to certify that funds a r e available at the Center for project requirements. After .
the Financial Management Division has certified funds, the Procurement Division,
Experimental Fabrication and Engineering Division, and Management Seflices
and Supply Division, are authorized to contractually obligate the United States
Government for materials and services ordered by the project.

In essence, a Form 506 represents a deposit to a job order which allows com-
mitment and obligation of Government funds.

9.5 SUBAUTHORIZATIONS

The subauthorization is the official document with which NASA field centers
finance services requested by one field Center of another NASA Center. A sub-
authorization transfers Form 506 and allotment dollars to the Center for the
services requested. Because it is NASA policy that work cannot begin without a
Form 506, the NASA Center, from which services a r e requested, must receive
a subauthorization before beginning the effort.

The NASA Center receiving the subauthorization is responsible for funds control
and reporting for the services rendered. However, the policy of Headquarters
is that the Center with project management responsibility for a project must ~

budget for the total project in its Project Operating Plan.

9.6 REIXBURSABLE'S

Reimbursable effort is defined a s work performed for any Government o r field

center, other than NASA. tt'ork cannot commence until NASA Headquarters
issues a resources authority warrant, Form 506 (reimbursable). Xormally ,
other Government agencies request GSFC services by purchase order o r con-
tractual agreements. Lf GSFC agrees to the request, Headquarters is requested

9-2
to issue the Form 506 authoSity and allotment authorization. Upon receipt of
these, procurement requests may be initiated subject to Financial Management
Division certification that funds a r e available. GSFC cannot subauthorize any
portion of a resource authorization received for a reimbursable order.

The Project Manager is responsible for assuring that all expense attributed to
reimbursable effort is charged to the resources authority warrant. This includes
a l l costs for purchases for material o r services, Civil Service manpower
travel, facility usage and overhead expenses when applicable.

9.6.1 Trust Funds

Trust fund agreements a r e cooperative agreements between NASA and foreign

entities for procurement o r furnishing by NASA of materials and services which
are funded by deposits to trust fund accounts. Trust fund deposits a r e fiscal
resources held by the Federal Government for the benefit of specific individuals
o r classes of individuals a s distinguished from the genera3 public, In admin-
istering these resources, the Government acts as a trustee and is limited in the
capacity to the actions authorized by the specific trust agreement.

9.7 BUDGET' DEVELOPMENT AND REVIEW

9.7.1 Budget Structure

NASA has one of the simplest appropriati'on (budget) structures in the Federal
Government in that NASA uses only three appropriation titles as contrasted with
other agencies which have as many a s 70 appropriation titles. The three NASA
appropriation accounts are Research and Development, Construction of Facilities,
and Research and Program Management.

a. The Research and Development Appropriation finances the purchase of

materials, contractual services, R&D transportation costs, equipment,
test and evaluation, and technical information support required in direct
support of flight projects, basic research, and operations of the tracking
netwarks. This-appropriation is not limited by Congressional action a s
to life duration, i.e., funds a r e available until e.xpended. However, NASA
has the option of establishing e-xpiration dates for field centers' use of
these funds.

b. The Construction of Facilities Appropriation finances the design, con-

struction, purchase of equipment, modernization of facilities, and advance
design of facilities planned f o r future authorizations. All construction

9-3
 involving new structures wherein the costs exceed Sl0,OOO and modifica-
tions to existing structures costing in excess of 525,000 a r e financed by
this appropriation. C of F funds a r e not limited by Congressional action
as to life duration. However, NASA has the option of establishing ex-
piration dates for field centers' use of these funds.

c. The Research and Program Management Appropriation finances the

personnel-related cost of NASA such as salaries, overtime, travel,
trsnsportat ion, rentals of equipment , administrative communications,
utiiities, printing, and other housekeeping operations not specifically
associated with 8 direct research project. This appropriation is an
annual appropriation, i.e., authority to obligate these funds automatically
terminates on June 30 and any residual funds are lost to Lux.%.

9.7.2 Budget Cycle

Headquarters requires field installations to submit semiannual POP'S in a format

prescribed by the Institutional Director. Goddard utilizes the "grass-rootsff
concept of budgeting which may be defined as a process in which all levels of
management a r e given an opportunity to make known manpower and funding re-
quirements considered necessary to continue functional support u d approved
research projects. Further, it affords each level of management an opportunity
to propose new effort which should be initiated and the part in which they wish to
participate. The major milestones involved in the budget cycle a r e shown in the
milestone schedule (Figure 9-1). A s shown on the milestone schedule, the timing
for preparation of the tfgrass-rootsfcbudget and submission of updated POP'S
may be related to the following requirements:

POP Submission to
NASA Headquarters Requirement

July 30 Initial grass roots estimates for inclusion in the

budget submission to Congress for the ne.xt fiscal
year and updates the current fiscal year.

February 15 ' Budget update of Congressional submission for

next fiscal year and approval of the revisions
for the second half of the current fiscal year.
Additionally, a preliminary look at subsequent
FY requirements if provided.

The Government's fiscal year is the 12-month period from July 1 to June 30.

9-4
 ul
Q ) '
c
0
e
ul
Q)

5
Q)
c
.-
e
4)
Q)
9
a
m
b

;
0
a
c
s
c
0;
2a
.-
Q)

i
a
I I
9-5
9.7.3 Budget Estimating- Dollars

A very critical element in the budget process is the problem associated with the
initial estimates of the total cost of a new project and the time-phasing of resource
requirements by fiscal year. There a r e various types of data available for use in
estimating the costs of new projects. Cost data a r e available for completed and
on-going projects, and actual costs for similar systems o r subsystems may be
used for costing purposes. Estimates may also be prepared based on projections
of contractor manpower required to design, fabricate, and test the spacecraft,
experiments, and associated ground support equipment. A very useful tool in the
pricing of new projects is the technique of "cost modeling."

Briefly, the "cost models" represent a mathematical technique, which relates

technical o r engineering parameters to systems, subsystems, and total project
cost. Through the careful selecting of parameters which can be identified in the
early stages of program development (i.e., number of watts of power used, weight
of the data handling and communications subsystem, etc.) and by utilizing regres-
sion analysis, it is possible to measure the relationship bebveen cost and such
factors as complexity, size, and quantity. Occasionally, the models a r e developed
from limited data bases and may reflect. a certain management philosophy o r
mode of operation. In those cases where deviations a r e apparent, adjustments
are made to the total estimated cost..

Once the total project cost has been established, spending profiles a r e prepared
which relate program s t a r t and length to fiscal year funding requirements. A
typical funding profile is a function of the total project length in that the percent-
age of contractor spending in any given year will vary when the length of the
project is either extended o r shortened.

Through the utilization of available cost data and sophisticated estimating tech-
niques, the reliability of cost estimates f o r new projects is improving.

For on-going projects, the contractor's monthly financial management reports

should be consulted and evaluated in assessing future R&D budget requirements.
The financial management reports provide forecast .costs on work covered con-
tractually, but the cost of future work not under contract must be estimated, on
a lesser scale, much the same way that effort is assessed for new projects.

It should be noted here that budgets a r e to be prepared, to the e-xtent practicable,

on an "accrued-cost" basis. That is, the increment of funding requested each
fiscal year for cost reimbursable contracts is limited to the funds required to
cover estimated costs for materials actually consumed o r services rendered to
accomplish contractual work for the fiscal year. This approach allows incremental

. 9-6
funding of contracts each fiscal year a s opposed to fully funding cost reimbursable
contracts at the total negotiated value at the time of award.

An Allowance for Program Adjustment (APA) (a s u m reserved to meet unfore-

seen cost growth) is to be established for each major flight project. The amount
of reserve will involve the individual circumstances of each project and will
consider such things a s schedule s b t u s , technical difficulty, etc.

Proposed new-start projects should also consider cost growth factors such a s
labor union agreements and their impact on labor costs. This is important be-
cause development, fabrication, and flight operations involve several years and
we do not have contractor proposals which anticipate these factors for estimating
and pricing purposes,

The Office of Manpower and Budget (OMB) prescribes that five-year estimates
should be based on projections of cost (in constant dollars at prices existing at
the time estimates a r e prepared) which (1)a r e not intended to predict future
economic conditions, and (2) do not reflect possible changes in the scope of
quality of the program which might result from experience gained in actual
practice.

Notwithstanding these instructions, GSFC is conducting a study to determine what

impact cost inflationary factors have had on h e cost of several'of our major
flight projects. Supplementary guidelines on this item will be provided at a later
time.

9.7.4 iManpower

GSFC takes a modified ffgrass-rootsf'approach to the development of manpower

POP'S. First, manpower data a r e collected on a requirements basis. This is
accomplished by the line organization developing a requirements plan for the
on-going commit-ments. The line organization, the so-called g r a s s roots of the
organization, develops a requirements plan for the on-going commitments.
These inputs a r e then iterated and reviewed through the line management, then
by the project people in the Center who a r e responsible f o r the project being
supported to be sure that the line organization fully understands the task for
which it is responsible and to eliminate double budgeting and the like. Out.of'
this comes a set of "requirements." Center management then goes through a
decision making cycle after these data a r e collected and understood where the
requirements a r e balanced against the constraints the Center has placed upon it,
programmatic limitations, R&PM dollars, Center ceiling, etc: From this process
attempt is now made to balance the risk of cutting any of this'requirement down
and try to make judgments on whether these cuts represent "acceptablerf risks.

9-7
The manpower POP generally follows this decision cycle and normally comes
out in August. 'The basic plan is put together once a year, through the line
organization, and is documented in a Program Operating Plan and is updated at
least on 6 month centers. Individual project agreements a r e documented by
Memorandum of Agreement (see para. 2.6.3).

9.7.5 Level of Detail

As stated above, the grass roots budget estimates a r e generally prepared at the
second level of line management,. the branches. The branches submit individual
"j&-order:' estimates for the various projects, and the total of all applicable
job-order estimates becomes the total project budget. The individual job-order
estimates for the R&D budget must be submitted in considerable detail; in fact,
each procurement costing $15,000 o r more must be described and the month the
commitment and obligation of funds a r e expected must be stated. The detail
required is as follows:

(a.) Technical description of job order

(b.) Routine materials
(c.) Technical information support services
(d.) Transportat ion
(e.) Fabrication services
(f .) Contract support services on-site
(g.) Contract support services off-site
(h.) Major procurements
(i ,) Automatic data processing equipment purchase
( j .) Civil service manpower requirements
(k.) Technical Representative name and telephone number
(1.) Business Representative name and telephone number

All job order budget items a r e also assigned job order numbers. The Center's
job order structure is basically the same a s the standard NASA system.

9.7.6 3Ianagement Reviews

The job order budget reviews 2re very extensive with the following levels of
Center management involved in the review cycle:

9- 8
 .0 Budget Office
0 F i r s t Level Line iManagement
0 Project Managers
0 Directors of -
0 Director

Upon completion of management reviews, the job order budgets a r e incorporated

into the prescribed POP format and Budget h a l y s t s coordinate the Center sub-
mission of the P O P with NASA Headquarters. It is emphasized that the budget
submission covers the entire life of each project, and is detailed a s to spacecraft,
. experiments, and ground operations and that ail estimates of major procurements
a r e time-phased and that all contracts having expenditure projections of
$1,000,000 o r more during the fiscal period a r e included in the budget submission
(POP) as separate line items.

9.8 PROGRAM OPERATIXG PLANS

The Program Operating Plan (POP) is the key to the budget system. Prior to
formal implementation, each project must have a financial and Performance Plan
o r Project Plan which covers the entire life of the project. The formal device
for initiating and updating resource and funding requirements, and against which,
progress and status i s compared, i s the POP. The POP'S a r e time-phased
budgets which are updated twice annually and show detailed 5-year forecasts of
funding requirements for each project.

The objectives of the POP system a r e generally to provide NASA management

with a basis to:

a. Prepare agency estimates for various phases of the budget formulation

and execution process.

b. Issue resource authorizations and allotments.

c. Evaluate financial performance and status against planned rates of

operating activity.

The value of the POP system is also to standardize the submission f r o m

the various NASA field installations of basic financial resource planning
data for each of the three NASA appropriations'discussed.

9-9
9.8.1 Program OfEices' Use 6f POP'S
The Program Office reviews the POP'S to ascertain progress, workload, adher-
ence to schedules, and ability to provide the requested funds to the projects. The
POP is then consolidated with POP'S of other centers which perform work for
the same Program Office. The consolidated POP becomes the Program Office's
official budget request to the Administrator.

9.8.2 Administrator's Use of POP'S

The Administrator uses the information contained in the POP'S to:

a. Approve budgets of Program Offices for the current year.

b. Grant Program Office the program authority (funding) for executing its
POP.

C. Request funding authority from the Office of Management and Budget (OSIB);
this funding represents aportion of the previously approved NASA budget.

d. Review the budget for the ne.* fiscal year with the OMB.

e. Evaluate performance of Program Offices by comparing actual commit-

ments and obligations with those stated in the P O P to determine if full
funding of the Program Office is required. Conversely, the Program
Offices use this technique on their field centers and the field centers
use it on their project managers and procurement staf€s.

9.9 CONTINUNG RESOLbTION

A continuing resolution is an agreement passed by both the Senate and the House
of Representatives allowing Federal agencies to continue in operation beyond
June 30. This resolution is required when the appropriation act has not been
passed and funds a r e not legally available to finance Government operations.
For example, most appropriations for the .salaries of Government perscnnel
e-qire each June 30; an appropriation o r continuing resolution provides for
personnel salaries beyond that date.

Vnder a continuing resolution, all activities authorized on June 30 can continue

in operation. Nothing new can be started until Congress acts and the President
signs the NASA appropriation.

9-10
9.10 GSFC'S JOB-ORDER STRUCTURE

GSFC's job-order structure is basically the NASA-wide coding structure. The

only difference is that GSFC uses the 3-digit organization code (division and
branch) a s a prefix to the NASA system, and uses digits 9 and 10 to further
detail the subsystems.

GSFC's job-order structure for ART/SRT is identical to the Headquarter's

system, except for the use of digits 1 through 3, responsible division and branch.
For example:

71 2 831 21 75 03
I I I I I I
Responsible division
I I I
I I I I I
(spacecraft technology) I I I I
I I
I I I
Branch (spacecraft electronics) I I I I
I I I
Unique project (OAO) I I
I I ' '
I
I I
System (spacecraft) I
I I
Subsystem (spacecraft support) I I
I
Serial number I

9.11 APPROVAL LEVELS FOE PROCUREMENT REQUEST

AND INTERNAL REPROGRAiMMINGS

Procurement. requests and internal reprogrammings within a project may be

approved at the following levels:

Branch Heads Under $25,000 .OO

Division Chiefs/Project Managers $25,000.00 to $100,000.00
Directors of - $100,000.00 to $1,000,000.00
Director/Deputy Director/ $1,000,000.00 and over
Associate Director

9.12 REPROGRAiMM.IXG (ELUTERXAL-HEADQUARTERS)

Project -Managers cannot reprogram funds between projects (i.e., OAO versus
-
_.
Om).

9-11
 A l l reprogrammings between projects, regardless of dollar amount, can be ap-
proved only by the Headquarters Program Office on the basis of a written request
from the Center Director,

9.13 COMMITMENTS

Commitments are firm administrative reservations of funds based on firm

requisitions, procurement requests, authorizations to execute contracts, or' other
authorized evidence which authorizes the creation of obligations without further
recourse to the o f f i c d responsible for certrfying that funds a r e available.

GSFC's commitment policy is as follows:

a. Commitments shall not be incurred in excess of available program

authority. To ensure that funds a r e available, all commitment trans-
actions must be submitted to the Financial Management Division
(Accounting Branch) for funds certification before submission to the
Procurement Division.

b. Commitments shall be recorded promptly against allotments, sub-

authorizations, o r other subdivision of funds.

c. Availability of funds shall be determined before a commitment is

incurred.

d. Commitment accounts and documents shall be maintained in the

Accounting Branch of the Financial Management Division.

9.14 OB LIGATIONS

In general, obligations a r e incurred when orders a r e placed, contracts a r e

awarded, o r services a r e received which require disbursement of money.

9.15 ACCRUED COST

I
Accruals a r e total costs incurred by contractors for services rendered o r
I
materials delivered in support of a contract. Accruals do not include purchase
orders issued by a contractor for se-rvices o r materials that he has not received.
I
9- 12
,

9.16 LTCOSTED OBLIGATIONS (FORWARD FUNDING)

The difference between the total funded value of a contract and the actual accruals
under that contract is referred to a s uncosted obligation.

9.17 ENCUMBERED FUNDS

-
Encumbered funds a r e the s u m of the following elements:

a. That portion of total project funds presently offset by bonafide disburse-

ments, vouchers for disbursements, a n d o r accrued costs.

b. Funds which have been transferred to another Government entity and

may not be withdrawn or reduced by the unilateral action of the Project
Manager.

C. Obligations to fixed-price prime contracts or fixed-price subcontracts

expected to be accrued o r disbursed within the reported year.

d. Those funds that a r e directed by C'enter management and may not be

reduced or withdrawn except by appeal to Center mamgement, such as
T&E and computer-operation prorate charges.

9.18 DISBURSEMENTS

A disbursement is the actual issuance of a check by the U. S. Treasury for pay-

ment of services rendered o r material received. Accrued costs under a contract
always exceed disbursement until final payment is made.

9.19 TEST AND EVALUATION DIVISION AND QUALITY ASSURANCE

DNZSION FUNDING

It is Goddard policy that the cost of operating the Center's Test and Evaluation
(T&E)and Quality Assurance (QA) Dhisions will be borne by the research and
development program.

The, annual operating budgets a r e initiated by these divisions on the basis of

projected requirements. The budgets are reviewed at a Director's staff meeting
with all Directors of -
present and a r e approved by the Office of the Director.
Test and Evaluation manpower planned f o r each project is based on known re-
quirements and past e.uperience, and is reviewed by each Project Manager.

9-13
. --
Each project bears the same percentage of the total T&E annual operating budget
as the percentage its planned manpower is of the total manpower available in
each division for direct flight-program support. Each project bears the same
percentage of the total QA annual operating budget a s the percentage of their
budget dollars in relation to the total R&D budget dollars.

After Center management approves the annual operating budget and the Project
Manager agrees to the manpower assignment, a fixed project cost is established
which cannot be changed. As they become available through Form 506 authority,
these funds a r e used to establish an R&D c a r r i e r account which is e'xpended a s
needed by the T&E and QA Divisions in accordance with the approved plan. .

This funding process does not include the cost of major procurements by T&E
and QA Divisions for unique requirements of a project. Each Division determines
these needs and negotiates f o r funds directly with the Project Manager. When
approved, the funds a r e identified a s a separate line-item entry in the project's
operating budget.

9.20 SPACE AND EARTH SCIENCES (SES) DIRECTOFUTE

COMPUTER FUNDING

GSFC policy dictates that the cost of operating SES computers at GSFC be borne
by the several R&D flight projects. Costs will be shared by the Physics and
Astronomy and Space Applications Projects a s well a s the Delta Project.

Items covered under SES computer support are:

a. Supplies - Paper, cards, cabinets, pool magnetic tapes, etc.

b. -
Operations Computer operators, keypunch operators, tape librarian,
plotter operators, EAM operators, and dispatchers.

c. Systems programming - Maintenance and enhancement of the software

operating system and general-purpose library subroutines.

d. Machine maintenance

Project-peculiar computer support (e .g., special programming) will continue to

be budgeted under the project. Certain rentals of the SES computers a r e funded
from Research and Program Management funds. The Goddard Institute for
Space Studies (GISS) computer activities (including rentals) are funded from
R&D funds separately. They are not included in the policy stated above. The

9- 14
 contribution of each project is based on the percentage of its total individual
budget to the total budget of each program area.

After Center management approves the total dollars required, the budget SES
'
computer support becomes a fixed assessment to the project. The Office of the
Director of SES manages the computer program.

9.21 FABRICATION CHARGES

To order services from the Experimental Fabrication and Engineering Division,

the originator completes a work order and forwards it to the Fabrication Division.
Estimates of the hours a task will require a r e made; the hourly rate is applied
to determine the cost. The Fabrication Division then forwards the request
(work load record form) including dollar estimates to the Financial Management
Division (Accounting Branch) for funds certification. If funds a r e available under
the cited job order and Form 506, the Financial Management Division agent w i l l
certify that funds a r e available and will return the work load record form to the
Fabrication Division. If funds a r e not available, the workload record form w d l
be returned to the originator.

Under no circumstances may the Fabrication Division perform work without a

certification that funds a r e available for reimbursing the Fabrication Division.

9.22 PROJECT JOB ORDER STATUS REPORTS

The Financial Management Dvision through the Business Data Branch provides
the Project Manager with various reports that reflects both budgetary and actual
commitment, obligation, disbursement, and accrued cost experience. These
reports &e listed in the GSFC Machine Reporting Register, published periodically
by the Business Data Branch of the Program Support Division. Copies a r e
available by request.

These reports reflect the official accounting records for GSFC at a particular
time and may be used for reports o r statistical data.

9- 15

. --
 APPENDIX A

FUNCTIONS AND AUTHORITIES OF

PROGRAM MANAGERS AND PROJECT MANAGERS
03 OFFICE OF SPACE SCIENCE AND
APPLICATIONS FLIGHT PROGRAMS

A-1
 APPENDIX A

FUNCTIONS AND AUTHORITIES O F PROGRAM MANAGERS

Aim. PROJECT ,M..4NAGERS
ON OFFICE O F SPACE SCIENCE AND
APPLICATIONS FLIGHT PROGRAMS

Project Managers a r e the senior NASA line officials exclusively responsible

for the execution of their projects within Headquarters and Center prescribed
,g.idelines and controls. Program. Managers a r e the senior NASA staff officials
exclusively responsible for developing and administering the Headquarter's
guidelines and controls.

Program Managers

1. The Program Manager is the senior NASA Headquarters staff official ex-
clusively concerned with the projects which compose his program.

2. The 'Program Manager is responsible for assuring the effective overall

generd management of his program. He is the focal point of all NASA
Headquarter's activity bearing directly on those projects which compose
his program. He is responsible for developing and administering the Head-
quarters guidelines and controls under which those projects are conducted.
He will carry out these responsibilities within his delegated authority.

3. The Program Manager's specific functions include, but are not limited to
the following:

a. Developing and/or updating, in collaboration with other participants,

an overall plan for implementation of his program, including:

(1)Objectives
(2) Missions
' (3) System concept
(4) Experiments
( 5 ) Schedules
(6) Funding
(7) Manpower
(8) Organization

A-3
 (9) Procurement arrangements
(10) Interfaces among centers, agencies, ercperimenters, and contractors
(11)Facilities
(12)Reporting and review
(13) Controls

b. Preparation of @e necessary m t e r i a l to represent the program to

NASA management, and making such representations as appropriate.
C. Budgeting for the program.
d. Reviewing'and concurring on the Project Plans prior to approval and
release to t h e executing centers.
e. Reviewing, assessing, and reporting of the effectiveness of the Center's
execution of the project, including management of contractors.
f. Administering OSSA guidelines and controls for the project, including
evaluation of proposed changes in confi,o;uration, contracts, costs,
schedules, objectives, performance, mission profiles, etc., and pre-
paring necessary Headquarters actions.
Identifying and defining solutions or alternate courses of action, when
major problems arise in the course of the program.
Developing a close working relationship with Center management offi-
cials, especially the Project iManager. Auditirg the Center's assessment
of project activity to maintain a real-time "feelfff o r the project opera-
tions and f o r the state of health of the project.
I
i. Assisting Center management in every way possible to facilitate their
execution of the project. Expediting Headquarter's actions in support
of the project.
j. Preparing, with Center support a s required, all staff papers required
in Headquarters in support of thg program, including:

(I) Project proposals

r

(2) Project approval documents

(3) Briefing memoranda
(4) Program management reports (after analysis of project management
reports from the centers)
.-
(5) Correspondence and directives
. -
c

. -
/
A-4
L
 (6) Congressional backup statements
(7) Budget material
(8) Mission status reports
(9) Other

k. Taking whatever additional initiative he deems necessary, within

organizational structure and guidelines, to ensure the successful com-
pletion of his program. .

Project Managers

1. The Project Manager is the senior NASA line official exclusively concerned
with the execution of his project.

2. The Project Manager i s responsible €or the effective day-to-day manage-

ment of his project. He is the focal point of all Center and field activity
bearing directly on his project. He is responsible for directing the execu-
tion of his project within guidelFes and controls established by NASA
Headquarters and his Center maqagement. He will c a r r y out these respon-
sibilities within his delegated authority and otherwise in the name of the
Center Assistant Director for Projects or the Center Director.

3. The Project Manager's specific functions include, but a r e not limited to,
the following:

a. Developing and/or updating the Project Plan, which specifies the plans
for execution of all elements of the project, including:

(1)Objectives
(2) Technical plan, including systems concepts
(3) Reliability and qualie assurance provisions
(4) Management plan
(5) Bianagement report&
(6) Documentation management
(7) Procurement arrangements
(8) Configuration and change control
(9) Schedules

A-5
 (10) Resource requirements
(11)Coordinated operations plan
(12)Experiment integration
(13) Data handling
(14) Facilities

b. Executing this plan in adherence to its provisions.

(1) Coordinating the activities of all elements of the project to ensure

effective performance in the execution of their responsibilities.

c. Organizing and supervising his Center Project Office which directs the
execution of this plan.

(1) Training the members of his organization

d. Directing and/or coordinating as applicable, the supporting elements

within his Center and other Centers which support the project, including:

Design, fabrication, test, and operation of in-house hardware

(2) Tracking and data system
(3) Launch vehicle system
(4) Launch operations
.(5) Other

e. Directing and/or coordinating, as applicable, supporting activities

within other agencies of the Federal Government.
f. Directing contractor effort on his project, (through Contracting Officer
if required): -
(1) Directly for those contractors where his project holds the contract
(2) Indirectly, as necessary, for the contractors of supporting organi-
zations

g
-. Preparation and dissemination of working agreements.
h. Establishment of working groups and coordination committees. Suy-
porting design review groups and fiiilure analysis groups, established
by Center and Headquarters, etc., as required.
/

. -
A-6
I. c
i. Preparation of specifications.
j. Review of changes and approval within his authority.
k. Preparation of necessary documentation in support of his project.
1. Providing other necessary support to Center management.
m. Keeping Center management and the Headquarter's Program Manager
fully apprised of the status of his project, particularly with regard to
adherence to:

(1) Schedules
(2) Funding -
(3) Performance

n. Preparation of accurate and complete Project Management Reports.

0. Maintaining a close working relationship with the Headquarters Program
Manager for his project.
p. Identifymg, devising, and executing effective solutions to management
and technical problems which arise during the course of his project.
q. Seeking the assistance of higher management authority in a timely
manner when necessary to achieve the objectives of the project.
r. Taking whatever additional initiative he deems necessary, within
organizational structure and guidelines, to assure the successful com-
pletion of his project.

A-7
 APPENDIX B

GENERALIZED PROJECT ORGA3IZATION

B-1
 APPENDIX B

GENERALI 2ED PROJE C T ORGANIZATION

PROJECT MANAGER

DEPUTY/OR
SCIENTIST ASSIST.
PROJECT MANAGER
1 I I

PROJECT PROJECT SYSTEMS

COORDlNATOR ENGINEER
b .
CONFIGURATION 8
DOCUMENTATION
OFFICER
------
i ADMl NlSTRATlV E
SUPPORT
(CODE 200)

i
-- -
SYSTEMS RELIABILITY
SUPPORT
I - - - - - - (CODE 300)

EXPERIMENT MISSION
SPACECRAFT
*
OR SYSTEM OPERATIONS
SENSOR SYSTEM MANAGER SYSTEMS
MANAGER MANAGER

f I MISSION NET’NO R K
SUP PORT
MANAGER MANAGER
(CODE 500) (CODE 800)
SUBSYSTEM
EXPERIMENT SUPPORT I 1
COO RDINA TO RS (CODE 700)

B-3
 APPEiVDIX C

OUTLINE OF MODEL SYSTEMS SAFETY PLAN

c-1
.

CONTENTS

Page

1.0 GENERAL ................................................... C-5

1.1 Introduction ........................................... C-5

1.2 Scope and Purpose ..................................... C-5
1.3 ............................................
Definitions C-5
1.4 Application and Implementation .......................... C-6
1.5 Applicable Documents .................................. C-6

2.0 SAFETY ORGAiWZATION AND RESPONSIBILITIES ............ C-7

2. 1 GSFC Organization and Responsibilities .................. C-7

2.2 Contractor Organization and Responsibilities .............. C-8

3.0 SAFETY PROGRAM REQUIREMENTS......................... C-8

3.1 Safety Plans ........................................... C-8

3.2 Safety Criteria and Precedence .......................... .C -8
3.3 System Safety Analysis Tasks ........................... C-8

3.3.1 Preliminary Analysis ............................ C-8

3.3.2 Detailed Analyses ............................... C-9
3.3.3 Operating Analyses .............................. C-10

3.4 Industrial and Public Safety ............................. C-10

3.5 DesignReview ......................................... C-10

4.0 SYSTErMS SAFETY MONITORING AND CONTROL ............. C-10

*

4.1 Safety Program Schedule................................ C-IO

4.2 Mishap Reporting ...................................... C-10
4;3 Safety Monitoring ...................................... C-11
4:4 Safety Audits .......................................... C-11
4.5 Waiver Procedures ..................................... C-11
4.6 Reporting and Documentation ............................ C-11

ATTACHSIEKT I .HAZARD LEVEL CATEGORIES ................. c-12

ATTACHMENT I1 .SYSTEMS SAFETY PRECEDENCE ............. C-13

c-3
.

APPENDIX C

OUTLINE OF MODEL SYSTEMS SAFETY PIAPT

1.0 GENERAL

1.1 Introduction

Identify the project and state the mission to which the Systems Safety Plan
applies. Describe briefly the spacecraft, its payload, and the ground system
involved. Identify the launch vehicle and the launch facility to be employed. .

1.2 Scope and Purpose

State the major systems, subsystems, experiments, facilities, ground equip-

ment, and operations to be included in the Safety Plans. Indicate the partici-
pation by other NASA centers, Government agencies, and whether contractors
and subcontractors will be involved, Conclude with "the purpose of this
plan is to provide in a si@e document the total Project Safety
Program requirements and to show the agency, center, and contractor re-
sponsibilities for implementation of these requirements. f'

. 1.3 Definitions

Under this paragraph define the safety team used in the plan. Examples a r e
given below. Of particular interest is definition of "systems safety" to be
used by the Projects Directorate, GSFC. This definition clearly differen-
tiates between extrinsic factors which subject flight hardware to hazards,
and intrinsic factors resulting in component o r subsystem malfunction. The
latter one to be considered a design, reliability a n d o r quality responsibilities
rather than safety responsibilities.

Recommended safety terminology:

a. Safety -
Freedom from chance of. injury o r loss to personnel, equip-
ment, or property.
b. -
System safety Systems safety is defined a s those engineering and man-
agement practices and procedures necessary to avoid personnel injury
and property loss to the maximum extent practical. Systems safety in-
cludes the protection through launch of flight hardware from loss o r
damage from e.utrinsic factors, but does not include property loss or

c-5
 .

damage to flight hardware due to internal component malfunctioning.

The latter is considered a design, reliability, a n d o r quality responsi-
bility.
C. Accident prevention -
Methods and procedures used to eliminate the
causes which lead, o r could lead, to an accident.
d. Hazard - The presence of a potential risk situation caused by an unsafe
act o r condition.
e. Risk - The chance of injury o r loss to personnel, equipment, o r property.
-
f. Major damage - damage to equipment which results in major system
degradation o r loss.
g* Major system degradation - A condition which results in one o r more
of the following:

(1) Jeopardized achievement of an operation o r performance of a mis-

sion; or delay beyond acceptable time limits.
(2) Inadvertent system activation.

1.4 Application and Implementation

State to whom the plan i s applicable and that this plan represents the safety
requirements planned for inclusion in contract work statements and System
Safety Plans from other Government organizations and contractors for
Project X. The planned implementation for each phase of the project may
, be outlined here.
~

1.5 Applicable Documents

List applicable NASA documents, project, and program documents and make
a statement of their applicability. Reference documents may be listed here
o r in an appendix.

Examples are:

a. Applicable Documents -
The following documents, of the latest approved
issue, form a part of this specification to the e-xtent described herein.

' b. Program Documents

Project Configuration ;LIanagement Plan

_ . C-6
 c. NASA Documents
NHB 1700.1, Vol. I NASA Safety Manual, Basic Safety Requirements.
- NHB 1700.1, Vol. III - System Safety
- NMI 7100.4 Authorization and Control of Research and Development
Programs,Projects, other Activities, and Sources Related thereto. '

d. Air Force Documents

AFETRM - 127 - 1 Range Safety Manual, Vol.I, A i r Force Eastern
Test Range Manual, January 1, 1969

e. . U.S. Army Documents

- WSMR Range Users Handbook dated 1May 1967 and Iievision I
dated 1 December 1967

f. Reference Documents
A list of reference documents is contained in Appendix A.

2.0 SAFETY ORGANIZATION AND RESPONSIBILITIES

In this section of the plan, describe the safety organizations and the respon-
sibilities for the GSFC project and associated contractors, the launch vehicle
project, the range, and other activities when involved. U s e organizational
charts where appropriate and identify personnel where possible.

2.1 CSFC Organization and Responsibilities

The Project Safety OBicer should be named, his position in the project
organization delineated, and his responsibility as the overall systems safety
focal point established.

The assignment of responsibilities to the other NASA installations for the

launch. vehicle &d.launch s i t e (range) safety programs should be specified.

The responsibilities of GSFC experimenters f o r in-house developed hardware

should be covered.

The relationship to the GSFC Health and Safety Engineering Office should be
established concerning the Industrial Safety responsibilities under Clause 86
of NASA PR 1.5204.

c-7
 .

2.2 Contractor Organization and Responsibilities

This section of the Safety Plan should include a chart of the prime contrac-
tors organization showing the relationship of the systems safety function.
The safety responsibilities of the prime contractor at all sites should be
stated. Indicate the prime contractor's responsibility for implementing
safety requirements on critical subcontracts.

Also include the safety provisions to be applied to institutional and industrial

e-xperimenters under prime contract to GSFC for the development and de-
livery of flight hardware.

3.0 SAFETY PROGRAM REQUIREMENTS

3.1 Safety Plans

Note other organizations such a s the prime contractors, critical subcontrac-

tors, NASA Centers, the range, etc., which will be responsible for developing
and implementing safety plans in support of the Project Safety Plan. Describe
the format to which the plans will be submitted. The plans should reflect the
requirements of paragraphs 3.2 through 3.5 below.

3.2 Safety Criteria and Precedence

Hazard categories and the precedence for reducing o r eliminating hazards

a r e illustrated in Appendix I and II. The Project Safety Officer should con-
sider modification of these general concepts to develop guidelines particu-
larly applicable to his project.

3.3 Systems Safety Analysis Tasks

This section should clearly establish the scope of the safety analysis to be
performed under the Systems Safety definition provided in 1.3-h above.
Consideration should be given to methodical examination and review of hard-
ware designs, test plans and procedures', and operating practices for the
purpose of identifying and controlling'hazards. '

3.3.1 Preliminary Analyses

I
I

Preliminary analyses should be conducted early in the program to

provide a comprehensive, qualitative analysis of the s y s t e d s u b s y s t e d
equipment in its intended operating environment for detecting and defining
 its potential hazards. Such information should be used in the develop-
ment of safety criteria to be included in the performance/design
specification. Consideration should be given to at least the following
areas:

a. Isolation of energy sources.

b. Fuels and propellants: characteristics, hazard levels and quality/
distance constraints; handling, storage, and transportation safety
features; compatibility factors, etc.
c . Proposed system environmental constraints.
d. Use of explosive devices and their hazard constraints.
e. Compatibility of materials.
f. Effect of transient current, electromagnetic radiation, and ionizing
radiation. Design of controls to prevent inadvertent activation of
.
initiation circuits
g. Use of pressure vessels and associated piping.
h. Documentation f o r safe operation and maintenance of the system.
i, Training and certification pertaining to safe operation and main-
tenance of the system..
j. Fire sources and protection.
k. Equipment layout and lighting requirements and their safety im-
plications in manual system.
1. Nuclear and isotope power sources o r experiments.
m. System interactions.
n. Long-term storage.
0. Break-off mechanisms.
p. Despin mechanisms.
q. Appendages (antennas, booms, solar paddles,’ etc.).
r. Solar cells.

3.3.2 Detailed Analyses

The preliminary analyses for hazard identification initiated early in

the program should be e.xpanded in depth in the Definition and Design
Phases. These analyses a r e to include the system? h d subsystems

c-9
 .

equipment and their interfaces. Catastrophic hazards shall be elimi-

'
nated or controlled. Nuclear systems will meet a negligible- hazard
category unless a waiver is granted.

3.3.3 OPerating Analyses

Analyses should be conducted to determine safety requirements for

personnel, procedures, and equipment used in installation, maintenance,
support, testing, operations, and training. Results of these analyses
shall provide the basis for: (I) design changes, where feasible, to
eliminate hazards o r provide safety devices, safeguards, etc.; (2) in-
puts to the warning, caution, and emergency procedures section of test
operating and maintenance procedures and instructions; (3) identifica-
tion of a hazardous period time span and actions required if such
hazards occur; and (4)special procedures for servicing, b a i n g ,
storage, and transportation.

3.4 Industrial and Public Safety

The System Safety Program shall include coordination with the GSFC Health
and'Safety Engineering Office to ensure an effective and integrated total
Safety Program.

3.5 Design Review

A review of the Safety Program shall be presented to the N A W G S F C Design

Review Team as a part of the Center's formal Design Review Program.
Additional Safety Program Reviews, if required, shall be conducted as
directed by the Project Manager.

4.0 SYSTEMS SAFETY MONITORING &.ID CONTROL

4.1 Safety Program Schedule

In this section provide a master schedule for integrating the activities to be

accomplished in the overall Project Safety Plan. Identify approvai dates for
the plans, the analyses, reviews, and audits and other events as applicable.

4.2 Mishap Reporting

All sigmficant mishaps shall be investigated, utilizing applicable procedures,

f o r causes and system safety implications. The findings, conclusions, and

c-10
.

recommendations shall be documented and submitted to the appropriate

organizations for disposition. The contractor shall be prepared to provide
technical assistance to boards investigating mishaps which occur within his
jurisdiction. A copy of all mishaps reports shall be sent to the GSFC Health
and Safety Engineering Officer f o r disposition. The contractor shall be pre- .
pared to provide technical assistance to boards investigating mishaps which
occur within his jurisdiction.

4.3 Safety Monitoring

Observation of designated hazardous/dangerous operations will be accom-

plished as necessary to ensure adherence to safety principles and compliance
with safety requirements and checklists. Normally, the degree of monitoring
necessary (spot-check, full time monitoring, etc.) will vary depending upon
such factors as: the nature of the operation; the history/experience; the
quality of technical data available; the personnel involved and the type of
facilities available. Other factors may also be decisive and the degree of
monitoring required should be periodically evaluated as the state-of-the-art
progresses.

4.4 Safety Audits

Each project will audit prime contractors' safety performance. The prime .
contractors will audit their own conformance to safety requirements and the
performance of their subcontractors and suppliers, a s required. These
audits will evaluate the degree of conformance to the established safety re-
quirements. Requirements audited will also include safety requirements
specified in design, manufacturing, test, and operational specifications.

4.5 Waiver Procedures

Areas of noncompliance with the project's established safety requirements

must be referred to the Project Manager for review and approval. Describe
the procedures to be followed. in obtaining waivers.

4.6 Reporting and Documentation

In this section identrfy all documents, and the responsible organizations, to

be prepared in support of the Project Safety Plan. Further, identify those
documents, prepared under other project functions that support or become
an integral part of the plan by reference. Describe the central source files
for project safety documentation.

c-11
 .

ATTACHMENT I - APPENDLY C
HAZARD LEVEL CATEGORIES

A. Safety Catastrophic

Condition(s) such that environment, personnel e r r o r , design characteristics,

procedural deficiencies, o r subsystem o r component malfunction will cause
subsequent death o r multiple injuries to personnel.

B. Safety Critical
Condition(s) such that environment, personnel e r r o r , design characteristics,
procedural deficiencies, o r subsystem o r component maifunction w i l l cause
personnel injury, o r will result in a hazard requiring immediate corrective
action for personnel .
C. Safety Marginal

Condition(s) such that environment, personnel e r r o r , design characteristics,

procedural deficiencies, o r subsystem failure o r component malfunction that
can be counteracted o r controlled without any injury to personnel.

D. Safety Negligible

Condition(s)' such that personnel e r r o r , design characteristics, procedural

deficiencies, o r subsystem failure or component malfunction will not result
in personnel injury.

c-12
 ATTACHMENT II - APPE'NDIX C
SYSTEM SAFETY PRECEDENCE

A. Design for Minimum Hazard .

The major effort throughout the design phases shall be to ensure inherent
safety through the selection of appropriate design features as fail safe,
redundancy, and increased ultimate safety factor.

B. Safety Devices

Known hazards which cannot be eliminated through design selection shall

be reduced to the acceptable level through the use of appropriate safety
devices as part of the system, subsystem o r equipment, e.g., shorting plugs
on squibs, safe and a r m devices.

C. Warning Devices

Where it is not possible to preclude the e'uistence o r occurrence of a known

hazard, devices shall be employed for the timely detection of the condition
and the generation of an adequate warning signal. Warning signals and their
application shall be designed to minimize the probability of wrong signals
o r of improper personnel reaction to the signals, e.g., N2 H, leak detectors,

D. Special Procedures

Where it is not possible to reduce the magnitude of an existing o r potential

hazard through design, o r the use of safety and warning devices, special
procedures shall be developed to counter hazardous conditions for enhance-
ment of personnel safety. Precautionary notations shall b e standardized in
accordance with the direction of the procuring activity. *

E. Residual Hazards

Residential hazards for which safety o r warning devices and special pro-
cedures cannot be developed o r provided for counteracting the hazard shall
be specifically identified to safety and program management. Continuation
of effort to eliminate o r reduce such hazards shall be accomplished
throughout the p r o g r m by maintaining awareness of new safety technology . '

c-13
 o r devices being developed and their application to the residual hazards.
Justification for the retention of residual hazards shall be documented.

c-14
. --
 APPENDIX D

SUPPORT Ii\iSTRUMENTATIOiV REQUIREMENTS

DOCUMENT (SIRD)

D-1
 APPENDIX D

' SUPPORT DTSTRUiMENTATION REQUIREIVENTS DOCUMENT (STRD)

RELEASE PROCEDURES

1. The SIRD (or revisions) is prepared by the Project Office in conjunction

with the NSM and MSM for the project. (For all revisions, a new page 010
will be prepared. Page 030 will be revised to reflect those pages affected
by the revision.)

2. Copies are provided to the NSM and MSM for concurrence within their
respective directorates.

3. Informal Network Directorate, and Mission and Data Operations Directorate

concurrence is received and any changes incorporated.

4. The Project Manager signs page 010 (in the case of a revision the Project
Manager also initials the "validate" block(s) on page 030 for the correct
revision).

5. Copies of the SIRD memorandum a r e prepared (see sample memorandum).

6. A memorandum from the Office of the Director to the appropriate Head-

quarters Associate Administrator, is prepared. This memo must contain
a statement that ND and MDOD concurrence has been received (see attached
sample). The route slip requests the Office of the Director to sign the
SIRD memorandum, page 010 and to forward the entire package. The
routing of the memo is from Project Manager to the appropriate Directorate
office to the Directors of Networks and Mission and Data Operations; then
to the Office of the Director. In addition, revisions a r e routed through
D r . George F. Pieper, Code 600, to the Office of the Director (see attach-
ment sample).

7. The documents attached to the memo consist of three copies of the SIRD
plus the original of page 010. (A11 the rest of the originals a r e retained by
the project office.) .

Study/Project managers should plan and schedule the issuance of an initial

SIRD (Support Instrumentation Requirements Document) concurrent with the
Project Plan. This first SIRD should meet the minimum requirements es-
tablished in the SIRD preparation instructions and contain the new and

D-3
continuing requirements placed by the Tracking and Data activities of the
project. It is attached to the Project Plan and sent to OSS o r OA, as ap-
propriate for approval purposes, and after their action, it is sent by the
program office(s) to OTDA for information, review, and commitment of
support and future resources. Additionally, GSFC sends OTDA informa-
tion copies of the project plan and SIRD concurrent with the transmittal of
the same documents to the OSS o r OA program approving office.

a. The. sequence of events subsequent to the Projects Directorate release

of the SIRD o r revision are as follows:

The package is routed as per the routing slip.

The Office of the Director signs the memorandum and page 010 of
the SIRD and forwards the package to the Associate Administrator,
OSS o r OA.

The Associate Administrator, OSS o r OA, signs page 010 and for-
wards the package t o the Office of Tracking and Data Acquisition
(OTDA).

OTDA approves the SIRD and signs page 010.

OTDA reproduces page 010 and attaches a copy to each SIRD set.
One copy of the SIRD, attached to the memorandum authorizing its
use, is forwarded to GSFC.

A copy of the SIRD and authority for use is sent to the Headquarters
Program Office in OSS o r OA along with original of page 010.

OSS o r OA returns page 010 to the Project Office at GSFC for

retention.

D-4

. --
 NATIONAL AERONAUTICS AND SPACE ADMINISTRATION
GODDARD SPACE FLIGHT CENTER
GREENBELT. MARYLAND20771

SAMPLE
. .
SIRD (or Revision) Memorandum

TO: NASA Headquarters

Attenti'on: Office of Space Science and Applications
Dr. John E. Naugle
FROM: Office of the Director

SUBJECT: ATS-F&G Support Instrumentation Requirements

Document (SIRD), (Revision Number 1.

The subject document (revision) is forwarded herewith for approval

and transmittal forward b the Office of Tracking and Data Acquisition
for their review.
The document defines the support requirements for the ATS-F&G
launch and subsequent flight operations. It w a s prepared by the ATS
Project staff in cooperation with the ATS Network Operations Manager
and Mission Support M-uer and has been reviewed by the cognizant
Trackng and Data Systems personnel.

(Brief narrative description of the chaIge and reason for it.)

Please return original Page 010 "Approval" to the ATS Project

Office, GSFC , Attention: G . Bullock.

E nc lo sur es
. Three copies of the ATS-F&G SIRD (Ftevision)
Original page 010 "Approval" page
GB:lh (8/18/70)
ATS Project, Code 460 ,

cc: D r . G. F . Pieper, Code 600, with 1 copy of SZRD (Revision)

J. R . Burke, NASA HQ, with 1 copy of SIRD (Revision)
H. L. Gerwin, Code 460, with 1 copy of SIRD (Revision)
R . R . Nersesian, Code 513, with 10 copies of SIRD (Revision)

D-5
 . .

APPENDIX E

EXAMPLES OF iMEMORXNDA OF AGREEMEiVT

.-
.-
. - E-1
c

c
 .
0
0
1'
0
9
0

.
0
0
91 9
0 0

. .

I:E:
n
(?
5,
N

w v )
&
U
I
0
*

=I
E ' 31
0

d
c
w
z
z
0
v)
o?
W
a
4

EI 4
w H
.- .e+ X

.
I-

c
-
u
s0
u
2:
p 1 '

/
E-3
c

. .
 E
0
d
.
0
0 7 .
0
0
0

ul
0
0 I'
0
0
0

n
0
l-4
rl
U
=/
*L* .
0
0
.
0
0 . "I
o
0
0

o
N
*
. m. O
n
d
h

E
v)
<

0
- 0
*T
- c ?
h

=I
*LL
0 0 0 0
5,

In
.

E -4
 cy
0. 0
.
cy

d
.
rn 0. 0
w
c9
0 d

.
ro
0
e4

2 :
rn
U

ro
W ey

m
d
. m
d

cy
b
d

..
uo
04
Qo
0

9
0
cy
El 0

.
e4
4

-“I
m
m
0

d d
w
u
% ; 2 2
m L i v l w
co
I
0
e
0

E-5
 i

9
I;
3
d

x 0
0

0
91 9
0 0

=jE
V m

0
d
.
0
Q
?I
0
9
0

CJ
0
0
I
z
.a-
s .
m
?I
n
rl
\o
pc
v
=I
*cr wd
d
0
"!
0 .

d
h

E
VI
c
c
cn
cy
rn
.
w
0 a
z
s zz c
cn U
J Llc
cr
w
2
E-c CJ 0
0 u c F+r Y

4 u zs,
kl
ic
U
w n
C J .
Z Lr
U U
v)

C
r(
pc
U
IJ
IJ
A
w
+i

3
w
3 1
0
CJ
* .
t: k
l W &

VI
5
e
d
d
u
s0
u
E -6