JSC 49040 (VER. 1.0), NASA SYSTEM ENGINEERING PROCESS FOR PROGRAMS AND PROJECTS (OCT-1994)
JSC 49040 (VER. 1.0), NASA SYSTEM ENGINEERING PROCESS FOR PROGRAMS AND PROJECTS (OCT-1994)., The overall policy by which NASA handles major system programs and projects was established under NASA Management Instruction (NMI) 7120.4 in November of 1993. However, the need exists for a common set of suggested processes, products, and terminology regarding the technical management of all programs and projects. These processes, products, and terminology have been established by an intercenter team and are contained in this document. In addition, this document contains a common project management terminology, established by the intercenter team.
The NASA Systems Engineering Process for Programs and Projects establishes a common set of suggested top-level technical processes for developing NASA missions. Developed by a NASA-wide team, it consists of a structured set of program/project technical activities and milestones. These are designed to effect a structured evolution of activities and products so that objectives are met effectively and efficiently. The purpose of this document is to provide guidance, criteria, approach, procedure, and product and terminology standards for the successful completion of these activities. Especially important are the progressive, structured, traceable steps of system baselining and configuration control. This document is subordinate to and supports NASA Management Instruction (NMI) 7120.4, Management of Major System Programs and Projects, and the associated NASA Handbook (NHB) 7120.5.
This document addresses the definition, production, and operation of the total operational system (hardware, software, personnel, facilities, data, and so on) used to accomplish mission objectives. Topics include a definition of the activities and logical flow (life cycle model), a description of the required maturity at given points in the cycle (control gates), descriptions of the required intermediate products (data dictionary) and a standardized set of definitions (lexicon).
It is anticipated that this work will provide three closely related needs:
1) a common and mutually understood starting point so that logical and consistent plans are easier to develop,
2) a ready reference to help ensure that critical activities are not forgotten, and
3) a distillation of recognized successful practices that can be used as a firm foundation for improvement.
It is taken as an axiom that a thorough understanding of what has worked in the past provides the best starting point for developing better ways to do things in the future. This document is not a new and radical departure, nor is it business as usual. It is a lean compendium of a proven and logical engineering process undertaken in the belief that much is to be gained simply by doing things as well as we know how, every time. However, one should note the following.
• The technical process is parallel to, yet distinct from, the specific procurement approach. A project must accomplish the same technical tasks whether performed in-house or by contractors.
• The technical process itself must be managed and controlled. This is distinct from the administration and organization of resources and personnel.
• Compromising the technical process entails grave risks. On the other hand, proceeding too slowly wastes resources.
• Cost and schedule are always paramount concerns. Too little, too much, or out of sequence activity can seriously jeopardize cost and schedule.