Vous êtes sur la page 1sur 209

JPR 7120.

3
March 2004

Project Management: Systems Engineering & Project Control Processes and Requirements

JPR 7120.3 JSC Procedures and Guidelines for Project Management: Systems Engineering and Project Control Processes and Requirements

Development Team
This document was developed as a joint effort between the JSC Systems Engineering Working Group (J-SEWG) and the Project Management Working Group (PMWG).

J-SEWG: AG/James Ortiz (Chair) AG/Jeff Phillips, Dwight Auzenne, Ralph Anderson EA/Linda Bromley, Joyce Carpenter, Cliff Farmer DA/Larry Bishop, Patricia Carreon IA/Jon Symes, John Jurgensen JA/Jay Hoover NA/Daniel Freund RA/Jason Noble SA/Karen Morrison XA/Cuong Nguyen OA/Jonette Stecklein

PMW G: AG/Lee Graham (Chair) AG/Samuel Padgett EA/Linda Bromley DA/Jerome Yencharis IA/Jon Symes JA/Gary Wessels AH/Brad Mudgett, Erica Vandersand NA/Jeevan Perera RA/Jason Noble SA/Douglas Whitehead LA/Richard Whitlock

Consultation supported proved by the following personnel: Booz-Allen & Hamilton, Inc./Jack Gavalas Raytheon Technical Services Company, LCC/Larry Patrick Raytheon Technical Services Company, LCC/Brian Vining Raytheon Technical Services Company, LCC/Harold Smith

Editorial and graphics design support provided by the following personnel: DynCorp/Betty Conaway InDyne/Sharon Hecht InDyne/Sid Jones

Change Record
Revision Basic Change 1 Date March 2004 April 2006 Organization/Phone AG/Lee Graham/281-244-5192 AG/Bobby Watkins/281-483-0243 Change in applicability to basic and applied research. Description

This JSC Procedures Guideline (JPG) is being changed to a JSC Procedures Requirement (JPR) document with no context changes. All referenced JPGs in this document will be evaluated during the annual review of this document and will be updated to reflect additional changes to any JPGs that are currently referenced.

Table o f Content s
Chapter 1
Introduction------------------------------------------------------------------------------1.1 Purpose------------------------------------------------------------------1.2 Applicability and Scope --------------------------------------------1.3 Authority ---------------------------------------------------------------1.4 References--------------------------------------------------------------1.4.1 External Documents -------------------------------------------------1.4.2 NASA Documents ---------------------------------------------------1.4.3 JSC Documents -------------------------------------------------------1.5 Cancellation------------------------------------------------------------1-1 1-1 1-1 1-2 1-3 1-3 1-4 1-7 1-7

Chapter 2
Overview of Project Management at JSC----------------------------------------2.1 Scope --------------------------------------------------------------------2.2 Systems Engineering ------------------------------------------------2.3 Project Control--------------------------------------------------------2.4 Project Types, Approaches, and Life Cycle Phases---------2.4.1 Project Types ----------------------------------------------------------2.4.1.1 Space flight system development projects---------------------2.4.1.2 Advanced technology development projects------------------2.4.1.3 Science research, applied research, and advanced studies------------------------------------------------------2.4.1.4 Institutional------------------------------------------------------------2.4.1.5 Operations--------------------------------------------------------------2.4.2 Project Approaches --------------------------------------------------2.4.2.1 Staffing------------------------------------------------------------------2.4.2.2 Type of contract ------------------------------------------------------2.4.2.3 Magnitude--------------------------------------------------------------2.4.2.4 Implementation approach ------------------------------------------2.4.3 Project Life Cycle Phases ------------------------------------------2.5 Project Management Forums --------------------------------------2.5.1 Project-level Forums ------------------------------------------------2.5.2 Directorate-level Forums -------------------------------------------2.5.3 Center-level Forums -------------------------------------------------2.5.3.1 JSC Engineering Review Board (ERB) ------------------------2.5.3.2 JSC Facility Review Board (FRB)-------------------------------2.5.3.3 JSC Project Management Council -------------------------------2.6 Documentation Tree -------------------------------------------------2.7 Project Team-----------------------------------------------------------2.7.1 Organization -----------------------------------------------------------2.7.2 Membership------------------------------------------------------------2.7.2.1 Project manager role -------------------------------------------------2.7.2.2 Deputy project manager (DPM) role ----------------------------2.7.2.3 Lead systems engineer (LSE) role -------------------------------2.7.2.4 Project control officer role -----------------------------------------2.7.2.5 Subsystem and discipline lead engineers role ----------------2.7.2.6 Verification lead role ------------------------------------------------2.7.2.7 Validation lead role --------------------------------------------------2.7.2.8 Project scientis t role -------------------------------------------------2.7.2.9 User representative role---------------------------------------------2.7.2.10 Administrative officer role -----------------------------------------2.7.3 Support Team ---------------------------------------------------------2.7.3.1 Line management support------------------------------------------2-1 2-1 2-1 2-1 2-2 2-2 2-2 2-2 2-2 2-3 2-3 2-4 2-4 2-4 2-5 2-5 2-6 2-7 2-7 2-7 2-7 2-7 2-7 2-8 2-11 2-12 2-12 2-12 2-12 2-13 2-13 2-13 2-14 2-14 2-15 2-15 2-15 2-15 2-15 2-15

STS104-723-014 (21 July 2001)


Backdropped over a wide scene of topography in the Middle East, the International Space Station (ISS) passes over the Persian Gulf. This photograph was taken with a 70mm handheld camera during a fly -around inspection by the Space Shuttle Atlantis crew not long after the two spacecraft separated. Prominent on the starboard side of the outpost is the newly-installed Quest airlock.

STS104-315-005 (12-24 July 2001)


With Earths horizon in the background, astronaut Michael L. Gernhardt, STS-104 mission specialist, participates in one of three spacewalks aimed toward wrapping up the completion of work on the second phase of the ISS. Gernhardt was joined on this spacewalk by astronaut James F. Reilly.

Table o f Content s
2.7.3.2 2.7.3.3 2.7.3.4 2.7.3.5 2.7.3.6 2.7.3.7 2.7.3.8 2.7.3.9 2.7.3.10 2.7.3.11 2.7.3.12 2.7.3.13 2.7.3.14 2.7.3.15 2.7.3.16 2.7.3.17 2.7.3.18 2.7.3.19 2.8 2.8.1 2.8.2 2.8.3 2.8.4 Safety and mission assurance (S&MA) support -------------Mission operations support ----------------------------------------Test operations lead support---------------------------------------Facilities support -----------------------------------------------------Environmental support----------------------------------------------Counterintelligence support ---------------------------------------Export control support ----------------------------------------------Logistics, transportation, and shipping support --------------Procurement support ------------------------------------------------Office of the Chief Financial Officer (CFO) support ------------------------------------------------------------------Office of the Chief Engineer support ---------------------------Legal support----------------------------------------------------------Communication and information technology support ------------------------------------------------------------------Documentation and graphics support ---------------------------Photographic-video support ---------------------------------------Public Affairs Office support -------------------------------------Human factors support----------------------------------------------Technology transfer and intellectual property management support ------------------------------------------------Project Management and Planning ------------------------------Project Management-------------------------------------------------Project Management Plan and Project Baseline--------------Program Operating Plan (Project Baseline Updates) ----------------------------------------------------------------Customer-Project Agreement -------------------------------------2-16 2-16 2-16 2-17 2-17 2-17 2-17 2-18 2-18 2-18 2-18 2-18 2-19 2-19 2-19 2-19 2-19 2-19 2-21 2-21 2-21 2-22 2-22

ISS01-323-010 (8 November 2000)

Early film documentation of the Expedition 1 crewmembers on board the ISS shows cosmonauts Sergei K. Krikalev (left) and Yuri P. Gidzenko at work in the Zvezda Service Module. This is one of the first film images that was released from the Expedition 1 crew.

Chapter 3
Project Life Cycle Requirements---------------------------------------------------3.1 Pre-Phase A Advanced Studies --------------------------------3.1.1 Overview ---------------------------------------------------------------3.1.2 Expected Results/Outcomes---------------------------------------3.1.3 Products-----------------------------------------------------------------3.1.4 Process ------------------------------------------------------------------3.1.5 Reviews Concept Review ---------------------------------------3.1.6 Management Decision ----------------------------------------------3.1.7 References--------------------------------------------------------------3.2 Phase A Preliminary Analysis ----------------------------------3.2.1 Overview ---------------------------------------------------------------3.2.2 Expected Results/Outcomes---------------------------------------3.2.3 Products-----------------------------------------------------------------3.2.4 Process ------------------------------------------------------------------3.2.5 Reviews -----------------------------------------------------------------3.2.5.1 The Requirements Review-----------------------------------------3.2.5.2 The Definition Review----------------------------------------------3.2.6 Management Decision ----------------------------------------------3.2.7 References--------------------------------------------------------------3.3 Phase B Definition ------------------------------------------------3.3.1 Overview ---------------------------------------------------------------3.3.2 Expected Results/Outcomes---------------------------------------3.3.3 Products-----------------------------------------------------------------3.3.4 Process ------------------------------------------------------------------3.3.5 Reviews -----------------------------------------------------------------3.3.5.1 The System Requirements Review------------------------------3-1 3-2 3-2 3-2 3-2 3-2 3-2 3-2 3-3 3-4 3-4 3-4 3-4 3-4 3-4 3-4 3-4 3-6 3-6 3-7 3-7 3-7 3-7 3-7 3-7 3-7

ISS01-E-5129 (December 2000)


Astronaut William M. (Bill) Shepherd, Expedition One commander, works on the Ward Room table in the Zvezda Service Module aboard the ISS.

vi

Table o f Content s
3.3.5.2 3.3.5.3 3.3.6 3.3.7 3.4 3.4.1 3.4.2 3.4.3 3.4.4 3.4.5 3.4.6 3.4.7 3.5 3.5.1 3.5.2 3.5.3 3.5.4 3.5.5 3.5.5.1 3.5.5.2 3.5.5.3 3.5.5.4 3.5.5.5 3.5.6 3.5.7 3.6 3.6.1 3.6.2 3.6.3 3.6.4 3.6.5 3.6.5.1 3.6.5.2 3.6.5.3 3.6.5.4 3.6.6 3.6.7 3.7 3.7.1 3.7.2 3.7.2.1 3.7.2.2 3.7.3 3.7.4 3.7.5 3.7.5.1 3.7.5.2 3.7.6 3.7.7 The System Definition Review-----------------------------------The Preliminary Design Review ---------------------------------Management Decision ----------------------------------------------References--------------------------------------------------------------Phase C Design-----------------------------------------------------Overview ---------------------------------------------------------------Expected Results/Outcomes---------------------------------------Products-----------------------------------------------------------------Process ------------------------------------------------------------------Reviews The Critical Design Review------------------------Management Decision ----------------------------------------------References--------------------------------------------------------------Phase D Development --------------------------------------------Overview ---------------------------------------------------------------Expected Results/Outcomes---------------------------------------Products-----------------------------------------------------------------Process ------------------------------------------------------------------Reviews -----------------------------------------------------------------The Production Readiness Review ------------------------------The Test Readiness Review---------------------------------------The System Acceptance Review ---------------------------------The Deployment Readiness Review ----------------------------The Operational Readiness Review-----------------------------Management Decision ----------------------------------------------References--------------------------------------------------------------Phase E Operations------------------------------------------------Overview ---------------------------------------------------------------Expected Results/Outcomes---------------------------------------Products-----------------------------------------------------------------Process ------------------------------------------------------------------Reviews -----------------------------------------------------------------The Delta Operational Readiness Review ---------------------The System Upgrade Review-------------------------------------The Safety Review---------------------------------------------------The Decommissioning Review -----------------------------------Management Decision ----------------------------------------------References--------------------------------------------------------------Project Termination--------------------------------------------------Overview ---------------------------------------------------------------Activities ---------------------------------------------------------------Nominal termination ------------------------------------------------Off-nominal termination -------------------------------------------Products-----------------------------------------------------------------Process ------------------------------------------------------------------Reviews -----------------------------------------------------------------The Termination Review-------------------------------------------The Decommissioning Review -----------------------------------Management Decision ----------------------------------------------References--------------------------------------------------------------3-8 3-9 3-10 3-10 3-11 3-11 3-11 3-11 3-11 3-11 3-12 3-12 3-13 3-13 3-13 3-13 3-13 3-16 3-16 3-17 3-17 3-17 3-18 3-18 3-18 3-19 3-19 3-19 3-19 3-19 3-19 3-19 3-19 3-19 3-20 3-20 3-20 3-21 3-21 3-21 3-21 3-21 3-22 3-22 3-22 3-22 3-22 3-24 3-24

STS105-725-006 (16 August 2001)


Astronaut Daniel T. Barry, STS-105 mission specialist, traverses along the Space Shuttle Discovery s payload bay, backdropped against the blue and white Earth, during one of two days of spacewalks. Barry was joined by astronaut Patrick G. Forrester, mission specialist, on both of the spacewalks scheduled for the STS-105 mission.

STS105-E-5168 (13 August 2001)


Astronaut Yury V. Usachev works out on the treadmill device in the Zvezda Service Module aboard the ISS. The Expedition 2 mission commander is only days away from returning to Earth following five months aboard the orbital outpost.

vii

Table o f Content s
Chapter 4
Project Management Processes and Requirements ----------------------------4.0.1 References--------------------------------------------------------------4.1 Systems Engineering Processes ----------------------------------4.1.1 Requirements Development ---------------------------------------4.1.1.1 Function-----------------------------------------------------------------4.1.1.2 Objective ---------------------------------------------------------------4.1.1.3 Responsibilities -------------------------------------------------------4.1.1.4 Life cycle ---------------------------------------------------------------4.1.1.5 Inputs --------------------------------------------------------------------4.1.1.6 Steps ---------------------------------------------------------------------4.1.1.7 Outputs ------------------------------------------------------------------4.1.1.8 Exit criteria -------------------------------------------------------------4.1.1.9 Measurement ----------------------------------------------------------4.1.1.10 Methods and techniques--------------------------------------------4.1.1.11 Software tools ---------------------------------------------------------4.1.1.12 References--------------------------------------------------------------4.1.2 Requirements Management----------------------------------------4.1.2.1 Function-----------------------------------------------------------------4.1.2.2 Objective ---------------------------------------------------------------4.1.2.3 Responsibilities -------------------------------------------------------4.1.2.4 Life cycle ---------------------------------------------------------------4.1.2.5 Inputs --------------------------------------------------------------------4.1.2.6 Steps ---------------------------------------------------------------------4.1.2.7 Outputs ------------------------------------------------------------------4.1.2.8 Exit criteria -------------------------------------------------------------4.1.2.9 Measurement ----------------------------------------------------------4.1.2.10 Methods and techniques--------------------------------------------4.1.2.11 Software tools ---------------------------------------------------------4.1.2.12 References--------------------------------------------------------------4.1.3 Operational Concept Development------------------------------4.1.3.1 Function-----------------------------------------------------------------4.1.3.2 Objective ---------------------------------------------------------------4.1.3.3 Responsibilities -------------------------------------------------------4.1.3.4 Life cycle ---------------------------------------------------------------4.1.3.5 Inputs --------------------------------------------------------------------4.1.3.6 Steps ---------------------------------------------------------------------4.1.3.7 Outputs ------------------------------------------------------------------4.1.3.8 Exit criteria -------------------------------------------------------------4.1.3.9 Measurement ----------------------------------------------------------4.1.3.10 Methods and techniques--------------------------------------------4.1.3.11 Software tools ---------------------------------------------------------4.1.3.12 References--------------------------------------------------------------4.1.4 Decomposition--------------------------------------------------------4.1.4.1 Function-----------------------------------------------------------------4.1.4.2 Objective ---------------------------------------------------------------4.1.4.3 Responsibilities -------------------------------------------------------4.1.4.4 Life cycle ---------------------------------------------------------------4.1.4.5 Inputs --------------------------------------------------------------------4.1.4.6 Steps ---------------------------------------------------------------------4.1.4.7 Outputs ------------------------------------------------------------------4.1.4.8 Exit criteria -------------------------------------------------------------4.1.4.9 Measurement ----------------------------------------------------------4.1.4.10 Methods and techniques--------------------------------------------4.1.4.11 Software tools ---------------------------------------------------------4-1 4-3 4-4 4-4 4-4 4-4 4-4 4-4 4-4 4-4 4-6 4-6 4-7 4-7 4-7 4-7 4-9 4-9 4-9 4-9 4-9 4-9 4-9 4-10 4-10 4-11 4-11 4-11 4-11 4-12 4-12 4-12 4-12 4-12 4-12 4-12 4-13 4-14 4-14 4-14 4-14 4-14 4-15 4-15 4-15 4-15 4-15 4-15 4-15 4-17 4-17 4-17 4-17 4-18

STS100-347-025 (28 April 2001)


The Canadian-built Space Station robotic arm transfers its launch cradle over to Endeavours Canadian-built robotic arm. A Canadian mission specialist, astronaut Chris A. Hadfield, was instrumental in the activity as he was at the controls of the original robot arm from his post on the aft flight deck of the Shuttle.

STS100-395-017 (19 April - 1 May 2001)


A close look at the window in this picture of the Destiny laboratory reveals the faces of astronauts Susan J. Helms and James S. Voss, flight engineers for the Expedition 2 mission. One of the two STS-100 space walkers, astronauts Scott E. Parazynski and Chris A. Hadfield, exposed the image with a 35mm camera on one of two days of performing spacewalks.

viii

Table o f Content s
4.1.4.12 4.1.5 4.1.5.1 4.1.5.2 4.1.5.3 4.1.5.4 4.1.5.5 4.1.5.6 4.1.5.7 4.1.5.8 4.1.5.9 4.1.5.10 4.1.5.11 4.1.5.12 4.1.6 4.1.6.1 4.1.6.2 4.1.6.3 4.1.6.4 4.1.6.5 4.1.6.6 4.1.6.7 4.1.6.8 4.1.6.9 4.1.6.10 4.1.6.11 4.1.6.12 4.1.7 4.1.7.1 4.1.7.2 4.1.7.3 4.1.7.4 4.1.7.5 4.1.7.6 4.1.7.7 4.1.7.8 4.1.7.9 4.1.7.10 4.1.7.11 4.1.7.12 4.1.8 4.1.8.1 4.1.8.2 4.1.8.3 4.1.8.4 4.1.8.5 4.1.8.6 4.1.8.7 4.1.8.8 4.1.8.9 4.1.8.10 4.1.8.11 4.1.8.12 4.1.9 4.1.9.1 4.1.9.2 References--------------------------------------------------------------Feasibility Study------------------------------------------------------Function-----------------------------------------------------------------Objective ---------------------------------------------------------------Responsibilities -------------------------------------------------------Life cycle ---------------------------------------------------------------Inputs --------------------------------------------------------------------Steps ---------------------------------------------------------------------Outputs ------------------------------------------------------------------Exit criteria -------------------------------------------------------------Measurement ----------------------------------------------------------Methods and techniques--------------------------------------------Software tools ---------------------------------------------------------References--------------------------------------------------------------Technology Planning------------------------------------------------Function-----------------------------------------------------------------Objectives --------------------------------------------------------------Responsibilities -------------------------------------------------------Life cycle ---------------------------------------------------------------Inputs --------------------------------------------------------------------Steps ---------------------------------------------------------------------Outputs ------------------------------------------------------------------Exit criteria -------------------------------------------------------------Measurement ----------------------------------------------------------Methods and techniques--------------------------------------------Software tools ---------------------------------------------------------References--------------------------------------------------------------Design-------------------------------------------------------------------Function-----------------------------------------------------------------Objective ---------------------------------------------------------------Responsibilities -------------------------------------------------------Life cycle ---------------------------------------------------------------Inputs --------------------------------------------------------------------Steps ---------------------------------------------------------------------Outputs ------------------------------------------------------------------Exit criteria -------------------------------------------------------------Measurement ----------------------------------------------------------Methods and techniques--------------------------------------------Software tools ---------------------------------------------------------References--------------------------------------------------------------Attainment -------------------------------------------------------------Function-----------------------------------------------------------------Objective ---------------------------------------------------------------Responsibilities -------------------------------------------------------Life cycle ---------------------------------------------------------------Inputs --------------------------------------------------------------------Steps ---------------------------------------------------------------------Outputs ------------------------------------------------------------------Exit criteria -------------------------------------------------------------Measurement ----------------------------------------------------------Methods and techniques--------------------------------------------Software tools ---------------------------------------------------------References--------------------------------------------------------------Integration--------------------------------------------------------------Function-----------------------------------------------------------------Objective ---------------------------------------------------------------4-18 4-19 4-19 4-19 4-19 4-19 4-19 4-19 4-20 4-21 4-21 4-21 4-21 4-22 4-23 4-23 4-23 4-23 4-23 4-23 4-23 4-25 4-25 4-25 4-25 4-25 4-25 4-26 4-26 4-26 4-26 4-27 4-27 4-27 4-28 4-29 4-29 4-29 4-29 4-30 4-31 4-31 4-31 4-31 4-31 4-31 4-31 4-32 4-33 4-33 4-33 4-33 4-34 4-35 4-35 4-35

STS108-725-010 (5-17 December 2001)


Backdropped by the blackness of space, the ISS was photographed by a crew member aboard the Space Shuttle Endeavour.

STS108-350-009 (10 December 2001)

Astronaut Linda M. Godwin, STS-108 mission specialist, works during a fourhour, 12-minute spac ewalk The main objective of the spacewalk was to install thermal blankets on mechanisms that rotate the ISSs main solar arrays.

ix

Table o f Content s
4.1.9.3 4.1.9.4 4.1.9.5 4.1.9.6 4.1.9.7 4.1.9.8 4.1.9.9 4.1.9.10 4.1.9.11 4.1.9.12 4.1.10 4.1.10.1 4.1.10.2 4.1.10.3 4.1.10.4 4.1.10.5 4.1.10.6 4.1.10.7 4.1.10.8 4.1.10.9 4.1.10.10 4.1.10.11 4.1.10.12 4.1.11 4.1.11.1 4.1.11.2 4.1.11.3 4.1.11.4 4.1.11.5 4.1.11.6 4.1.11.7 4.1.11.8 4.1.11.9 4.1.11.10 4.1.11.11 4.1.11.12 4.1.12 4.1.12.1 4.1.12.2 4.1.12.3 4.1.12.4 4.1.12.5 4.1.12.6 4.1.12.7 4.1.12.8 4.1.12.9 4.1.12.10 4.1.12.11 4.1.12.12 4.1.13 4.1.13.1 4.1.13.2 4.1.13.3 4.1.13.4 4.1.13.5 4.1.13.6 Responsibilities -------------------------------------------------------Life cycle ---------------------------------------------------------------Inputs --------------------------------------------------------------------Steps ---------------------------------------------------------------------Outputs ------------------------------------------------------------------Exit criteria -------------------------------------------------------------Measurement ----------------------------------------------------------Methods and techniques--------------------------------------------Software tools ---------------------------------------------------------References--------------------------------------------------------------Technical Work and Resource Management------------------Function-----------------------------------------------------------------Objective ---------------------------------------------------------------Responsibilities -------------------------------------------------------Life cycle ---------------------------------------------------------------Inputs --------------------------------------------------------------------Steps ---------------------------------------------------------------------Outputs ------------------------------------------------------------------Exit criteria -------------------------------------------------------------Measurement ----------------------------------------------------------Methods and techniques--------------------------------------------Software tools ---------------------------------------------------------References--------------------------------------------------------------Safety and Mission Success---------------------------------------Function-----------------------------------------------------------------Objective ---------------------------------------------------------------Responsibilities -------------------------------------------------------Life cycle ---------------------------------------------------------------Inputs --------------------------------------------------------------------Steps ---------------------------------------------------------------------Outputs ------------------------------------------------------------------Exit criteria -------------------------------------------------------------Measurement ----------------------------------------------------------Methods and techniques--------------------------------------------Software tools ---------------------------------------------------------References--------------------------------------------------------------Control ------------------------------------------------------------------Function-----------------------------------------------------------------Objective ---------------------------------------------------------------Responsibilities -------------------------------------------------------Life cycle ---------------------------------------------------------------Inputs --------------------------------------------------------------------Steps ---------------------------------------------------------------------Outputs ------------------------------------------------------------------Exit criteria -------------------------------------------------------------Measurement ----------------------------------------------------------Methods and techniques--------------------------------------------Software tools ---------------------------------------------------------References--------------------------------------------------------------System Analysis ------------------------------------------------------Function-----------------------------------------------------------------Objective ---------------------------------------------------------------Responsibilities -------------------------------------------------------Life cycle ---------------------------------------------------------------Inputs --------------------------------------------------------------------Steps ---------------------------------------------------------------------4-35 4-35 4-35 4-35 4-40 4-40 4-40 4-41 4-41 4-41 4-42 4-42 4-42 4-42 4-42 4-42 4-43 4-45 4-45 4-45 4-46 4-46 4-46 4-47 4-47 4-47 4-47 4-48 4-48 4-48 4-51 4-51 4-51 4-51 4-51 4-51 4-53 4-53 4-53 4-53 4-53 4-53 4-53 4-55 4-55 4-55 4-56 4-56 4-56 4-57 4-57 4-57 4-57 4-57 4-57 4-58

ISS003-E-5415 (10 September 2001)


Expedition 3 mission commander Frank L. Culbertson, Jr., conducts inflight maintenance with a ratchet under a panel in the Unity Node 1 on the ISS. This image was taken with a digital still camera.

ISS003-E-5634 (17 September 2001)


Cosmonaut Mikhail Tyurin, Expedition 3 flight engineer, packs the docking probe in a stowage bag in Unity. The docking probe successfully guided the arrival of the Russian-built Pirs docking compartment to the ISS.

Table o f Content s
4.1.13.7 4.1.13.8 4.1.13.9 4.1.13.10 4.1.13.11 4.1.13.12 4.1.14 4.1.14.1 4.1.14.2 4.1.14.3 4.1.14.4 4.1.14.5 4.1.14.6 4.1.14.7 4.1.14.8 4.1.14.9 4.1.14.10 4.1.14.11 4.1.14.12 4.1.15 4.1.15.1 4.1.15.2 4.1.15.3 4.1.15.4 4.1.15.5 4.1.15.6 4.1.15.7 4.1.15.8 4.1.15.9 4.1.15.10 4.1.15.11 4.1.15.12 4.1.16 4.1.16.1 4.1.16.2 4.1.16.3 4.1.16.4 4.1.16.5 4.1.16.6 4.1.16.7 4.1.16.8 4.1.16.9 4.1.16.10 4.1.16.11 4.1.16.12 4.2 4.2.1 4.2.1.1 4.2.1.2 4.2.1.3 4.2.1.4 4.2.1.5 4.2.1.6 4.2.1.7 4.2.1.8 4.2.1.9 Outputs ------------------------------------------------------------------Exit criteria -------------------------------------------------------------Measurement ----------------------------------------------------------Methods and techniques--------------------------------------------Software tools ---------------------------------------------------------References--------------------------------------------------------------Verification ------------------------------------------------------------Function-----------------------------------------------------------------Objective ---------------------------------------------------------------Responsibilities -------------------------------------------------------Life cycle ---------------------------------------------------------------Inputs --------------------------------------------------------------------Steps ---------------------------------------------------------------------Outputs ------------------------------------------------------------------Exit criteria -------------------------------------------------------------Measurement ----------------------------------------------------------Methods and techniques--------------------------------------------Software tools ---------------------------------------------------------References--------------------------------------------------------------Validation --------------------------------------------------------------Function-----------------------------------------------------------------Objective ---------------------------------------------------------------Responsibilities -------------------------------------------------------Life cycle ---------------------------------------------------------------Inputs --------------------------------------------------------------------Steps ---------------------------------------------------------------------Outputs ------------------------------------------------------------------Exit criteria -------------------------------------------------------------Measurement ----------------------------------------------------------Methods and techniques--------------------------------------------Software tools ---------------------------------------------------------References--------------------------------------------------------------Reviews -----------------------------------------------------------------Function-----------------------------------------------------------------Objective ---------------------------------------------------------------Responsibilities -------------------------------------------------------Life cycle ---------------------------------------------------------------Inputs --------------------------------------------------------------------Steps ---------------------------------------------------------------------Outputs ------------------------------------------------------------------Exit criteria -------------------------------------------------------------Measurement ----------------------------------------------------------Methods and techniques--------------------------------------------Software tools ---------------------------------------------------------References--------------------------------------------------------------Project Control Processes ------------------------------------------Resource Management----------------------------------------------Function-----------------------------------------------------------------Objective ---------------------------------------------------------------Responsibilities -------------------------------------------------------Life cycle ---------------------------------------------------------------Inputs --------------------------------------------------------------------Steps ---------------------------------------------------------------------Outputs ------------------------------------------------------------------Exit criteria -------------------------------------------------------------Measurement ----------------------------------------------------------4-59 4-59 4-59 4-60 4-60 4-60 4-61 4-61 4-61 4-61 4-61 4-61 4-62 4-63 4-63 4-63 4-63 4-64 4-64 4-65 4-65 4-65 4-65 4-65 4-65 4-65 4-66 4-67 4-67 4-67 4-67 4-68 4-69 4-69 4-69 4-69 4-69 4-69 4-69 4-71 4-71 4-71 4-71 4-72 4-72 4-73 4-73 4-73 4-74 4-74 4-74 4-74 4-74 4-74 4-74 4-74

JSC2001-E-24454 (8 August 2001)


Astronaut John M. Grunsfeld, STS-109 payload commander, uses virtual reality hardware at the Johnson Space Center (JSC) to rehearse some of his duties on the upcoming STS-109 mission, NASAs fourth servicing visit to the Hubble Space Telescope.

STS109-E-5048 (3 March 2002)

The top portion of the Hubble Space Telescope is photographed some 350 miles above the Pacific Ocean southwest of Mexico, as the Space Shuttle Columbia is about to use its 50-foot-long robotic arm to lower the telescope into its cargo bay. The image was one of a series recorded with a digital still camera.

xi

Table o f Content s
4.2.1.10 4.2.1.11 4.2.1.12 4.2.2 4.2.2.1 4.2.2.2 4.2.2.3 4.2.2.4 4.2.2.5 4.2.2.6 4.2.2.7 4.2.2.8 4.2.2.9 4.2.2.10 4.2.2.11 4.2.2.12 4.2.3 4.2.3.1 4.2.3.2 4.2.3.3 4.2.3.4 4.2.3.5 4.2.3.6 4.2.3.7 4.2.3.8 4.2.3.9 4.2.3.10 4.2.3.11 4.2.3.12 4.2.4 4.2.4.1 4.2.4.2 4.2.4.3 4.2.4.4 4.2.4.5 4.2.4.6 4.2.4.7 4.2.4.8 4.2.4.9 4.2.4.10 4.2.4.11 4.2.4.12 4.2.5 4.2.5.1 4.2.5.2 4.2.5.3 4.2.5.4 4.2.5.5 4.2.5.6 4.2.5.7 4.2.5.8 4.2.5.9 4.2.5.10 4.2.5.11 4.2.5.12 4.2.6 Methods and techniques--------------------------------------------Software tools ---------------------------------------------------------References--------------------------------------------------------------Planning-----------------------------------------------------------------Function-----------------------------------------------------------------Objective ---------------------------------------------------------------Responsibilities -------------------------------------------------------Life cycle ---------------------------------------------------------------Inputs --------------------------------------------------------------------Steps ---------------------------------------------------------------------Outputs ------------------------------------------------------------------Exit criteria -------------------------------------------------------------Measurement ----------------------------------------------------------Methods and techniques--------------------------------------------Software tools ---------------------------------------------------------References--------------------------------------------------------------Documentation and Data Management-------------------------Function-----------------------------------------------------------------Objective ---------------------------------------------------------------Responsibilities -------------------------------------------------------Life cycle ---------------------------------------------------------------Inputs --------------------------------------------------------------------Steps ---------------------------------------------------------------------Outputs ------------------------------------------------------------------Exit criteria -------------------------------------------------------------Measurement ----------------------------------------------------------Methods and techniques--------------------------------------------Software tools ---------------------------------------------------------References--------------------------------------------------------------Cost Estimating -------------------------------------------------------Function-----------------------------------------------------------------Objective ---------------------------------------------------------------Responsibilities -------------------------------------------------------Life cycle ---------------------------------------------------------------Inputs --------------------------------------------------------------------Steps ---------------------------------------------------------------------Outputs ------------------------------------------------------------------Exit criteria -------------------------------------------------------------Measurement ----------------------------------------------------------Methods and techniques--------------------------------------------Software tools ---------------------------------------------------------References--------------------------------------------------------------Performance Measurement ----------------------------------------Function-----------------------------------------------------------------Objective ---------------------------------------------------------------Responsibilities -------------------------------------------------------Life cycle ---------------------------------------------------------------Inputs --------------------------------------------------------------------Steps ---------------------------------------------------------------------Outputs ------------------------------------------------------------------Exit criteria -------------------------------------------------------------Measurement ----------------------------------------------------------Methods and techniques--------------------------------------------Software tools ---------------------------------------------------------References--------------------------------------------------------------Schedule Management----------------------------------------------4-74 4-75 4-75 4-76 4-76 4-76 4-76 4-76 4-76 4-76 4-76 4-77 4-77 4-78 4-78 4-78 4-79 4-79 4-79 4-79 4-79 4-79 4-79 4-80 4-80 4-80 4-80 4-80 4-81 4-82 4-82 4-82 4-82 4-82 4-82 4-82 4-83 4-83 4-83 4-84 4-84 4-84 4-85 4-85 4-86 4-86 4-86 4-86 4-87 4-89 4-89 4-89 4-89 4-89 4-90 4-91

STS108-E-5594 (15 December 2001)


As seen in a medium view from a digital still camera aimed through a window on Endeavours aft flight deck, the ISS, now staffed with its fourth three-person crew, is contrasted against a patch of the blue and white Earth during a farewell look from the Shuttle following undocking. The Destiny laboratory is partially covered with shadows in the foreground.

ISS004-E-10071 (17 April 2002)


Moments prior to the undocking of the Space Shuttle Atlantis from the ISS, an Expedition 4 crewmember took this digital still photograph from a window in the Pirs Docking Compartment. The STS-110 crew spent about a week aboard the ISS and successfully installed the S0 (S-zero) truss. Also visible in this image are the Soyuz Spacecraft, Space Station Remote Manipulator System/Canadarm2 and Pressurized Mating Adapter 3.

xii

Table o f Content s
4.2.6.1 4.2.6.2 4.2.6.3 4.2.6.4 4.2.6.5 4.2.6.6 4.2.6.7 4.2.6.8 4.2.6.9 4.2.6.10 4.2.6.11 4.2.6.12 4.2.7 4.2.7.1 4.2.7.2 4.2.7.3 4.2.7.4 4.2.7.5 4.2.7.6 4.2.7.7 4.2.7.8 4.2.7.9 4.2.7.10 4.2.7.11 4.2.7.12 4.3 4.3.1 4.3.1.1 4.3.1.2 4.3.1.3 4.3.1.4 4.3.1.5 4.3.1.6 4.3.1.7 4.3.1.8 4.3.1.9 4.3.1.10 4.3.1.11 4.3.1.12 4.3.2 4.3.2.1 4.3.2.2 4.3.2.3 4.3.2.4 4.3.2.5 4.3.2.6 4.3.2.7 4.3.2.8 4.3.2.9 4.3.2.10 4.3.2.11 4.3.2.12 4.3.3 4.3.3.1 4.3.3.2 4.3.3.3 Function-----------------------------------------------------------------Objective ---------------------------------------------------------------Responsibilities -------------------------------------------------------Life cycle ---------------------------------------------------------------Inputs --------------------------------------------------------------------Steps ---------------------------------------------------------------------Outputs ------------------------------------------------------------------Exit criteria -------------------------------------------------------------Measurement ----------------------------------------------------------Methods and techniques--------------------------------------------Software tools ---------------------------------------------------------References--------------------------------------------------------------Project Analysis ------------------------------------------------------Function-----------------------------------------------------------------Objective ---------------------------------------------------------------Responsibilities -------------------------------------------------------Life cycle ---------------------------------------------------------------Inputs --------------------------------------------------------------------Steps ---------------------------------------------------------------------Outputs ------------------------------------------------------------------Exit criteria -------------------------------------------------------------Measurement ----------------------------------------------------------Methods and techniques--------------------------------------------Software tools ---------------------------------------------------------References--------------------------------------------------------------Crosscutting Processes----------------------------------------------Acquisition Management-------------------------------------------Function-----------------------------------------------------------------Objective ---------------------------------------------------------------Responsibilities -------------------------------------------------------Life cycle ---------------------------------------------------------------Inputs --------------------------------------------------------------------Steps ---------------------------------------------------------------------Outputs ------------------------------------------------------------------Exit criteria -------------------------------------------------------------Measurement ----------------------------------------------------------Methods and techniques--------------------------------------------Software tools ---------------------------------------------------------References--------------------------------------------------------------Risk Management ----------------------------------------------------Function-----------------------------------------------------------------Objective ---------------------------------------------------------------Responsibilities -------------------------------------------------------Life cycle ---------------------------------------------------------------Inputs --------------------------------------------------------------------Steps ---------------------------------------------------------------------Outputs ------------------------------------------------------------------Exit criteria -------------------------------------------------------------Measurement ----------------------------------------------------------Methods and techniques--------------------------------------------Software tools ---------------------------------------------------------References--------------------------------------------------------------Configuration Management ---------------------------------------Function-----------------------------------------------------------------Objective ---------------------------------------------------------------Responsibilities -------------------------------------------------------4-91 4-91 4-91 4-91 4-91 4-91 4-92 4-92 4-93 4-93 4-93 4-93 4-94 4-94 4-94 4-94 4-94 4-94 4-94 4-96 4-96 4-96 4-96 4-96 4-96 4-97 4-97 4-97 4-97 4-97 4-97 4-97 4-98 4-99 4-99 4-99 4-100 4-100 4-100 4-101 4-101 4-101 4-101 4-101 4-101 4-101 4-102 4-103 4-103 4-103 4-104 4-104 4-105 4-105 4-105 4-105

STS110-718-013 (13 April 2002)


Astronaut Lee M. E. Morin, STS-110 mission specialist, anchored on the mobile foot restraint on the ISS Canadarm2, moves toward the Stations newly installed S0 (S-zero) truss during this second scheduled spacewalk Astronaut Jerry L. Ross, mission specialist, worked in tandem with Morin on the spacewalk.

STS110-366-002 (11 April 2002)


Astronaut Steven L. Smith, STS-110 mission specialist, works inside the S0 truss, newly installed on the ISS. Astronaut Rex J. Walheim (out of frame), mission specialist, worked in tandem with Smith during the spacewalk.

xiii

Table o f Content s
4.3.3.4 4.3.3.5 4.3.3.6 4.3.3.7 4.3.3.8 4.3.3.9 4.3.3.10 4.3.3.11 4.3.3.12 4.3.4 4.3.4.1 4.3.4.2 4.3.4.3 4.3.4.4 4.3.4.5 4.3.4.6 4.3.4.7 4.3.4.8 4.3.4.9 4.3.4.10 4.3.4.11 4.3.4.12 Life cycle ---------------------------------------------------------------Inputs --------------------------------------------------------------------Steps ---------------------------------------------------------------------Outputs ------------------------------------------------------------------Exit criteria -------------------------------------------------------------Measurement ----------------------------------------------------------Methods and techniques--------------------------------------------Software tools ---------------------------------------------------------References--------------------------------------------------------------Quality Management ------------------------------------------------Function-----------------------------------------------------------------Objective ---------------------------------------------------------------Responsibilities -------------------------------------------------------Life cycle ---------------------------------------------------------------Inputs --------------------------------------------------------------------Steps ---------------------------------------------------------------------Outputs ------------------------------------------------------------------Exit criteria -------------------------------------------------------------Measurement ----------------------------------------------------------Methods and techniques--------------------------------------------Software tools ---------------------------------------------------------References--------------------------------------------------------------4-105 4-105 4-106 4-107 4-108 4-108 4-108 4-108 4-109 4-110 4-110 4-110 4-110 4-110 4-110 4-111 4-112 4-113 4-113 4-113 4-113 4-113

ISS005-E-19968 (6 November 2002)


Astronaut Peggy A. Whitson, Expedition 5 flight engineer, exercises in the Destiny laboratory on the ISS.

Appendices
Appendix A Project Management Content Requirements ----------------A.1 Title Page---------------------------------------------------------------A.2 Introduction------------------------------------------------------------A.3 Objectives --------------------------------------------------------------A.4 Customer Definition and Advocacy-----------------------------A.5 Project Authority -----------------------------------------------------A.6 Management-----------------------------------------------------------A.7 Project Requirements------------------------------------------------A.8 Technical Summary -------------------------------------------------A.9 Logistics ----------------------------------------------------------------A.10 Schedules---------------------------------------------------------------A.11 Resources---------------------------------------------------------------A.12 Controls -----------------------------------------------------------------A.13 Implementation Approach -----------------------------------------A.14 Acquisition Summary -----------------------------------------------A.15 Program/Project Dependencies -----------------------------------A.16 Agreements ------------------------------------------------------------A.17 Safety and Mission Success---------------------------------------A.18 Risk Management ----------------------------------------------------A.19 Environmental Impact ----------------------------------------------A.20 Test and Verification ------------------------------------------------A.21 Technology Assessment--------------------------------------------A.22 Commercialization---------------------------------------------------A.23 Reviews -----------------------------------------------------------------A.24 Termination Review Criteria --------------------------------------A.25 Tailoring ----------------------------------------------------------------A.26 Change Log ------------------------------------------------------------A-1 A-1 A-1 A-1 A-1 A-1 A-1 A-1 A-1 A-1 A-1 A-1 A-2 A-2 A-2 A-2 A-2 A-2 A-2 A-2 A-2 A-2 A-2 A-3 A-3 A-3 A-3

ISS005-E-20309 (8 November 2002)


Soyuz 5 Commander Sergei Zalyotin looks at a plant growth experiment in the Zvezda Service Module on the ISS.

xiv

Table o f Content s
Appendix B Systems Engineering Management Plan Outline-----------B.1 Description of the System of Interest---------------------------B.2 Description of the Technical Processes-------------------------B.3 Software Developm ent----------------------------------------------B.4 Project Technical Management Processes ---------------------B.5 Organization (Team) Structure -----------------------------------B.6 Other Systems Engineering Concerns --------------------------Appendix C Trace of Project Management Processes to Life Cycle ---Appendix D Project Tailoring Guidelines-------------------------------------Appendix E Terms and Definitions---------------------------------------------Appendix F Acronyms -------------------------------------------------------------Appendix G Photograph Captions-----------------------------------------------Appendix H Spiral Development Process----------------------------------STS111-383-009 (5-19 June 2002)
Astronauts Kenneth D. Cockrell (left) and Paul S. Lockhart, STS-111 mission commander and pilot, participate in one of the STS-111 detailed test objectives (DTOs). The purpose of DTO 694 is to produce ultra-pure water from the Shuttles fuel cell water. This water can replace manifested ultra-pure water supplies, and significantly decrease the mass and volume required to support biotechnology payloads.

B-1 B-1 B-1 B-1 B-1 B-2 B-2 C-1 D-1 E-1 F-1 G-1 H-1

Figures
Chapter 2 2.1-1 Project management scope-----------------------------------------2.4-1 Typical development processes for projects ------------------2.4-2 Project life cycle phases --------------------------------------------2.5-1 Pre-proposal/proposal/implementation approval process------------------------------------------------------2.6-1 Documentation tree --------------------------------------------------Chapter 3 3-1 Pre-Phase A advanced studies diagram-------------------------3-2 Phase A preliminary analysis diagram--------------------------3.3-1 Phase B system definition diagram------------------------------3.3-2 Phase B preliminary design diagram----------------------------3-4 Phase C design diagram--------------------------------------------3-5.1 Phase D development fabrication and integration stage diagram ------------------------------------------3-5.2 Phase D development preparation for deployment stage diagram -----------------------------------------3-5.3 Phase D development deployment and operational verification stage diagram--------------------------3-6 Phase E operations diagram---------------------------------------3-7.1 Off-nominal project termination diagram----------------------3-7.2 Nominal project termination diagram---------------------------Chapter 4 4-1 Exa mple of three levels of system of interest-----------------4-2 Example of enabling systems -------------------------------------4-3 Decomposition of the systems of interest----------------------4-4 Relationship among needs, goals, and objectives------------4.1-1 Requirements development process diagram -----------------4.1-2 Requirements management process diagram -----------------4.1-3 Operational concept development process diagram---------4.1-4 Decomposition process diagram ---------------------------------2-1 2-3 2-6 2-9 2-11

3-3 3-5 3-8 3-9 3-12 3-14 3-15 3-16 3-20 3-23 3-23

STS111-318-030 (5-19 June 2002)


Astronaut Philippe Perrin, STS-111 mission specialist representing CNES, the French Space Agency, looks out an aft flight deck window of Endeavour.

4-2 4-2 4-3 4-3 4-5 4-10 4-13 4-16

xv

Table o f Content s
4.1-5 4.1-6 4.1-7 4.1-8 4.1-9 4.1-10 4.1-11 4.1-12 4.1-13 4.1-14 4.1-15 4.1-16 4.2-1 4.2-2 4.2-3
JSC2003-E-02172 (15 January 2003)
An overall view of the Station flight control room (BFCR) in Houstons Mission Control Center (MCC). A large screen at the front of the room shows astronauts Kenneth D. Bowersox and Donald R. Pettit, Expedition 6 mission commander and NASA ISS science officer, during the missions only scheduled spacewalk.

4.2-4 4.2-5 4.2-6 4.2-7 4.3-1 4.3-2 4.3-3 4.3-4

Feasibility study process diagram--------------------------------Technology planning process diagram -------------------------Design process diagram --------------------------------------------Attainment process diagram---------------------------------------Integration process diagram ---------------------------------------Vee chart-------------------------------------------------------------Technical work and resource management process diagram-------------------------------------------------------Safety and mission success process diagram------------------Control process diagram--------------------------------------------System analysis process diagram --------------------------------Verification process diagram--------------------------------------Validation process diagram----------------------------------------Reviews process diagram ------------------------------------------Resource management process diagram -----------------------The planning process diagram ------------------------------------Documentation and data management process diagram -----------------------------------------------------------------Cost estimating process diagram---------------------------------Performance measurement process diagram ------------------Schedule management process diagram------------------------Project analysis process diagram---------------------------------Acquisition management process diagram --------------------Risk management process diagram------------------------------Configuration management process diagram -----------------Quality management process diagram---------------------------

4-20 4-24 4-28 4-32 4-36 4-37 4-43 4-48 4-54 4-58 4-62 4-66 4-70 4-75 4-77 4-80 4-83 4-87 4-92 4-95 4-98 4-102 4-106 4-111

xvi

Project Management: Systems Engineering & Project Control Processes and Requirements

Introduction

Introduction

Chapter 1 Introduction
This document provides a description of the basic processes and general practice for the development and operation of all projects managed at the Lyndon B. Johnson Space Center (JSC). In addition to the processes and requirements documented here, all projects shall comply with applicable JSC directives and requirements established by applicable law, regulations, Executive Orders, and NASA directives. In the event of a conflict, the NASA directive, Executive Order, regulation, or law (in ascending order) shall have precedence. Over the last ten years, JSC and NASA have undergone many changes, examples of which include the creation of the Center-level Systems Management Offices and the Headquarters-level Chief Financial Officers Cost Analysis Division, an increased emphasis on risk management and the use of probabilistic risk analysis (PRA) and cost assessment requirements description (CARD) documentation. One of the more visible and significant changes is that the Agency has evolved a strategic planning process that is based on a family of Enterprises. JSC has also created new offices and processes to implement Agency, Congress, and White House input and direction. Similarly, NASA program and project development and management have evolved as documented in NASA Procedures and Requirements (NPR) 7120.5B, NASA Program and Project Management Processes and Requirements. The Agency has also developed interim guidance related to systems engineering (SE) as documented in draft NPR 71xx.x (document number not yet assigned), NASA Systems Engineering Processes and Requirements. These changes have been put in place to ensure that programs and projects are not only in concert with the Enterprise efforts, but are also efficiently and consistently planned, budgeted, and executed. Additional guidelines e.g., risk management, software-independent verification and validation (IV&V), logistics management, and export control have also been put in place for similar purposes. Another significant change has been that both the Agency and JSC have implemented the International Organization of Standardization (ISO) 9000 Quality Management System. This system is the day-to-day process by which JSC implements the requirement to continually improve Center processes, products, and services, and to use measurable objectives to establish the quality of its work. JSC has documented this in JSC Procedures and Guidelines (JPG) 5335.3, JSC Quality Management System Quality Manual. As part of this continual improvement effort, JSC has made a number of additional critical decisions on project processes and product control. These include: Implementing JSC Policy Directive (JPD) 8090.1, Systems Engineering Policy

Implementing JPC 7120.2, JSC Project Management Council Implementing this document, JPG 7120.3, Project Management: Systems Engineering and Project Control Processes and Requirements Implementing JPD 7120.1, JSC Project Management Policy Aligning the SE processes to be used at JSC with interim Agency guidance and industry standards, practices, and maturity models such as the Electronic Industries Alliance (EIA)-632, Processes for Engineering a System, the INCOSE Systems Engineering Handbook, and the Capability Maturity Model Integration (CMMI) for Systems Engineering, Software Engineering, Integrated Product and Process Development, and Supplier Sourcing and documenting them in this publication. This document therefore combines, in coordination with the JSC Management System and the JSC organizational structure, project management, project control and SE principles and practices. It does this in a fashion compatible with the previously mentioned Agency project management and SE guidelines and directives. In this document, a requirement is identified by a shall, a good practice by a should, permission by a may or a can, expectation by a will, and descriptive material by an is. 1.1 Purpose The purpose of this document is to define Centerwide processes, practices, and product requirements to support the planning, operations, and management of projects at JSC. This document provides overall direction and processes to be followed by all projects and project team members at JSC. 1.2 Applicability and Scope This document has been developed to ensure a common understanding and documentation of the processes, practices, and procedures that shall be required for development and integration of all hardware and software projects at JSC. These projects include activities in the areas of space flight system development, advanced technology development, advanced studies, institutional support operations, and any combination thereof. It also serves as an informationonly source for activities such as: Basic and applied research investigations that are part of a portfolio (per NPR 7120.5C) Small Business Innovation Research (SBIR) Center Director Discretionary Fund (CDDF) funded projects

1-1

Project Management: SE & Project Control Processes & Requirements

Space Act Agreements that do not exceed $100,000 (including civil service labor, facilities, and materials cost) Research and Technology Objectives and Plans The JSC Center Director is accountable for JSC support to projects managed by Agency programs. As such, JSC activities and JSC projects managed by Agency programs shall follow the processes stipulated in this document. Any disagreements that may arise between the requirements of this document and direction provided by the program(s) shall be brought forward to the JSC Engineering Review Board (ERB) for clarification on the potential level of risk being assumed. The ERB chairperson and the appropriate program manager will discuss the issue and resolve it. Final resolutions shall be appropriately documented in the project management plan and project-customer agreements (e.g., ITAs, MOUs, and Class 1 deliverables). While basic common processes and general practices are discussed in this document, project managers, working with their project team members, should tailor implementation to the specific needs of the project consistent with the project scope, visibility, cost, complexity, criticality, and risk. For purposes of this document, tailoring should be considered to be a method to encourage innovation and achieve products in an efficient manner while still meeting the expectations of the customer. Tailoring approaches shall be coordinated with all affected parties as early as pos-

sible and documented in the project management plan (PMP) for approval, as a minimum, and the program commitment agreement (PCA) and program plan, as appropriate. 1.3 1.3.1 Authority Per NPR 7120.5B, paragraph P2.4, Each Center is responsible for developing and implementing the Center-level policies, processes, procedures, and requirements necessary to ensure successful program/project execution. Per NPR 71xx.x (document number not yet assigned), paragraph 2.4, Each Center is responsible for developing and implementing Center-level policies, processes, procedures and requirements necessary to ensure successful execution of the processes and requirements according to this document. Per JPD 8090.1, The JSC Office of the Chief Engineering is responsible for: 1) Establishing policy, requirements, and guidelines for systems engineering processes and products for the development and operation of JSC systems. Per JPD 7120.1, The JSC Chief Engineer is responsible for: 1) Serving as the process steward for JSC project management, including development and maintenance of JSC project management procedures and guidelines that are compliant with Agency policies and the JSC quality management system.

1.3.2

1.3.3

1.3.4

1-2

Introduction

1.4

References
Paragraph 4.3.2.12

1.4.1 External Documents Number Title AD-A319533KKG, Continuous Risk Management Guidebook DTIC#: AD-A319 533\6\ XAB ANSI/AIAA G-043Guide for Preparation of Operational Concept 1992 Documents CMMICapability Maturity Model Integration (CMMI) for SE/SW/IPPD/SS Systems Engineering, Software Engineering, Integrated Product and Process Development, and Supplier Sourcing

4.1.3.12 1, 4.1.1.6, 4.1.1.7, 4.1.1.10, 4.1.1.11, 4.1.1.12, 4.1.2, 4.1.2.2, 4.1.2.4, 4.1.2.6, 4.1.2.7, 4.1.2.8, 4.1.2.11, 4.1.2.12, 4.1.3.1, 4.1.3.6, 4.1.3.7, 4.1.3.12, 4.1.4.5, 4.1.4.6, 4.1.4.7, 4.1.4.10, 4.1.4.12, 4.1.7.12, 4.1.8, 4.1.8.12, 4.1.9, 4.1.9.2, 4.1.9.5, 4.1.9.6, 4.1.9.12, 4.1.10.6, 4.1.10.7, 4.1.10.12, 4.1.11.12, 4.1.12.6, 4.1.12.12, 4.1.13, 4.1.13.6, 4.1.13.12, 4.1.14.12, 4.1.15.6, 4.1.15.12, 4.3.1.1, 4.3.1.4, 4.3.1.5, 4.3.1.6, 4.3.1.8, 4.3.1.10, 4.3.1.12, 4.3.2, 4.3.2.12, 4.3.3.6, 4.3.3.7, 4.3.3.12, 4.3.4, 4.3.4.6, 4.3.4.7, 4.3.4.12, App. E App. E 1, 4.1.1, 4.1.1.2, 4.1.1.5, 4.1.1.11, 4.1.1.12, 4.1.2.4, 4.1.2.7, 4.1.2.11, 4.1.2.12, 4.1.3.6, 4.1.3.7, 4.1.3.8, 4.1.3.12, 4.1.4.6, 4.1.4.7, 4.1.4.8, 4.1.4.12, 4.1.7, 4.1.7.11, 4.1.7.12, 4.1.8, 4.1.8.7, 4.1.8.12, 4.1.9.2, 4.1.9.5, 4.1.9.6, 4.1.9.12, 4.1.11.12, 4.1.12.6, 4.1.12.12, 4.1.13, 4.1.13.10, 4.1.13.11, 4.1.13.12, 4.1.14.1, 4.1.14.12, 4.1.15, 4.1.15.1, 4.1.15.12, 4.2.5, 4.2.5.1, 4.2.5.12, 4.3.1.6, 4.3.1.7, 4.3.1.9, 4.3.1.12, 4.3.3.12 4.1.10, 4.1.10.12, 4.1.13.4, 4.1.13.12, 4.3.4, 4.3.4.2, 4.3.4.7, 4.3.4.8, 4.3.4.10, 4.3.4.11, 4.3.4.12 4.2.5, 4.2.5.1, 4.2.5.12 4.2.7, 4.2.7.12 App. E

EIA-632

CMMI Project Planning Process Processes for Engineering a System

EIA-731.1

Systems Engineering Capability Model

EIA-748A EIA-748-98 IEEE 1220-1998

ISO 9001:2000 MIL-HDBK-340A, Vols. 1 and 2 SP 800-12 SWELT:RM0.2

Earned Value Management Systems Industry Guidelines for Earned Value Management Systems Institute of Electrical and Electronic Engineers (IEEE) Standard for Application and Management of Systems Engineering Processes Quality Management Systems Requirements Test Requirements for Launch, Upper Stage and Space Vehicles An Introduction to Computer Security: the NIST Handbook (Web page) Requirements Management Guidebook Analysis of Automated Requirements Management Capabilities

4.3.4, 4.3.4.12 2.4.2.4 4.3.2.12 4.1.2.4, 4.1.2.7, 4.1.2.11, 4.1.2.12 4.1.14.12, 4.1.15.12

1-3

Project Management: SE & Project Control Processes & Requirements

Number

Title Customer-Centered Products Expert Choice, Inc. (Web page) Fundamentals of Project Management INCOSE Systems Engineering Handbook

Project Management Toolbox Risk Management Guide for DoD Acquisition System Engineering Fundamentals Visualizing Project Management W. Lilly Project Control Study for the National Academy of Public Administration (NAPA)

Paragraph 4.0.1, 4.1.2.4, 4.1.2.7, 4.1.2.11, 4.1.2.12 4.1.5.12 4.2.2, 4.2.2.12 1, 4.1.1.5, 4.1.1.7, 4.1.1.8, 4.1.1.10, 4.1.1.11, 4.1.1.12, 4.1.2.2, 4.1.2.4, 4.1.2.5, 4.1.2.7, 4.1.2.11, 4.1.2.12, 4.1.3.2, 4.1.3.5, 4.1.3.6, 4.1.3.7, 4.1.3.8, 4.1.3.9, 4.1.3.10, 4.1.3.12, 4.1.4.2, 4.1.4.6, 4.1.4.7, 4.1.4.8, 4.1.4.9, 4.1.4.10, 4.1.4.11, 4.1.4.12, 4.1.6.6, 4.1.6.12, 4.1.7, 4.1.7.3, 4.1.7.5, 4.1.7.10, 4.1.7.12, 4.1.8.3, 4.1.8.10, 4.1.8.12, 4.1.9.5, 4.1.9.10, 4.1.9.11, 4.1.9.12, 4.1.11.12, 4.1.12.10, 4.1.12.11, 4.1.12.12, 4.1.13.9, 4.1.13.11, 4.1.13.12, 4.3.1.7, 4.3.1.12, 4.3.3.12, 4.3.4.6, 4.3.4.12 4.2.2, 4.2.2.12, 4.2.4, 4.2.4.12, 4.2.5, 4.2.5.12, 4.2.6, 4.2.6.12 4.3.2.12 4.1.3.10, 4.1.3.12, 4.1.4.2, 4.1.4.5, 4.1.4.10, 4.1.4.12, 4.1.13.12 4.2.2, 4.2.2.12, 4.2.6, 4.2.6.12 2.1

1.4.2 Number

NASA Documents Title Full Cost Initiative Agencywide Implementation Guide (Web page) KHB 1700.7 KSC Payload Ground Safety Handbook NASA-GB-1740.13- NASA Guidebook for Safety Critical Software 96 Analysis and Development NASA-STD-2100-91 NASA Software Documentation Standard NASA-STD-2201-93 Software Assurance Standard NASA-STDSoftware Safety NASA Technical Standard 8719.13A NASA-STD-8739.8 Software Assurance NASA-STD-8739 series Next-Generation Space Telescope (NGST) (Web page) NMI 7234.1 Facilities Utilization Program NPD 1280.1 NASA Management System Policy NPD 1440.6G NASA Records Management NPD 1441.1D NASA Record Retention Schedule NPD 2190 NASA Export Control Program NPD 2820.1 NASA Software Policies NPD 7330.1F Approval Authorities for Facilities Projects

Paragraph 4.2.1, 4.2.1.12, 4.2.2.7 4.1.11.6, 4.1.11.12 4.1.11.6, 4.1.11.12 4.1.11.6, 4.1.11.12 4.1.11.1, 4.1.11.6, 4.1.11.12 4.1.11.6, 4.1.11.12 4.1.11.6 4.1.11.12 4.1.6.6, 4.1.6.12 2.5.3.2 4.3.4, 4.3.4.2, 4.3.4.12 4.2.6, 4.2.6.12 4.2.3, 4.2.3.12 2.7.3.8 2.6, 4.1.11.6 2.4.1.4, 2.6

1-4

Introduction

Number NPD 7500.1 NPD 8010.2 NPD 8010.3 NPD 8730.4 NPD 8800.14B NPD 8810.2 NPD 8820.2A NPD 8820.3 NPD 8831.1D NPD 9501.3A NPR 1440.6G NPR 2190.1 NPR 71xx.x

Title Program/Project Logistics Metrics System Notification of Intent to Terminate Operating Space Systems NASA Software Independent Verification and Validation (IV&V) Policy Policy for Real Property Management Master Planning for Real Property Design and Construction of Facilities Facility Sustainable Design Management of Institutional and Program Facilities and Related Equipment Earned Value Performance Management Records Management Export Control NASA Systems Engineering Processes and Requirements (document number not yet assigned)

Paragraph 2.6 2.6 2.6, 3.7, 3.7.5.2, 3.7.7 2.6, A.20 2.4.1.4 2.4.1.4 2.4.1.4, 2.6 2.4.1.4, 2.6 2.4.1.4, 2.6 4.2.5, 4.2.5.1, 4.2.5.12 2.6 2.6 1, 1.3, 4.0.1, 4.1.1, 4.1.1.1, 4.1.1.11, 4.1.1.12, 4.1.2, 4.1.2.1, 4.1.2.4, 4.1.2.7, 4.1.2.11, 4.1.2.12, 4.1.3, 4.1.3.1, 4.1.3.7, 4.1.3.12, 4.1.4, 4.1.4.1, 4.1.4.7, 4.1.4.12, 4.1.5, 4.1.5.1, 4.1.5.12, 4.1.6, 4.1.6.1, 4.1.6.6, 4.1.6.12, 4.1.7, 4.1.7.1, 4.1.7.2, 4.1.7.5, 4.1.7.8, 4.1.7.12, 4.1.8, 4.1.8.1, 4.1.8.2, 4.1.8.4, 4.1.8.5, 4.1.8.12, 4.1.9, 4.1.9.1, 4.1.9.12, 4.1.10, 4.1.10.1, 4.1.10.2, 4.1.10.12, 4.1.11, 4.1.11.1, 4.1.11.12, 4.1.12, 4.1.12.1, 4.1.12.12, 4.1.13, 4.1.13.1, 4.1.13.12, 4.1.14, 4.1.14.1, 4.1.14.12, 4.1.15, 4.1.15.1, 4.1.15.12, 4.1.16, 4.1.16.1, 4.1.16.12, 4.3.1, 4.3.1.1, 4.3.1.2, 4.3.1.6, 4.3.1.12, 4.3.2.1, 4.3.2.12, 4.3.3, 4.3.3.1, 4.3.3.12, 4.3.4, 4.3.4.1, 4.3.4.12, App. E 1, 1.3, 2.4.2.4, 2.6, 3.2, 3.2.7, 3.3, 3.3.7, 3.4, 3.4.7, 3.5, 3.5.7, 3.6, 3.6.7, 4.1.6, 4.1.6.1, 4.1.6.3, 4.1.6.12, 4.1.9.6, 4.1.9.12, 4.1.10.12, 4.1.11.1, 4.1.11.2, 4.1.11.12, 4.1.12.10, 4.1.12.12, 4.1.13, 4.1.13.12, 4.1.14, 4.1.14.12, 4.1.15.12, 4.2.1, 4.2.1.12, 4.2.4, 4.2.4.12, 4.3.1, 4.3.1.1, 4.3.1.2, 4.3.1.3, 4.3.1.6, 4.3.1.12, 4.3.2.5, 4.3.2.12, 4.3.3.12, 4.3.4, 4.3.4.12, App. A, A.18, B.4, App. E App. E 2.6, 4.3.2, 4.3.2.6, 4.3.2.10, 4.3.2.12, A.18 4.1.7.6

NPR 7120.5B

NASA Program and Project Management Processes and Requirements

NPR 7120.5C NPR 8000.4 NPR 8705.2

NASA Program and Project Management Processes and Requirements (Draft) Risk Management Procedures and Guidelines Human-Rating Requirements and Guidelines for Space Flight Systems

1-5

Project Management: SE & Project Control Processes & Requirements

Number NPR 8820.2E NPR 8831.2D NPR 9501.3 NSTS 13830 NSTS 1700.7 NSTS 1700.7 Addendum NSTS 5300.4(1D-2) RP 1358

Title Facility Project Implementation Guide Facilities Maintenance Management Earned Value Management Implementation on NASA Contract Payloads Safety Review and Data Submittal Requirements Safety Policy and Requirements for Payloads Using the STS Safety Policy Requirements for Payloads Using the International Space Station Safety, Reliability, Maintainability, and Quality Provisions for the Space Shuttle Program Systems Engineering Toolbox for Design-Oriented Engineers

Paragraph 2.4.1.4, 2.6 2.4.1.4, 2.6 4.2.7, 4.2.7.12 4.1.11.6, 4.1.11.12 4.1.11.6, 4.1.11.12 4.1.11.6, 4.1.11.12 4.1.11.6 2.6, 4.1.1.11, 4.1.1.12, 4.1.2.4, 4.1.2.7, 4.1.2.11, 4.1.2.12, 4.1.5.10, 4.1.5.12, 4.1.6.10, 4.1.6.12, 4.3.2.10, 4.3.2.12 2.3, 4.2.1, 4.2.1.12, 4.2.4, 4.2.4.12 2.4.2.4, 2.6, 3, 3.1, 3.1.7, 3.2, 3.2.7, 3.3, 3.3.7, 3.4, 3.4.7, 3.5, 3.5.7, 3.6, 3.6.7, 4.1.1.11, 4.1.1.12, 4.1.2.4, 4.1.2.7, 4.1.2.11, 4.1.2.12, 4.1.4.2, 4.1.4.3, 4.1.4.7, 4.1.4.10, 4.1.4.12, 4.1.5.1, 4.1.5.12, 4.1.6.4, 4.1.6.12, 4.1.7, 4.1.7.3, 4.1.7.6, 4.1.7.8, 4.1.7.12, 4.1.8.5, 4.1.8.6, 4.1.8.7, 4.1.8.12, 4.1.9.3, 4.1.9.6, 4.1.9.7, 4.1.9.12, 4.1.10.3, 4.1.10.5, 4.1.10.10, 4.1.10.12, 4.1.11, 4.1.11.1, 4.1.11.6, 4.1.11.12, 4.1.12.2, 4.1.12.12, 4.1.13, 4.1.13.2, 4.1.13.3, 4.1.13.6, 4.1.13.7, 4.1.13.10, 4.1.13.12, 4.1.16.1, 4.1.16.2, 4.1.16.4, 4.1.16.5, 4.1.16.6, 4.1.16.7, 4.1.16.8, 4.1.16.12, 4.2.4, 4.2.4.12, 4.2.6, 4.2.6.12, 4.3.1.5, 4.3.1.7, 4.3.1.10, 4.3.1.12, 4.3.3, 4.3.3.3, 4.3.3.12, 4.3.4.3, 4.3.4.12, App. E 4.1.11.6 4.1.11.6, 4.1.11.12 4.3.2.12 4.2.4, 4.2.4.12, 4.2.7, 4.2.7.12 4.3.2.12 4.1.6.12

SP 6103 SP 6105

NASA Readings in Project Control NASA Systems Engineering Handbook

SSP 41173 SSP 50038 SSP 51079

WSP 09-0014

Space Station Program Quality Assurance Requirements Computer-Based Control System Safety Requirements International Space Station Program Risk Management Plan NASA Cost Estimating Handbook 2002 (Web page) Probabilistic Risk Assessment Procedures Guidebook for NASA Managers and Practitioners Technology Readiness Levels: A White Paper Project Management

1-6

Introduction

1.4.3 JSC Documents Number Title AG-CWI-001 JSC Lessons Learned Process CWI J29W-01 JSC Export Compliance JMI 2314.2L Identifying and Processing JSC Scientific, Technical and Administrative Documents JMI 5150.5F Processing of JSC Procurements Through Delivery, Acceptance and Payment Stages JMI 5151.5B Management of Support Contracts JPC 7120.2 JSC Project Management Council JPD 1382.1H Release of Information to News Media JPD 1382.4K Freedom of Information Act (FOIA) JPD 2200.1A Release of JSC Scientific and Technical Information to External Audiences JPD 5335.1 JSC Quality Policy JPD 7120.1 JSC Project Management Policy JPD 8090.1 JSC Systems Engineering Policy JPG 1440.3 JSC Files and Record Management Procedures JPG 1700.1 JPG 5335.2 JPG 5335.3 JPG 8080.5 JSC Announcement 02-035 JSC-24937 LA-CWI-01 SLP 4.6 SLP 4.20 JSC Safety and Total Health Handbook Space Act Agreements JSC Quality Management System Quality Manual JSC Design and Procedural Standard Manual Charter of the Engineering Review Board JSC Earned Value Management Handbook Limited Life Time Cycle Items Program Requirements Document Budget Planning Process Procurement Process Measurement and Improvement JSC Cost Estimating (Web page)

Paragraph 4.3.4.6, 4.3.4.12 2.7.3.8 4.2.3, 4.2.3.12 4.3.1.12 4.3.1.12 1, 2.5.3.3 2.7.3.17 2.7.3.17 4.2.3, 4.2.3.12 4.3.4, 4.3.4.12 1, 1.3, 2.6 1, 1.3, 2.6 2.7.2.10, 4.2.3, 4.2.3.12, 4.2.6, 4.2.6.12 4.1.11.6, 4.1.11.12 4.3.1.1, 4.3.1.3, 4.3.1.12 1, 4.1.11.6, 4.3.4, 4.3.4.3, 4.3.4.12 4.1.11.6 2.5.3.1 2.6 4.1.11.6, 4.1.11.12 4.2.1.6 4.3.1.1, 4.3.1.3, 4.3.1.12 4, 4.2.1.10, 4.3.3.10, 4.3.3.12 4.1.12.11, 4.1.13.12

1.5 None.

Cancellation

1-7

Project Management: Systems Engineering & Project Control Processes and Requirements

Overview of Project Management at JSC

Overview of Project Management at JSC

Chapter 2 Overview of Project Management at JSC


2.1 Scope Project Management is the function of planning, overseeing, and directing the numerous activities required to achieve the requirements, goals, and objectives of the customer within specified cost, quality, and schedule constraints. The scope of project management includes two major areas of emphasis, both of equal weight and importance. These areas are systems engineering (SE) and project control. It is critical for the success of the project that the project management team understands that both major areas must be successfully implemented and continually used throughout the project life cycle. Definitions for SE and project control, as well as the main content areas under each, are depicted in Figure 2.1-1.

(product or service). The emphasis is on achieving stakeholder functional, physical, and operational performance requirements in the intended use environments over the planned life of the system and within cost and schedule constraints. SE includes the engineering and technical management processes that consider the interface relationships across all elements of the system or other systems, or as part of a larger system. The SE function systematically considers all technical aspects of a project in making design choices and is a continuous, iterative process that is used throughout the life cycle of the project. These iterative efforts result in the best system architecture, design, manufacturing, and operations possible for the given cost and schedule constraints. The success of every Johnson Space Center (JSC) project is highly dependent on the SE process being properly exercised at all levels of design and across all phases of the project life cycle.

Project Management
A disciplined approach for the definition, implementation, integration, and operation of a system (product or service). The emphasis is on achieving stakeholder functional, physical, and operational performance requirements in the intended use environment over its planned life. SE includes the engineering processes and technical management processes that consider the interface relationships across all elements of the system, other systems, or as part of a larger system. 1 Systems requirement development and management Operations concept development Systems architecture development (decomposition, feasibility studies, design, attainment, technology planning, systems analysis) Integration, verification, validation, safety, and mission success SE management (technical work and resource management, control, reviews)

Systems Engineering

Configuration management Risk management Acquisition management Quality management

Total management process of establishing and maintaining project baselines for project content, scope, configuration, schedule, and cost. 2 Resource management Planning Project analysis Documentation and data management Schedule management Performance measurement Cost estimating

Project Control

1NASA 2From

Systems Engineering Working Group Definition, Draft SE NPR 12/2002. W. Lilly Project Control Study for the National Academy of Publication Administration (NAPA), 1989.

Figure 2.1-1. Project management scope. 2.2 Systems Engineering SE is a disciplined approach for the definition, implementation, integration, and operation of a system 2.3 Project Control Project control is the total management process of establishing and maintaining project baselines and

2-1

Project Management: SE & Project Control Processes & Requirements

effectively supporting the project manager in meeting the overall objectives of the project. It functions in both a proactive and a reactive context. The proactive aspects of project control include baseline control of project processes and control of the project management plan and its changes over the life cycle. An ex ample of such a proactive aspect might be identification of process trends that may eventually lead to problems in meeting cost or schedule. Reactive aspects of project control include performance measurement and control, and management of variances to the project cost and schedule. This includes taking corrective actions for these variances. The success of projects depends on disciplined attention to numerous planning, resource, and scheduling variables, and the integration and optimization of interrelated activities. Project control ensures that project objectives are met by monitoring and measuring progress regularly to identify variances from plan. Corrective action can then be taken when necessary. For example, systematic attention to the implications of variances between planned baselines and actual performance on projects is critical to taking early remedial action, thereby reducing costly delays and increasing the probability of achieving success. Additional detailed background discussions on project control experiences can be found in Special Publication (SP) 6103, NASA Readings in Project Control . 2.4 Project Types, Approaches, and Life Cycle Phases This section addresses two related but distinct subjects. First, in Section 2.4.1, the various types of project implementations at the center are presented along with their defining characteristics. This is followed by a discussion, in Section 2.4.2, of the important subject of identifying and selecting the appropriate project approach to improve the likelihood of achieving project success. The project life cycle is presented in Section 2.4.3. 2.4.1 Project Types A discussion of the types of projects at JSC needs to be prefaced with an understanding that most, if not all projects, involve one or more of the listed project types at some point during the project life cycle. The determination of what type of project designation is most appropriate is based on the intended final product and the project approach used to complete it. The list of project types includes: Space flight system development project Advanced technology development project Science research, applied research, or advanced studies project

Institutional project Operations project 2.4.1.1 Space flight system development projects Space flight system development projects are generally those hardware (H/W) and/or software (S/W) projects that result in an end product for flight into space. These items may include products for flight experiments, flight crew equipment, or detailed test objectives (DTOs). A common characteristic of a space flight system development project is often a waterfall development process, as shown in Figure 2.4-1. 2.4.1.2 Advanced technology development projects Advanced technology development projects are those H/W and/or S/W projects characterized by an end product for use in test or demonstration of a design concept(s). These intended final products may or may not result in a product to be operated in space or on an aircraft. The development of these products can be characterized by a spiral development process, as shown in Figure 2.4-1. A larger view of the spiral detail is provided in Appendix H. Examples of this type of project at JSC include Robonaut and the variable specific impulse magnetoplasma rocket (VASIMR). 2.4.1.3 Science research, applied research, and advanced studies Science research and applied research projects are efforts that are intended to answer, or at least to address, fundamental research or development questions. Basic research can thus be understood to have no direct or foreseen applications. Applied re search is most commonly an effort to develop advanced prototype H/W and/or S/W. Advanced studies examine the feasibility of approaches to a design problem or an operational alternative. Examples of advanced studies include studies performed to support strategic planning formulation. Since these final products are commonly developed based on a pay as you go level of effort (LOE) process tied to funding availability, the development effort may vary from year to year. Because of the diverse scope and unique selection and review process for fundamental, applied research and advanced studies projects, a modified management approach is warranted. The end goals of research projects often do not fit the life cycle definitions shown here. However, sub-projects within a research project may fit within these requirements. Examples include the development of research facilities, test rigs, mockups, and other research equipment.

2-2

Overview of Project Management at JSC

PROJECT TYPE Space Flight System Development Waterfall development

TYPICAL DEVELOPMENT PROCESS

Advanced Technology Development

Spiral development based on technology readiness level (TRL)

Science and Applied Research

Pay as you go level of effort (LOE) typically sub-TRL 3 activities

Institutional

Either 1) Waterfall 2) Spiral 3) LOE Either 1) Waterfall 2) Spiral 3) LOE

Operations

Figure 2.4-1. Typical development processes for projects. 2.4.1.4 Institutional Institutional projects are the buildings, site infrastructure, and H/W and/or S/W development efforts that culminate in an end product that supports a mis sion-critical infrastructure or Center-operational function. Examples of this project type include typical construction of facilities (CofF), Center-funded construction, infrastructure modification (e.g., telephone system), or education efforts (e.g., KC-135 Student Program, etc.). It also includes technical support system development such as the design and data management system (DDMS), Mission Control Center (MCC) local area network (LAN) upgrade, or aircraft H/W and S/W development efforts. The CofF and associated support projects have a unique feature among institutional project types since they already have an existing set of project management processes, practices, and requirements. These include: NASA Policies and Directives (NPD) 7330.1F, Approval Authorities for Facilities Projects NPD 8800.14B, Policy for Real Property Management NPD 8810.2, Master Planning for Real Property NPD 8820.2A, Design and Construction of Facilities NASA Procedures and Requirements (NPR) 8820.2E, Facility Project Implementation Guide NPD 8831.1D, Management of Institutional and Program Facilities and Related Equipment NPR 8831.2D, Facilities Maintenance Management NPD 8820.3, Facility Sustainable Design In addition, the current versions of NPR 8820.3 and NPR 8820.2E require an engineering-procurement-construction (EPC) approach to facility delivery, commonly referred to as a design-bid-build process using performance-based, fixed-price contracts. Facilities and associated support projects shall be exempt from the requirements documented herein, with the exception of the various project management forums discussed in Section 2.5, because of the EPC approach, the existing laws and regulations concerning design and construction standards, and the existing body of knowledge and practice in this area. 2.4.1.5 Operations Operations projects are those building, site infrastructure, and H/W and/or S/W development efforts that provide a foundation for future development and research to use or build on. This project type is typically characterized by the following major points:

2-3

Project Management: SE & Project Control Processes & Requirements

The vast majority of the life of the project is spent in the operations phase. The project product functions as a facility to allow additional H/W and/or S/W to be added, where this new S/W could accomplish an asyet-unspecified new mission. The project management team makes decisions on a life cycle basis, as opposed to a near-term problem-resolution focus. Activities such as a preplanned product improvement (P3 I) effort may be part of the core project. The project management process has a clear understanding of not precluding future as-yet-unspecified H/W and/or S/W modifications. It should be understood that while the operations project H/W and/or S/W may have been developed under a space flight system waterfall process, an advanced technology spiral process, or even an LOE process, the project type is considered operations due to the role of a support facility for additional future capabilities. Examples of this project type include the Space Station Training Facility, the Hubble Space Telescope, and, at a program level, the Space Shuttle Program and the International Space Station Program. 2.4.2 Project Approaches Given the project need and real-world constraints, the project team, stakeholders, and customer must identify the project approach that will most likely achieve success. It is critical that discussions of project approach include all stakeholders and customers, and that consensus results are formally documented in the project management plan (PMP) prior to authorization to proceed (ATP).* (See Section 2.5.3.3 for a discussion of the ATP process.) Development and implementation of the approach of the project is the responsibility of the project manager and the project management team. For JSC projects, some characteristics for success should be implemented to the maximum extent possible. These include: The maximum use of contractor documentation and processes, once these have been determined to meet or exceed government-equivalent items, for contractor-supported/NASA -managed projects A very close contractor/NASA working relationship for all team members, especially including the NASA contracting officer, for contractorsupported/NASA-managed projects
*

An agreed-to-, documented minimum project documentation/deliverables list An agreed-to, documented minimum content for each project documentation/deliverable An absolute minimum set of requirements for the project (both stated and implied) An extremely aggressive effort to minimize requirement changes/additions over the life of the project A documented, agreed-to minimum amount of reporting and statusing to customer, Center, Agency, or external forums Each technical area should include technically experienced team members who are capable of successfully working with others A rapid but well-documented, streamlined change order review, approval, and implementation process A rapid but well-documented H/W and/or S/W modification process Collocation of the entire team to the greatest extent possible Maximum use of information technology (IT) resources to increase the productivity of each team member The project approach is developed by carefully considering, discussing, and selecting from several sets of supportive options. Elements of project approach to consider include: Staffing Type of contract Magnitude Implementation approach Degree of implementation of the characteristics for success previously mentioned Customer desires The potential breadth of answers to these discussions clearly shows the wide variation possible in many aspects of the project (e.g., deliverables), and the resulting impact to project schedules and resources. 2.4.2.1 Staffing One of the first project approach discussions shall be the level of civil service involvement. This would include whether the project will be a governmentfurnished equipment (GFE)/data project (i.e., accomplished solely by civil service technical development), a contractor-developed/NASA-managed project, or a project that is a combination of both. 2.4.2.2 Type of contract If the project requires contractor support, the next question that needs to be addressed is the type of contract to be used.

ATP is a formal approval provided by the JSC Project Management Council (PMC) to implement a JSC project. This approval marks a commitment by the Center to execute the project within the plans and resource envelopes authorized at the time approval is given.

2-4

Overview of Project Management at JSC

2.4.2.3 Magnitude Still another supportive option to consider in developing the project approach is the overall life cycle cost estimate for the project. A project estimated to cost less than $1M could, and probably should, have a simpler project management approach than a project costing greater than $10M. The selected project approach should be tailored to effectively manage and achieve the individual project. This could include reduced project team size, increased use of Web-based SE and project control applications, increased use of IT resources to support project decision making, reduced number of project deliverables, reduced content of the agreed-to list of project deliverables, etc. Dis cussion of the budget-driven project tailoring should be a significant factor in the development of the PMP, schedules, and deliverables. For example, for a small project under $1M it may be technically acceptable to combine the Preliminary Design Review (PDR) and Critical Design Review (CDR). In contrast, a large project greater than $10M may require not only a PDR and a CDR, but also H/W PDRs and CDRs separate from S/W PDRs and CDRs. In that case, integrated system PDRs and CDRs would be required as well. As the reader call tell, the budget-driven project tailoring approach is a key discussion when planning and defining a project. 2.4.2.4 Implementation approach For space flight systems and advanced technology development projects, the project management team shall consider whether the project approach is a baseline approach, an X-project approach, a protoflight approach, or a protoqual approach. Each of these approaches is discussed further in this document. This document focuses primarily on the baseline approach. It shall be considered the default standard approach to be used by JSC projects. Although the other approaches are acceptable alternatives, the rationale for any alternate tailored approach must be documented in the PMP. It is of special importance, however, that the project team understands that use of other than a baseline approach needs to be discussed and concurred with by the customer, directorate, and Center management as early as possible in the project formulation efforts and prior to ATP. a) Baseline approach A baseline approach can be considered to be a project following a standard life cycle and providing a complete project deliverables set such as is discussed in SP 6105, NASA Systems Engineering Handbook , and the latest version of NPR 7120.5B, NASA Program and Project Management Processes and Requirements. This includes planning and documentation development (e.g., trade studies,

PMP, acceptance test plan, system documentation, etc.). It begins at Pre-Phase A or Phase A and continues on until termination of the project. A tailored baseline approach is generally the default approach for institutional and operational projects based on NPRs and NPDs for facilities. b) X-project approach An X-project approach is an option when the project management and the customer are willing to accept an increased level of risk, above that of the baseline approach, in meeting cost, schedule, and performance requirements for the project. Normally, this fast-paced approach is appropriate when the project incre mentally builds on past development efforts and pushes the technological boundaries in only one or two well-defined areas. Typically, X-project types exhibit all of the characteristics for project success discussed earlier. c) Protoflight approach A protoflight approach is an option to consider when the project/program is also willing to accept an increased level of risk above the baseline approach, and when there are other factors that would make non-baseline approaches desirable. An example of this might be the need to develop a quick reaction capability to solve an urgent problem within an operational system. A protoflight approach requires a test program that combines the objectives of the qualification and acceptance test programs with the understanding that all protoflight components and assemblies are intended for subsequent flight use. The protoflight approach uses agreed-to and documented reduced test levels, cycles, and/or durations from the standard qualification test requirements. This is intended to allow the protoflight-tested H/W to be used later for flight. This approach is not intended, nor it is acceptable, to be used as a standard lower-cost, faster alternative to the baseline qualification and acceptance test programs. A protoflight approach has a higher level of technical risk approach as compared to a full qualification test program due to there being no demonstrated flight duration capability (i.e., number of cycles, or time or operation or exposure to the service environment) and, in some cases, lower demonstrated margins over the service environment extremes. A key characteristic of a protoflight approach is that there is a significant amount of discussion with the customer prior to accepting this higher-risk approach as documented in the PMP. d) Protoqual approach A protoqual approach is another increased-risk alternative approach

2-5

Project Management: SE & Project Control Processes & Requirements

from the baseline flight qualification and acceptance testing approach. A protoqual approach is very similar to a protoflight approach, except that a modified qualification test program is conducted only on a single item, and that test item is considered available for flight. The normal full acceptance test program is then conducted on all other items intended for flight. Additional information regarding both the protoflight and the protoqual approaches can be obtained in MIL-HDBK-340A, Vols. 1 and 2, Test Requirements for Launch, Upper Stage and Space Vehicles. 2.4.3 Project Life Cycle Phases All JSC project activities shall use the same project life cycle phase template to manage their efforts. This template shall consist of an interval-based approach, defined by the completion of various activities and products, as well as successful completion of the respective control gate at the end of the stage or phase. This control gate will be a defined management and/ or technical milestone in the development of the project and will be documented in the PMP (see FIG. 2.4-2). Documentation of these life cycle phases, their respective activities and products, and their control gate serves as a common template for project management efforts throughout the life of the project. Because of the wide diversity of project types at JSC, it is important to understand the intent behind each activity, phase, and stage to identify the applicable processes and control gates. While the terminology may not be identical across all project types, the intent is the same. For example, for research projects,
Control Gates Life Cycle Phase Stage Objective Pre-Phase A (Advanced Studies) Phase A (Preliminary Analysis) System Definition Analyze project requirements Establish optimum architecture System Definition Phase B (Definition) Preliminary Design

the Phase A goals and objectives may be the Announcement of Opportunity (AO) the researcher is responding to, while for a space flight system development project goals and objectives may be provided as part of the Enterprise strategic plans. Another example is the risk management plan. The researcher will follow the same risk management process called out in Section 4.3.2; however, it may be documented as an integral part of the research plan developed in support of the effort. Detailed discussions of the various life cycle phases are provided in Chapter 3, Project Life Cycle Requirements.

Phase C (Design) Fabrication & Final Design Integration Perform final design

Phase D (Development) Preparation for Deployment

Phase E (Operations) Deployment & Operational Operations Disposal Verification Conduct Conduct deployment & operation operational verification Decommission or dispose of system

Project Feasibility Understand the customer Identify feasible alternatives

Analyze Perform system preliminary requirements design Establish optimal system design

Manufacture Prepare & assembly system for Integration & deployment test Verification & acceptance

Figure 2.4-2. Project life cycle phases.

2-6

Overview of Project Management at JSC

2.5 Project Management Forums JSC projects may have several different forums that provide management and technical oversight. The initial baseline project management oversight forum shall be the JSC PMC until formally delegated to a lower-level board. However, to the greatest degree possible, the Center management team will attempt to delegate oversight to the lowest possible board, thus putting the management and technical oversight as close as possible to the project and its efforts. Project managers and project teams must understand that: Projects may be required to report to centerlevel forums Projects may be required to report to programlevel forums. Projects may be required to report to directoratelevel forums. Projects may establish their own forums At and across the project level. At and across the system level. At the subsystem level. There are many different forms a forum can take. For example, Management councils Management boards Review boards Control boards Technical working groups The forums used and defined by the project shall be defined in the PMP. 2.5.1 Project-level Forums The designation of the project-specific boards is defined at the discretion of the project manager and project management team as they see fit to ensure that project needs, goals, and objectives are satisfied. The project team may also establish technical forums down and across the project organization to communicate, resolve, and concur on technical aspects of the system. In both cases, some form of these boards should exist over the entire life cycle of the project. 2.5.2 Directorate-level Forums Each directorate may have a unique number of technical and management boards, board structures, and placements within the organization deemed appropriate to manage their projects. One option for delegation of management oversight from the JSC PMC is to a directorate-level management board.

2.5.3 Center-level Forums 2.5.3.1 JSC Engineering Review Board (ERB) The JSC ERB charter and membership are documented in JSC Announcement 02-035, Charter of the Engineering Review Board . The JSC ERB ensures consistent application of policies, guidelines, processes, standards, and requirements as related to SE across JSC. The Board also evaluates new program and institutional initia tives, ensuring consistency with the Centers strategic objectives. Further, the Board provides the Center Director a means to ensure that viable project trade-offs and decisions are made. The ERB functions in concert with the JSC PMC, provid ing a technical review capability; however, ERB endorsement is not a prerequisite to a JSC PMC presentation or decision. Types of ERB presentations include: project status/ overview presentations, technical issue resolution presentations, Center process improvement initiative presentations, project pre-proposal authorization presentations, and project implementation approval presentations. Center project management-related process improvement initiatives are presented to the ERB for approval and status since the Board is responsible for ensuring consistent application of Center processes. ERB project pre-proposal authorization presentations may be required, by direction of the Center PMC. This would occur prior to Center PMC pre-proposal authorization. For projects requiring Center PMC ATP, project implementation approval presentations must be approved by the ERB. This approval reflects an ERB decision as to whether the system and its operation are well enough understood to warrant design and acquisition of the end items. Direction within the purview of the ERB may result during any presentation, and may require further coordination with the customer and stakeholders . Any changes affecting the PMP or projectcustomer agreements shall be documented. 2.5.3.2 JSC Facility Review Board (FRB) The FRB provides senior management review and assessment of proposed facility and facility-associated support projects and functions as a Facilities Utilization Review Board in accordance with NASA Management Instruction (NMI) 7234.1. The responsible office is Center Operations with membership from across the JSC directorates. The FRB charter is at: http://servermpo.arc.nasa.gov/Services/CDMSDocs/Centers/JSC/Dirs/JP G/JPG1107.1AC4.html. The Board functions as a management review forum for facilities and associated support project types, as discussed in Section 2.4.1. It shall review all proposed facility and facility-associated support projects, and recommend to the PMC a primary project oversight forum for these project types. If delegated by the PMC, the FRB functions as the primary oversight forum for this project type.

2-7

Project Management: SE & Project Control Processes & Requirements

2.5.3.3 JSC Project Management Council In relation to JSC projects, the JSC PMC is the highest Center-level decision-making body, and it exists to ensure JSC project success. A detailed dis cussion of the JSC PMC applicability, functions, and membership is defined in JPC 7120.2. Because of the number of JSC projects, not all will be reviewed on a regular basis by the JSC PMC. Some shall be formally delegated, in writing, to a directorate-level project management board. However, any JSC project, whether delegated to a directorate board or not, shall be required to provide a status to the JSC PMC if requested by the JSC PMC chairperson. As a general rule, JSC projects meet with the PMC to receive formal ATP as defined in the PMC preproposal, proposal, and implementation process outlined in Section 2.5.5.1. Once established, projects meet with the PMC to present status on an agreed-to basis. Other project topics may be covered at the discretion of the JSC PMC chairperson. Where the project manager for a JSC project is resident in a program office, the JSC PMC shall be limited to reviewing only the JSC support to that project. In this case, the presenter need not be the project manager. For those projects where the project manager is resident in a directorate, the JSC PMC will review the full project scope, including cost, technical, and schedule aspects. In this case, the presenter should be the project manager. 2.5.3.3.1 JSC Project Management Council processes 1) General Process Overview The JSC PMC chairperson convenes the PMC quarterly as a minimum. The JSC PMC secretary coordinates requests for special JSC PMCs with the JSC PMC membership. The results of the JSC PMC discussions and assessments are documented in the form of minutes, findings, and actions. Outside-of-board (OSB) decision making by the JSC PMC chairperson is not the preferred process and is used on an exception basis only. All OSB decisions are documented in writing and provided to the JSC PMC membership by the JSC PMC secretary at the earliest opportunity. Unless otherwise documented herein, OSB activity is limited mainly to only time-critical decisions. The following paragraphs define the standard JSC PMC milestones on which the JSC PMC bases its deliberations and decisions regarding the initiation or continuance of projects. The JSC PMC makes three major decisions in the life cycle of a project. These are to: (1) pursue new business by initiating or concurring on preproposal/proposal activity for development or

support service projects; (2) approve imple mentation of a project; and (3) for projects that have given the ATP, concur with continued development and implementation of the project, authorize or enable the corrective action neces sary to mitigate unfavorable impacts during project development, or terminate the project (FIG. 2.5-1). 2) Pre-proposal Approval Process The purpose of the pre-proposal approval process is to characterize for the JSC PMC any perceived business opportunities in which JSC may want to participate. This review occurs as soon as sufficient understanding of the customers request and resources required is available. It occurs before the concept review milestone in Pre-Phase A. The discussion at the JSC PMC will be focused around four major points. These points are: Whether the project being proposed is within the JSC mission and goals Whether there is the appropriate level of JSC support available to provide a reasonable probability of success for the pre-proposal and proposal development effort What the estimated costs for the pre-proposal and proposal efforts are, and what funding sources are available Whether this pre-proposal and proposal development effort was requested by a NASA program A favorable outcome of this JSC PMC review results in approval to begin a pre-proposal effort. No set criterion is established to define, in advance, whether delegation to a lower-level directorate board should be done. However, at the same time as the JSC PMC provides preproposal approval, the project may formally request delegation to a lower-level board. The information requested is minimal in order that JSC PMC decisions may be timely; however, the information must provide assurance that there has been a complete and thorough as sessment of all resources necessary to successfully complete the pre-proposal and proposal development effort. For facility and facilityassociated support projects, the JC PMC shall review the recommendations of the FRB and decide on the appropriate project review board. If the pre-proposal and/or proposal efforts were specifically requested in writing by a NASA program, the pre-proposal team shall immediately proceed without waiting for JSC PMC approval and shall report their initiation of efforts at the earliest possible JSC PMC. Similarly, if the pre proposal effort was not requested by the program but can be funded by internal directorate funds

2-8

Overview of Project Management at JSC

Project pre -proposal discussion at directorate(s)

Is it a facility or facilityassociated project? Yes Facility Review Board review

No

Directorate(s) identify pre-proposal/proposal manager for project

Has pre-proposal funding been obtained?

Yes

Pre-Phase A work begins

FRB recommends PMC review oversight of project? No Follow facility NPDs and NPRs for project development

No Yes

Inform JSC PMC of pre-proposal development effort

FRB provides project oversight Modify PMC pre-proposal form Develop PMC pre -proposal approval form

Yes Present to JSC PMC. Pre-proposal approval given? PMC delegated oversight to directorate ? Yes Directorate boards provide project oversight authorization to proceed Engineering Review Board Facility Review Board Johnson Space Center NASA Policy Directive NASA Procedures and Requirements outside of board Project Management Council Follow facility NPDs and NPRs for project development

Terminate activity

No

Actions assigned ?

No

Yes

No

Facility project ? Yes

No

Directorate(s) name pre-proposal/proposal manager Pre-Phase A work Phase A work Directorate or designated board reviews Phase B work begins

Key:

ATP ERB FRB JSC NPD NPR OSB PMC

Customer approval review Present to JSC PMC for concurrence (may be processed OSB) Phase C work begins

Yes

Program directed project? No

ERB review Completed assigned actions Yes

System Definition Review (SDR) completed

Yes Yes

Present to JSC PMC w/ proposal results. ATP given? Terminate activity per Section 3.7

No

Actions assigned ? No

Project presents status to JSC PMC on agreed-t o project -specific schedule

Figure 2.5-1. Pre-proposal/proposal/implementation approval process.

2-9

Project Management: SE & Project Control Processes & Requirements

(e.g., Center general and administration (G&A) allocation) or external Center funding, the team may immediately proceed without waiting for JSC PMC approval. In such case, the pre-proposal team shall report their initiation of efforts at the earliest possible JSC PMC. At that time, the JSC PMC must determine whether project oversight will be kept at the PMC or delegated to a directorate-level project management board. The JSC PMC approval for this effort may be given OSB. If the pre-proposal efforts are for a project in support of a non-NASA program and funded by internal Center funds, JSC PMC approval shall be required prior to initiation of these activities. Detailed PMC procedures in support of this process are documented in the JSC Office of the Chie f Engineers Web site. 3) Implementation Approval Process The purpose of the implementation approval process is to review the project proposal developed and to determine whether it should be implemented. This review occurs at the same time as System Definition Review (SDR) in Phase B of the project life cycle. The discussion at the JSC PMC will be focused around four major points: That the project is appropriate for the JSC mission and goals That there is the appropriate completeness and accuracy of the proposal development effort expended to date Whether the appropriate level of JSC support is available to provide a reasonable probability of success for the resulting project The appropriateness of delegating management oversight to a directorate-level board (and which directorate-level board to delegate to) A favorable outcome results in an ATP for implementation of the project. An unfavorable outcome may result in additional work being required or termination of the effort (FIG. 2.5-1). For all projects given ATP, the JSC PMC shall document in its minutes the frequency of future status reviews. The JSC PMC project approval information requested is minimal in order that JSC PMC decisions may be timely; however, the information must also provide assurance that a complete and thorough proposal development effort has been made. If the proposal efforts were specifically requested in writing by a NASA program, the proposal team can immediately proceed without waiting for JSC PMC approval and shall report their initiation of efforts at the earliest possible

time to the JSC PMC. JSC PMC approval for this effort may be given OSB. Detailed PMC procedures in support of this process are documented in the JSC Office of the Chief Engineers Web site. 4) Implementation Review Process The purpose of the JSC PMC implementation review is to look at the current status of the project or project support effort. The discussion at the JSC PMC will be focused around two major points; i.e., to: Demonstrate to the JSC PMC that the project is meeting its intended goals and requirements within the approved schedule and resource envelopes. Apprise the JSC PMC of any corrective action needed above the project level. A favorable outcome results in an authorization to continue des ign, development, or operations activities on the project. An unfavorable outcome may result in additional work being required or termination of the project. The JSC PMC project status review information requested is minimal in order that JSC PMC decisions may be timely; however, the information must also provide assurance that there is complete and thorough project management of the design, development, or operations effort. All approved projects will be reviewed on an agreed frequency, and this frequency shall be formally documented in the JSC PMC minutes. Detailed PMC procedures in support of this process are documented in the JSC Office of the Chief Engineers Web site.

2-10

Overview of Project Management at JSC

2.6 Documentation Tree The following figure (FIG. 2.6-1) is provided to graphically show the various levels and relationships of many project management or project managementrelated documents as they affect JSC projects. The listings shown are not a complete representation of all documents since there are many more documents (including NASA external documentation) that are applicable. The listing is instead intended to show the JSC Center-level and directorate-level implementation of these documents and their requirements.
Headquarters Level What
NPR 7120.5B
Program/Project Management

Facilities NPDs and NPRs NPR 1440.6G


Records Management NPD 8820.2A NPD 8820.3 NPR 8820.2E NPR 8831.2D NPD 8831.1D NPD 7330.1F Design and Construction of Facilities Facility Sustainable Design Facility Project Implementation Guide Facilities Maintenance Management Management of Institutional and Program Facilities and Equipment Approval Authorities for Facilities Projects

NPD 7500.1 NPD 8010.2


Metrics System Program/Project Logistics Systems Engineering Engineering

NPR NPR Systems

NPD 8730.4
S/W IV&V

NPD 2820.1 NPD 9501


EVM

NPD 8010.3
Terminate Space Systems

NPR 8000.4
Risk Management

NPR 2190.1
Export Control

Software Policies

Center Level Detail of What

JSC EVM Handbook NASA RP 1358


Systems Engineering Toolbox

JPG
Software Guide and Requirements

JPG Project Management

JPD JPD 8090.1


Systems Engineering Project Control (includes EVM)

How

SP 6105
Systems Engineering Handbook

JPD 7120.1
Project Management

Directorate Level Detail of How


WP 09-0014
Project Management

EA-WI-023

TBD

TBD

TBD

TBD

Various WIs

WSTF Key:
Completed

Engineering

MOD

SLSD

IRD

FCOD

JA

In development

Handbook

Figure 2.6-1. Documentation tree.

2-11

Project Management: SE & Project Control Processes & Requirements

2.7 Project Team JSC uses, and shall continue to use, a collaborative engineering and development approach for all Center projects. As such, the project and support teams include representation of all organizations necessary to successfully complete the project. The following project and support team member discussions are intended to document a minimum set of roles and responsibilities needed to effectively and successfully manage a project. The team member listings also highlight the need for a conscious project discussion as to individual team member roles and responsibilities. The project must make a strong effort to identify the correct minimum number of individuals early in the project planning effort. In this identification process, however, there must be a clear understanding of the expected workload for each project and support team member. Especially important is an understanding of the workload for those individuals who take on multiple project roles (e.g., project manager and project control officer). The detailed discussion of what is required for each role is, therefore, provided to lay a common framework across all projects and directorates at JSC. The project manager can also use the project team membership discussion for additional purposes. For example, they can use it for: A quantitative planning tool for estimating the minimum number of project personnel. An introduction to the tailored management processes and procedures to be used. Finally, these agreed-to project management positions shall be documented in the project management plan. 2.7.1 Organization The project organization is the establishment of clear, non-conflicting authority relationships between positions that have been assigned specific tasks required to achieve project requirements. A full understanding of the project performance requirements, costs, and schedules is necessary to identify the specific sets of responsibilities involved. Delegation of authority to undertake these responsibilities is key to organiza tion, and is one of the most important managerial abilities. Unless authority is effectively delegated, duties requiring coordination of group activities cannot be effectively assigned to a subordinate supervisor, who must, in turn, must have adequate authority to accomplish those tasks or assign them to others. A projects organizational structure and staffing are dependent on the character of the project and will change as the project matures and areas of importance and priorities shift. The project manager is responsible for identifying these necessary project changes and directing the associated replanning, reorganizing, and

re-staffing. Not all project position described in the following sections are necessary for every project. 2.7.2 Membership The following paragraphs describe functions and roles of various positions in the project management team. 2.7.2.1 Project manager role The project manager shall have the authority and responsibility to execute the project. The project manager is responsible for all aspects of the project beginning with identification of the project team skill requirements and ending, ultimately, in ensuring that project requirements are met within budget and schedule. The project manager is responsible, in accordance with Federal regulations and NASA and JSC management directives (many of which are referenced herein), for the successful planning and implementation of project resources, schedule, and performance objectives. This includes being responsible for the overall project safety and risk management. The project manager receives authority via a clear chain of delegation beginning with the program commitment agreement (PCA) and flowing through the program plan to the project management plan (for program-delegated projects) or by the approved project management plan (for JSC projects not tied to a specific program). The project manager monitors all aspects of project planning, definition, development, and implementation to develop a clear grasp of progress and problems. The project manager will then determine the necessary corrective action and implement it. The project manager is therefore responsible for determining when changes to the project schedule, design requirements, and available resources are necessary or when interim test results, failure investigations, or other unpredictable constraints also require changes in the project, such as parallel and/or repetition of design activities. Additional key aspects of the project managers responsibilities include: a. Functioning as the project representative to upper management. As such, it is the project managers responsibility to remain cognizant of external issues and concerns and address them in a timely manner. b. Identifying to line management the skills required to successfully achieve the project objectives and working with line management to identify team members who meet these requirements. c. Ensuring that the SE functions are accomplished in accordance with this guideline. d. Ensuring that the project control functions are accomplished in accordance with this guideline,

2-12

Overview of Project Management at JSC

e. f. g.

h. i.

j.

including incorporation of appropriate earned value management (EVM). Ensuring formulation and maintenance of the project acquisition strategy. Ensuring adequate training for the project team members. Knowledge of the information generated within the project and taking appropriate action to protect it, depending on its sensitivity. Ensuring project compliance with export control requirements. Ensuring appropriate implementation of safety for personnel and protection of national security classified/sensitive/valuable unclassified information, material, facilities, and other property. For a contractor-supported/NASA-managed project, developing and maintaining an understanding of the contractors processes, procedures, and activities.

2.7.2.2 Deputy project manager (DPM) role Depending on the project, it may be necessary to have a DPM in addition to the project manager. The DPM will normally be formally delegated all of the responsibilities held by the project manager when the project manager is absent. In addition, the DPM may be delegated primary responsibilities for selected project management tasks by the project manager. Any project-unique responsibilities need to be documented in the PMP. Some examples of reasons why a DPM may be required include: A very large or complex project A geographically distributed project A project management developmental opportunity for an individual 2.7.2.3 Lead systems engineer (LSE) role The LSE is a key member of the project team. The LSE is functionally responsible to the project manager for assuring that system implementation fulfills system needs and that proper system engineering practices are being followed. The LSE oversees the project system engineering activities, including in-house and any contractor responsibilities, to assure they are adequate and in compliance with the project constraints of performance requirements, cost, and schedule. As part of the effect to ensure that proper system engineering practices are being followed, the LSE must direct, monitor, or coordinate applicable SE tasks both within the Center and, to the appropriate level and as required, outside the Center. The LSE must also constantly review and evaluate the technical aspects of the project to ensure that the system/ subsystems engineering processes are functioning appropriately. In addition, the LSE plays the major

role in determining tailoring, if any, for the SE practices of the project. Although the project manager will look to the subsystem managers as the authorities on subsystem performance, it is the responsibility of the LSE to: Ensure the analytical and physical integration of the subsystems. Monitor the performance of all subsystems. Ensure the technical performance of the overall integrated system. Identify, plan, schedule, appropriately resource load, and execute all system-level test activities to support the overall project schedule. As part of their effort in ensuring that system implementation fulfills system needs, the LSE is responsible for managing and directing all of the projects SE activities performed using the SE processes outlined in Chapter 4. These activities include requirements development and flowdown, formulation of systems architectures and concepts, systems design, interface definition and control, draft development and monitoring of technical performance measure ments (TPMs), system-level risk management, systemlevel trade studies, fabrication planning, test plan development, system integration and testing, and verification. Another role of the LSE is to make recommendations on project design trade-offs where performance, cost, and schedule must be balanced. Through responsibility for the technical adequacy of all system-related activities of the project, the LSE must strive to ensure that system engineering is exercised in all project decisions. Finally, the skills and knowledge necessary for an LSE are normally accrued from multiple past subsystem or system assignments, training classes, and other professional developmental experiences. 2.7.2.4 Project control officer role The project control officer shall be responsible to the project manager for all project documentation, for assessing project progress against baseline schedule(s), for providing integrated (i.e., technical, cost, and schedule) project-level non-technical recommendations, and for assisting the project manager in control of project resources and activities, including budget, schedules, customer agreement, and overall project management. The project control officer shall also be responsible for providing support to the total management process of establishing and maintaining project baselines and effectively supporting the project manager in meeting the overall objectives of the project. The project control officer is responsible for: Resource management Project planning

2-13

Project Management: SE & Project Control Processes & Requirements

Documentation and data management Project assessment Cost estimating Performance measurement Project analysis Schedule management Acquisition management Risk management Configuration management (CM) Quality management The project control officer shall: a. Provide detailed recommendations early in the project planning phases of what minimum data set (including the deliverables list) is required throughout the project life cycle. b. Ensure project progress and activities are consistent with approved project customer agreements, budgets, schedules, and acquisition strategies. c. Ensure all aspects of the project cost and schedule status are integrated and documented (especially including subsystem status). d. Manage the day-to-day project-support functions such as management information systems (including IT security plans), organizing the logistics of programmatic reviews, compiling and reporting project metrics, and reporting contract or NASA-internal performance measurement surveillance efforts (including any EVM efforts). e. Ensure project document compliance with any NASA requirements and, if applicable, ensure contractor document compliance with any contractual requirements. f. Fulfill the library and records retention function for storage and retrieval of project documents. g. Develop the project data management procedures for the project. h. Develop and implement planning for contract acquisition. i. Provide detailed recommendations for the project acquisition strategy. j. Provide the project input for the annual Center/ program operating plan (POP) cycle. 2.7.2.5 Subsystem and discipline lead engineers role The subsystem lead engineer (SLE) and the discipline lead engineer (DLE) prove a significant factor in the successful technical and cost management of a project. The SLE is the project managers primary contact on management of a particular subsystem. Depending on the project product complexity and staffing constraints, an SLE may be responsible for more than one subsystem. The DLE performs a similar function, but is responsible for the manage-

ment of performance analyses for the system or subsystem. Examples of engineering disciplines that may be important to the project include: aerodynamics analysis; aerothermal analysis; guidance, navigation, and control; static and dynamic structural analyses; materials analysis; software/avionics development, and reliability, maintainability, availability, and human factors. SLEs and DLEs shall support the subsystem or analysis detailed status to the project LSE for technical review and integration, and to the project control officer for review and integration of cost and schedule status. The SLE or DLE shall: a. Be responsible for ensuring the subsystem or analysis requirements are appropriately and correctly flowed down from system requirements. b. Be responsible for ensuring the subsystem or analysis requirements are achieved within project budget and schedule. c. Be responsible for the subsystem functions and, therefore, for the technical performance of their subsystem. [SLEs] d. Be responsible for the technical accuracy and completeness of their discipline areas. [DLEs] e. Make appropriate use of the management tools provided by the project control officer (e.g., EVM, critical path analysis, 5 5 risk management matrix, technical performance measurements, etc.). f. Be responsible for developing subsystem or analysis design documentation to support scheduled reviews. g. Be responsible for the planning and conduct of subsystem fabrication and testing. [SLEs] h. Ensure that, to the maximum extent possible, the system will be tested appropriately and can fulfill its requirements and perform as intended. i. All subsystem-level test activities and support are identified, planned, scheduled, appropriately resource loaded, and executed to support the overall project schedule. 2.7.2.6 Verification lead role The verification lead is accountable to the project manager and is responsible for all verification aspects of the project. The verification lead shall: a. Ensure requirements are verifiable. b. Develop the verification plan. c. Identify the most effective verification methods. d. Identify verification criteria and coordinate activities with verification facilities, participants, and other team members. e. Execute the verification plan. f. Develop or coordinate verification procedures.

2-14

Overview of Project Management at JSC

g. Collect and document verification results. h. Evaluate results for compliance or need for reverification. 2.7.2.7 Validation lead role The validation lead is accountable to the project manager and is responsible for all validation aspects of the project. The validation lead shall: a. Develop the validation plan. b. Identify the most effective validation method. c. Coordinate activities with validation facilities, participants, and other team members. d. Execute the validation plan. e. Develop or coordinate the validation procedures . f. Collect and document the validation results. 2.7.2.8 Project scientist role Not every JSC project needs to have a project scientist. However, it may be necessary to have a project scientist on a project if there is significant scientific instrumentation/utilization in the project. For a sciencebased project, the project scientist shall be deemed necessary when no principal investigator (PI) exists, when multiple PIs exist, when the PI is external to the Center, or when the JSC PI cannot serve in the project scientist function for the project. The project scientists role, duties, and responsibilities shall include: a. Overseeing the scientific integrity of the projects mission within project constraints. b. Ensuring that science requirements are adequately documented and verified in the project. c. Ensuring that the project planning, definition, implementation, and operations are appropriate for the science requirements. d. Serving as the scientific advisor to the project manager, advising on proposed changes to science objectives or requirements, when necessary . e. Participating in appropriate project reviews to ensure the project science requirements are appropriately addressed. f. Acting as the science interface for data analysis and plans. It should be noted that when a PI serves in the role of project scientist, the PI may also serve as the project manager. 2.7.2.9 User representative role A key input into the project day-to-day management often comes from the end user of the product. While not every project at JSC needs to have a user representative on its team, it is critical that the project team continually consider the user as its develops the end products. Some examples of user representatives include flight crew, flight controllers, surgeons, or the JSC IT community. For those projects that have

a flight crew representative, their role is to provide the operators viewpoint and experience throughout all phases of the project, and to obtain consensus of the Astronaut Office on issues involving safety and mission success. The flight crew representative shall act as a consultant to the project team, and provide input into, and concurrence on, project requirements and products. The flight crew representative will also coordinate participation from the Astronaut Office in testing and checkout, procedures development and verification, and other activities as appropriate. Involvement of the Astronaut Office ensures that the on-orbit experience and lessons learned are carried forward in engineering activities dealing with human space flight. In addition, the Astronaut Office benefits by gaining in-depth knowledge of the systems they will operate on orbit. 2.7.2.10 Administrative officer role The administrative officer is responsible for assisting the project manager in a variety of administrative activities in support of the project. Responsibilities may vary depending on the size and complexity of the project and the project managers delegation of responsibilities and assignments. Responsibilities may include the tracking of project-related correspondence, handling of personnel actions, oversight and maintenance of internal task agreements (ITAs), and recording and tracking of action items (both internal to the project and assigned to the project ex ternally). The administrative officer may also serve as the official training and records officer for the project, thereby ensuring compliance with JSC Procedures and Guidelines (JPG) 1440.3, JSC Files and Record Management Procedures. 2.7.3 Support Team The following paragraphs describe various functions and roles in support of the project management team. 2.7.3.1 Line management support JSC projects normally operate on a matrix organizational approach. As such, the primary functions of line management in the life cycle of a project include: a. Participating in the project approval process. b. Providing the resources, facilities, and tools required for the project. c. Selecting competent and knowledge project managers. d. Implementing Agency, Center, directorate, and division policies, procedures, and standards. e. Enforcing safety, cost, schedule, technical, and management processes to ensure product and services are consistent and of high quality.

2-15

Project Management: SE & Project Control Processes & Requirements

f. Providing support and oversight over technical management decisions. g. Ensuring projects and project decisions that impact other projects, processes, or priorities established by the customers, the Agency, Center, directorate, and/or division are coordinated/communicated. h. Ensuring communication and integration across projects and other divisional/organizational lines. i. Mentoring the entire project team. j. Providing technical and management guidance to the project manager based on project complexity and the experience level of the project manager. While line management reserves the right to provide technical direction to project managers under their supervision, any resulting changes in baselined cost, schedule, or performance requirements shall be approved by the customer in accordance with the established CM process. Technical issues that cannot be resolved between the line management chain and the project manager shall be presented to the JSC ERB for final disposition prior to coordination with the customer. In cases where the project or line management feels a decision jeopardizes crew safety or mission success, appeals should be taken directly through the appropriate management chain or indirectly (anonymously) through the independent assessment (IA) organizations, the JSC Ombuds, the NASA Safety and Reporting System (NSRS), the Government Auditing Office, and/or the NASA Inspector General. Given line management responsibilities for the selection and performance of the project manager, line management can replace any or all of the project management team under their supervision when significant technical competency or management issues with the project management team are identified. In all cases, this removal should be coordinated with the project customer and the directorate. 2.7.3.2 Safety and mission assurance (S&MA) support S&MA project support is provided through a Safety and Mission Assurance Directorate-assigned representative, usually collocated with the project team. In this capacity, the S&MA representative shall: a. Assist the project manager in assuring that all system S&MA requirements (including personnel and facility safety) are appropriately defined and implemented. b. Provide for an independent S&MA oversight and assessment function for all aspects of the project. c. Serve as the single point-of-contact between the project team and the Safety and Mission Assur-

ance Directorate, assuring proper coordination, review, or approval of all safety, reliability, maintainability, and quality assurance (QA) responsibilities and practices. d. Ensure that S&MA processes are established within the project. 2.7.3.3 Mission operations support Mission operations project support is provided through an assigned representative or representatives. typically these representatives come from the Mission Operations Directorate. The representative shall be the projects interface with the mission and operations discipline organizations and personnel. The project team normally requires a person to lead efforts associated with ensuring that the project mis sion operations are properly defined, planned, and executed. Mission operations encompass the flight and ground operations support personnel, S/W, procedures, H/W, and facilities required to execute the flight mission. The responsibilities of the mission operations support team member are also to lead the efforts associated with defining the operations team and ensure that the operations team is trained and ready to support operations. Ground operations are included as the ground segment of mission operations. 2.7.3.4 Test operations lead support The test operations lead is accountable to the project manager and is the system test team individual responsible for ensuring that, to the maximum extent possible, the system will be tested appropriately and can fulfill its requirements and perform as intended. The test operations lead shall ensure that: a. All system-level test requirements provided by the project team have been identified and documented prior to testing. b. All system-level test procedures provided by the project team have been developed and verified prior to testing. c. All subsystems supporting the system-level tests are ready to support and are appropriately documented. d. The Test Readiness Review (TRR) appropriately addresses all system test performance and safety requirements and incorporates all applicable lessons learned from the JSC lessons learned database (http://iss-www.jsc.nasa.gov/ss/issapt/lldb/) as well as the NASA lessons learned database (http://llis.gsfc.nasa.gov/); and that the required test and/or integration facilities have been verified to provide the necessary conditions and have been scheduled and are available. e. The required test and/or integration facilities have been verified to provide the necessary

2-16

Overview of Project Management at JSC

conditions and have been scheduled and are available. f. The required ground support equipment (GSE) has been verified to provide the necessary support resources and has been scheduled and is available. 2.7.3.5 Facilities support In some cases, it may be necessary for the project to have support for the modification or construction of Center facilities. Coordination of these activities may be accomplished through a Center Operations representative on the project team, or it may be accomplished through project team coordination directly with appropriate Center Operations personnel. For new facilities, it is critical that all requirements be identified in any budget submission, and the impact on other funding sources (e.g., institutional) also be defined. New facility requirements should be split between nonrecurring (outfitting) and recurring (operations and maintenance). Considerable and timely foresight must be given to facility requirements. Most requirements ideally can be accommodated with minimal changes to existing facilities. Where changes are required, however, cost and schedule considerations will determine the procedure for affecting change. Facility projects may be funded by project or CofF funds. Project funding can be used only through use of an Unforeseen Programmatic Document that explains the urgency of the requirement and gives reasons why the requirement has not been included in the CofF budget cycle. The CofF budget cycle requires a minimum of three years from initial submission of the requirement to completion of construction. Initially, the project requirements are specified for inclusion in the CofF budget cycle. A preliminary engineering report further defines the requirements during the first year, design is accomplished during the second year, and construction is started during the third year. In most instances, construction can be completed in one year. A number of Center offices participate in the preliminary engineering report and design phases, ensuring the completed project will satisfy all requirements and meet Center objectives. 2.7.3.6 Environmental support In some cases, it may be necessary for the project to have support for environmental concerns or impacts . Coordination of these activities may be accomplished through a Center Operations representative on the project team, or it may be accomplished through project team coordination directly with appropriate Center Operations personnel. When planned project activities have the potential for environmental impact, the support function pro-

vides the capability to perform analyses and make assessments of the potential environmental impact. Some of the areas the environmental team supports include storm water and wastewater management, industrial and hazardous waste management, oil storage, asbestos and lead control, and spills and releases management. 2.7.3.7 Counterintelligence support In almost all cases, it will be necessary for the project to have support for the counterintelligence function. Coordination of these activities may be accomplished through a Center Operations representative on the project team, or it may be accomplished through project team coordination directly with the appropriate Center Operations personnel. The Center counterintelligence function provides an assessment and support capability for the project, the Center, and the Agency. This function works to actively identify potential technologies and other products that could be used by foreign governments (businesses or individuals) for their economic/strategic advantage. This function is distinctly separate fro m the export control function in that it also works to actively assess technology development areas and analyzes them against specific threat areas. A key characteristic of these counterintelligence representatives is their ability to work proactively with the project management team to ensure both the appropriate awareness and responsibilities to manage the protection of these technologies, and how to identify attempts to access them improperly. 2.7.3.8 Export control support In some cases, it may be necessary for the project to have support for export control activities. Coordination of these activities may be accomplished through a Center Operations representative on the project team,, or it may be accomplished through project team coordination directly with the appropriate Center Operations personnel. The purpose of the export control function is to ensure compliance with the JSC export control re quirements documented in the JSC Common Work Instruction (CWI) J29W-01, JSC Export Compliance, the NASA export control directive, NPD 2190, NASA Export Control Program, and the export control requirements of the Departments of State and Commerce as well as other agencies. This important function covers all JSC projects and encompasses export control to all product technologies and technical information that have the potential for export outside of the U.S. In addition, the Export Control Office provides consultation and guidance for all project activities at JSC.

2-17

Project Management: SE & Project Control Processes & Requirements

2.7.3.9 Logistics, transportation, and shipping support In some cases, it may be necessary for the project to have support for logistics, transportation, and shipping. Coordination of these activities may be accomplished through a Center Operations representative on the project team, or it may be accomplished through project team coordination directly with appropriate Center Operations personnel. For logistics, transportation, and shipping support, it is critical that all requirements be identified as early as possible in the life cycle. Early identification and communication of any of these requirements would minimize the probability of project disruption from these support areas. 2.7.3.10 Procurement support For contracted projects, the project managers procurement interface is a Procurement Office representative to the project team. This representative may or may not be collocated. For a JSC internal project (e.g., GFE), the project Procurement Office representative may only function to assist in purchasing of materials, services, or components for the final project product. The Procurement Office representative shall be responsible for: a. Development of the Master Buy Plan submis sion to the JSC Procurement Office. b. Coordinating the acquisition strategy including scheduling and assisting in the development of the presentation to the Acquisition Strategy Meeting with JSC management and, if required, NASA Headquarters. c. Assisting in the development of the statement of work (SOW) for the contract. d. The request for proposal (RFP). e. Formation and operation of a Source Evaluation Board leading to source selection. The Procurement Office representative is also responsible for contract negotiation for a contracted project. The Procurement Office representative also supports the development of a change order control system to implement contract changes. Timely development of change requirements and technical evaluation of change proposals by the Project Office will permit early change order negotiations and ensure a firm contract baseline. Formal authority to enter into and modify contracts rests solely with the contracting officer in the cognizant Procurement Office; however, there must be a close working relationship between the contracting office and the project contracting officer technical representative (COTR) to ensure appropriate management and direction of any contractors support efforts.

2.7.3.11

Office of the Chief Financial Officer (CFO) support The Office of the Chief Financial officer is the focal point for financial planning and budget execution for the Center. The Office designs and implements the financial and resources systems required for proper data collection and reporting and ensures that Agency and Center-level financial and resource decisions are implemented. It reviews, approves, and implements financial and resources policies and systems and integrates the planning, implementation, management, and control of all resources for which the Center is responsible. The CFO provides guidance in administrative responsibilities of the technical community in regard to the initiation and approval of purchase requests. The guidance is included in the IFM On-line Quick Reference, http://olqr-cf.ifmp.nasa.gov. Guidance regarding planning and execution of civil service travel will be provided at a later date. 2.7.3.12 Office of the Chief Engineer support The Office of the Chief Engineer provides support to the projects primarily through the Systems Management Office (SMO). The SMO provides leadership, consultation services, and technical expertise on SE and project management. The SMO also reviews and determines Centerwide usage and consistency for common SE and project management processes, procedures, and practices. This includes the use and implementation of appropriate performance measurement systems requirements such as EVM. As a project consultant, the SMO can assist the project in planning and accomplishing Pre-Phase A, Phase A, and even some Phase B efforts. Experience has shown that a significant percentage of projects that have failed to meet performance, cost, or schedule requirements has had an inadequate effort in these critical project phases. Therefore, the SMO can be called on to assist the project in executing these phases appropriately. As a project reviewer, the SMO can act as an independent reviewer, either at the request of the project itself, the program manager, the director, or the Center Director. In this capacity, the SMO can examine the project from a technical, cost, and/or schedule viewpoint and provide detailed recommendations for corrective actions. 2.7.3.13 Legal support The project manager must maintain a close working relationship with the legal representative on all issues or concerns developing with legal implications or involving legal policy. Matters that should give rise

2-18

Overview of Project Management at JSC

to claims or litigation should be communicated and coordinated as early as possible. Any correspondence or contacts by external NASA legal counsel should be referred to or reported immediately to the Chief Counsel or the Chief Counsels designated representative. Any court or administrative legal papers affecting NASA (e.g., lawsuits, claims, subpoenas, or summons) shall also be referred to the Chief Counsel for advice and guidance. 2.7.3.14 Communication and information technology support JSC has significant existing IT and communications capabilities to support individual or project needs. Because of the diverse nature of projects at JSC, however, unique communication or IT requirements may develop. Coordination and discussion of these requirements may be accomplished through an Information Resources Directorate (IRD) representative on the project team, or it may be accomplished through project team coordination directly with appropriate IRD personnel. For information on existing directorate-specific IT tools, the project team should review the listings at http://cio.jsc.nasa.gov/Center/itp/standards/standards.htm. These unique communications and IT requirements should be identified early in the project planning efforts to provide for effective long-range implementation and budget planning as part of the Agency and JSC forecast. With this information, early communications feasibility engineering for lease or contracting workloads for project execution can be accomplished. Timely scheduling to include communications in project planning will permit the required communications and IT support to be available to support the project for management, scientific, technical, and operational requirements. 2.7.3.15 Documentation and graphics support JSC has significant existing documentation and graphics capabilities to support individual or project needs. Coordination and discussion of these needs may be accomplished through an IRD representative on the project team, or it may be accomplished through project team coordination directly with the appropriate IRD personnel. Some of the documentation and graphics services and products provided throughout the project life cycle include printing and reproduction, editing and technical writing, graphics, mail delivery/pickup services, and documentation repository. 2.7.3.16 Photographic-video support The project may require photographic or video support over its life cycle. The IRD is responsible for providing the photographic and operational video

services for development and mission support. Coordination and discussion of these needs may be accomplished through an IRD representative on the project team, or it may be accomplished through project team coordination directly with the appropriate IRD personnel. For space flight mission support, this includes acquisition, distribution, recording, search/retrieval and playback, editing, duplication, and archiving. Operational services are also provided to satisfy project-level test, training, and administration video support requirements. This support team also operates the audio/video distribution network and the JSC cable TV system. 2.7.3.17 Public Affairs Office support The Public Affairs Office provides support to the projects and the project team by serving as a liaison for project information going to the public and the media. Coordination of these activities may be accomplished through a Public Affairs Office representative on the project team (if there is enough demand); or it is more likely that it may be accomplished through project team coordination directly with the appropriate Public Affairs Office personnel. Additional guidance can be obtained through reference to JPD 1382.1H and JPD 1382.4K. 2.7.3.18 Human factors support For cases in which the H/W or S/W being developed requires a human interface, it may be necessary for the project to have support for human factors and habitability concerns or impacts. Coordination of these activities may be accomplished through project team coordination directly with the appropriate repre sentatives or by having an assigned representative in the team. Typically these representatives come from the Space and Life Sciences Directorate. When planned project activities have the potential for human factors or habitability impact, the support function provides the capability to perform analyses and make assessments of potential impact. Involvement of human factors also ensures that on-orbit operational habitability experience reports and lessons learned are carried forward in project activities. Some of the areas human factors and habitability personnel support include physical and visual accessibility, human strength capabilities and limitations, workstation design, internal environment design, labeling and coding, and user/computer interaction. 2.7.3.19 Technology transfer and intellectual property management support The Office of Technology Transfer & Commercialization provides support to projects in two areas, technology transfer and intellectual property management.

2-19

Project Management: SE & Project Control Processes & Requirements

The technology transfer representative shall: a. Assist the project manager in technology planning by Identifying and negotiating with potential partners for joint technology development ventures. Identifying technologies at other government organizations and universities that would be prime candidates for technology infusion into the project. b. Assist the project manager in identification and documentation of new innovations that result from technology development performed by the project. c. Provide guidance on all technology transfer functions and initial guidance on intellectual property matters. The Patent Counsel and the Patent Counsels staff shall assist the project manager on all matters pertaining to intellectual property, which includes but is not limited to invention disclosures, patent prosecution, copyrights, S/W usage agreements, new technology and patent rights clauses in contracts, and procurement counseling on related issues.

2-20

Overview of Project Management at JSC

2.8 Project Management and Planning Project management and planning activities provide the framework to ensure that a project meets the established budget, schedule, safety, and technical requirements to satisfy both project and the customers objectives. The project management and planning activities shall operate over the entire life cycle of the project and must be developed and implemented such that a rapid assessment and response capability is in herent. The amount of project management and planning performed should be commensurate with project approach, type, size, risks, and complexity. Project management and planning activities are included in a PMP (see Appendix A for template). This not only establishes project controls that include a project baseline to allow for performance to be monitored and corrective action taken, if necessary; it also allows for a clear communication to project team members of the processes, methods, and activities that will be used in managing the project. Included in this shall be any tailoring approaches to be used during the lifetime of the project. In addition to the PMP, project management and planning activities create other products and documentation that supplement the PMP and support the annual program operating plan (POP) process. Project activities will likely change the project baseline as the project progresses. Reviews may be conducted internally or externally by the project, program (if applicable), or center or through an independent assessment organization. If significant performance variances or risks are identified that jeopardize project objectives, changes to the PMP and project baseline may be required. 2.8.1 Project Management One of the key aspects of project management is the formation and operation of a project team. That is the art of transforming a group into a team that operates efficiently and effectively. While each project is unique, there are key underlying characteristics that should be understood and followed by each project manager at JSC. They are: Honesty Integrity Leadership Motivation Negotiation Communication Delegation Decision making As the project begins Pre-Phase A activities and plans and progresses through Phase E, the project team will transform itself. This fact must be well understood by the project manager since each phase has specific

characteristics and, more importantly, requires a different management guidance style for each (also called situational leadership). Many descriptions of this transformation process exist. As an example, one description is called the Four-Stage Model. Simply stated, the team passes through four stages on its way to a unified, effective work team. The stages and the associated management style are lis ted below: 1. Forming F (Telling; e.g., provides specific directions and closely supervises performance) 2. Storming F (Selling; e.g., explains decisions and provides opportunity for clarification) 3. Norming F (Participating; e.g., shares ideas and facilities in decision making) 4. Performing F (Delegating; e.g., turns over responsibility for decisions and implementations) Since a considerable number of knowledge sources exist on this topic, further discussion on the generic transformation process and the appropriate management guidance style for each is left for the reader to obtain external to this document. Available resources include the Human Resources Development Branch and the Academy of Program and Project Leadership (APPL) (http://appl.nasa.gov/home/). 2.8.2 Project Management Plan and Project Baseline As the project develops, one of the key documents that captures and establishes the baseline for the project implementation activities is the PMP. A PMP documents project products and describes the overall plan for project implementation. The PMP shall serve as the basic agreement for the project among the project manager, the Center managing the project, and the program management (if the project is directly supporting a program). PMPs are unique to each project; and the level of detail may vary with the size, complexity, sensitivity, and other particular characteristics of the project. The PMP also contains additional information, and shall be prepared in accordance with Appendix A of this document. The PMP shall create an integrated project baseline by linking scope, requirements, schedule, and cost to risk. To accomplish this, projects shall start the planning process in the Pre-Phase A efforts, a process that will mature with the continuation of the system definition and preliminary design process. The draft PMP shall be completed at the end of Phase A. The final PMP shall be completed during Phase B, and it shall be maintained and updated throughout the remaining project life cycles. The planning process should be conducted in parallel with the definition of requirements. During Phase A, a product-oriented work breakdown structure (WBS) shall be developed and refined as requirements are more defined. In addition to a WBS, projects

2-21

Project Management: SE & Project Control Processes & Requirements

should have a high-level schedule, a life cycle cost estimate, and an organization concept developed. During Phase B, an integrated resource-loaded schedule shall be developed with refinement of the WBS and schedule and development of a bottom-up budget estimate. A risk assessment should also be completed to determine the amount of budget and schedule management reserve needed. As the project progresses through the remaining life cycle phases, periodic reviews should be made to determine whether other changes within the project are necessary. (See Section 4.2.2 for an overview of the planning process.) 2.8.3 Program Operating Plan (Project Baseline Updates) Project management and planning efforts may be used to assess Center or directorate-level support efforts and take corrective action, if necessary. Every year each project is required to submit a budget estimate, updating life cycle and phased funding, and schedule and workforce requirements to the program/ Enterprise. The program/Enterprise consolidates the various project budget estimates into a POP. The POP covers all aspects of the project and is the latest estimate of funding needs required to achieve baseline scope and schedule. The development process for the POP begins with the issuance of POP guidelines. The project manager then conducts a review of the entire project. Included in this review is an assessment of any requirements changes, an assessment of the previous years plan vs. the projects actual performance, major project risks and their associated cost and/or schedule potential impacts, and any readjustments from the original project life cycle based on unforeseen funding changes . However, any changes to requirements, schedule, and resulting budget, as well as the risk profile and reserve posture, should be managed through an internal project change process and be reflected as changes to funding needs. The resulting funding needs are what is presented annually as part of the POP process. Center management reviews the POP submittal for consistency and compliance with Center commitments and responsibilities. The POP is then submitted to the programs and Headquarters for review, comment, and eventual approval. Through this review process and subsequent POP marks, current operating plans and future year funding, and workforce and schedule requirements are established for each project. 2.8.4 Customer-Project Agreement The customer-project agreement documents the requirements on the project related to how it will do business relative to the customer and the expectations on the product or service supplied (usually by reference

to an attached specification). The project shall ensure that there is a written document of the customer-project agreement, agreed-to and signed by both parties. Parties should be aware that the degree of clarity and definition of the customer-project agreement directly influences the success of the project. Several forms of customer-project agreements may exist. For technical agreements, the minimum requirements listed below may be implemented in the form of a contract, a letter of agreement, or documented according to a customerspecific template. The customer-project agreement should address, at a minimum: Project needs, goals, objectives, assumptions, and constraints (the context for the project). Product or service requirements, including performance, interfaces, quality, environmental and other constraints, and verification and validation requirements. Requirements on the conduct/implementation of the project. Includes the content, level, and fre quency of reporting; data, H/W and S/W deliv erables; schedule information to support monitoring and incorporation into higher-level (e.g., program) schedules; process standards; and customer and project roles relative to the major technical reviews. Resources provided by the customer or other organizations to the project such as funding, personnel, equipment, facilities, and materials. Resources devoted by the supplier organization (the project) the accomplish the project such as personnel, equipment, facilities, materials, and subcontracts. The project agreement with the customer will flow down into the project PMP, either directly or as the implementing elements necessary to meet the agreement. While the elements of the customer-project agreement will be included in the PMP, the project benefits from having a separate agreement with the customer. In that way, the customers approval is not required to change elements of the PMP that do not directly impact the customer.

2-22

Project Management: Systems Engineering & Project Control Processes and Requirements

Project Life Cycle Requirements

Project Life Cycle Requirements

Chapter 3 Project Life Cycle Requirements


This chapter outlines requirements for Johnson Space Center (JSC) projects as they relate to the products, reviews, and management decisions that are expected for each phase of the project development life cycle.* A discussion of each life cycle phase includes: Overview Provides a top-level summary narrative of major project activities accomplished during the life cycle phase. Expected Results/Outcomes Lists the major results and outcomes that the project is expected to accomplish during the life cycle phase. Products Lists the major products that the project is required or expected to produce during the life cycle phase.

Process Provides a flow diagram that depicts the sequence of major activities that occurs during this phase, and shows how the project management processes support these activities. NOTE: For an in-depth discussion of the process steps, refer to Special Publication (SP) 6105, NASA Systems Engineering Handbook . Reviews Lists the p roject-level life cycle reviews that are performed during this life cycle phase. This discussion includes the purpose of the review; the objectives the project team should accomplish as part of the review; checklists to aid in determining successful completion of the review; and decisions that are made at the project level based on information from the review (Section 4.1.16, Reviews). Management Decisions Outlines any management decisions made outside of the project team during the life cycle phase.

Refer to Section 2.4 for a discussion of the project life cycle for facilities and associated support projects .

3-1

Project Management: SE & Project Control Processes & Requirements

3.1 Pre-Phase A Advanced Studies1 3.1.1 Overview Pre-Phase A, Advanced Studies, is performed to develop an understanding of project needs and expectations, and to identify feasible project alternatives to fulfill these needs and expectations. This phase initiates the project development life cycle. Involvement from the project customer is essential at this stage to scope the project. The project customer provides a statement of project needs, goals, and objectives, and discloses project constraints and assump tions. This phase results in a feasibility assessment of whether project needs can be accomplished within the constraints and as sumptions provided by the customer. 3.1.2 Expected Results/Outcomes During Pre-Phase A, the project team should: Confirm customer project needs. Assess the technical and programmatic feasibility of the project. Define objectives and top-level functional and performance requirements. Produce a feasibility assessment report. Conduct a concept review. 3.1.3 Products The feasibility assessment report shall be the primary product of this phase. It documents the studies completed during Pre-Phase A to assess project feasibility. The contents of this report are reviewed during the Concept Review (CR). The following are repre sentative contents of this report: Project needs, goals, and objectives and relevance to the Center Implementation Plan Project assumptions, guidelines, and constraints Top-level functional and performance requirements Documentation of all system and functional concepts and architectures considered, and rationale for selection or rejection Operations concepts Evaluation criteria (also known as figures of merit or measures of effectiveness) Performance measures (cost, schedule, and technical) Life cycle schedule and cost estimates Technology development requirements Trades and analysis results A review and report on applicable lessons learned 3.1.4 Process The diagram (FIG. 3-1) at the top of the following page indicates the steps in this phase of the project life cycle that should be accomplished when evolving the system of interest. Interaction of these steps and

the associated reviews is also illustrated along with the project management (PM) processes that should be referenced in executing each activity. 3.1.5 Reviews Concept Review A CR, the purpose of which is to validate project needs and objectives and to examine concepts for meeting those objectives, shall be performed to exit Pre-Phase A. At the review, the project team should be prepared to: Demonstrate that project objectives are complete and understandable. Confirm that proposed concepts demonstrate technical and programmatic feasibility for meeting stakeholder needs and objectives. Confirm that customer project needs are clear and achievable. Ensure that prioritized evaluation criteria (also known as figures of merit or measures of effectiveness) are provided for subsequent analysis. Identify skills needed for the next phase. The following checklist is provided to aid in determining successful completion of the review: Has the project need been clearly identified? Are the project objectives clearly defined and stated? Are they unambiguous and consistent? Are project assumptions and constraints clearly defined? Will satisfaction of the preliminary set of requirements provide a system that will meet stakeholder needs and objectives? Have the concept evaluation criteria that are to be used in the candidate systems evaluation been identified and prioritized? Is the project feasible? Has at least one solution been identified that is technically feasible, and that meets stated assumptions and constraints? Is the rough cost estimate within the acceptable cost range? Are schedule and cost estimates credible? Was a technology search done to identify existing assets that could satisfy the project or part of the project? Were all applicable lessons learned identified, evaluated, and incorporated to the maximum extent possible? Project Decision The project manager decides whether the project is ready to recommend authoriza tion to proceed to the preliminary analysis phase. 3.1.6 Management Decision The decision to proceed from Pre-Phase A, Advanced Studies, to Phase A, Preliminary Analysis, shall be provided by a directorate-level board or its delegate. For projects that involve multiple directorates, approval

3-2

Project Life Cycle Requirements

Project Customer Provides Project Needs, Goals, Objectives, Assumptions, and Constraints Iterate Requirements and Concepts to Establish Feasibility Start 1.1 Refine User Needs & Objectives
Requirements Development & Management

Management Decision/Control Gate Concept Review


Reviews

Understand Customer Management Decision/Control Gate


PMC Approval*

Start

1.3 Develop Top-Level Requirements


Requirements Development & Management

Identify Feasible Alternatives 1.6 Flowdown Top-Level Systems Requirements


Requirements Development & Management

1.10 Synthesize & Down Select


Feasibility Study

1.2 Refine Constraints & Assumptions


Requirements Development & Management

1.5 Develop Evaluation Criteria 1.2a Assess Project Feasibility (bid/no bid decision)
Feasibility Study

1.2b Prepare PMC Proposal Approval Form*

Feasibility Study

1.8 Allocate Requirements


Requirements Development & Management Feasibility Study

1.9 Analyze & Evaluate


Feasibility Study, Technology Planning

1.4 Develop Top-Level Functional Concept


Operations Concept Development

1.7 Develop Feasible Systems Concept(s)


Decomposition, Feasibility Study

X.X Phase Step


Supporting PM Process

Management and Planning


Technology Planning, Acquisition Management, Risk Management, Quality Management, Control, Technical Work and Sources Management, C onfiguration Management, Safety and Mission Success, Resource Management, Planning, Documentation and Data Management, Cost Estimating, Performance Measurement, Schedule Management, Project Analysis

*Refer to Section 2.5.3.3 (JSC Project Management Council)

Figure 3-1. Pre-Phase A advanced studies diagram. to proceed shall be obtained from all directorate-level boards. For management decisions concerning entry into this phase, please refer to the PMC discussion in Section 2.5.3.3. 3.1.7 References The following document, which was used to prepare this section, offers additional insights into Pre-Phase A, Advanced Studies:
1

SP 6105, NASA Systems Engineering Handbook , 1995.

3-3

Project Management: SE & Project Control Processes & Requirements

1,2 3.2 Phase A Preliminary Analysis 3.2.1 Overview Phase A, Preliminary Analysis, is performed to examine further the feasibility and desirable of a suggested new system and its compatibility with NASA strategic plans. During this phase, requirements and concepts are iterated to establish optimal system requirements and top-level system architecture.

3.2.2 Expected Results/Outcomes During Phase A, the project team should: Refine both top-level functional and performance requirements and corresponding evaluation criteria and metrics. Develop and refine both system-level require ments and corresponding evaluation criteria and metrics. Develop interface requirements to external systems, if applicable. Identify alternative operations and logistics concepts. Demonstrate that credible, feasible system architecture designs exist. Examine alternative system architectural design concepts. Establish an optimized system architecture. Identify technical and technology risks, and outline mitigation plans. Initiate environmental impact studies, if applicable. Refine resource need estimates for the project. Produce a needs statement. Produce a top-level operations concept. Produce a preliminary set of project plans, including preliminary versions of the project management plan (PMP), systems engineering (SE) management plan, risk management plan, technology development plan, and logistic plan. 3.2.3 Products The project definition package shall be the primary product of Phase A. This package documents the activities conducted during this phase to define project requirements, systems architecture, and preliminary plans. The following are representative contents of this package: A needs statement for the project Project constraints and system boundaries Top-level project and system requirements with corresponding evaluation criteria and metrics (also known as figures of merit or measures of effectiveness) A list of credible, feasible systems architecture designs considered Alternative operations and logistics concepts

Feasibility studies Recommended system architecture Advanced technology requirements Risk studies, including mitigation plans Cost and schedule estimates A preliminary set of project plans, including preliminary versions of the PMP, SE management plan, risk management plan, technology development plan, and logistics plan.

3.2.4 Process The diagram at the top of the following page (FIG. 3-2) indicates the steps in this phase of the project life cycle that should be accomplished in the course of evolving the system of interest. Interaction of these steps and the associated reviews is also illustrated along with the PM processes that should be referenced in executing each activity. 3.2.5 Reviews 3.2.5.1 The Requirements Review A Requirements Review (RR) shall be conducted, usually early in Phase A, to determine whether the requirements development and the requirements management functions are sufficiently established to proceed with determining the optimum system architecture. At the RR, the project team should be prepared to: Demonstrate that project requirements are complete and understandable. Demonstrate that prioritized evaluation criteria are consistent with requirements and the operations and logistics concepts. Confirm that requirements and evaluation criteria are consistent with customer needs. Demonstrate that operations and architecture concepts support mission needs, goals, and objectives; assumptions, guidelines, and constraints ; and project requirements. Demonstrate that the process for managing change in requirements is established, documented in the project information repository, and communicated to stakeholders. Project Decision Based on the results of the RR, the project manager shall decide whether to proceed with steps toward the establishment of optimum system architecture. 3.2.5.2 The Definition Review A successful Definition Review (DR) shall be conducted prior to exiting Phase A. The purpose of the DR is to determine whether to proceed with developing the proposed system architecture design and any technology needed to accomplish project goals. Review

3-4

Project Life Cycle Requirements

Management Decision/Control Gate Concept Review Reviews Start 2.1 Refine Top-Level Project Requirements

Iterate Requirements and Concepts to Establish Optimal System Requirements and Top-Level Architecture
Analyze Requirements Requirements Review Reviews 2.4 Define & Refine System Requirements
Requi rements Development & Management

Establish Optimum Architecture

Management Decision/Control Gate Definition Review Reviews

2.8 Synthesize & Down Select


Feasibility Study

Requirements Development & Management

2.3 Develop & Refine Evaluation Criteria


Feasibility Study

2.6 Allocate Requirements To Elements


Decomposition

2.7 Analyze & Evaluate Architectures & Concepts


Feasibility Study; Technology Planning

2.2 Refine Mission & Operations Concept(s)


Operations Concept Development

2.5 Develop Alternative System Architecture & Concepts


Operations Concept Development Feasibility Study; Technology Planning; Design

X.X Phase Step


Supporting PM Process

Management and Planning


Technology Planning, Acquisition Management, Risk Management, Quality Management, Work and Resource Management, Control, Configuration Management, Safety and Mission Success, Resource Management, Planning, Documentation and Data Management, Cost Estimating, Performance Measurement, Schedule Management, Project Analysis

Develop Tools and Methods


Verification, Validation, System Analysis, Feasibility Study

Figure 3-2. Phase A preliminary analysis diagram. results should reinforce project merit and provide a basis for the system acquisition strategy. At the DR, the project team should be prepared to: Establish the proposed systems architecture design and the allocation of functional system requirements are optimized to satisfy project objectives with respect to the requirements trades and evaluation criteria established at the CR. Demonstrate that system requirements meet project objectives. Identify both technical and technology risks, and the plans to mitigate those risks. Present refined cost, schedule, and personnel resource estimates. The following checklist should be used to aid in determining successful completion of the DR: Will the selected system architecture design meet system requirements and satisfy project objectives and stated needs? Are cost and schedule estimates in the preliminary plans realistic in view of system require ments and the selected architecture? Are system-level requirements complete, consistent, and verifiable? Have preliminary allocations been made to lower levels? Have the requirements trades converged on an optimized set of system requirements? Do the trades address project cost and schedule constraints as well as technical needs? Do the trades cover a broad spectrum of options? Have the remaining trades been identified to select a proposed system architecture design? Are plans in place for the design and development phases? Are the upper levels of the system product breakdown structure completely defined? Are decisions made as a result of the trades consistent with evaluation criteria established at the CR? Have major design issues been identified for the elements? Have technical and technology risks been identified, and have mitigation plans been developed?

3-5

Project Management: SE & Project Control Processes & Requirements

Project Decision The project manager decides whether the project is ready to proceed to Phase B, Definition, for developing the system architecture/ design and any technology needed to accomplish the goals of the project. If the project is deemed ready, authorization is requested to proceed to Phase B, Definition. 3.2.6 Management Decision Directorate-level board(s) or its delegates shall authorize the project to proceed to Phase B, Definition, to develop the system architecture/design and any technology need to accomplish project goals.

3.2.7 References The following documents, which were used to prepare this section, offer additional insights into Phase A, Preliminary Analysis: 1 SP 6105, NASA Systems Engineering Handbook , 1995. 2 NPR 7120.5B, NASA Program and Project Management Processes and Requirements, 2002.

3-6

Project Life Cycle Requirements

3.3 Phase B Definition1,2 3.3.1 Overview Phase B, Definition, of the project life cycle is performed to establish an initial project design-to baseline. The baseline includes a formal flowdown of project-level performance requirements to a complete set of design specifications for the system of interest down to the lower levels of its architecture. During this phase, technical requirements are sufficiently detailed to establish firm schedule and cost estimates for the project. Early in Phase B, the effort focuses on system requirements analysis and system definition and selection, allocating functions to particular items of hardware (H/W), software (S/W), personnel, etc. System functional and performance requirements along with architectures and designs are solidified as system of interest trade studies and subsystem trade studies iterate in an effort to seek out more cost-effective designs. Later in Phase B, the effort shifts to establishing a functionally complete, preliminary design solution that meets project goals and objectives. Trade studies continue. Interfaces among major end items are defined. Engineering test items may be developed and used to derive data for further design work; and project risks are reduced by successful risk mitigation efforts, including technology developments and demonstrations. Phase B culminates in a series of Preliminary Design Reviews (PDRs), continuing the system of interest PDR and PDRs for lower-level end items, as appropriate. 3.3.2 Expected Results/Outcomes During Phase B, the project team should: Demonstrate that the system of interest architecture and design are acceptable, complete, and optimized relative to measures of effectiveness (e.g., figure of merit, performance goals, etc.), and that all requirement allocations to functional elements are complete. Show that the system of interest design is correct and can be built to meet project needs, goals, and objectives. Show that all major project risks have mitigation plans in place. Show that all requirements are complete and consistent. Show that the design meets cost and schedule constraints. 3.3.3 Products A functionally complete solution that meets project goals and objectives shall be produced as the primary product of Phase B. This solution shall be expressed and control as a design-to specification at all levels of the system architecture.

A number of products should be prepared in support of the solution, including: New or revised plans, such as the PMP, SE management plan, risk management plan, and other supporting plans such as specialty engineering plans, safety plans, S/W management plans, test plans, and verification and validation plans. System of interest functional requirements defined to the lowest level as appropriate, including internal and external interfaces (interface control documents (ICDs)) Trade studies and feasibility analyses Verification requirements matrix Baseline concept of operation Work breakdown structure (WBS) and dictionary Statement(s) of work (SOW(s)) System of interest cost-effectiveness model, technical resource estimates, and life cycle cost estimates Technology development test results Acquisition strategies and requirements 3.3.4 Process Figures 3-3.1 and 3-3.2, which appear at the top of the following pages, indicate the steps in Phase B that should be accomplished when evolving the system of interest. The interaction of these steps and their associated reviews are also illustrated in the figures along with the PM processes that should be referenced in executing each activity. 3.3.5 Reviews 3.3.5.1 The System Requirements Review The System Requirements Review (SRR) shall be conducted early in Phase B. The objective of this review is to confirm that system-level requirements and specifications are sufficient to meet project objectives . At the SRR, the project team should be prepared to demonstrate that systems -level requirements and specifications meet project objectives. The following checklist is provided to aid in determining successful completion of the SRR: Are allocations contained in the system of interest specifications sufficient to meet project objectives? Are evaluation criteria established and realistic? Are measures of effectiveness established and realistic? Are cost estimates established and realistic? Has a system verification concept been identified? Are appropriate plans being initiated to support project system development milestones?

3-7

Project Management: SE & Project Control Processes & Requirements

Integrate
Integration, Systems Analysis

Management Decision/Control Gate System Definition Review(s)

Definition Review
Reviews

System Requirements Review


Reviews

Element C Element B Element A 3.3 Flowdown & Refine Requirements


Requirements Development & Management, Decomposition Establish Optimum System Design

Reviews

Analyze System Requirements

Start

3.1 Mission & Requirements Analysis


Requirements Development & Management

3.2 Develop System Evaluation Criteria


Design

3.4 Develop & Refine Prime/Critical Item Concepts


Decomposition, Design

3.5 Allocate Requirements to End Items


Requirements Management, Decomposition

3.6 Evaluate & Analyze System End Item Concepts


Systems Analysis

3.7 Synthesize/Select Optimal Option


Design, Attainment

Iterate Requirements and Concepts to Establish Optimal Design-To Baseline

Develop Technology
Technology Planning

3.11 Develop & Refine Tools & Methods


Technology Planning

X.X Phase Step


Supporting PM Process

Management and Planning


Technology Planning, Acquisition Management, Risk Management, Quality Management, Control, Work and Resource Management, Configuration Management, Safety and Mission Success, Resource Management, Planning, Documentation and Data Management, Cost Estimating, Performance Management, Schedule Management, Project Analysis

Figure 3-3.1. Phase B system definition diagram. Have technology development issues been identified along with approaches to their solution? Have specialty engineering considerations been incorporated into the systems -level requirements and specifications? Project Decision At the SRR, a decision is reached regarding whether the design team has demonstrated sufficient understanding of the mission for the system of interest, programmatic issues, and potential system of interest implementations to enable a commitment to the feasibility of the desired capability. Successful completion of the SRR freezes project requirements and leads to a formal decision to proceed with preparations for project implementation. Complicated systems of interest with multiple elements may require multiple SRRs. The decision to proceed may result in the preparation of a request for a formal project start decision. 3.3.5.2 The System Definition Review A System Definition Review (SDR) shall be conducted to exit design selection and enter preliminary design. An SDR examines the proposed system architecture/design and the flowdown to all functional elements of the system to determine whether to proceed with developing the selected design and any technology needed to accomplish project goals. At the SDR, the project team should be prepared to: Demonstrate that the architecture/design is acceptable, requirements allocation is complete, and a system that fulfills project objectives can be built within constraints. Ensure that the verification concept and preliminary verification program are defined. Have established end item acceptance criteria. Ensure that adequate detailed information exists to support initiation of further development or acquisition efforts.

3-8

Project Life Cycle Requirements

Management Decision/Control Gate System Definition Review(s)


Reviews

Integration Systems/Elements/Lower Architectural Elements


Integration

Management Decision/Control Gate System Definition Review(s)


Reviews

Lower Architectural Elements Preliminary Design

4.2 Perform Design Analysis


Design

Start

4.1 Analyze & Refine Requirements


Requirements Development & Management

4.6 Evaluate, Verify, & Validate Design


Systems Analysis, Verification, Validation

4.3 Perform Engineering Development Tests


Verification

4.5 Perform Preliminary Design


Design

4.4 Define Interfaces


Decomposition, Design

4.7 Complete Plans & Documentation for Qualification Items


Verification

Management and Planning


Technology Planning, Acquisition Management, Risk Management, Quality Management, Control, Work & Resource Management, Configuration Management, Safety and Mission Success, Resource Management, Planning, Document ation and Data Management, Cost Estimating, Performance Measurement, Schedule Management, Project Analysis

X.X Phase Step


Supporting PM Process

Figure 3-3.2. Phase B preliminary design diagram. The following checklist is provided to aid in determining successful completion of the SDR: Will the top-level system design selected meet system requirements, satisfy project objectives, and address operational needs? Can the selected top-level system design be built within cost constraints and in a timely manner? Have all system-level requirements been allocated to one or more lower levels? Have major design issues for the elements and subsystems been identified? Have major risk areas been identified and addressed with mitigation plans? Have plans been completed to control the development design process? Is a development verification/test plan in place to provide data for making informed design decisions? Is the minimum end item product performance documented in the acceptance criteria? Is there sufficient information to support contract proposal efforts? Is there a complete, validated set of requirements with sufficient system definition to support cost and schedule estimates (if required)? Project Decision At the SDR, a decision is made that indicates whether the system of interest and its operation are well enough understood to warrant design and acquisition of the end items. Successful completion of the SDR releases both approved specifications for the system of interest and its elements and preliminary specifications for the design of appropriate functional elements. Authorization to proceed with preliminary design activities is requested. 3.3.5.3 The Preliminary Design Review A PDR shall be conducted for the system of interest and for each of its major subsystems and/or configuration items (CIs). The PDR is not a single review but is a number of reviews that includes the system of interest PDR and PDRs conducted on sub-elements of the system. The PDR demonstrates that the preliminary design meets all system requirements with acceptable risk; shows that the correct design option has been selected, interfaces have been identified, and verification methods have been satisfactorily described; and establishes the basis for proceeding with detailed design. At the PDR, the project team should: Ensure that all system requirements have been allocated, the requirements are complete, and flowdown is adequate to verify system performance.

3-9

Project Management: SE & Project Control Processes & Requirements

Show that the proposed design is expected to meet the functional and performance require ments at the CI level. Show sufficient maturity in the proposed design approach to proceed to final design Show that the design is verifiable and the risks have been identified, characterized, and mitigated, where appropriate. The following checklist is provided to aid in determining successful completion of the PDR: Can the proposed preliminary design meet all requirements within planned cost and schedule? Have all external interfaces been identified? Have all system and segment requirements been allocated down to the CI level? Are all CI design-to specifications complete and ready for formal approval and release? Has an acceptable operations concept been developed? Does the proposed design satisfy requirements critical to human safety and project success? Do the human factors considerations of the proposed design support the intended end users ability to perform and operate the system effectively? Have production, verification, operations, and other specialty engineering organizations reviewed the design? Is the proposed design producible? How long lead items have been considered? Do specialty engineering project plans and design specifications provide sufficient guidance, constraints, and systems requirements for design engineers to execute the design? Is the reliability analysis based on sound methodology; and does it allow for realistic logistics planning and life cycle cost analysis? Are sufficient project reserves and schedule slack available to proceed further? Are the integrated logistics support analyses mature enough, and are they realistic? Has the Safety and Mission Assurance Review Team approved of the Phase I safety data package? Project Decision After the PDR is successfully completed, the design-to baseline and the Phase I safety data package are approved. Authorization is requested for the project to proceed to design phase. 3.3.6 Management Decision There are three decision points in Phase B. The SRR is sometimes referred to as an interim review rather than a control gate review. For large projects, the decision that is reached following the SRR is to begin/stop preparing for release of a request for proposal (RFP) for Phase B studies. For smaller

projects, the directorate-level decision may be to proceed with a commitment of in-house resources to proceed with Phase B project implementation. The first control gate decisions follows the SDR. For projects requiring Center PMC authority to proceed, an Engineering Review Board (ERB) decision is reached regarding whether the system and its operation are well enough understood to warrant design and acquisition of the end items. Specifications are approved for the system as well as preliminary specifications for the design of appropriate elements. Plans to control and integrate the expanded technical process are in place. JSC PMC approval for a project approved by the ERB at this SDR control gate may be obtained outside of board (OSB). At the conclusion of the PDR is another control gate management decision point. This one approves the design-to baseline and authorizes the project to proceed to the design phase. The design-to baseline may include preliminary engineering design drawings, end-item specifications, preliminary ICDs, and preliminary S/W specifications. Identical to the SDR control gate, a decision to proceed into Phase C, Design, should be obtained from the directorate-level board or its delegate. The decision may also be presented to the ERB on request. 3.3.7 References The following documents, which were used to prepare this section, offer additional insights into Phase B, Definition: 1 SP 6105, NASA Systems Engineering Handbook 1995. 2 NPR 7120.5B, NASA Program and Project Management Processes and Requirements, 2002.

3-10

Project Life Cycle Requirements

3.4 Phase C Design1,2 3.4.1 Overview The Phase C, Design, phase of a project establishes a complete design build-to baseline that is ready to fabricate (or code), integrate, and verify. Trade studies continue. Engineering test units, which more closely resemble actual H/W, are built and tested to establish confidence that the design will function in the expected environments. Engineering specialty analysis results are integrated into the design, and the manufacturing process and controls are defined and validated. At each step in the successive refinement of the final design, corresponding integration and verification activities are planned in greater detail. Phase C culminates in a series of Critical Design Reviews (CDRs) that contain the system of interestlevel CDR and CDRs corresponding to different levels of the system hierarchy. At this point, a detailed design of the system of interest and its associated subsystems , including its operations systems, is complete and ready to be released. 3.4.2 Expected Results/Outcomes During Phase C, the project team should: Establish a build-to baseline of the system of interest. Verify that the detailed design meets system of interest requirements. Ensure that verification and acceptance testing requirements are satisfied. Ensure that system of interest performance and operations requirements are satisfied. 3.4.3 Products During Phase C, a completed, detailed design of the system of interest and all its components including subsystems, testing system, and operations systems shall be expressed and controlled as the build-to baseline. This baseline should include: Build-to specification(s) at all levels of the system architecture A baseline of all requirements and designs, including traceability to all levels Baseline updates to system architecture, verification requirements matrix, WBS, project plans, etc., reflecting project maturity Baselined system integration, operations, and manufacturing plans Completed and archived trade studies A refined integrated logistics support plan Refined verification and validation plans 3.4.4 Process The diagram (FIG. 3-4) at the top of the following page indicates the steps that should be accomplished

during this phase of the project life cycle. The interaction of these steps and the associated reviews are also illustrated along with the PM processes that should be referenced to execute each activity. 3.4.5 Reviews The Critical Design Review A CDR shall be conducted for the system of interest and each of its major subsystems and/or CIs. The CDR is not a single review but is a number of reviews that includes the system of interest CDR and CDRs conducted on specific CIs. The CDR discloses the complete system of interest des ign in full detail; ascertains that technical problems and design anomalies have been resolved; and ensures that the design maturing justifies the decision to initiate fabrication/ manufacturing (or coding), integration, and verification of project H/W and S/W. At the CDR, the project team should be prepared to: Ensure that the build-to baseline contains detailed H/W and S/W specifications that can meet functional and performance requirements. Ensure that the design has been satisfactorily audited by s pecialty engineering organizations. Ensure that production processes and controls are sufficient to proceed to fabrication (or coding). Provide evidence that planned quality assurance (QA) activities will establish perceptive verification and screening processes to produce a quality product. Verify that the final design fulfills specifications established at the PDR. The following checklist is provided to aid in determining successful completion of the CDR: Can the proposed final design be expected to meet all requirements within planned cost and schedule? Is the design complete? Are drawings ready to begin production? Is the S/W product definition sufficiently mature to start coding? Is the build-to baseline sufficiently traceable to assure there are no orphan requirements? Has all qualification testing been completed? Are all internal interfaces completely defined and compatible? Are external interfaces current? Are integrated safety analyses complete? Do these analyses show that identified hazards have been controlled, or has the appropriate authority waived the remaining risks that cannot be controlled? Are production plans in place and reasonable? Are there adequate quality checks in the production process?

3-11

Project Management: SE & Project Control Processes & Requirements

Management Decision/Control Gate Preliminary Design Review(s)


Reviews

Integration Systems/Elements/Lower Architectural Elements


Integration

Management Decision/Control Gate Critical Design Reviews(s)


Reviews

Lower Architectural Elements Start 5.1 Define & Control Detailed Design Interfaces
Decomposition Design

Final Design

5.2 Perform Detailed Design


Design

5.5 Evaluate, Verify, & Validate Design


Design, Attainment Systems Analysis, Verification, Validation

5.3 Perform Engineering Test


Design, Verification

5.6 Complete Detailed Design & Production Plans


Design

5.4 Fabricates/Tests Qualification Items


Verification

Management and Planning


Technology Planning, Acquisition Management, Risk Management, Quality Management, Control, Work & Resource Management, Configuration Management, Safety and Mission Success, Resource Management, Planning, Document ation and Data Management, Cost Estimatin g, Performance Measurement, Schedule Management, Project Analysis

X.X Phase Step


Supporting PM Process

Figure 3-4. Phase C design diagram. Are the logistics support analyses adequate to identify integrated logistics support resource requirements? Are comprehensive system integration and verification plans complete? Has the Safety and Mission Assurance Review Team approved the Phase II safety data package? Project Decision As a result of successful CDR completion, the build-to baseline, production plans, and verification plans are approved. Approved drawings are released and authorized for fabrication. The decision is made to authorize coding of deliverable S/W and system qualification testing and integration. All open issues are resolved with closure actions and schedules. The Phase II safety data package has been approved. Authorization to proceed to Phase D is requested. 3.4.6 Management Decision The affected directorate-level board(s) provide authorization to initiate fabrication/manufacturing (or coding), integration, and verification of project H/W and S/W. 3.4.7 References The following documents, which were used to prepare this section, offer additional insights into Phase C, Design: 1 SP 6105, NASA Systems Engineering Handbook , 1995.
2

NPR 7120.5B, NASA Program and Project Management Processes and Requirements, 2002.

3-12

Project Life Cycle Requirements

3.5 Phase D Development1,2 3.5.1 Overview The purpose of the Phase D, Development, phase is to build and verify the system of interest designed in the previous phase, deploy it, and prepare it for operations. Activities include fabrication (e.g., H/W, S/W facilities construction), integration, verification, and deployment of the system of interest. Additional activities include initial training of operating personnel and implementation of the logistics support plans. The major product is the system of interest that has been shown to be capable of accomplishing the purpose for which it was created. 3.5.2 Expected Results/Outcomes During Phase D, the project team should: Buildi.e., fabricate (or code)the end items (i.e., the lowest-level items in the system of interest architecture). Integrate end items according to the integration plan and perform verifications, thereby yielding verified components and subsystems. Repeat this process of successive integration until a verified system is achieved. Verify and validate the system; i.e., develop verification and validation procedures at all levels, and perform system of interest qualification verification(s) and acceptance verification(s) and validation(s). Prepare for operations; i.e., prepare the operators manuals and maintenance manuals. Train initial system operators and maintainers, perform operational verification(s), audit as-built configurations, and finalize and implement an integrated logistics support plan. 3.5.3 Products The primary product of Phase D shall consist of the completed, verified, validated, and accepted system of interest and associated documentation necessary for normal operations. Example products include: Verified and validated H/W and S/W products As-built and as-deployed documentation Updated logistics support plans Operations plans and procedures, including operations, maintenance, and disposal procedures Training materials Documentation of lessons learned Verification, validation, and acceptance data Problem/failure reports 3.5.4 Process The following diagrams (FIGS. 3-5.1, 3-5.2, and 3-5.3) indicate the steps in Phase D that should be accomplished in the course of evolving the system of in -

terest from design to operational use. The interaction of these steps and the associated reviews are also illustrated along with the PM processes that should be referenced in executing each activity. During this phase of the life cycle, the system of interest is transformed through three distinct stages, each of which is bounded by control gates. These three stages include fabrication and integration, preparation for deployment, and deployment and operational verification.

3-13

Project Management: SE & Project Control Processes & Requirements

Management Decision/Control Gate Critical Design Review(s)


Reviews

Manufacture & Assembly

Integration & Test

Integrate Systems, Control & Verify Interfaces


Integration, Control

Management Decision/Control Gate System Acceptance Review


Reviews

Subsystems

Start

Production Readiness Reviews(s)


Reviews

Lower Architectural Elements

Test Readiness Reviews(s)


Reviews

6.1 Ready Production Facilities


Attainment

6.2 Fabricate/Assemble End Item


Attainment

6.5 Test/Verify End Item


Attainment, Systems Analysis, Verification, Validation

6.6 Assemble & Physically Integrate System


Integration

6.9 Test/Verify System


Verification, Validation

6.3 Complete End Item Verification Test


Attainment, Verification

6.7 Complete Test Plans & Documentation for System


Integration, Verification, Validation

6.10 Perform Acceptance Testing


Validation

6.4 Complete Plans/ Documentation for End Item


Attainment

6.8 Complete Plans & Documentation for System


Integration

X.X Phase Step


Supporting PM Process

Train Management and Planning


Technology Planning, Acquisition Management, Risk Management, Quality Management, Control, Work and Resource Management, Configuration Management, Safety and Mission Success, Resource Management, Planning, Documentation and Data Management, Cost Estimating, Performance Measurement, Schedule Management, Project Analysis

Figure 3-5.1 Phase D development fabrication and integration stage diagram.

3-14

Project Life Cycle Requirements

Management Decision/Control Gate System Acceptance Reviews


Reviews

Deployment Readiness Review


Review

Start

7.2 Configure Hardware


CM, Control

7.3 Configure Software


CM, Control

7.1 Deliver/Install System

7.4 Configure Support System


CM, Control

7.7 Complete Integrated Pre-Deployment Checkout


Verification

7.5 Prepare Personnel

7.6 Update Ops Plans & Procedures


Work & Resource Management, CM

X.X Phase Step


Supporting PM Process

Management and Planning


Technology Planning, Acquisition Management, Risk Management, Quality Management, Cont rol, Work and Resource Management, Configuration Management, Safety and Mission Success, Resource Management, Planning, Documentation and Data Management, Cost Estimating, Performance Measurement, Schedule Management, Project Analysis

Figure 3-5.2. Phase D development preparation for deployment stage diagram.

3-15

Project Management: SE & Project Control Processes & Requirements

Deployment Readiness Review


Review

Management Decision/Control Gate Operational Readiness Review


Reviews

Start

8.1 Deploy

8.2 Configure for Checkout and Operations


Validation

8.3 Demonstrate Operational Capability


Validation

X.X Phase Step


Supporting PM process

Management and Planning


Technology Planning, Acquisition Management, Risk Management, Quality Management, Control, Work and Resource Management, Configuration Management, Safety and Mission Success, Resource Management, Planning, Documentation and Data Management, Cost Estimating, Performance Measurement, Schedule Measurement, Project Analysis

Figure 3-5.3. Phase D development deployment and operational verification stage diagram. 3.5.5 Reviews 3.5.5.1 The Production Readiness Review A Production Readiness Review (ProRR) shall be conducted to ensure that production plans, facilities, and personnel are in place and ready to begin production. The ProRR is conducted after the CDR and prior to the start of production. At the ProRR, the project team should be prepared to: Demonstrate that all significant production engineering problems encountered during development, including S/W problems, have been resolved. Ensure that the design documentation is adequate to support manufacturing, fabrication, or coding. Ensure that production plans and preparations are adequate to begin manufacturing, fabrication, or coding. Establish that adequate resources have been allocated to support end item production. The following checklist should be used to aid in determining successful completion of the ProRR: Is the design baselined? Have incomplete design elements been identified? Have risks been identified and characterized and mitigation efforts defined? Has the bill of materials been reviewed, and have critical parts been identified? Have delivery schedules been verified? Have alternative sources been identified? Have adequate spares been planned and budgeted? Are the facilities and tools sufficient for end item production? Are special tools and test equipment specified in proper quantities? Are personnel qualified? Are drawings baselined? Is production engineering and planning mature for cost-effective production? Are production processes and methods consistent with quality requirements, and are they compliant with occupation safety, environmental, and energy conservation regulations? Project Decision A successful ProRR results in certification of production readiness by the project manager and involved specialty engineering organizations. The project manager recommends whether to proceed to production.

3-16

Project Life Cycle Requirements

3.5.5.2 The Test Readiness Review A Test Readiness Review (TRR) shall be conducted to ensure that all test article H/W and S/W, the test facility, ground support personnel, and test procedures are ready for integrated testing, data acquisition, reduction, and control. The TRR is conducted after system fabrication and integration, but prior to the start of a formal test cycle. At the TRR, the project team should be prepared to: Confirm that in-place test plans meet verification requirements and specifications. Confirm that sufficient resources are allocated to the test effort. Examine detailed test procedures for completeness and safety. Determine that critical test personnel are testand safety-certified. Confirm that test support S/W is adequate, pertinent, and verified. The following checklist should be used to aid in determining successful completion of the TRR: Have the test cases been reviewed and analyzed for expected results? Are the results consistent with the test plans and objectives? Have the test procedure been dry run? If so, do they indicate satisfactory operation? Have test personnel received training and certification, if required, in test operations and s afety procedures? Are resources available to adequately support planned tests as well as contingencies, including failed H/W replacement? Has the test support S/W been demonstrated to handle test configuration assignments, data acquisition, reduction, control, and archiving? Project Decision A successful TRR results in certification of formal system test readiness by the project manager and involved specialty engineering organizations. The project manager decides whether to proceed with planned system verification and acceptance testing. 3.5.5.3 The System Acceptance Review A System Acceptance Review (SAR) shall be conducted to examine the system, its end items and documentation, and the test data and analyses that support its verification. The SAR also ensures that the system has sufficient technical maturity to authorize its shipment to and installation at the launch site or intended operational facility. The SAR is conducted near completion of the system fabrication and integration stage, and prior to preparations for deployment. At the SAR, the project team should be prepared to:

Establish that the system is ready to be delivered and accepted under DD-250. Ensure that the system meets acceptance criteria established at the SDR. Establish that the system meets requirements and will function properly in the expected operational environments as reflected in test data, demonstrations, and analyses. Establish an understanding of the capabilities and operational constraints of the as -built system, and ensure that the documentation delivered with the system is complete and current. For flight systems, ensure that the system (H/W and S/W) has been certified for flight. This certification includes successful H/W qualification testing of the qualification unit and H/W and/or S/W acceptance testing of the flight unit. Certification documentation includes the following: identification (part number, part name), baseline requirements and associated verifications, safety data package, baseline test and analysis, documentation (qualification and acceptance plans, procedures, reports), limited-life item list, approved waivers, or deviations and material usage agreements (MUAs), etc. The following checklist should be used to aid in determining successful completion of the SAR: Are tests and analyses complete? Do the tests and analyses indicate that the system will function properly in the expected operational environment(s)? Does the system meet the criteria described in the acceptance plans? Does the system meet the needs of the stakeholders? Is the system ready to be delivered (e.g., flight items to the launch site and non-flight items to the intended operational facility for installation)? Is the system documentation complete and accurate? Is it clear what is being bought? Has all open work been identified and dispositioned? Has the Safety and Mission Assurance Review Team approved the Phase III safety data package? Project Decision A successful SAR results in the approval of the as -built baseline by the project manager, involved specialty engineering organizations, and the customer. The project manager recommends whether to proceed to prepare the system for deployment. 3.5.5.4 The Deployment Readiness Review A Deployment Readiness Review shall be conducted to demonstrate that the system is ready for deployment. This review includes examining tests,

3-17

Project Management: SE & Project Control Processes & Requirements

demonstrations, analyses, and audits. It also ensures that all H/W, S/W, personnel, and procedures are operationally ready. In a flight environment, this review equates to a Flight Readiness Review (FRR) where system readiness for a safe and successful launch and for subsequent flight operations is determined. The De ployment Readiness Review is conducted on completion of delivery, installation and configuration of the system but prior to system deployment and the operational capability demonstration. At the Deployment Readiness Review, the project team should be prepared to: Certify that system operations can safely proceed with acceptable risk. Confirm that system and support elements are properly configured and ready. Establish that all interfaces are compatible and function as expected. Establish that the system state supports a go decision based on go/no-go criteria. The following checklist should be used to aid in determining successful completion of the Deployment Readiness Review: Are the system elements ready to support operations? Is the system safe and capable of achieving mission success? Are the system interfaces checked out and found to be functional? Are all environmental factors within constraints ? Have all open items and waivers been examin ed and found to be acceptable? Project Decision Based on the results of the Deployment Readiness Review, the project manager recommends whether to proceed with steps toward deployment and operational verification of the system. 3.5.5.5 The Operational Readiness Review An Operational Readiness Review (ORR) shall be conducted to examine the actual system characteristics and procedures used in the system of interests operation, and to ensure that all H/W, S/W, personnel, procedures, and user documentation accurately reflect the deployed state of the system of interest. The ORR is conducted when the system of interest and its operational and support equipment and personnel are ready to become operational. At the ORR, the project team should be prepared to: Establish that the system of interest is ready to transition into an operational mode through examination of available test results, analyses, and operational demonstrations. Confirm that the system of interest is operationally and logistically supported in a satisfactory manner considering all modes of operation and

support (i.e., normal, contingency, and unplanned.) Establish that operational documentation is complete and that this documentation represents the system of interest configuration and its planned modes of operation. Establish that the training function is in place and has demonstrated a capability to support all aspects of system of interest maintenance, preparation, operation, and recovery. The following checklist should be used to aid in determining successful completion of the ORR: Are system of interest H/W, S/W, personnel, and procedures in place to support operation? Have all detected anomalies been resolved, documented, and incorporated into existing operational support data? Are the changes that are necessary to transition the system of interest to an operational configuration ready to be made? Are all waivers closed? Are the res ources in place or financially planned and approved to support the system of interest during its operational lifetime? Project Decision Based on the results of the ORR, the project manager, with concurrence from the customer, recommends whether to assume normal operational use of the system of interest. 3.5.6 Management Decision During Phase D, Development, two management decisions are necessary: Upon completion of system verification and acceptance testing, authorize the project to proceed in preparation for delivery and installation of the system for operational use. Upon completion of system deployment and demonstration of operational capabilities, authorize the project to commence normal operations for the system. 3.5.7 References The following documents, which were used to prepare this section, offer additional insights into Phase D, Development:
1

SP 6105, NASA Systems Engineering Handbook , 1995. 2 NPR 7120.5B, NASA Program and Project Management Processes and Requirements, 2002.

3-18

Project Life Cycle Requirements

3.5 Phase E Operations1,2 3.6.1 Overview The purpose of Phase E, Operations, is to use the system of interest to meet its initially identified need. The Operations phase encompasses the use of the system of interest; the maintenance and upgrade of the system of interest; and the training of personnel who operate, maintain, and upgrade the system of interest. Evolution of the system of interest is included in this phase, as long as the changes do not involve major changes to the architecture. (Changes of that scope constitute new requirements, and the project life cycle starts over.) This phase also deals with preparation for the safe decommission and disposal of the system of interest at the end of its operational life, though the costs and risks associated with decommission and dis posal should be considered during earlier phases of the project life cycle. 3.6.2 Expected Results/Outcomes During Phase E, the project team shall: Operationally use the system of interest. Maintain an upgrade the system of interest. Train operations and maintenance personnel. Prepare to conduct the decommissioning review. Document lessons learned. Conduct delta ORRs. Conduct safety reviews. Conduct upgrade reviews. 3.6.3 Products Phase E products are the results of the operational use of the system of interest. Examples of these include: System-intended products or services delivered Engineering data on system, subsystem, and materials performance Operations and maintenance logs Problem/failure reports Decommissioning studies Lessons learned documents System upgrade proposals 3.6.4 Process The diagram (FIG. 3-6) at the top of the following page indicates the steps in this phase of the project life cycle that should be accomplished in the course of evolving the system of interest. Interaction of these steps and the associated reviews are also illustrated along with the PM processes that should be referenced in executing each activity.

3.6.5 3.6.5.1

Reviews The Delta Operational Readiness Review Delta ORRs shall be conducted in Phase E whenever significant system changes occur. These reviews are typically held a few weeks or even a few months before operational use of the system changes. Delta ORRs essentially have the same content as the ORR described in Section 3.5.5.5. 3.6.5.2 The System Upgrade Review System Upgrade Reviews are held, as necessary, to present planned system upgrades to the project staff. This type of review is primarily informational, however approval is required when any change to critical systems is needed or extra resources are required. At the System Upgrade Reviews, the project team should be prepared to: Show before and after physical architecture diagrams. Show before and after functional architecture diagrams. Show before and after data diagrams. Describe any H/W and/or S/W changes. Describe the impact to operational procedures or training. Provide an upgrade schedule. The following checklist should be used to aid in determining successful completion of the System Upgrade Review: Has the rationale for the upgrade been sufficiently described? Are changes to the system fully described in diagrams and text? Do operations and training personnel completely understand the impacts to their procedures? Are all costs associated with the upgrades provided? Does the schedule allow enough time for necessary changes by the affected parties? Where is the appropriate life cycle phase to reenter to implement upgrades? Is a delta ORR required as a result of the changes ? Project Decision The project manager decides whether to recommend proceeding with system upgrades . 3.6.5.3 The Safety Review Periodic Safety Reviews are held to examine the established safety procedures and identified hazards. At the Safety Review, the project team should be prepared to: Examine current safety documentation. Review all safety incidents, their resolution, or plans for their resolution. Review all identified safety hazards and their mitigation procedures.

3-19

Project Management: SE & Project Control Processes & Requirements

Management Decision/Control Gate (Delta) Operational Readiness Review


Reviews

Management Decision/Control Gate Reenter Appropriate Life Cycle Phase 9.6 Distribute System Products System Upgrade Review
Reviews

Management Decision/Control Gate Critical Design Review(s)


Reviews

9.8 Update & Documentation


Work & Resource Mgmt. Configuration Mgmt.

9.10 Sequential Production


Work & Resource Mgmt. Control

Start

Attainment Control

9.1 Configure for Operations


Configuration Mgmt. Control

9.2 Operate the System


Work & Resource Mgmt. Configuration Mgmt. Safety Control

Rqmts. Development Requirements Mgmt. Feasibility Study Technology Planning Design Systems Analysis

9.9 Improvement Block Changes

9.3 Train Personnel


Work & Resource Mgmt. Control

10.1 Preparation for Decommission/ Disposal


Work & Resource Mgmt. Control

9.7 Assess Trends


Work & Resource Mgmt. Control

9.4 Maintain System


Work & Resource Mgmt. Configuration Mgmt. Acquisition Mgt. Control

Safety Review
Reviews

X.X Phase Stop


Supporting PM Process

9.5 Support System


Work & Resource Mgmt. Quality

Management and Planning


Technology Planning, Acquisition Management, Risk Management, Quality Management, Control, Work and Resource Management, Configuration Management, Safety and Mission Success, Resource Management, Documentation and Data Management, Cost Estimating, Performance Measurement, Schedule Management, Project Analysis

Figure 3-6. Phase E operations diagram. Identify new safety hazards and plans to resolve or mitigate them. The following checklist should be used to aid in determining successful completion of the Safety Review: Is current safety documentation up to date and accessible to all personnel? Have all safety incidents been properly addressed? Are current safety procedures still relevant and effective? Project Decision The project must decide whether current safety procedures and identified hazards and resolutions are acceptable. 3.6.5.4 The Decommissioning Review Details of the Decommission Review are addressed in Section 3.7. In this phase, the project shall initiate decommissioning studies and begin preparations for the Decommissioning Review. 3.6.6 Management Decision Directorate-level boards may/may not authorize the project to proceed with system operations. Customer management boards (whether Center- or program-level) may authorize recommended system upgrades. 3.6.7 References The following documents, which were used to prepare this section, offer additional insights into Phase E, Operations: 1 SP 6105, NASA Systems Engineering Handbook , 1995.
2

NPR 7120.5B, NASA Program and Project Management Processes and Requirements, 2002.

3-20

Project Life Cycle Requirements

3.7 Project Termination1 3.7.1 Overview During Project Termination, the project team methodically plans and performs actions that bring the project to a timely, orderly conclusion, and efficiently and safely remove the system from the field of operational or active NASA interest. Project termination generally occurs for one of the following reasons: The project has successfully completed Phase E, Operations, and the system of interest is nominally approaching the end of its planned useful service life. The project has exceeded safety, cost, and/or schedule limits to an unacceptable degree during its design, development, or operations. The project is anticipated to be unable to meet the commitments contained in project controlling agreements and plans. The project need is no longer valid. Project termination activities are planned and conducted so that appropriate degrees of oversight and control are provided both to the concluding stages of the project, whether nominal or off-nominal, and to the justification of, preparation for, and execution and documentation of decommissioning and/or disposal of the system of interest. 3.7.2 Activities The sets of activities differ for nominal and offnominal termination. 3.7.2.1 Nominal termination For nominal project Termination during operations, the project shall: Monitor the schedule to stay informed of the approach of the nominal end of schedule system service life. At an appropriate time, in advance of the end of service life, begin and complete preparations to make removal of the system of interest from service as efficiently, safely, and otherwise acceptable to the system operating environment as constraints permit. Remind all stakeholders of the approach of the end of schedule system service life. Gather and prepare to present information, as available, that both supports and opposes on-time termination of the project and disposal of the system. Coordinate and document detailed plans for nominal project termination, system

decommissioning and disposal, and project/system personnel transition. Maintain the capability to continue system operations in the event that decommissioning is postponed at the Decommissioning Review. Participate in a Decommissioning Review. The Decommissioning Review will either approve termination and disposal as planned or with modifications, or decide on new schedule/performance/safety/cost-based trigger(s) for postponed termination and disposal. If decommissioning is approved: Terminate project activity and support disposal of the system of interest and transition of personnel as planned or as redirected from plans by the Decommissioning Review. Document project closeout, support system decommissioning/disposal documentation insofar as project personnel are involved, and turn over control of the project information repository to the next -higher tier of management. If decommissioning is approved with modifications, plan modifications shall be made and presented to the Decommis sioning Review Board for concurrence. If decommissioning is postponed, continue system operations and either: Prepare as before to meet the Decom missioning Reviews new schedulebased termination target; or Monitor and assess trends using Decommissioning Review-designated performance/safety/cost triggers to recommend the next appropriate termination target. 3.7.2.2 Off-nominal termination Entry into the off-nominal termination phase occurs as a result of a Termination Review decision by the JSC Project Management Council (PMC) or the PMP designated authority. The Termination Review is held due to violation of established thresholds, anticipated inability to meet established commitments, or the project need no longer being valid. The project shall: Support the JSC PMC or the authority designated by the PMP project Termination Review. The project Termination Review shall either direct termination or establish new schedule/ performance/safety/cost-based trigger(s) or agreements to permit continued design, development, or operations.

3-21

Project Management: SE & Project Control Processes & Requirements

Upon direction to terminate, prepare to remove the system of interest from service in a manner that is efficient, safe, and acceptable to the system. Inform all stakeholders of the decision to terminate the project early, and dispose of the system of interest or its unintegrated elements before the scheduled end of service life. Gather and prepare to present information, as available, that both supports and opposes the proposed early termination of the project and disposal of the system. Coordinate and document detailed plans for early project termination, system disposal, and personnel transition. Participate in a Decommissioning Review, which will approve decommissioning plans either as presented or with modifications. If decommissioning is approved with modifications, the plan modifications shall be made and presented to the Decommissioning Review Board for concurrence. If decommissioning is approved: Terminate project activity, and support disposal of the system of interest and transition of project/system personnel as planned or as redirected from plans by the Decommis sioning Review. Document project closeout, support system decommissioning/disposal documentation insofar as project personnel are involved, and turn over control of the project information repository to the next -higher tier of management. 3.7.3 Products During Project Termination planning, the following are documented: Evidence supporting and/or opposing Project Termination and system disposal at the planned time System decommissioning/disposal requirements and plans Project closeout requirements and plans Project/system personnel transition requirements and plans Lessons learned 3.7.4 Process The diagrams (FIGS. 3-7.1 and 3-7.2) on the following page indicate the steps involved in off-nominal and nominal Project Termination and decommissioning. The interaction of these steps and the associated reviews is also illustrated along with the processes that should be referenced in executing each activity.

3.7.5 Reviews 3.7.5.1 The Termination Review A Termination Review is held in the off-nominal case to review violations of established project thresholds and/or anticipated inability to meet established commitments. At the review, the project should be prepared to detail: Current project status, concentrating on the contributors to the violation of established project threshold and/or anticipated inability to meet the established commitments that necessitated the review. The justification and authority of the established threshold or agreement. The result of this review will be a decision, by the governing authority (JSC PMC- or PMP-designated authority) to terminate the project or to establish new thresholds to continue design development or operations. 3.7.5.2 The Decommissioning Review In the nominal case, a Decommissioning Review is conducted to determine whether and how to terminate the project and dispose of the system. If the off-nominal case, the review is conducted to determine only how to terminate the project and dispose of the system. In either case, as with most reviews, the project team contributes significant technical content. At the review, the project team should be prepared to: Cite the authority under which they initiated preparations for termination of the project, dis posal of the system of interest, and transition of project/system personnel. Discuss the project schedule. Demonstrate that plans for project termination, system decommissioning and disposal, and project/system personnel transition at the proposed time are: Feasible. Consistent with requirements. Acceptable to stakeholders.1 Efficient, safe, and acceptable to the system operating environment as constraints permit. For the nominal case, Present information as available, both supporting and opposing the proposed termination of the project and disposal of the system. For the off-nominal case, Cite the authoritative direction to terminate and dispose. Review any top-level implementing guidance that the project received during planning for termination and disposal.

3-22

Project Life Cycle Requirements

Life Cycle Phases B E


(Definition, Design, Development, Operations)

Termination
10.1 Prepare for Disposal Alert Stakeholders Write and Coordinate Detailed Plans Terminate ? Yes Decommissioning Review
Reviews

Continuous Performance Assessment


Risk Management, Safety, Quality, Systems Analysis, Project Control Need Valid? PMP threshold violation/ anticipated inability to meet commitment ? No No Management Decision/ Control Gate Termination Review (JSC PMC - or PM Designated Authority)

Management Decision/Control Gate

With Mods Make Modifications As Necessary

As Planned

Yes

10.2 Decommission/ Dispose Implementation Plan Terminate Project Dispose of System Transition Personnel Document Actions and Decisions Give Repository to NextHigher Tier

No

Reestablish Thresholds/ Legitimize Need

Key:

Step Name/Description
Supporting PM Process

Decision

Verify Proper Plan Implementation Provide Assurance to Decommissioning Review Authority

Figure 3-7.1. Off-nominal project termination diagram.

Life Cycle Phase E


(Operations)

Termination
10.1 Prepare for Disposal Inform Stakeholders Gather Information For and Against Write and Coor dinate Detailed Plans Maintain Capability to Continue Operations Decommissioning Review
Reviews

Monitor Schedule
Schedule Management

Management Decision/Control Gate

No

Nominal End of Life Approaching ?

Yes

With Mods Make Modifications as necessary

Postponed

As Planned

10.2 Decommission/Dispose Implementation Plan Terminate Project Dispose of System Transition Personnel Document Actions and Decisions Give Repository to NextHigher Tier

Key:

Step Name/Description
Supporting PM Process

Decision

Verify Proper Plan Implementation Provide Assurance to Decommissioning Review Authority

Figure 3-7.2. Nominal project termination diagram.

3-23

Project Management: SE & Project Control Processes & Requirements

A successful Decommissioning Review assures that the decommissioning and disposal of system items and processes is appropriate and effective. This review determines whether the following conditions are met prior to decommissioning: Reasons for decommissioning/disposal are documented Disposal plan is complete and in compliance with local, state, and Federal environmental regulations Disposal plan addresses disposition of H/W, S/W, facilities, processes, and any contractual/ procurement actions necessary Disposal risks have been assessed Data archival plans have been defined Sufficient resources are assigned to complete the disposal plan A personnel transition plan is in place

Subsequent to implementation of the decommis sioning and disposal plans, assurance that these two plans were implemented as agreed is provided to the authority approving the plans. 3.7.6 Management Decision Management will direct whether to proceed with project termination, system disposal, and personnel transition in accordance with specific plans described at the Termination Review and Decommissioning Review, and, if not, what modifications to prescribe. 3.7.7 References The following document, which was used to prepare this section, offers additional insights into Project Termination: 1 NPD 8010.3, Notification of Intent to Terminate Operating Space Systems, 1999.

3-24

Project Management: Systems Engineering & Project Control Processes and Requirements

Project Management Processes and Requirements

Project Management Processes and Requirements

Chapter 4 Project Management Processes and Requirements


This chapter outlines the processes and requirements in support of Johnson Space Center (JSC) projects. It is divided into three sections. Section 4.1 addresses the systems engineering (SE) processes; Section 4.2 addresses the project control processes; and Section 4.3 presents those processes that cut across SE and project control. The following information is presented for each process: Process overview Provides a top-level summary narrative of the overall objective of the process, major process steps, products, and relationships with other project management (PM) processes. Function Provides the requirements for tasks and expected outcomes resulting from the process. Objective Defines the purpose of the process. Responsibilities Outlines the roles of key project team members in planning and executing the process steps. Life cycle Identifies the project life cycle phases supported by the process. Inputs Identifies the main inputs that support execution of the process. Steps Outlines the required main steps and preferred sequence of steps involved in executing the process. Steps are annotated with support of information that provides additional detail and clarification. Outputs Identifies the primary outputs from the process. Exit criteria Provides conditions for determining process completion. Measurement Identifies example base and derived measures that may be used in conjunction with executing the process. Base measures are simple measures relating to the primary activity that is being performed. Derived measures apply some algorithm to the base measure to provide trending data for corrective action analysis and future planning and estimating. While example measures are provided, it is the project teams responsibility to identify those measures that provide appropriate insight into the health of this project process. The procedure, which is defined in SLP 4.20, Process Measurement and Improvement, should be followed to properly identify, collect, analyze, and report project measures.

Methods and techniques Provides a list of available methodologies and techniques that could be used to execute the process steps. Software tools Provides a brief discussion of the functions provided by typical software (S/W) tools available to support the process. References Lists sources used to prepare the content of the process section or that can offer further insight into the process. The following paragraphs introduce several concepts and nomenclatures that are key for understanding the content of the PM processes covered in this chapter. In this chapter, extensive reference is made to the terms system, system of interest, and enabling system. These concepts are briefly explained below. A system is the combination of elements that functions together to produce the capability required to meet a need. Elements include all of the hardware (H/W), S/W, equipment, facilities, personnel, and processes and procedures needed for this purpose. The system of interest is the entity for which the project engineering team is responsible for designing, developing, integrating, and testing. The system of interest may be at any level in the hierarchy of a complex system. In considering a spacecraft, for example, the system of interest may be at the spacecraft level, the com munications system level, or the avionics box level. The system of interest may include human-level interactions. (FIG. 4-1). Enabling systems are those systems that complement the system of interest by providing essential services (e.g., launch, tracking and data relay, and navigation services) that comple ment the systems of interest but do not contribute directly to their functioning (FIG. 4-2). In this document, the nomenclature used to denote the decomposition of the system of interest is shown on page 4-3, Figure 4-3. Another important concept introduced here is that of project scope. Project scope constitutes the vision for the project and consists of the following elements: Need to develop or procure a system Goals and objectives of the customer and stakeholders Information about the customers and users of the system How the system will be developed or purchased, tested, deployed, and used. Project scope also includes the boundaries and constraints of both the project and the system.

4-1

Project Management: SE & Project Control Processes & Requirements

Figure 4-1. Example of three levels of system of interest.

Figure 4-2. Example of enabling systems.

4-2

Project Management Processes and Requirements

Parent System

System s of Interest

Enabling System(s)

System Element 1 (or Subsystem)

System Element N (or Subsystem)

Lower Architectural Elements

Lower Architectural Elements

End Items

End Items

Figure 4-3. Decomposition of the systems of interest. Key elements of the project scope are needs, goals, and objectives. The relationship among these is depicted in Figure 4-4. Project scope is defined up front, such that the vision and constraints of the project are clearly understood by the project team before requirements are written. This is an essential component that ensures the success of the project. The concept of project scope is reflected in the PM processes addressed in this chapter. 4.0.1 References The following documents, which were used to prepare this section, offer additional insights into the PM processes: 1 NPR 71xx.x (document number not yet assigned), Systems Engineering Processes and Requirements.
2

Hooks I, Farry K. Customer-Centered Products, American Management Association (AMACOM), 2001.

Needs
? Reason for the Project ? Derived from the Problem Statement ? Should Not Change Much Over Time Example: The Nation has a Need for Assured Human-Rated Space Transportation."

Goals
? Define What Actions Must Be Accomplished to Meet the Needs ? Derived from the Needs Example: To Fly Safely

Objectives
? Define How the Needs and Goals Are Accomplished (how do we know when we get there) Example: One Vehicle Loss in 500 Flights

Figure 4-4. Relationship among needs, goals, and objectives.

4-3

Project Management: SE & Project Control Processes & Requirements

4.1 Systems Engineering Processes 4.1.1 Requirements Development1,2 The Requirements Development process is performed to gather needs and constraints and to transform them into agreed-to requirements for the system of interest. These requirements, which are stated in acceptable technical terms, represent a complete description of the system of interest. The same Requirements Development process will be used to evaluate changes to requirements in an agreement or when other stakeholder requirements are identified that affect the system of interest. 4.1.1.1 Function1 In the Requirements Development process: Customer and stakeholder needs shall be defined. System of interest requirements shall be verified and validated. Requirements shall be evaluated and maintained due to changes in the needs or constraints of the system of interest. Requirements traceability/flow down shall be established. All technical requirements shall be documented. 4.1.1.2 Objective 1,2 The primary objective is to produce and analyze re quirements that will serve as the foundation for establishing the functions that a system of interest has to perform, how well the system of interest must perform, and with what systems it must interact. Requirements which, depending on design maturity, take the form of specifications, drawings, models, or other design documents are used to (1) build, code, assemble, and integrate end products; (2) verify end products against; (3) obtain off-the-shelf products; or (4) assign a supplier for development of subsystem products. 4.1.1.3 Responsibilities The Lead Systems Engineering function ensures that the Requirements Development process is fully implemented and the output of requirements meets intended criteria. The project or program manager is ultimately responsible for the content of the requirements, but the Lead Systems Engineering function assists the project or program manager in providing technical overview of the process. 4.1.1.4 Life cycle Requirements development begins during the advanced studies phase of the development life cycle, carries through preliminary analysis, and is baselined in the definition phase. Requirements development may also take place in the desk and development phases, if changes occur in agreements or enabling systems.

4.1.1.5 Inputs2,3 There are three types of inputs to the Requirements Development process: (1) statement of need or project request made by the customer from the agreement, other documents, enabling systems, and stakeholders that have a stake in the outcome of the system of in terest; (2) requirements in the form of outcomes from other processes, such as technical plans and decisions from technical reviews; and (3) requested or approved changes to requirements of the first type. Typical inputs to the Requirements Development process should include, but are not limited to: Goals and objectives Project or customer needs Stakeholder needs Assumptions, guidelines, and constraints (e.g., from specialty and design engineering) Technology availability, maturity, costs, and risks Outputs from preceding projects Records of meetings and conversations with the customer Policies and procedures Laws and regulations Operations concepts 4.1.1.6 Steps4 SE performs all of the steps in the Requirements Development process. The diagram at the top of the following page (FIG. 4.1-1) illustrates the major steps and products of the Requirements Development process. The three major steps are to (1) develop customer requirements, (2) develop system of interest requirements, and (3) analyze and validate requirements. These steps are progressively and iteratively executed until a validated set of requirements is achieved. The internal steps are shown in this illustration as well. The following adds detail to the steps illustrated: Develop Customer Requirements Stakeholder needs, expectations, constraints, and interfaces shall be collected and translated into customer requirements. Elicit and Collect Stakeholder Needs Elicit, identify, and collect stakeholder needs, expectations, constraints, and in terfaces for all phases of the system of interest life cycle. Engage relevant stakeholders using methods for eliciting needs, expectations, constraints, and external interfaces. Develop Customer Requirements Transform stakeholder needs, expectations, constraints, and interfaces into customer requirements. Translate stakeholder needs, expectations, constraints, and interfaces into documented customer requirements.

4-4

Project Management Processes and Requirements

Develop Customer Requirements

Elicit and Collect Stakeholder Needs

Develop Customer Requirements

Customer Requirements

Develop System of Interest Requirements

Establish System of Interest and Subsystem Requirements Establish and Maintain Operational Concepts and Associated Scenarios

Allocate Subsystem Requirements

Identify Interface Requirements

System of Interest Requirements

B Analyze and Validate Requirements

Establish and Maintain a Definition of Required Functionality Analyze Requirements to Achieve Balance

Analyze Requirements

C Validate System of Interest Requirements

Validate Requirements

KEY

Step/Activity

Product

Information/Output Flows

Connector

Figure 4.1-1. Requirements development process diagram. Define constraints for verification and validation. Develop System of Interest Requirements Customer requirements shall be refined and elaborated to develop system of interest and subsystem requirements. Establish system of interest and subsystem requirements. Establish and maintain system of interest and subsystem requirements that are based on customer requirements. Develop requirements in the technical terms necessary for system of interest and subsystem design. Derive requirements that result from design decisions. Establish and maintain a relationship among requirements for consideration during change management and require ments allocation. Allocate Subsystem Requirements Allocate requirements for each system of interest component. Allocate requirements to functions. Allocate requirements to system of interest components. Allocate design constraints to system of interest components. Document relationships among allocated requirements. Identify Interface Requirements Identify interfaces that are both external and internal to the system of interest. Develop requirements for identified interfaces. Analyze and Validate Requirements Requirements shall be analyzed and validated, and a definition of required functionality shall be developed with documented rationale provided. Establish and Maintain Operational Concepts and Associated Scenarios Develop operational concepts and scenarios, including functionality, performance, maintenance, support, and disposal, as appropriate. Define environment in which the system of interest will operate, including boundaries and constraints. Review operational concepts and scenarios to refine and discover requirements. As system of interest components are selected, develop a detailed operational concept that defines the interaction of the system of interest, the end user, and the environment, and that satisfies operational, maintenance, support, and disposal needs. Establish and Maintain Definition of Required Functionality Analyze and quantify functionality required by end users. Analyze requirements to identify logical or functional partitions. Using established criteria, partition requirements into groups to facilitate and focus requirements analysis.

4-5

Project Management: SE & Project Control Processes & Requirements

Consider the sequencing of time-critical functions both initial and subsequently during system of interest development. Allocate customer requirements to functional partitions, objects, people, or support elements to support the synthesis of solutions. Allocate functional and performance re quirements to functions and sub-functions. Analyze Requirements Analyze requirements to ensure they are necessary and sufficient. Analyze stakeholder needs, expectations, constraints, and external interfaces to remove conflicts and to organize into related subjects. Analyze requirements to determine whether they satisfy the objectives of higher-level requirements. Analyze requirements to ensure they are specific, measurable, achievable, resource constrained, and time constrained (SMART). Identify key requirements that have a strong influence on cost, schedule, functionality, ris k, or performance. Identify technical performance measures that will be tracked during the development effort. Analyze operational concepts and scenarios to refine customer needs, constraints, and interfaces and to discover new requirements. Analyze Requirements to Achieve Balance Analyze requirements to balance stakeholder needs and constraints. Use proven models (e.g., simulations) and prototyping to analyze the balance of stakeholder needs and constraints. Perform risk assessment on the requirements and functional architecture. Examine system of interest life cycle concepts for requirements impacts on risks. Prioritize requirements. Requirement priority information is key information to support any required project de-scope. Validate Requirements Validate requirements to ensure the resulting system of interest will perform appropriately and as intended in the customer environment using multiple techniques, as appropriate. Analyze requirements to determine the risk that the resulting system of interest

will perform appropriately in its intendeduse environment. Explore the adequacy and completeness of requirements by developing system of interest representations and obtaining feedback about them from relevant stakeholders . Assess the design as it matures in the context of the requirements validation environment to identify validation issues and expose unstated needs and customer requirements. Obtain customer concurrence with the requirements. 4.1.1.7 Outputs3,4 The primary output from the Requirements Development process is a system of interest requirements document that becomes the design baseline in passing the System Requirements Review (SRR) milestone. This requirements document may include: Concept of operation Mission requirements Functional require ments Customer restraints on the conduct of verification/validation Derived requirements Product requirements Product-component requirements Interface, environmental, and nonfunctional requirements Performance requirements, including key performance parameters Design constraints Relationship among requirements (e.g., parent, child, peer requirements) Physical and functional interface requirements Product installation, operational, maintenance, and support concepts Use cases (primarily for S/W development) Timeline scenarios System architecture Functional architecture Activity diagrams Results of requirements validation Technical baseline 4.1.1.8 Exit criteria3 An approved, validated system of interest requirements document that is derived from each individual requirement statement shall be: Clear, unique, consistent, stand-alone, and verifiable. Traceable to an identified source requirement. Not redundant to, nor in conflict with, any other known requirement.

4-6

Project Management Processes and Requirements

Not biased by any particular implementation. Identified with a verification method assigned to each requirement. Traceable to a higher-level requirement. Documented with results of customer concurrence discussions. While producing the system of interest requirements document, consider whether: The impact of enterprise and external constraints on system design is understood. The design team concurs with the list of requirements. Cost goals are established for the system. Stakeholder concurrence discussion results are documented. Requirements are verifiable via test, demonstration, examination, etc. All requirements are allocated. 4.1.1.9 Measurement The following table provides example base and derived measures that can be used in conjunction with executing the Requirements Development process. See discussion of Measurement on page 4-1. Base Measures Total # of Shall Statements Requirements Definition Effort (full-time equivalents (FTEs))

Functional concept analysis Functional definition and decomposition Quality functional deployment (QFD) Extraction from sources such as documents, standards, or specifications Observation of existing products, environments, and workflow patterns Use cases (primarily for S/W development) Business case analysis Reverse engineering (for legacy products)

4.1.1.11 Software tools16 Some means of capturing requirements should be required. This usually is a repository, the nature of which is dependent on the size and complexity of the system of interest. At a minimum, requirement statements must be captured and controlled, relationships among primary and derived requirements must be identified and managed, and a means for tracking changes over time must be provided. There are a number of commercial off-the-shelf (COTS) S/W applications (e.g., DOORS, SLATE) that provide extensive capabilities supporting requirements development and management. For a list of potential tools, see the table Derived Measures Total # of Requirements @ SRR Planned vs. Actuals Requirements Definition Productivity (allocated resources vs. actual resources used) Requirements Definition Effort Planned vs. Actuals Requirements Definition Rate Charts Requirements Definition Effort as % of Total Engineering Effort

Defects in Requirements (by phase) # of Incomplete Requirements

Requirements Defects Projected @ SRR vs. Actuals # of Blanks, To Be Determined (TBD), To Be Supplied (TBS), Incomplete Requirements vs. Planned @ SRR provided by INCOSE at: http://www.incose.org/tools/eia632tax/eia632top.html. 4.1.1.12 References The following documents, which were used to prepare this section, offer additional insights into the Requirements Development process: 1 NPR 71xx.x (document number not yet assigned), Systems Engineering Processes and Requirements.
2

4.1.1.10 Methods and techniques3,4 Some of the methods and techniques that may be used in the developing requirements are: Questionnaires, interviews, and brainstorming Working groups Project reviews Mission analysis Requirements analysis Performance analysis Trade studies Prototypes and models Constraint evaluation Cost/benefit analysis

EIA-632, Processes for Engineering a System, ANSI/EIA-632-1998, 1999.

4-7

Project Management: SE & Project Control Processes & Requirements

INCOSE Systems Engineering Handbook , Version 2.0, 2000.


4

CMMI-SE/SW/IPPD/SS V1.1, Capability Maturity Model Integration (CMMI) for Systems Engineering, Software Engineering, Integrated Product and Process Development, and Supplier Sourcing , 2002. 5 SP 6105, NASA Systems Engineering Handbook , 1995.
6

RP 1358, Systems Engineering Toolbox for Design-Oriented Engineers, 1994.

4-8

Project Management Processes and Requirements

4.1.2 Requirements Management1,2 The Requirements Management process is performed to manage the requirements of the system of interest and its subsystem components, and to identify inconsistencies among those requirements and the plans and work products of the project. This process manages all requirements received or generated by the project, including both technical and nontechnical requirements. The Requirements Development process is the primary source of these requirements. 4.1.2.1 Function1 In the Requirements Management process: Baselined requirements developed in the Requirements Development process shall be established. Proposed changes shall be reviewed by affected organizations to assess impact on project cost, schedule, and performance on the system of interest. Proposed changes shall be reviewed by interfacing organizations and stakeholders to assess impact on the system of interest. Requirements shall be maintained under configuration control. Changes to the baselined requirements shall be managed and assessed. 4.1.2.2 Objective 2,3 The objective of requirements management is to establish a repository of baseline system of interest requirements to serve as a foundation for requirements refinement and revision by subsequent functions in the product development life cycle, for a nonambiguous and traceable flow of requirements to system of interest sub-components, and for support of corrective actions based on inconsistent requirements. 4.1.2.3 Responsibilities The Lead Systems Engineering function is to ensure that the Requirements Management process is fully implemented and the output of requirements meets intended criteria. The project or program manager is ultimately responsible for the content of the requirements, but the Lead Systems Engineering function assists the project or program manager in providing technical overview of the process. The Lead Systems Engineering function should ensure that impacts from changes to requirements are ex amined thoroughly and fully tracked to completion in the Requirements Management process. 4.1.2.4 Life cycle18 Requirements management begins with project initiation and carries through all phases of the project.

4.1.2.5 Inputs3 Specific inputs should include those produced by the Requirements Development process, namely: Concept of operations Mission requirements Functional requirements Customer restraints on the conduct of verification/validation Derived requirements Product requirements Product-component requirements Interface environmental, and nonfunctional requirements Performance requirements, including key performance parameters Design constraints Relationship among requirements Physical and functional interface requirements Product installation, operational, maintenance, and support concepts Use cases (primarily for S/W development) Timeline scenarios System architecture Functional architecture Activity diagrams Requirements defects reports Technical performance measurements (TPMs) Results of requirements validation Technical baseline 4.1.2.6 Steps2 SE performs all five steps in the Requirements Management process. These steps and their overall relationships are illustrated in Figure 4.1-2 at the top of the following page. In performing the Requirements Management process, users shall: Develop with the requirements providers an understanding of the meaning of the requirements. Establish criteria for distinguishing appropriate requirements providers. Establish objective criteria for the acceptance of requirements. Analyze requirements to ensure that established criteria are met. Reach an understanding of the requirements with the requirements provider so the project participants can commit to the requirements. Obtain commitment to the requirements from project participants. Assess the impact of requirements on existing commitments. Negotiate and record commitments.

4-9

Project Management: SE & Project Control Processes & Requirements

System of Interest Requirements

Manage Requirements Changes

Develop Understanding of Requirements

Obtain Commitment to Requirements

Requirements Repository

Identify Inconsistencies Among Project Plans, Work Products, and Requirements

Requirements Inconsistencies

Maintain bi-directional Traceability of Requirements Step/Activity Product Information/Output Flows B

KEY

Connector

Figure 4.1-2. Requirements management process diagram. Manage changes to the requirements as they evolve during the project. Capture all requirements and requirements changes given to or generated by the project. Maintain the requirements change history with a rationale for the changes. Evaluate the impact of requirement changes from the standpoint of relevant stakeholders. Make the requirements and change data available to the project. Maintain bi-directional traceability among the requirements and the project plans and work products. Maintain requirements traceability to ensure that the source of lower-level (i.e., derived) requirements is documented. Maintain requirements traceability from a requirement to its derived requirements as well as to its allocation of functions, objects, people, processes, and work products. Maintain horizontal traceability from function to function and across interfaces. Generate requirements traceability matrix. Identify inconsistencies between the project plans and work products and the requirements. Review project plans, activities, and work products for consistency with the re quirements and changes made to the requirements. Identify both the source of the inconsistency and the rationale. Identify changes that need to be made to the plans and work products resulting from changes to the requirements baseline. Initiate corrective action. 4.1.2.7 Outputs18 The output of the Requirements Management process is a system of interest requirements repository that contains the validated set of requirements and provides control over requirement additions, changes, and deletions. In addition to requirements, other information is stored in the repository, including: Requirement rationale and assumptions Requirement assignments Requirement bi-directional traceability Any other information contained in the requirements document that needs to be controlled and made available to the various stakeholders Requirements defects reports 4.1.2.8 Exit criteria2 A configuration-controlled requirements repository shall have a documented requirements tracking method. The repository contains requirements that shall be: Clear, unique, consistent, stand-alone, and verifiable. Traceable to an identified source requirement. Not redundant to, nor in conflict with, any other known requirement. Not biased by any particular implementation. Identified with a verification method assigned to each requirement. Traceable to a higher-level requirement. Documented with results of customer concurrence discussions.

4-10

Project Management Processes and Requirements

4.1.2.9 Measurement The following table provides example base and derived measures that can be used in conjunction with executing the Requirements Management process. See discussion of Measurement on page 4-1. Base Measures Total # of Requirements (e.g., name of shall statements) # of Requirements Added, Changed, or Deleted Requirements Management Effort (FTEs)

INCOSE Systems Engineering Handbook , Version 2.0, 2000.


4

EIA-632, Processes for Engineering a System, ANSI/EIA -632-1998, 1999. Derived Measures Requirements Managed Planned @ SRR vs. Actuals Requirements Volatility = % Added, Changed, or Deleted (since SRR) Requirements Management Productivity Requirements Management Effort Planned @ SRR vs. Actuals Requirements Management Effort as % Total Engineering Effort

4.1.2.10 Methods and techniques Some of the methods and techniques that may be used in the Requirements Management process are: Requirements analysis Traceability analysis 4.1.2.11 Software tools18 Some means of capturing requirements should be required. This usually is a repository of some kind, the nature of which is dependent on the size and complexity of the system of interest. At a minimum, requirement statements must be captured and controlled, relationships among primary and derived requirements must be identified and managed, and a means for tracking changes over time must be provided. A number of COTS S/W applications (e.g., DOORS, SLATE) provide extensive capabilities supporting requirements development and management. For a list of potential tools, see the table provided by INCOSE at: http://www.incose.org/tools/eia632tax/eia632top.html. 4.1.2.12 References The following documents, which were used to prepare this section, offer additional insights into the Requirements Development process: 1 NPR 71xx.x (document number not yet assigned), NASA Systems Engineering Processes and Requirements. 2 CMMI-SE/Sw/IPPD/SS V1.1, Capability Maturity Model Integration (CMMI) for Systems Engineering, Software Engineering, Integrated Product and Process Development, and Supplier Sourcing, 2002.

5 6

SP 6105, NASA Systems Engineering Handbook , 1995.

RP 1358, Systems Engineering Toolbox for Design-Oriented Engineers, 1994. 7 SWELT:RM0.2, Requirements Management Guidebook , 1996. 8 Hooks I, Farry K, Customer-Centered Products, American Management Association (AMACOM), 2001.

4-11

Project Management: SE & Project Control Processes & Requirements

4.1.3 Operational Concept Development1 The Operational Concept Development process is performed to better understand the capabilities and performance of the system of interest within its proposed mission, use, or function. This process helps to focus the Requirements Development process so systems operations, deployment, delivery, support (including maintenance and sustaining), training, and disposal as well as all modes and states are considered during system of interest definitionregardless of engineering discipline. The operations concept describes the who, what, when, where, and how of the system. Operational concept and scenario development evolves as an iterative process. Operational concepts are refined as solution decisions are made, system of interest components are defined, and lower-level detailed requirements are developed. 4.1.3.1 Function1,2 In this process, a high-level definition of the operational concept and scenarios for the system of interest shall be established and maintained to cover the operational stages and to define timeline, functions, and interfaces. 4.1.3.2 Objective The primary objective of the Operational Concept Development process is to document what the operational system will do and why, and to communicate with the end user so that operational needs are clearly understood. The secondary objective is to define any critical, top-level performance requirements (stated either qualitatively or quantitatively) and system rationale. Other objectives are to: Provide traceability between operational needs and written source requirements captured in the Requirements Development process. Establish a basis of requirementse.g., personnel requirements, support requirements, etc. to support the system of interest over its life. Establish a basis for integration test planning, interface and system-level requirements, and any requirements for environmental stimulators. Provide the basis for computation of system capacity, behavior underload/overload, and mission-effectiveness calculations. Validate requirements at all levels to discover implicit requirements overlooked in source documents. 4.1.3.3 Responsibilities The Lead Systems Engineer is responsible for leading discussions with operations personnel (e.g., end users, system operators, facilities, flight crew, Mission Operations) and the Design Engineering Team to develop the
3

concept of operations. All parties should concur on the defined concept of operations. The Lead Systems Engineer is also responsible for the performance of the process steps outlined below. The Design Engineering Discipline (e.g., mechanical, electrical, S/W) are responsible for using the defined concept of operations as the basis for functional decomposition and requirements allocation. The Project Manager is responsible for reviewing and agreeing on the defined concept of operations. 4.1.3.4 Life cycle Operations concept development begins during the advanced studies phase of the development life cycle, and these concepts are further refined and alternatives defined during preliminary analysis. As system of in terest requirement changes are encountered during the definition, design, and development phases, operations concepts shall also be updated to ensure concurrency. Operations concepts and associated scenarios provide input into the development of operational products (e.g., operational plans and procedures) performed during the development phase. 4.1.3.5 Inputs3,4 Typical inputs to this process include, but are not limited to: Goals and objectives Mission needs Stakeholder needs Assumptions, guidelines, and constraints System of interest operating environment(s) System of interest concept and system hierarchy Technical operational requirements Statement of operational objectives System requirements document Data flow diagrams State/mode diagrams Behavior diagrams Customer standard operating procedures Existing operational infrastructure Records of meetings and conversations with customer 4.1.3.6 Steps25 The diagram on the following page (FIG. 4.1-3) illustrates the major steps and products of this process. These are progressively and iteratively executed until a validated concept of operations is achieved. In performing the Operational Concept Development process, users shall take the following steps: Top-Level Operational Concepts and Associated Scenarios Top-level operational concepts and associated scenarios shall be developed.

4-12

Project Management Processes and Requirements

?
Develop Top-Level Operational Concepts and Scenarios Define Top-Level Operational Environments Top-Level Con Ops and Scenarios

Evolve Operational Concepts and Scenarios Evolve Operational Environments

Integrated Set of Detailed Con Ops and Scenarios

Review Operational Concepts and Scenarios

Derived System of Interest Requirements

These steps are progressively and iteratively executed until a validated concept of operations is achieved. Information/Output Flows Product Connector

KEY

Step/Activity

Figure 4.1-3. Operational concept development process diagram. Develop top-level operational concepts and scenarios. Include functionality, performance, maintenance, support, and disposal as appropriate. Identify and develop scenarios consistent with the level of detail in the stakeholder needs, expectations, and constraints in which the proposed system of interest is expected to operate. Define top-level operational environments. Define the environments in which the system of interest will operate. Include boundaries and constraints. Detailed Operational Concepts and Scenarios Establish and maintain detailed operational concepts and scenarios. Evolve operational concepts and scenarios. As system of interest components are selected, further evolve operational concepts and scenarios to describe the conditions, operating modes, and operating states specific to each system of interest component. Evolve operational environments. Evolve the operational environments for each system of interest component defined. Take into consideration that the environment for any given system of interest will be influenced by other system of interest components and by the external environment. Review operational concepts and scenarios. Integrate operational concepts and scenarios produced for each physical level of system of interest decomposition. Refine requirements and discover overlooked implicit requirements. The following questions should be answered in the development of an operational concept: Operational Distribution or Deployment: Where will the system be used? Mission Profile or Scenario: How will the system accomplish its mission objective? Performance and Related Parameters: What are the critical system parameters to accomplish the mission? Utilization Environments: How are the various system components to be used? Effectiveness Requirements: How effective or efficient must the system be in performing its mission? Operational Life Cycle: How long will the system be operated by the user? Environment: What environments will the system be expected to operate in effectively? 4.1.3.1 Outputs15 The primary output from this process is a system of interest concept of operations document that is baselined at the SRR milestone. Outputs of this process include: Concept of operations document

4-13

Project Management: SE & Project Control Processes & Requirements

Top-level and detailed operational concept definitions Operational, installation, support, maintenance, training, disposal, and support concepts Integrated set of component-level operational concepts and scenarios Operational behavior models for each operational mode traceable from source requirements Operational scenarios (step-by-step descriptions of how the proposed system of interest should operate and interact with its users and external interfaces) Use cases Timeline scenarios Timeline analyses of component interactions Trade analyses for the operations concept System test plan test threads and key test features Environmental simulation plan Derived requirements 4.1.3.2 Exit criteria Exit criteria include: Release and approval of the system of interest concept of operations document at the SRR. Assurance that all operational concept changes affecting the system of interest have been properly communicated to the interfacing and component suppliers. 4.1.3.3 Measurement3 The following table provides example base and derived measures that can be used in conjunction with executing the Operational Concept Development process. See discussion of Measurement on page 4-1. Base Measures # of Functional Flow Diagrams # of System External Interfaces # of Unresolved Source Requirement (i.e., TBD, TBS, etc.) 4.1.3.4 Methods and techniques3,6 In addition to a scan of the listed input documents, additional operational insight can be achieved through: Interviews with operators of current/similar systems. Interviews with potential users. Interface working group (IFWG) meetings. Observation of existing products, environments, and workflow patterns.
3,5

The following diagramming techniques may be employed to capture operational concepts: Context diagrams Mission event sequence illustrations Functional flow diagrams Timeline charts N2 charts 4.1.3.5 Software tools A standard word processor is sufficient for developing the concept of operations document and associated scenarios. Once the document and the associated scenarios have been developed, they should be placed under configuration management (CM) control to maintain and support their evolution. The use of basic spreadsheet and graphics tools is also applicable in the development of N2 charts as are context, event sequence, timeline, and functional flow diagrams. 4.1.3.12 References The following documents, which were used to prepare this section, offer additional insights into the Operational Concept Development process:
1

NPR 71xx.x (document number not yet assigned), NASA Systems Engineering Processes and Requirements . 2 CMMI-SE/SW/IPPD/SS V1.1, Capability Maturity Model Integration (CMMI) for Systems Engineering, Software Engineering, Integrated Product and Process Development, and Supplier Sourcing, 2002. CMMI is a service mark of Carnegie Mellon University. 3 INCOSE Systems Engineering Handbook , Version 2.0, 2000.
4

Section 4.3.1 of this document.

Derived Measures Functional Flow Diagrams Required vs. Completed System External Interfaces Required vs. Completed Unresolved Source Requirement Statements % Completed
5

EIA-632, Processes for Engineering a System, ANSI/EIA -632-1998, 1999. 6 Defense Systems Management College, System Engineering Fundamentals, 2001. 7 ANSI/AIAA G-043-1992, Guide for Preparation of Operational Concept Documents.

4-14

Project Management Processes and Requirements

4.1.4 Decomposition1 The Decomposition process is performed to develop an architectural breakdown of the system of interest into lower-level elements to allocate the functions and requirements to the respective elements of the system of interest and to identify all physical and functional interfaces for the various levels. Decomposition is an iterative process that is performed until the system of interest is decomposed to the level needed to fully define it. Typically, the Decomposition process runs concurrent with development of the system concept of operations (SECTION 4.1.3) because the concept of operations is used as the basis for functional decomposition and requirements allocation. 4.1.4.1 Function1 In the Decomposition process: Physical and functional architectures shall be developed that identify the next lower-level physical or functional elements of the system of interest. The system architecture for the system of interest shall include an allocation of functions and requirements to the respective elements of the system of interest. Identification of interfaces shall also be developed and documented, thereby defining all physical and functional interfaces for the various levels of the system of interest. All physical and functional interfaces shall be identified, developed, and documented for the system of interest. 4.1.4.2 Objective 2,3,4 The primary objectives are to (1) document the allo cation of higher-level systems, requirements, or customer needs into lower-level components within the context of the system of interest; and (2) document the interfaces down to the lower-level components. This allows for a better understanding of what the system of interest has to do and in what ways it can perform, both logically and in terms of the performance required. Other objectives are to: Allocated higher-level functional and performance requirements to lower-level functions (i.e., requirements traceability). Document how requirements are parsed/ detailed into requirements for functional or physical components. Identify priorities and conflicts associated with lower-level functions. Provide information essential to optimizing and evaluating solutions. Form the basis for design definition.

Develop and maintain interface control or definition documentation that defines all physical and functional interfaces for the various levels of the system of interest. Identify and characterize interfaces between decomposed elements and functions. 4.1.4.3 Responsibilities3 The Lead Systems Engineer is responsible for the performance of the process steps outlined below. Process execution may include working and coordinating with multiple engineering disciplines (e.g., H/W, S/W, mechanical, electrical, environmental) to ensure the proper and appropriate level of system decomposition is achieved. The Design Engineering Team is the primary customer of the products resulting from the Decom position process. Decomposition process products are used by the Design Engineering Team as the basis for design. 4.1.4.4 Life cycle System decomposition begins during the advanced studies phase of the project life cycle with the development of a high-level system architecture and breakdown structure. The system of interest architecture and interfaces are further refined, and architectures associated with alternative solutions are defined during preliminary analysis. As the system of interest continues through the definition and design phases (i.e., system definition, preliminary design, and final design stages) of the life cycle, the architecture and interfaces of the selected solution are further decomposed to whatever level of decomposition is needed to fully define the system. 4.1.4.5 Inputs4,5 Typical inputs to this process include, but are not limited to: System goals and objectives System requirements, including functional, physical, environmental, and performance products and interface requirements System hierarchy concepts High-level architectures (functional and physical) Operational concepts and scenarios, including: Use cases (for S/W projects) Data flow diagrams State/mode diagrams Behavior diagrams Timeline scenarios 4.1.4.6 Steps2,5,6 SE is responsible for all of the steps in the Decomposition process. The following diagram (FIG. 4.1-4) illustrates the major steps and products of this process.

4-15

Project Management: SE & Project Control Processes & Requirements

Higher-Level System Requirements

Allocate System Requirements to Lower-Level Architectures

Functionally Decompose System of Interest

Lower-Level Functional Architectures

Identify Functional and Physical Interfaces

Physical Decompose System of Interest High-Level Operational Concepts & Architectures

Lower-Level Physical Architectures

Interface Control Documentation

Iterate process. Lower-level architectures become higher-level ones in next process pass. Information/Output Flows

KEY

Step/Activity

Product

Connector

Figure 4.1-4. Decomposition process diagram. Higher-level architectures, operational concepts, and system requirements are from the previous concurrent execution of the decomposition, operations concept development, and requirements development processes, respectively. This repetitive decomposition occurs until the architecture detail and allocation of require ments are sufficient for the design process to start as follows: Functionally Decompose System of Interest Functional decomposition shall be performed on the sys tem of interest. Decompose the system functions into subfunctions. Iterate until the system is decomposed into its basic sub-functions and each sub-function at the lowest level is completely and uniquely defined by its requirements. The resulting product is the functional architecture. Physically Decompose System of Interest Physical decomposition shall be performed on the system of interest. Functional decomposition of the system occurs concurrently with physical decomposition of the system. The resulting product is the physical architecture. Allocate Requirements to the Architectures System of interest requirements shall be allocated to the lower-level functional and physical architecture. To achieve this: Distribute the functional system requirements to each of the functional system elements. Distribute the physical system requirements to each of the physical system elements. Perform and establish traceability of performance requirements (requirements allocation sheets (RASs)). Identify Interfaces Functional and physical interfaces shall be identified and maintained. Identify and document functional and physical interfaces between products internal to the system of interest. Identify and document functional and physical interfaces associated with external items and enabling systems. Identify and document interfaces between products and the product-related life cycle processes. For example, such interfaces may include those between a product that is to be fabricated and the jigs and fixtures that are used to enable fabrication during the manufacturing process. Ensure that the documented interface solutions account for all of the interface requirements developed in the requirements development processes.

4-16

Project Management Processes and Requirements

Some specific activities that can occur during the Decomposition process include: Task sequences and relationships (functional flow block diagram (FFBD)) Process and data flows (i.e., integration definition for function modeling (IDEF0) diagrams) The time sequence of time-critical functions (timeline analysis sheets (TLSs) 4.1.4.7 Outputs1,2,3,5,6 Primary outputs from this process are: Functional architecture Physical architecture Product breakdown structure Interface control documents (ICDs) 4.1.4.8 Exit criteria2,6 Exit criteria include: Completion of FFBD documentation to level of detail required for project life cycle phase. Completion of interface definition descriptions for all interfaces (N2 charts may be sufficient). Completion of RASs (or tables) for all functional requirements. 4.1.4.9 Measurement2 The table at the bottom of the page provides example base and derived measures that can be used in conjunction with the Decomposition process. See discussion of Measurement on page 4-1. 4.1.4.10 Methods and techniques25 Several methods and techniques are available to adequately define and represent the functional and physical architecture of the system of interest. These include: Functional Flow Block Diagramming Diagrams that show the logical sequence (network) of actions that leads to fulfillment of a function. Timeline Analysis Used to define the time sequence of time -critical functions. The TLS adds Base Measures d # of Functional Flow Diagrams # of System External Interfaces # of Issues/Risks Identified

detail to defining durations of various functions. It defines concurrency, overlapping, and sequential relationships of functions and tasks. It identifies time-critical functions that directly affect system availability, operating time, and maintenance downtime. Finally, it is used to identify specific time-related design requirements. N2 Diagramming A matrix displaying functional interactions, or data flows, at a particular hierarchical level. RASs Used to identify allocated performance and to establish traceability of performance requirements. IDEF0 A common modeling techniques for the analysis, development, re -engineering, and integration of information systems, business processes, or SE analysis. Where the FFBD is used to show the functional flow of a product, IDEF0 is used to show data flow, system control, and the functional flow of life cycle processes. Trade Studies Used to evaluate different decomposition (architecture) alternatives. Functional Thread Analysis A thread consists of the system input and output. Analysis of threads identifies stimulus-condition-response threads to control S/W development. Modeling and Simulation Used to verify the interpretation, definition, and viability of key functions. Real-Time Structural Analysis An alternative to functional allocation that is usually applied to the design of S/W-intensive systems. Typical steps are to construct data flow diagrams and data dictionaries. Object-Oriented System Modeling Used to construct an object that combines data structure and behavior in a single entity to represent the components of a system. This form of modeling allows conceptual issues to be clearly understood before the system is built.

Derived Measures Function Flow Diagrams Required vs. Completed ICDs Required vs. Completed Unresolved Issues/Risks % Completed/Mitigated Depth of Functional Hierarchy % vs. Target Depth % of Requirements Allocated at the Lowest Level of Hierarchy

4-17

Project Management: SE & Project Control Processes & Requirements

Architectures may also include standards and design rules governing the development of system components and their interfaces, as well as guidance to aid product developers. 4.1.4.11 Software Tools2 A standard word processor is sufficient for documenting the architectures and ICDs. Once developed, they should be placed under CM control to maintain and support their evolution. The use of basic spreadsheet and graphics tools is also applicable in the development of N2 charts, RASs, and TLSs, as well as functional flow and IDEF0 diagrams. Other S/W tools that can be used in the Decomposition process include: Analysis tools Modeling tools Prototyping tools Simulation tools Requirements traceability tools

4.1.4.12 References The following documents, which were used to prepare this section, offer additional insights into the Decomposition process: 1 NPR 71xx.x (document number not yet assigned), NASA Systems Engineering Process and Requirements. 2 INCOSE Systems Engineering Handbook , Version 2.0, 2002. 3 SP 6105, NASA Systems Engineering Handbook , 1995. 4 Defense Systems Management College, System Engineering Fundamentals, 2001. 5 CMMI-SE/SW/IPPD/SS V1.1, Capability Maturity Model Integration (CMMI) for Systems Engineering, Software Engineering, Integrated Product and Process Development, and Supplier Sourcing, 2002. CMMI is a service mark of Carnegie Mellon University.
6

EIA-632, Processes for Engineering a System, ANSI/EIA -632-1998, 1999.

4-18

Project Management Processes and Requirements

4.1.5 Feasibility Study1 The Feasibility Study process is performed to evaluate and iterate the needs and potential approaches for technical and programmatic feasibility. This process establishes technical and resource feasibility and identifies the associated risks of meeting requirements within the given constraints. 4.1.5.1 Function1,2 The Feasibility Study process is performed to evaluate the technical and programmatic possibility of success of an approach(es) to realizing the system of interest. Credibility of a candidate concept and its subsequent design is also at issue in this requirement. In the Feasibility Study process: Evaluation criteria for assessing feasibility of approaches shall be established and ranked. One or more technically and programmatically implementable approaches for the system of interest under consideration shall be established in the feasibility study. Cost estimates shall be determined for each possible system of interest approach. 4.1.5.2 Objective The Feasibility Study process is performed to ascertain whether the system of interest can be designed, implemented as designed, and then accomplish system goals all within the constraints imposed by the fiscal and thermal environments of the project. 4.1.5.3 Responsibilities Depending on the size and complexity of the project, the Feasibility Study process is led by the Project Manager or by another individual who is acting in the role of Lead Systems Engineer and can take a broad view of the total system of interest. Consultation with experienced personnel who have performed similar projects may be useful. Other personnel/roles may participate in proportion to the scale and complexity of the project. Broad participation in the feasibility study by the Project Team and outside experts usually contributes to the fidelity of the study effort. For example, Design Engineering Disciplines may develop the system concept and architecture options for evaluation. Specialty Engineering Disciplines may contribute to the evaluate process or identify show-stoppers to proposed concept options. Cost Personnel may contribute to estimating the cost of the possible system approaches. 4.1.5.4 Life cycle During Pre-Phase A, Advanced Studies, the process iterates between requirements and alternative concepts, with the goal of establishing feasibility by admitting one or more concepts. It is intended that

the feasibility assessment by completed during Phase A, Preliminary analysis, where requirements and concepts are refined to establish optimal system requirements and a single, optimum top-level architecture. However, circumstances may indicate the need for continuing assessments at lower levels in the architecture to complete optimization of the total system of interest. 4.1.5.5 Inputs As shown in Section 4.1.5.6, the Feasibility Study process begins with an understanding of the system of interest stakeholders and their needs, the operational environment, and the system sub-elements. These are examined in the Requirements Development (Section 4.1.1), Re quirements Management (Section 4.1.2), Operational Concept Development (Section 4.1.1), and Decomposition (4.1.4) processes. Therefore, the outputs of these processes, listed below, should be used as inputs to the Feasibility Study process. Requirements document Contents of the system of interest requirements repository, including requirement: Additions, changes, and deletions Rationale and assumptions Assignments Bi-directional traceability Concept of operations document Functional architecture Physical architecture Product breakdown structure Preliminary interface definition 4.1.5.6 Steps In Pre -Phase A, requirements and concepts are iterated to establish feasibility; and in Phase A, requirements and concepts are iterated to establish optimal system requirements and top-level architecture. Major steps and products of the Feasibility Study process are illustrated in Figure 4.1-5. The specific steps in the process follow. In taking these steps, study participants: Should Review Requirements To understand the expected performance, conceptual configuration, and operating environment of the system of interest. Study participants should also examine the decomposition of stakeholder needs, assumptions, presumed scenarios, environmental constraints, and structure documented in the: Requirements document. Contents of the requirements repository. Concept of operations. Functional and physical architectures.

4-19

Project Management: SE & Project Control Processes & Requirements

Requirements Document

Requirements Repository

Concept of Operations

Functional/Physical Architectures

Preliminary Interface Document

Product Breakdown Structure

START Review Requirements Determine Option Costs, Benefits, Schedules, Risks

Identify Constraints

Select Options for Evaluation

Preliminary Options Costs, Schedules, Risks

Preliminary Option Ops Concepts

Preliminary Option Interface Definition

Preliminary Option Tech Plans

Develop Evaluation Criteria

Prioritized Evaluation Criteria

Select Feasible Options

Feasibility Assessment Document

KEY

Step/Activity

Product

Information/Output Flows

Connector

Figure 4.1-5. Feasibility study process diagram. Preliminary interface definition. Product breakdown structure. Should Identify Constraints Analyze information gained from the review to identify environmental, operational, functional, or architectural constraints. Identify critical physical or functional interfaces or project constraints. Shall Select Options for Evaluation Develop alternative solutions or conceptual designs for the system of interest. Shall Determine Cost Estimates for Each Option Identify alternative operations and logistics concepts. Develop cost and schedule estimates for each alternate solution. Identify technical, cost, schedule, programmatic, and safety risks for each alternate solution. Shall Develop and Prioritize the Evaluation Criteria Establish prioritized evaluation criteria for assessing the feasibility of the alternative solutions. Select criteria appropriate to the system of interest. Assess the fit of the solution with JSC or organization strategic or implementation plans. Examples can include, but are not limited to, the factors shown in the table at the top of the following page. Shall Select Feasible Options Use prioritized evaluation criteria to identify technically and programmatically feasible solutions for further study or development. produce a feasibility assessment document that includes, but is not limited to, the following: Description of and rationale for evaluation criteria Descriptions of alternatives considered, which can include preliminary option: Costs, schedules, risks Operations concepts Interface definition Technical plans Ranked feasible alternative solutions list 4.1.5.7 Outputs For the Feasibility Study phase: For Pre-Phase A, the output of this process is a top-level or partial feasibility assessment. For Phase A, the output of this process is a completed feasibility assessment.

4-20

Project Management Processes and Requirements

Performance

Technology Readiness

(As required) (As required)

Physical Envelopes Safety Life Cycle Cost, Budget, During All and Schedule Applicable Project Phases (As required) Design, development, Length test, and evaluation Width (DDTE) Height Deployment Mass Skills, training Electromagnetic Disposal compatibility/ Foreseeable required electromagnetic improvement/ interference augmentation/ (EMC/EMI) complementary or follow -on system

Resources

Specialty Engineering

Risk

Power Information technology Facilities Thermal rejection On-orbit crew time Crew training time Upmass Up volume On-orbit stowage space Downmass Down volume Launch infrastructure Operations & communications infrastructure Ground processing infrastructure

Reliability Maintainability Transportability Sustainability Producibility Supportability Human Factors Safety Quality Assurance S/W Assurance Environmental Fabrication Test & Verification Training Operations Information Systems Logistics & Maintenance

Technical & performance Safety Cost Schedule

4.1.5.8 Exit criteria For the Feasibility Study phase: For Pre-Phase A, a top-level or partial feasibility assessment shall be documented and accepted at the concept review. For Phase A, completed feasibility assessment shall be documented and accepted at the definition review. 4.1.5.9 Measurement The following table provides example base and derived measures that can be used in conjunction with executing the Feasibility Study process. See discussion of Measurement on page 4-1. Base Measures Total # of Alternative Solutions Studied

Trade studies Cost-benefit studies Risk assessment matrix Success tree analysis Benchmarking Concurrent engineering

4.1.5.11 Software tools Standard office automation tools that support identification and direct communication of the process inputs to the study team should generally be used; e.g., word processor, spreadsheet, and presentation slide S/W for personal computers Derived Measures Total # of Alternative Solutions Studied Planned vs. Actual Alternative Solution Study Rate Charts

Feasibility Study Effort (FTEs)

Feasibility Study Productivity Feasibility Study Effort Planned vs. Actuals Feasibility Study Effort as % Total Engineering Effort

4.1.5.10 Methods and techniques3 The key techniques here are sound managerial and engineering judgment. The following technical and management devices may be useful in performing the assessments:

(PCs). Some tools are available that provide for documentation of the options, input of the evaluation criteria, and display of the ranked list of options. One such tools is Expert Choice.4

4-21

Project Management: SE & Project Control Processes & Requirements

4.1.5.12 References The following documents and Web site, which were used to prepare this section, offer additional insights into the environment of the Feasibility Study process: 1 NPR 71xx.x (document number not yet assigned), NASA Systems Engineering Pro cesses and Requirements . 2 SP 6105, NASA Systems Engineering Handbook , 1995. 3 RP 1358, System Engineering Toolbox for Design-Oriented Engineers, 1994. 4 Expert Choice, Inc., www.exp ertchoice.com

4-22

Project Management Processes and Requirements

4.1.6 Technology Planning1,2 The Technology Planning process is performed to ensure that technologies critical to the success of the project are identified and the effort to advance the technologies is understood and feasible. 4.1.6.1 Function1,2 For a system to be realized, the technologies that enable achievement of system goals must be available within the resources and schedule of the project. A technology assessment is therefore performed and documented to identify and characterize requirements and development plans for the key enabling and enhancing technologies that the system of interest will require, and how these technologies will be acquired and incorporated into the system. In the Technology Planning process: An initial technology assessment shall be performed and documented that identifies any key enabling and enhancing technologies that will need to be infused into the system of interest and also identifies the existing technology readiness level (TRL) for each. (References explain determining TRLs.) Identified technologies shall be further assessed and documented to determine what is required to advance them to the level necessary for successful inclusion into the overall system of interest. Technology maturation and insertion planning shall be developed and documented for each identified technology that describes quantifiable milestones, decision gates, and fallback positions for incorporating the identified technologies into the system of interest. 4.1.6.2 Objectives The Technology Planning process is performed to document the selection of system-required technologies and to schedule their maturation and incorporation into the system of interest. Technology planning includes identification of partnering opportunities with other agencies, centers, industry, and academia. 4.1.6.3 Responsibilities2 The Lead Systems Engineer provides primary technical assessment on needs and requirements for products, materials, and services. The Lead Systems Engineer is responsible for performing the planning steps below, which outline how technical assessment for the technology planning mechanisms is performed. The Project Manager is responsible for formulating technology planning strategy(ies) for the project. The Project Manager also makes the final decisions concerning project technology planning and approves any corrective actions related to the performance of the technology insertion into the system of interest.

The Stakeholder Representative interfaces with the Project Manager and the Lead Systems Engineer for soliciting information in support of the technology planning function. The Stakeholder Representative also provides advice on assessing technology maturation and insertion. 4.1.6.4 Life cycle7 Technology planning begins in the Pre-Phase A, Advanced Studies, where conceptual technology development requirements are documented to help to answer the general question of mission feasibility. Subsequently, during Phase A, Preliminary Analysis, technology development requirements and plans are documented that reflect increased understanding gained from that phases iterations between requirements and concepts to develop optimal system requirements and top-level architecture. Finally, during Phase B, Definition, technology development plans are updated to accommodate any changes indicated by the iterations between requirements and concepts to establish the optimal design-to baseline. 4.1.6.5 Inputs Typical inputs should include, but not be limited to: Needs, goals, objectives Requirements Programmatic guidelines and constraints] System specifications System concept and architecture Cost/effectiveness analyses Environmental assessment Feasibility assessment Specialty engineering studies Life cycle cost estimates Trade and analysis results Analysis model descriptions SE tool descriptions Program and project management plans (PMPs) Engineering master plan and master schedule Operations concepts Evaluation criteria Reference missions Technical performance measures 4.1.6.6 Steps1,3,6 Three main steps to this process are to review and understand requirements and concepts, to establish the key technologies needed by the system of interest, and to plan for their maturation and insertion. These major steps and products of the Technology Planning process, which are discussed further below, are illustrated in Figure 4.1-6. Requirements and concepts should be reviewed. Examine current life cycle phase inputs.

4-23

Project Management: SE & Project Control Processes & Requirements

Inputs for Current Life Cycle Phase

Requirements & Concepts Developing in Current Life Cycle Phase

START Review Requirements and Concepts

Key Technology Definitions, TRLs, and Gaps

Is New Technology Required?

Yes

Established Required Key Technologies TRL Advancement Plans Plan for Technology Maturation & Insertion Low -TRL Technology Insertion Criteria Maturation & Insertion Schedule No Document That No New Technologies Are Needed

Technology Alternative Employment Criteria

Technology Development Requirements

Technology Development Plan

STOP

KEY

Step/Activity

Information/Product

Information/Output Flows

Connector

Figure 4.1-6. Technology planning process diagram. Keep abreast of concurrently developing requirements. Required key technologies shall be established. Identify and document key technologies required by the system of interest using tools and resources such as the NASA Technology Portal to identify potential technologies; e.g., http://nasatechnology.nasa.gov/index.cfm. Identify key partnerships. Identify and document the TRL of each required key technology. Identify where technology gaps exist, in cluding gaps significant enough to question the viability for a concept to be realized. Evaluate those technologies that can incrementally improve project capabilities, decrease risk, improve safety, or reduce cost. Identify technologies that have distribution restrictions on the S/W, H/W, or data. If no new technology are required, document this and advise termination of process. Technology maturation and insertion shall be planned for required low-TRL technologies. Determine and document activities for advancing required technologies from lower TRLs to levels required for incorporation into the system of interest. Generate technology development plans to remove identified technology gaps. Explore innovative avenues to expand participation and infuse the latest technological and commercial capabilities into the project. Ensure that plans for technological or commercial cooperation include a full description of the opportunities for partnering, the potential partners, the need to protect intellectual property, the likelihood of the partnership achieving fruition, the expected contribution, and the confidence that the partnership will remain in force. Determine and document the criteria for assessing when required low-TRL technologies that must be matured can be inserted into the system of interest. Schedule and document anticipated technology maturation and insertion for each identified required low-TRL technology, and protect against technology non-maturation.

4-24

Project Management Processes and Requirements

Describe calendar-based milestones for the insertion of each required technology. Document alternatives to incorporating the identified low-TRL technologies into the system of interest, and establish decision gates and decision criteria for proceeding with the alternatives. As indicated by the life cycle phase, document technology development requirements and/or the technology development plan. Identify potential technologies to disclose. 4.1.6.7 Outputs For the Technology Planning phase: Pre-Phase A, Advanced Studies, is a set of conceptual technology development requirements. Phase A, Preliminary Analysis, is a set of technology development requirements and plans. Phase B, Definition, is any updates to the technology development plans. 4.1.6.8 Exit criteria For the Technology Planning phase: Pre-Phase A, Advanced Studies, conceptual technology development requirements shall be documented and accepted by the concept review. Phase A, Preliminary Analysis, documented technology requirements and plans shall be accepted by the definition review. Phase B, Definit ion, any updates to the technology development plans shall be documented and accepted by the definition review. 4.1.6.9 Measurement The table at the bottom of the page provides example base and derived measures that can be used in conjunction with executing the Technology Planning process. See discussion of Measurement on page 4-1. 4.1.6.10 Methods and techniques4 The following technical and management methods the key tools of which have been and will remain sound managerial and engineering judgment and decisiveness may be useful in technology planning: Base Measures Total # of Technologies Assessed

Concurrent engineering Brainstorming Delphi technique Nominal group technique Cause and effect diagram (fishbone) Flowchart analysis TRL classification

4.1.6.11 Software tools The Technology Planning process should include a review of technology databases and portals, and interviews with experienced technology developers whose expert judgment can shed light on potential technology challenges for the system of interest. Thus, standard office automation tools that support identification and direct, condensed communication of process inputs to the study team should generally be used; e.g., word processor, spreadsheet, technology databases/portals, data mining tools such as an expert locator system, and presentation slide software for PCs. 4.1.6.12 References The following documents and Web site, which were used to prepare this section, offer additional insights into the environment of the Technology Planning process: 1 NPR 71xx.x (document number not yet assigned), NASA Systems Engineering Pro cesses and Requirements . 2 NPR 7120.5B, NASA Program and Project Management Processes and Requirements, 2002.
3

INCOSE Systems Engineering Handbook , Version 2.0, 2000. 4 RP 1358, System Engineering Toolbox for Design-Oriented Engineers, 1994. 5 Mankins JC. Technology Readiness Levels: A White Paper. Advanced Concepts Office, Office of Space Access and Technology, NASA, 1995. 6 Next -Generation Space Telescope (NGST) Web site explanation of TRLs, http://www.ngst.nasa.gov/public/unconfigured/doc _0852/rev_01/NGST_TRLs.html . 7 SP 6105, NASA Systems Engineering Handbook , 1995. Derived Measures Total # of Technologies Assessed Planned vs. Actuals Technology Assessment Rate Charts

Technology Planning Effort (FTEs)

Technology Planning Productivity Technology Planning Effort Planned vs. Actuals Technology Planning Effort as % Total Engineering Effort

4-25

Project Management: SE & Project Control Processes & Requirements

4.1.7 Design14 The Design process is performed to provide a methodical and iterative effort that transforms system of interest requirements into qualitative and quantitative solutions. this process involves taking identified products from previous phases and establishing a system definition sufficient for moving into attainment. Requirements are iterated and decomposed into progressively lower levels using trade studies to optimize the selected system of interest. The selected solution is validated to meet needs, goals, objectives, costs, and schedules. This solution is evaluated for manufacturability, operations, safety, reliability, maintainability, parts/materials adequacy, requirements compliance, and operations concept consistency. All interfaces are identified and documented. Approaches to verify and validate all requirements and specifications are documented. The process completes the design of the system of interest by defining the set of identified configuration items and defining their interfaces, integrated as a system. The Design process is applied to all levels of the system of interest to: Establish specified requirements and detailed drawings or documents for system of interest products. Define initial and final specifications, including interface specifications, for subsystems of each system of interest product that requires further development. Identify enabling product requirements to facilitate meeting functional requirements during attainment, production, test, deployment, operations, training, support, and disposal. Designs provide the appropriate content not only for attainment but also for other phases of the product life cycle, such as modification, re-procurement, maintenance, sustainment, and installation. Design documentation provides a reference to support mutual understanding of the design by relevant stakeholders and supports future changes to the design both during attainment and subsequent phases of the life cycle. A complete design description is documented in a technical data package that consists of a full range of features and parameters including form, fit, function, interface, manufacturing process characteristics, and other parameters. Established organizational or project design standards (e.g., checklists, templates, object frameworks) form the basis by which to achieve a high degree of definition and completeness in design documentation. Design begins in the earliest phases of the project with development or preliminary system concepts and specifications and continues throughout system definition and design. Predominate activities, however, occur in the preliminary design and detailed design phases of the project life cycle. Specifically, preliminary design:

Establishes a design-to solution that fully meets project needs, goals, and objectives. Completes test and verification plans. Establishes design-dependent requirements and interfaces. Completes implementation level of design. Detail design: Establishes complete, validated build-to detailed design. Completes all design specialty audits. Establishes manufacturing processes and controls. Finalizes and integrates interfaces. 4.1.7.1 Function1 In the Design process: Requirements for the system of interest shall be further decomposed and allocated to elements of the system(s) of interest. Proposed solutions that address the system of interest requirements shall be identified. Trade studies of the proposed solutions shall be performed to provide an objective foundation for selection of the solution(s). The selected solution shall be documented. 4.1.7.2 Objective 1 The primary objective of the Design process is to document that identified needs, goals, and objectives of the customer and other stakeholders can be achieved by a baselined system of interest solution, and the system of interest can be attained, operated, and de-commissioned within the technical, budget, and schedule scope of the program/project plans. 4.1.7.3 Responsibilities3,4 In the Design process, the Lead Systems Engineer is responsible for ensuring the relationships of the system of interest are being designed to its environment and subsystems rather than with the internal details of how the system of interest will accomplish its objectives. The Lead Systems Engineers viewpoint is broad rather than deep, encompassing system functionality from end to end and temporally fro m conception to disposition. The Design Engineering Disciplines (e.g., mechanical, electrical, S/W) have the primary responsibility for actual system of interest design. Specialty Engineering Disciplines and Support Functions (e.g., quality engineering, quality assurance (QA), S/W assurance, CM, data management) contribute to the design when and as required. For example, engineering specialty analysis results are integrated into the design, and the manufacturing process and controls are defined and validated.

4-26

Project Management Processes and Requirements

4.1.7.4 Life cycle Some early design activities take place in Phase A in support of synthesizing and down selecting proposed system concept(s) and drafting preliminary system specifications. Some design activities also take place early in Phase B in support of definition reviews such as development of the systems evaluation criteria, development and refinement of the prime items concepts, and performing trades for selecting the optimal solution. The preliminary Design process begins following successful System Definition Reviews (SDRs) during Phase B and ends in a series of Preliminary Design Reviews (PDRs) containing the system of interest-level PDR as well as PDRs for lower-level components, as appropriate. Detailed design execution is conducted during Phase C, culminating in a series of Critical Design Reviews (CDRs) for the system of interest and all of its components . 4.1.7.5 Inputs1,3 Available and necessary inputs required for the Design process range from analyses, assessments, and studies to plans and requirements. These inputs will occur during various stages of development. Some will be conceptual or preliminary documents and only partially complete, while others will be fully complete and approved. Some of these inputs are further refined or completed during the Design process and are listed as outputs. The following provides a listing of typical inputs that should be considered during design: Results from evaluations, analyses, and studies of cost/effectiveness, risks, life cycle cost, logis tics, support, producibility, reliability, human factors, maintainability, safety/hazards, specialty engineering, environmental, feasibility, trades, and failures modes and effects Concepts, including system, functional, operations, integrated logistics support, and integration and assembly All requirements, including top-level project, science, system/segment, allocated, disposal, flow down, refined, interface, lower level, performance, technology, development, verification, and validation Plans in various stages of development, including PMPs, SE management plans, CM plans, integration and assembly plans, integrated logistics support plans, QA plans, risk management plans, system safety plans, verification and validation plans, etc. Other inputs include: Needs, goals, and objectives Assumptions, guidelines, and constraints Performance measures, including budgets and margins Design disclosure Product breakdown structure

System specifications Applicable standards Verification requirements matrix ICDs Design-to specifications Design selection with rationale Development test results Engineering items Hardware/software list Integrated schematics Material and processes data

4.1.7.6 Steps4 Figure 4.1-7 illustrates the major steps and products of the Design process. This process begins with outputs from decomposition and ends with a fully characterized design solution. More detailed activities associated with these steps are provided below. NOTE: Reference NPR 8705.2 for space flight systems that carry humans or whose function or malfunction may pose a hazard to NASA space systems that carry humans. Detailed Alternative Solutions and Selection Criteria Shall Be Developed Various alternative design solutions and association evaluation criteria should be established from which an optimal design solution can be selected. These alternative solutions are refined and evaluated until a preferred design solution is selected. Develop Evaluation Criteria Evaluation criteria should be established that address design issues for the life of the product. Synthesize and Down Select Optimal Solution Establish project and system specifications from which potential solutions can be selected. Select Optimal Solution Select and document product/components of the system of interest that best satisfies evaluation criteria. Preliminary Design Shall Be Established Establish system of interest capabilities and architecture, including partitions, component identifications, system states and modes, major intercomponent interfaces, and external interfaces. Analyze and Refine Requirements Detail and update specifications, flow down requirements to the component level, and establish disposal and interface requirements. Use the Requirements Development process (Section 4.1.1) as required. Perform Design Analyses Capture design analyses and trade study results in reports as required. The Systems Analysis process (Section 4.1.13) is applied here as necessary.

4-27

Project Management: SE & Project Control Processes & Requirements

System Definition

Needs, Goals, and Objectives

Develop Evaluation Criteria Perform Design Analyses Perform Engineering Development Tests Define Interfaces

Synthesize and Down Select

Select Optimal Solution

Preliminary Design To Spec

A Analyze and Refine Requirements

Preliminary Design

Perform Preliminary Design

Evaluate, Verify, and Validate Preliminary Design

Design to Spec

Complete Plans and Documentation for Qualification Items Define and Control Detailed Interfaces Perform Engineering Tests Product Fabricate/Test Qualification Items

Detailed Design

Perform Detailed Design

Evaluate, Verify, and Validate Detailed Design

Complete Detail Design and Production Plans

Build to Spec

KEY

Step/Activity

Information/Output Flows B

Connector

Figure 4.1-7. Design process diagram. Perform Engineering Development Tests Identify engineering items and capture development test results. Engineering tests are conducted on test units created to resemble actual components to establish confidence that the design will function in the expected environment. Define Interfaces Update the ICD and create integration schematics. Perform Preliminary Design Prepare the design disclosure, create an engineering parts list, and generate a hardware/software list. Complete the design-to baseline. Complete Plans and Documentation for Qualification Items. Evaluate, Verify, and Validate Preliminary Design Check preliminary design for cost effectiveness and life cycle cost, and other specialty engineering considerations. Use the Verification and Validation processes (Sections 4.1.14 and 4.1.15) as necessary. Detailed Design of the System of Interest Shall Be Developed The system of interest structure and capabilities are defined in sufficient detail for conducting attainment, integration, verification, and validation. Perform Detailed Design Update design disclosure, produce material and processes data, and develop integration and assembly plans. Complete build-to baseline. Design and Control Detailed Interfaces Update interface control documentation. Perform Engineering Tests Capture/update development test results and finalize engineering items. Test units that closely resemble actual components are evaluated to ensure the design will operate as expected in the target environment. Fabricate/Test Qualification Items Produce qualification items and capture qualification test results. Evaluate, Verify, and Validate Detailed Design Check final design to assure that it meets cost-effectiveness goals, life cycle cost, and other specialty engineering considerations. Use the Verification and Validation processes (Sections 4.1.14 and 4.1.15) as necessary. Complete Detailed Design and Production Plans Create build-to specifications and verification requirements and specifications.

4.1.7.7 Outputs In general, the output of the Design process is a technical data package that evolves over the project life cycle to ultimately include all remaining lowerlevel requirements and designs and build-to speci-

4-28

Project Management Processes and Requirements

fications at all levels. Depending on the stage of the design, this technical data package includes: Results from analysis and refinement of requirements Evaluate of cost/effectiveness, environmental, failure modes and effect analysis (FMEA), logistics support, reliability, maintainability, safety and hazards, and life cycle costs Revisions to plans such as the program management plans, SE management plans, integrated logistics support plans, S/W QA plans, verification and validation plans, risk management plans, etc. System specification Evaluation criteria Operations concept System concept and architecture Design disclosures Product breakdown structure Technology development requirements ICDs Integration and assembly concept and design Integrated logistics support concept Documented selection, including rationale Design analysis reports Trade analysis and results Electronic parts list Hardware/software list Integrated schematics Instrumentation program and command list Material and process data Integration and assembly design Development test results Engineering items Verification requirements and specifications 4.1.7.8 Exit criteria1,4 Although design may occur throughout the remainder of the system of interest life cycle, most design activities are considered complete when CDR requirements are satisfied. Therefore, to transition these design components from the Design process to the Attainment process (Section 4.1.8), the following criteria must be satisfied: A design solution (i.e., a build-to specification) shall be baselined and documented that satisfies system of interest requirements and meets stakeholder needs. Documented readiness to attain, verify, and validate the system of interest shall be established. Customer signature approval of updated in ternal task agreements (ITAs) or statements of work (SOWs) with firm cost to complete shall be acquired. Safety and Mission Assurance Review Team (SMART) approval of the safety data package shall be provided.

Successful completion of subsystem design reviews i.e., PDR, CDR shall be documented. Successful completion of system of interest design reviews i.e., PDR, CDR shall be documented. 4.1.7.9 Measurement The table at the top of the following page provides example base and derived measures that can be used in conjunction with executing the Design process. See discussion of Measurement on page 4-1. 4.1.7.10 Methods and techniques3 Methods and techniques used in the Design process depend, to some degree, on the nature of the system of interest. However, typical methods and techniques include: Brainstorming Literature searches Trade studies Analysis of risks, hazards, failure modes and effects, reliability, cause-consequence, etc. Dimensioning and tolerancing Surveys Vendor inquiries N2 charts System schematics Interface diagrams Tables and drawings of detailed interface data QFD Layout sketches Decision trees Functional flow diagrams 4.1.7.11 Software tools Designing a system of interest involves the potential use of numerous tools of various sizes. These range from tools intended to help to express the physical characteristics of the system of interest to tools that are used to analyze associated design parameters. There are concept development tools, system safety and reliability analysis tools, design-related analytical tools, graphical data development and interpretation tools, statistical tools, QA tools, and trend analysis tools. Other tools include computer-aided design tools; drafting tools for preparation of drawings and schematics; and tools that provide archival, CM, and review of design documentation (e.g., design and data management system (DDMS)). For a current and extensive listing of commercially available design tools, see the table provided by INCOSE at: http://www.incose.org/tools/eia632tax/eia632top.html. This table lists tools that support the solution definition requirements of EIA-632.

4-29

Project Management: SE & Project Control Processes & Requirements

Base Measures # of Design Elements (e.g., # of subsystems, # of H/W configuration items (CIs), # of S/W CIs) Number of Requirements Not Met By Design Solution # of Allocated Requirements (to subsystems, H/W, S/W)

Derived Measures Planned vs. Actual Design Elements Planned vs. Actual Requirements Met by Design Solution % Allocated Requirements to Subsystems, H/W CIs, S/W CIs % Requirements Not Allocated

# of Requirements Verified by Analyses # of TBDs in Design Solution # of Unresolved Interface Issues Elements in Design Solution Defined Design Milestone Dates

Planned vs. Actual Requirements Verified Planned vs. Actual TBDs Planned vs. Actual Unresolved Interface Issues Planned vs. Actual Elements Defined Milestone Planned vs. Actuals Design % Complete Planned vs. Actuals

Design Effort (FTEs)

Design Productivity Design Effort Planned vs. Actuals Design Rate Charts Design Effort as % Total Engineering Effort

4.1.7.12 References The following documents, which were used to prepare this section, offer additional insights into the Design process:
1

NPR 71xx.x (document number not yet assigned), NASA Systems Engineering Processes and Requirements.
2

EIA-632, Processes for Engineering a System, ANSI/EIA -632-1998, 1999. 3 INCOSE Systems Engineering Handbook , Version 2.0, 2000. 4 SP 6105, NASA Systems Engineering Handbook , 1995.
5

CMMI-SE/SW/IPPD/SS V1.1, Capability Maturing Model Integration (CMMI) for Systems Engineering, Software Engineering, Integrated Product and Process Development, and Supplier Sourcing, 2002.

4-30

Project Management Processes and Requirements

4.1.8 Attainment1,2,3 The Attainment process is performed to transform each system of interest solution into an actual product. Attainment is accomplished through buying, building, supplying, or coding the product as determined by the trade studies. This process is executed to procure, acquire, and/or manufacture end items associated with each level of the system of interest. Resulting system of interest end items may then be assembled, integrated into other systems of interest, verified, and validated. See the Integration, Verification, and Validation processes (Sections 4.1.9, 4.1.14, and 4.1.15) for further details regarding the disposition of attained end items. The result of successfully completing this process is a fully integratable system of interest that satisfies its specified requirements. System of interest integration preparation during attainment ensures that both internal and external interfaces function according to requirements; that designed states, modes, dynamic allocations, or other operational switching functions perform as required; and that any designed overload conditions, reduced operational levels, or designed-in degraded mode of operations are included. Example characteristics of the Attainment process are: S/W is coded, data are documented, services are performed and documented, electrical and mechanical parts are fabricated, product-unique manufacturing processes are put into operation, processes are documented, and facilities are constructed. 4.1.8.1 Function1 In the Attainment process: The documented solution shall be made available and communicated among individuals involved with transforming the solution into a product. Procedures and work instructions and supporting enabling systems shall be in place for transforming the solution into a product. The solution shall be transformed into a product. 4.1.8.2 Objective 1 The objective of the Attainment process is to build subsystems of interest and prepare these subsystems for progressive integration by creating the overarching system of interest while developing confidence that the results will meet system of interest requirements. 4.1.8.3 Responsibilities4 In the Attainment process, the Lead Systems Engineer is primarily responsible for requirements baseline maintenance and requirements feedback to design. The Lead Systems Engineer ensures and manages the technical integrity of the requirements baseline, continually updating it as various changes are imposed on it during the Attainment process and communicat-

ing changes to relevant stakeholders. The Lead Systems Engineer is also responsible for monitoring activities during the Attainment process to identify the potential effects of any issues that may surface in other parts of the system of interest or its external interfaces. Finally, the Lead Systems Engineer updates technical plans and schedules, as necessary, to reflect the technical resolution of these issues. Actual solution attainment is the responsibility of the Subsystem Lead Engineers. By working closely with the Lead Systems Engineer, the Subsystem Lead Engineers ensure subsystem solutions are transformed into appropriate systems of interest solutions (i.e., fabricated items, S/W code, acquired components) that are ready for further integration and test. 4.1.8.4 Life cycle1 Attainment begins at the point where the documented solution (i.e., the build-to specification) for the system of interest is considered fixed and ends with the successful completion of the system of interest acceptance. This corresponds to the end of Phase C, Design, and the initial stages of Phase D, Development. 4.1.8.5 Inputs1,5 The primary inputs to attainment are: Baselined build-to specifications that satisfy requirements and meet stakeholder needs. Documented readiness to produce, verify, and validate the system of interest. Inputs into the Attainment process will take place during various stages of completion. Some will be conceptual or preliminary documents and only partially complete, while others will be fully complete and approved. Following is a listing of typical inputs: System specification Technology development requirements Documented selection with rationale Factors such as cost/effectiveness, environmental, FMEA, logistics support, producibility, R&M, safety/hazard analysis, and life cycle costs . Acceptance criteria Material and process data Electronics parts list Hardware/software list Users manual Plans such as the PMP, QA plan, acceptance plan, development plan, safety plan, reliability plan, integration and assembly plans, verification and validation plans, qualification item plan, etc. 4.1.8.6 Steps5 The following diagram (FIG. 4.1-8) illustrates the major steps and products of the Attainment process. This process begins with outputs from the Design process (Section 4.1.7) and ends with a fully tested

4-31

Project Management: SE & Project Control Processes & Requirements

system of interest. More detailed activities associated with these steps are provided below.
Receive Product(s) Communicate Solution Build Product(s) Reuse Product(s) Product(s)

Build-to Spec(s) Attain Products

Verify and Validate Product(s) Against Requirements

Assemble Product(s) Provide Enabling Systems

Assembled Product(s)

Verify Assemblies Prepare Maintenance Manuals

Validate Assemblies Train System Operators and Maintainers

Complete Product(s)

Support Product Attainment

Develop Procedures

Prepare Users Manual

Document Lessons Learned

Finalize Text Procedures

KEY

Step/Activity

Product

Information/Output Flows

Figure 4.1-8. Attainment process diagram. The basic steps in the Attainment process are: Products Shall Be Acquired, Fabricated, or Coded Communication Solution The documented solution is made available and communicated among those individuals involved in transforming the solution into a product. Receive, build, or reuse the end item(s); i.e., the lowest-level items in the system of interest architecture. Fabrication is conducted in accordance with the build-to design and manufacturing/production plans. Product(s) Shall Be Verified and Validated Against Requirements (Verification and Validation processes, Sections 4.1.14 and 4.1.15) Ensure the product(s) satisfy requirements. Ensure the item(s) satisfy the intent of the build-to solution. If more than one end item is required to create the system of interest: Product(s) shall be assembled. Assemble in accordance with the buildto design and assembly plans. Assemblies shall be verified (Verification process, Section 4.1.14). Verify any assemblies in accordance with the verification plan. Assemblies shall be validated (Validation process, Section 4.1.15). Validate any assemblies in accordance with the validation plan. Other activities occur during the Attainment process that facilitate either end item acquisition or fabrication activities. These activities include: Develop Procedures Procedures are required to fabricate end items. These procedures provide the specific instructions necessary at each stage of fabrication to create the item. Provide Enabling Systems Define, plan, and establish any enabling systems needed to support fabrication of the end items. Examples of enabling systems include qualification unit and ground support equipment. Prepare Users Manual As the end item is acquired or fabricated, initiate preparation of the users manual. Prepare Maintenance Manuals Begin maintenance manual development during the Attainment process. Train System Operators and Maintainers Initiate training for system operators and maintainers. Document Lessons Learned Lessons learned provide information for Attainment process refinement. Finalize Test Procedures Finalize test procedures for acceptance testing. 4.1.8.7 Outputs2,5 Primary outputs from the Attainment process, which are completed, validated, and verified products, are:

4-32

Project Management Processes and Requirements

Acquired H/W, S/W, firmware end products or composites of system of interest products built or coded to their specified requirements, drawings, or descriptive documents; or other needed physical entities (e.g., trained personnel, certified facilities, special techniques, manuals). Lessons learned. The following provides a listing of typical outputs: Evaluation, verification, and validation of design factors such as cost/effectiveness, environmental, producibility, FMEA, logistics support, reliability, maintainability, safety/hazard analysis, and life cycle costs. End items Support items Spares QA results As-built documentation Technical manuals and data Users manual Integrated system Support equipment Operations procedures Delivered/installed system Final documentation Trained personnel Waivers Phase III safety data package Final test procedures 4.1.8.8 Exit criteria The following shall be accomplished to satisfy exit from this process: Base Measures Defects in Design (by phase) Milestones Dates (reviews, change control boards, baseline document publication) Code Effort (FTEs)

A system of interest is developed or acquired. Verification and validation of the system of interest is accomplished and documented. 4.1.8.9 Measurement The table at the bottom of the page provides example base and derived measures that can be used in conjunction with the Attainment process. See discussion of Measurement on page 4-1. 4.1.8.10 Methods and techniques4 Methods and techniques include: CM of requirements baseline Functional analysis tool N2 charts Functional flow diagrams 4.1.8.11 Software tools Many S/W tools are required to attain system of interest end items. The nature of these tools depends on whether the end item is a fabricated item, a S/W item, or an acquired item. Most of the tools are also outside the domain of SE i.e., they are unique tools associated with fabrication, S/W development, or acquisition and, as such, are not referenced in this document. The SE tools used in this process are tools used for requirements management and, if necessary, functional analysis. For a list of potential tools, see the table provided by INCOSE at: http://www.incose.org/tools/eia632tax/eia632top.html.

Derived Measures Design Defects Projected vs. Actuals Milestones Planned vs. Actuals Code Productivity Code Effort Planned vs. Actual Code Rate Charts Code Effort as % Total Engineering Effort

Code Size (# lines of code)

Code Size Planned vs. Actual Code % Complete Planned vs. Actuals

Defects in S/W Code (by phase)

Code Defects Projected vs. Actuals

4-33

Project Management: SE & Project Control Processes & Requirements

4.1.8.12 References The following documents, which were used to prepare this section, offer additional insights into the Attainment process: 1 NPR 71xx.x (document number not yet assigned), NASA Systems Engineering Processes and Requirements . 2 EIA-632, Processes for Engineering a System, ANSI/EIA -632-1998, 1999.
3

CMMI-SE/SW/IPPD/SS V1.1, Capability Maturity Model Integration (CMMI) for Systems Engineering, Software Engineering, Integrated Product and Process Development, and Supplier Sourcing, 2002. 4 INCOSE Systems Engineering Handbook , Version 2.0, 2000. 5 SP 6105, NASA Systems Engineering Handbook , 1995.

4-34

Project Management Processes and Requirements

4.1.9 Integration1,2 The Integration process is performed to interconnect distinct and separable elements to form a comp lete final system for verification. An integral part of ensuring physical system integration success is comprehensive integration planning; i.e., continually checking that all of the pieces remain compatible and that they will support the intended product. In this activity, each system element is analyzed to ensure compatibility with other elements within the system of interest. Compatibility with other (external) enabling systems is also verified. This assessment ensures that each system element can be adequately accommodated with respect to the basic constraints imposed by the system of interest and the final integrated system. Another key aspect of the integration process is management of internal and external interfaces of the system of interest. Physical integration is more than just a one-time assembly of elements at the conclusion of design and attainment. Integration is conducted incrementally, using an iterative process of assembling elements, evaluating these elements, and assembling more elements. This process steadily progresses through increasingly more realistic incremental functionality until the final system is achieved. There is a higher probability that a system of interest that has been integrated in this manner will pass verification and validation. For some systems, the last integration phase will occur when the system is deployed at its intended operational site. Execution of the physical interconnection system integration activities follows the SE Design and Attainment processes (Sections 4.1.7 and 4.1.8) and results in a fully integrated system that will be verified by the SE Verification process (Section 4.1.14). 4.1.9.1 Function1 In the Integration process: Planning for the needs (i.e., H/W, S/W, human factors, facility, personnel, etc.) to integrate individual elements into the system of interest shall be performed. Procedures and work instructions and supporting enabling systems shall be put into place for integrating the products. The configuration of products being integrated, as well as the integrated products as being representative of the configuration in which the system of interest will be used, shall be validated. Testing of the interface(s) shall be performed. Integration planning shall be performed to ensure success in the physical and operational integration of the system of interest.

4.1.9.2 Objective 2,3 The primary objective of this process is to manage activities to achieve complete system integration through the progressive assembly of elements according to a defined integration sequence and procedures. The Integration process integrates end products, enabling systems, and external interfacing systems as appropriate to the level of the system of interest and as required for verification. 4.1.9.3 Responsibilities4 The Lead Systems Engineer is responsible for overall management of the Integration process, including the integration sequence. In this role, the Lead Systems Engineer ensures integration planning activities are performed, Test Readiness Reviews (TRRs) are conducted, and only verified CIs are integrated into the next -higher assembly for further verification. The Verification Lead supports the Lead Systems Engineer to ensure that development and documentation of system-level integration and test plans are accomp lished and that the required integration facilities have been verified to provide the necessary conditions, have been scheduled, and are available. 4.1.9.4 Life cycle Integration is an activity that exists at all points in the project life cycle. The Vee chart, which appears as a foldout as page 35, represents systems definition and development in three dimensions. The horizontal axis of the chart is notional time. The vertical axis represents levels of system/element decomposition. The further down on the chart, the more detailed the system information and, hence, the system depth. Implicit in the chart is an axis perpendicular to the paper that represents the increasing number of subsystems identified and being decomposed in parallel (system breadth). On the upward Integration and Verification leg (i.e., the right side of the Vee), integration activities consist of executing the integration and verification plans developed on the accompanying downward leg level. The hard work for integration takes place on the downward leg. Integration in the downward leg is applied at each baseline level to ensure compatibility is maintained during system definition and design. While descending down this leg, the process remains the same except for the level of detail analyzed. The horizontal lines going across the Vee chart indicate the baseline levels and reflect the connection between the integration plan and the assembly of elements into subsystems on the upward leg of the Vee. Simultaneously, analysis is taking pace to assure integration on the perpendicular axis. The 3-way analysis approach produces detailed element-to-element integration and

4-35

Project Management: SE & Project Control Processes & Requirements

optimizes the system with respect to overall effectiveness (rather than sub-optimizing the system by optimizing each element for its maximum performance). Integration in the downward leg consists of identifying all interfaces (physical, electrical, data/information, and operational) and documenting the corresponding interface requirements in ICDs. As for any requirement, interface requirements in the ICDs must have verification plans written as part of the baseline. The context for the verification plans for the interface re quirements in the ICDs is that baseline levels operations scenarios/concepts/plans/procedures. Finally, integration plans must be developed at that baseline level to describe how the elements will be assembled or integrated to be ready for test and verification. Commensurate ICDs, verification plans, operational concepts, and integration plans, which are all written at the same baseline level on the downward leg of the Vee, control the execution of integration and verification at the same baseline level on the upward leg of the Vee. 4.1.9.5 Inputs2,3,5 Typical inputs to this process include, but are not limited to: Operations concept ICDs Development schedule and status System requirements Design documentation Validated products to be integrated Product breakdown structure System hierarchy System architecture (functional, physical)

4.1.9.6 Steps2,3,4,6 The diagram at the bottom of the page (FIG. 4.1-9) illustrates the major steps and products of the Integration process. The Lead Systems Engineer is responsible for ensuring all major steps in the Integration process are performed. Adherence to the major steps of this process directs the project toward meeting its integration requirements. For each major process step, additional guidance is provided as to the expected typical subprocess activities and products. Integration Planning Steps An integration plan and process shall be established. Develop the overall project plan and process to achieve system integration and include this as part of the Systems Engineering Management Plan (SEMP). Define the project integration responsibilities, especially as they relate to the project acquisition strategy (Section 4.3.1). Provide the project manager with cost and schedule inputs related to integration engineering life cycle activities in support of the project planning effo rt. Ensure a conceptual version of the integration plan is available at the SDR, a preliminary version is available at the PDR, and a final/approved version is available at both the CDR and the Production Readiness Review (ProRR).

Integration Planning

Establish an Integration Plan and Process

Determine Integration Sequence

Establish Integration Environment

Establish Integration Procedures and Criteria

Interface Compatibility

Continue Integration Plan

Review and Manage Interface Descriptions

System Integration

Confirm Product Readiness for Integration

Assemble Products

Evaluate Assembled Products

Fully Integrated System

KEY

Step/Activity

Product

Information/Output Flows

Figure 4.1-9. Integration process diagram.

4-36

Project Management Processes and Requirements

4-37

Project Management: SE & Project Control Processes & Requirements

4-38

Project Management Processes and Requirements

An integration sequence shall be determined. Identify the products to be integrated. Identify the product integration verifications to be performed using the definition of the interfaces between products. Identify alternative product integration sequences. Select the best integration sequence. Periodically review the product integration sequence and revise, as needed, to ensure that variations in production and delivery schedules have not adversely impacted the sequence or compromised the factors on which earlier decisions were based. Record the rationale for decisions made and deferred. An integration environment shall be established. Identify requirements for product integration environment. Identify verification criteria and procedures for product integration environment. Decide whether to make or buy needed product integration environment. Develop integration environment if a suitable environment cannot be acquired. Maintain product integration environment throughout the project. Dispose of those portions of the environment that are no longer useful. Integration procedures and criteria shall be established. Establish and maintain integration procedures for the products. Establish and maintain criteria for product integration and evaluation. Establish and maintain criteria for validation and delivery of integrated product. Continually Perform Integration Planning Horizontal integration shall be performed to: Monitor and integrate system definition activities and results at the lower levels of the hierarchy to ensure compatibility. Monitor and integrate the preliminary design activities and results at lower levels of the hierarchy to ensure overall system integrity. This monitoring and integration includes tracking interfaces, TPMs, allocations, etc. Track parameters, budgets, and interfaces as final design progresses to ensure that the design will fit together and work, and to facilitate later physical integration of the system.

Monitor and address lower-level hierarchy effects and issues to the system level. Interface Compatibility Steps Review and management of interface descriptions shall be performed. Review interface data for completeness and ensure complete coverage of all interfaces. Ensure that products and interfaces are marked to ensure easy and correct connection to the joining product. Periodically review adequacy of interface descriptions. Ensure compatibility of the interfaces throughout the life of the product. Resolve conflict, noncompliance, and change issues. Maintain repository for interface data that are accessible to project participants. System Integration Steps Product readiness for integration shall be confirmed. Perform hardware/software integration (HSI) prior to the PDR to establish confidence that the H/W and S/W design concepts are adequate to meet functional interfaces. Perform HSI prior to CDR on engineering units to establish confidence that the H/W and S/W detailed designs meet requirements. Track status of all products as soon as they become available for integration. Ensure products are delivered to the product integration environment in accordance with the product integration sequence and available procedures. Confirm receipt of each properly identified product. Ensure each received product meets its description. Check configuration status against the expected configuration. Perform pre -check (e.g., by performing a visual inspection and using basic measures) of all physical interfaces before connecting products. Assemble Products Integration of system elements shall proceed in accordance with the integration plan. Ensure readiness of the product integration plan. Ensure assembly sequence is properly performed. Revise product integration sequence and available procedures as appropriate.

4-39

Project Management: SE & Project Control Processes & Requirements

Recommend verification and validation plans/procedures updates based on integration outcomes. Assembled product components shall be evaluated. Conduct a TRR of assembled products. Record the TRR results. 4.1.9.7 Outputs4 Primary outputs from this process are: Integration plans System integration process (to include in SEMP) Integration procedures and criteria Integration sequence Integration environment Integration environment requirements
Base Measures
Requirements Management Measures Total # of Integration Environment Requirements (e.g., # of shalls) # of Integration Environment Requirements Added, Changed, Deleted Requirements Development Measures Total # of Shalls for Integration Environment Integration Environment Requirements Effort (FTEs)

TRR results Verification and validation plan/procedure updates Fully integrated system 4.1.9.8 Exit criteria Exit criteria include: Attainment of a fully integrated system of interest. Successful TRR in preparation for verification and acceptance of the system. 4.1.9.9 Measurement The following table provides example base and derived measures that can be used in conjunction with executing the Integration process. See discussion of Measurement on page 4-1.
Derived Measures
Integration Requirements Managed Planned vs. Actuals Integration Requirements Volatility = % Added, Changed, Deleted

Total # of Integration Requirements Planned vs. Actuals Integration Requirements Definition Productivity Integration Requirements Definition Effort Planned vs. Actuals Integration Requirements Definition Rate Charts Integration Requirements Definition Effort as % Total Engineering Effort Integration Size Planned vs. Actual % Integration Completed Planned vs. Actuals Integration Productivity Integration Effort Planned vs. Actuals Integration Rate Charts Integration Effort as % Total Engineering Effort Integration Anomalies Projected vs. Actuals Interface Defects Projected vs. Actuals Integration Planning % Complete Planned vs. Actuals % Integration Planning Milestones Met Planned vs. Actuals Integration Planning Productivity Integration Planning Effort Planned vs. Actuals Integration Planning Effort as % Total Engineering Effort % Integration Plan Reviewed; % Approved by Identified Stakeholders % Tracking Integration Milestones Met Planned vs. Actuals % Integration Issues Closed Integration Management Effort Planned vs. Actuals Integration Management Effort as % Total Engineering Effort CI Status Summary

Technical Solution (TS) Measures # of Products to Integrate Integration Effort (FTEs)

Number of Integration Anomalies Number of Interface Defects Planning Measures Integration Planning Milestone Dates (e.g., due dates on planning checklist) Integration Planning Effort (FTEs)

Integration Plan Status Monitoring and Control Measures Tracking Integration Milestones Dates Integration Issues/Actions Status Overall Integration Management Effort CM Measures CI Status

4-40

Project Management Processes and Requirements

4.1.9.10 Methods and techniques5 Several methods and techniques are available. These include: Integration Maps/Trees An integration map or tree shows how elements are integrated to form the system of interest. Each node represents an element of the system of interest. N2 Diagramming A matrix displaying functional interactions, or data flows, at a particular hierarchical level. Simulations For example, the use of threads, rapid prototypes, virtual prototypes, and physical prototypes. The degree of virtual vs. physical prototyping used to support element integration depends on the functionality of the design tools, the complexity of the element, and the risk associated with that element. IFWGs Can be established to review interface statements/drawings, and are a good means of ensuring direct interaction of all parties to the system of interface. Horizontal integration methods and techniques include: Mathematical models (e.g., to ensure the power consumption needs of the overall system can be met by the power supplied by or to the system; or to integrate experiments, payloads, or payload complements at the rack, pallet, lab, or partner levels for purposes of transportation, accommodation, or operations) Data collection and analysis Compatibility analysis Impact assessments Planning and scheduling analyses 4.1.9.11 Software tools5 A standard office automation word processor is sufficient for documenting the integration-related

plans, processes, procedures, requirements, analyses, and criteria developed and documented under this process. Once developed, these documents should be placed under CM control to maintain, control, and support their evolution. Also, to ensure that proper configuration of the elements required for integra tion is obtained, a standard CM tool should be employed to document a concurrent baseline that is consistent with the output of the project. The use of a basic office automation spreadsheet and graphical tools is applicable in the development of N2 charts and integration sequences (maps, trees), respectively. Mathematical S/W tools should be considered to support the development and execution of mathematical models during analytical integration activities. 4.1.9.12 References The following documents, which were used to prepare this section, offer additional insights into the SE Integration process: 1 NPR 71xx.x (document number not yet assigned), NASA Systems Engineering Processes and Requirements. 2 CMMI-SE/SW/IPPD/SS V1.1, Capability Maturity Model Integration (CMMI) for Systems Engineering, Software Engineering, Integrated Product and Process Development, and Supplier Sourcing, 2002.
3

EIA-632, Processes for Engineering a System, 1999. 4 SP 6105, NASA Systems Engineering Handbook , 1995. 5 INCOSE Systems Engineering Handbook , Version 2.0, 2000.
6

NPR 7120.5B, NASA Program and Project Management Processes and Requirements, 2002.

4-41

Project Management: SE & Project Control Processes & Requirements

4.1.10

Technical Work and Resource Management1,2 The Technical Work and Resource Management process is performed to plan how technical aspects of the work will be accomplished and to identify the resources that are necessary to accomplish this work. Execution of this process by the SE effort provides technical inputs to the overall project work and resource planning effort. There are two basic aspects to this process: the plan and organize aspect, and the monitor and control aspect. The plan and organize aspect identifies technical needs and constraints in support of the overall project planning effort. Technical requirements, which define the structure required to bring the system of interest into being, include identification, integration, and scheduling of all engineering functions and tasks; work breakdown structure (WBS) development; organizational structure definition (as related to the project); and descriptions of or references to key policies, standards, and processes. The results are documented in an SE management approach, often called SEMP, which relates technical requirements to project requirements, providing the structure to guide and control the integration of engineering activities needed to achieve SE objectives that are consistent with a top-level PMP. The monitor and control aspect provides visibility into technical progress and risks, and detection of variances needing corrective action. Monitoring requires tailoring the level of control of the complexity and risk of the project, tracking data for the level of control, and initiating a corrective action when measures do not meet expected results. Controlling requires setting thresholds of control limits and activating corrective actions based on risk analysis. A review process compares the results against the technical effort documented estimates, commitments, and plans. Adequate visibility enables timely corrective action to be taken before performance deviates significantly from plans. 4.1.10.1 Function1 In the Technical Work and Resource Management process: Technical content and technical products (e.g., documents, drawings) of the work to be accomplished shall be defined. Detailed technical schedule estimates necessary to accomplish the work shall be defined. Technical skills and capabilities necessary to perform the work shall be identified. Resource estimates (e.g., cost, labor) to perform the work shall be provided. Status relative to the cost, schedule, and technical progress of the work shall be provided.

4.1.10.2 Objective 1 The objective of the Technical Work and Resource Management process is to document and status the SE effort required to accomplish the goals and objectives of the system of interest. This includes describing how the efforts are carried out, who accomplishes them, how they are controlled, and how technology is transitioned from the technology base to system of interest products. Basically, the objective of this process is to establish the SE management approach whether it is documented in an SEMP or some other document and record and report status against it. 4.1.10.3 Responsibilities3 The Lead Systems Engineer is responsible for managing the SE effort throughout the technical aspects of the project life cycle. This includes managing the system of interest decomposition and definition processes as well as the Integration, Verification, and Validation processes (Sections 4.1.9, 4.1.14, and 4.1.15). Attendant with this is the requirement to control the completeness and integrity of project technical baselines, ensuring an efficient and logical progression through these baselines while maintaining cost and schedule consistent with business baseline. SE audits the design and coding process and the design engineering solutions for compliance to all higher-level baselines. SE also ensures that concurrent engineering is properly applied throughout the project life cycle by involving the required specialty engineering disciplines. The SEMP is the guiding document for all these activities. The Project Manager approves the SEMP, ensures that SEMP requirements and plans are properly integrated into the PMP, and allocates project resources to execute the SEMP. (NOTE: At the discretion of the Project Manager, the SEMP and the PMP may be combined into a single document.) 4.1.10.4 Life cycle The Technical Work and Resource Management process begins at the earliest stages of the project life cycle and continues throughout the project. Planning for and development of the SEMP is one of the first planning activities of any project. The SEMP then becomes the baseline against which SE tasks, budgets, and schedules are measured throughout the remainder of the project. The SEMP is not a static document, however. It must be reviewed and revised as conditions change on the project. 4.1.10.5 Inputs3 Typical inputs required by the Technical Work and Resource Management process to create an SEMP include: Needs, goals, and activities

4-42

Project Management Processes and Requirements

Project plans and schedules, including the PMP and other plans and schedules Assumptions, guidelines, and constraints Concepts and architectures, including system, functional, and operations Product breakdown structure System specification Requirements, including top-level project, science, and system/segment Once the SEMP is established and commitment to it are secured, inputs to this process are typically to progress status with regard to tasks, budgets, and schedules. 4.1.10.6 Steps4 The following diagram (FIG. 4.1-10) illustrates the major steps and products of the Technical Work and Resource Management process. More detailed activities associated with these steps are provided below. Establish Estimates SE planning parameters shall be established and maintained. Parameters include all of the information needed by the project to perform necessary SE planning

organizing, staffing, directing, coordinating, reporting, and budgeting. Estimate the Scope of the Project Establish a system of interest structure to estimate the scope of the project. Identify and describe tasks in sufficient detail to specify estimates of project tasks, responsibilities, and schedule. Identify system of interest products and any enabling products to be produced, acquired, or reused. Establish Estimates of Technical Attributes Establish and maintain estimates of technical attributes of work products and tasks. Size, connectivity, complexity, and structure of deliverable and non-deliverable work products, documents, and operational and support S/W are typical inputs to estimate. These parameters are used to support technical planning estimates of efforts, cost, and schedule. See the Control process (Section 4.1.12) for identification and allocation of technical attributes.

Plan and Organize


Establish Estimates Establish Project Scope Establish Estimates of Technical Attributes Identify Project Risks Define Project Life Cycle Plan for Data Management Determine Estimates of Effort and Cost Plan for Project Resources Project Attributes A

A Develop the SEMP B Obtain SEMP Commitment

Establish Budget and Schedule

Plan for Needed Knowledge and Skills Review Plans that Affect the Project

Identify Processes Reconcile Work and Resource Levels

Plan Stakeholder Involvement

Establish the SEMP

SEMP

Obtain SEMP Commitments

SEMP Commitments

Monitor and Control C Monitor Technical Efforts Monitor Planning Commit- Project Data Stakeholder Parameters ments Risks Management Involvement Conduct Progress Reviews Results Conduct Milestone Reviews

Manage Corrective Action

Analyze Issues

Take Corrective Action

Manage Corrective Action

Correction Action Results

KEY

Step/Activity

Product

Information/Output Flows

Connector

Figure 4.1-10. Technical work and resource management process diagram.

4-43

Project Management: SE & Project Control Processes & Requirements

Define Project Life Cycle Define the project life cycle phases on which to scope the major system of interest phase for the current state of the product, expected future phases, and the relationships and effects among the phas es. Adjust planning parameters to account for relationships and effects among phases. Determine Estimates of Effort and Cost Estimate the project effort and cost for the work products and the task based on estimation rationale. Develop the SEMP An SEM P shall be established and maintained as the basis for managing the SE aspects of the project. This SEMP details the work activities and work products of the integrated technical effort across the project. Establish Budget and Schedule Establish and maintain the project budget and schedule. Identify Project Risks Identify and analyze project risks (Risk Management process, Section 4.3.2). Plan for Data Management Plan for the management of project data. Plan for Project Resources Plan for necessary resources to perform the SE aspects of the project. Plan for Needed Knowledge and Skills Plan for knowledge and skills needed to perform the project. Identify Processes Identify technical and engineering management processes to be used in executing the project (see the Quality Management process, Section 4.3.4, for additional details regarding identifying and tailoring the project processes.) Plan Stakeholder Involvement Plan the involvement of identified stakeholders. Establish the SEMP Establish and maintain the SEMP and its contents. Obtain Commitment to the SEMP Commitments to the SEMP shall be established and maintained. Review Plans Affecting the Project Review all plans that affect the project to understand project commitments; e.g., technology development plans, systems integration plans, verification and validation plans, and PMPs. Plans developed within other process areas typically contain information similar to that called for in the SEMP. These plans may provide additional detailed guidance and should be compatible with and support the SEMP to indicate who has authority, responsibility, accountability, and control.

Reconcile Work and Resource Levels Reconcile the SEMP to reflect available and estimated resources. When integrated teams are involved, special attention must be paid to resource commitments in circumstances of distributed integrated teams and when individuals are on multiple integrated teams in one or more projects. Obtain SEMP Commitments Obtain commitment from the project manager and relevant stakeholders responsible for performing and support SEMP execution. Monitor Technical Effort Technical effort shall be monitored against the SEMP. Monitor SEMP Planning Parameters Monitor the actual values of the project planning parameters against the SEMP. See the Control process (Section 4.1.12) for actual tracking and reporting of significant technical attributes. Monitor Commitments Monitor commitments against those identified in the SEMP. Monitor Project Risks Monitor risk against those risks identified in the SEMP (see the Risk Management process, Section 4.3.2, for further details of this activity). Monitor Data Management Monitor the management of project data against data management requirements in the SEMP. Monitor Stakeholder Involvement Monitor stakeholder involvement against the SEMP. Conduct Progress Reviews Periodically review the progress, performance, and issues of the project against the SEMP. Conduct Milestone Reviews Review the accomplishments and results of the project at selected project milestones (see the Reviews process, Section 4.1.16, for further details of this activity). Manage Conservative Action to Closure Significant deviations from plan shall be analyzed and corrective actions shall be managed to closure. See the Quality Management process (Section 4.3.4) and the Safety and Mission Success process (Section 4.1.11) for related details associated with management corrective actions. Analyze Issues Collect and analyze the issues and determine the corrective actions necessary to address these issues. Take Corrective Action Take corrective action(s) on identified issues. Manage Corrective Action Manage corrective actions to closure.

4-44

Project Management Processes and Requirements

4.1.10.7 Outputs4 The output associated with planning and organizing technical work and resource management shall be an SEMP. The SEMP, whether it is a standalone document or is embedded in the PMP, is the single integrated technical planning document. It incorporates not only what the project needs to do to accomplish the SE effort, but also how the efforts are to be carried out, who will accomplish them, how they are to be controlled, and how the technology is to be transitioned from the technology base to the system of interest products. Actual structure and content of the SEMP will vary according to project needs, but generally the SEMP should be organized to describe the: System of interest and its structure. Technical processes. Project technical management processes. Organizational structure. Constraints and concerns. An outline for development an SEMP is found in Appendix D of this document. Specific content of the SEMP would typically include: SE task descriptions, including size and complexity of tasks and work products WBS, including work packages and task dictionary Technical approach and processes, including project life cycle phases Technical management approach and processes, including estimating models, effort and cost es timates with rationale, schedule and schedule dependencies, budget, and identified and prioritized risks Acquisition strategy and plans in support of SE activities Base Measures Planning Milestone Dates Planning Effort (FTEs)

References to or actual plans for engineering functions; e.g., reliability, maintainability, human engineering, safety, producibility, integrated logistics support, data management, CM, etc. Staffing requirements, including inventory of skills needed, and staffing and new hire plans Critical facilities and equipment lists Records indicating reviews and commitments to the SEMP For the monitor and control aspect of this process, major outputs should include: Records of project performance and significant deviations Documented project progress and milestone review results List of issues needing corrective action and corrective actions results 4.1.10.8 Exit criteria The exit criteria for the Technical Work and Re source Management process shall be: Establishment of and commitment to an SEMP. Regular, documented reviews of technical effort against the SEMP. 4.1.10.9 Measurement The following table provides example base and derived measures that can be used in conjunction with executing the Technical Work and Resource Management process. See discussion of Measurement on page 4-1.

Derived Measures Planning % Complete Planned vs. Actuals % Planning Milestones Met Planned vs. Actuals Project Planning Productivity Project Planning Effort Planned vs. Actuals Project Planning Effort as % Total Engineering Effort % Tracking Milestones Met Planned vs. Actuals % Issues Closed Project Management Effort Planned vs. Actuals Technical Management Effort as % Total Engineering Effort Planned vs. Actual Tailoring Dates % Process Compliance % Processes Modified or Tailored Out % Plans Reviewed; % Approved by Identified Stakeholders

Tracking Milestone Dates (e.g., monthly progress reviews, milestone reviews) Issues/Actions Status Overall Technical Project Management Effort Tailoring Report Completion # of Processes Tailored (i.e., modified or tailored out) # of Plans and Associated Status

4-45

Project Management: SE & Project Control Processes & Requirements

4.1.10.10 Methods and techniques3 The following methods and techniques are representative of those typically used in technical work and resource management: WBS analysis Networking scheduling Workflow diagram Program evaluation review technique (PERT) charting Activity-on-arrows diagram Precedence diagrams Gantt charts Resource leveling Decision tree 4.1.10.11 Software tools Depending on the size and complexity of the system of interest, the tools used to support the Technical Work and Resource Management process could vary from typical office products (e.g., spreadsheets, word processors, and graphical representation tools) to very sophisticated commercial products built on top of Microsoft Project or other standard project management applications. Generally, the basic requirements are to use tools that support capturing, analyzing, and publishing schedules, costs, budgets, and resources. Other tools may be required to support the capture and analysis of skill, knowledge, education, and training information. These could be commercial tools, when management and tracking of many people over a period of years is required, or a project built using spreadsheets or commonly available databases. 4.1.10.12 References The following documents, which were used to prepare this section, offer additional insights into the Technical Work and Resource Management process: 1 NPR 71xx.x (document number not yet assigned), NASA Systems Engineering Processes and Requirements . 2 EIA-731.1, Systems Engineering Capability Model, 2002.
3

SP 6105, NASA Systems Engineering Handbook , 1995. 4 CMMI-SE/SW/IPPD/SS V1.1, Capability Maturity Model Integration (CMMI) for Systems Engineering, Software Engineering, Integrated Product and Process Development, and Supplier Sourcing, 2002. 5 NPR 7120.5B, NASA Program and Project Management Processes and Requirements, 2002.

4-46

Project Management Processes and Requirements

4.1.11 Safety and Mission Success1,2 The Safety and Mission Success process is performed to provide for early identification, analysis, reduction, elimination, and control of hazards to ensure the safety, reliability, maintainability, and quality of the system of interest. The requirements on the part of SE are to monitor, coordinate, and integrate the overall project safety and mission success established by project management. Project management and SE must rely on contributions from both the specialty engineering disciplines and the traditional design disciplines for functional expertise and specialized analytic methods related to safety and mission success. Specialty engineering areas include reliability, maintainability, QA, quality engineering, and safety engineering. Specialty engineers contribute throughout the SE process. As part of the technical effort, they apply specialized analytical techniques; define system requirements in their areas of expertise; perform analyses; and evaluate data packages, engineering change requests, test results, and documentation for major project reviews. A part of the systems engineers function is to verify that these specialty engineering activities are coherently integrated into the project. 4.1.11.1 Function1,2,3 Safety engineering is performed to provide for the early identification, analysis, reduction, elimination, and/or control of hazards associated with the system of interest. Reliability engineering implements specific design features to ensure that the system of interest can perform in physical environments for the required amount of time. Maintainability engineering implements specific design features to optimize maintenance characteristics of the system in the physical environments. Quality engineering and QA verifies that the system of interest is produced and delivered in accordance with its safety, performance, and design requirements, and that approved processes are followed during the project life cycle. S/W QA ensures that the S/W processes and products conform to requirements, standards, and procedures through a planned and systematic set of activities as stated in NASA-STD-2201-93.18 Safety and mission success personnel at JSC will comply with the documents maintained in the safety and mission assurance (S&MA) documentation tree (http://www.hq.nasa.gov/office/codeq/doctree/gdoc.htm). The Safety and Mission Success process will: Scope the amount of S&MA support needed. Ensure the system of interest is safe; i.e., Potential hazards shall be identified. A method to monitor and control, eliminate, or reduce identified hazards shall be established.

Hazard mitigation efforts shall be ensured to be implemented as designed and to perform the intended function. Systems safety s hall be an integral part of the overall risk management process using probabilities estimates and severity classes for understanding and managing safety risks. Ensure the system of interest is reliable. Ensure the system of interest is maintainable. Ensure the system of interest is of high quality. 4.1.11.2 Objective 3 The primary objective of this process is to integrate specialized quality engineering and safety, reliability, maintainability, and quality assurance techniques/processes throughout all phases of the project life cycle. Other objectives are to ensure that: Safety and mission success processes will be used throughout the project life cycle to prevent potential system failures. Project decisions made will be consistent with JSC S&MA principles. The safety of the public, NASA flight crews, employees, and critical assets will not be jeopardized. 4.1.11.3 Responsibilities The Project Manager ensures that safety and mis sion success processes are performed by the project. The Lead Systems Engineer is responsible for integrating safety and mission success functions into the project and for coordinating the performance of these functions by the project team. This includes working with the S&MA Directorate at JSC to scope the best approach to meet the specific needs of the project as related to safety and mission success. S&MA project support is provided through S&MAassigned representatives. In this capacity, the S&MA Representatives will (1) assist the project manager in ensuring that all S&MA requirements are appropriately defined and implemented; (2) guide the project during life cycle development through the safety, assurance, procurement, certification, shipping, etc., processes; and (3) serve as a point of contact between the project team and the S&MA Directorate, assuring proper coordination, review, or approval of all safety and mission success responsibilities and practices. Support from numerous personnel is provided, as required, to meet the needs of the project. The safety engineer, reliability engineer, maintainability engineer, quality engineer, QA specialist, procurement quality assurance (PQA) specialist, and S/W QA engineer are all part of the S&MA Directorate. The difference in the roles of a quality engineer, QA specialist, PQA specialist, and S/W QA engineer are clarified below.

4-47

Project Management: SE & Project Control Processes & Requirements

The quality engineer ensures that products provided meet or exceed S&MA requirements. The QA specialist ensures that processes are implemented and followed. The PQA specialist ensures that S&MA requirements are imposed on contracts and delegates QA functions to other agencies (e.g., Defense Contract Management Agency (DCMA)). The S/W QA engineer is responsible for QA, quality engineering, and safety on S/W products. 4.1.11.4 Life cycle The Safety and Mission Success process establishes and maintains an effective process through all phases of the project life cycle. S&MA requirements, reviews, and plans are integrated into the project life cycle. 4.1.11.5 Inputs Typical inputs to this process include, but are not limited to: System goals and objectives System requirements Operational concepts and scenarios Trade studies Project plans Feasibility assessment Schedules/timelines System constraints Quality and test procedures

Procurement documents (SOW, data requirements descriptions) Version description document ITA Development plans Engineering drawings Design documents Verification and validation plan/document ICDs Certification data package Acceptance data package (ADP) Problem reports 4.1.11.6 Steps The project team, in accordance with the responsibilities outlined in Section 4.1.11.3 above, performs the process steps illustrated in Figure 4.1-11. Determine S&MA Support Level S&MA support shall be scoped to determine the amount of support needed. Prepare and approve an ITA. Ensure System Safety System safety shall be integrated into the life cycle development of the system of interest. Develop and execute a system safety plan. Provide regular reporting of system safetyrelated issues and status to project management. Formulate the System Safety Design Criteria The common goal of system safety design

Ensure System Maintainability

Maintainability Plans, Procedures, Analysis, Reports, Issues, & Status

Ensure System Safety

Ensure System Quality

Ensure System Reliability

Safety Plans, Procedures, Analysis, Reports, Issues, & Status

Quality Plans, Procedures, analysis, Reports, Issues, Status

Reliability Plans, Procedures, Analysis, Reports, Issues, & Status

KEY

Step/Activity

Product

Information/Output Flows

Figure 4.1-11. Safety and mission success process diagram.

4-48

Project Management Processes and Requirements

criteria is to achieve acceptable and minimized levels of design-associated hazards. Many hazards can be eliminated by selecting appropriate specifications, standards, materials, design features, and previously qualified components as expressed in design criteria. Review and approve verification/validation plan. Review and approve requirements documents and verification criteria. Prepare hazard analysis to identify potential hazards and drive design solutions. A safety data package is prepared and submitted to the Safety Review Panel (SRP). Phase I is submitted at the PDR, Phase II at the CDR, and Phase III after qualification testing. (NOTE: For government-furnis hed equipment (GFE), the safety review is performed by the SMART; and for GFE payloads, the safety review is performed by the Payload Safety Review Panel (PSRP).5,6 Perform Software Safety Analysis S/W safety is defined in SSP 50038, NASA-STD 8719.13, and NASA-GP-1740.13-96.7,8,9 Perform Safety Testing Safety tests are planned to demonstrate that safety provisions, alarms, and procedures called out in the hazard analysis are adequate and to verify hazard controls are implemented, effective, and satisfy requirements. Perform Ground Safety Analysis The ground safety analysis report is an analysis required to alert vehicle integrators to any specific safety-related design features of the project. Normally this involves integrating the project through the Kennedy Space Center (KSC) as shown in KSC 1700.710 and further defined in NSTS 13830.11 The paragraphs identified in KSC 1700.7 and NSTS 13830 provide information on the intent and content of this analysis report. These documents are specific to KSC operations but cover most typical project safety-related delivery scenarios. If an organization other than KSC is integrating flight H/W onto a vehicle/flight article, a review of these paragraphs should ensure an understanding of the necessary material to support negotiations with the organizations safety group. Ground systems with S/W controls must meet the safety requirements in NASA-STD-8719.13.8 Support TRRs. Ensure that the system and all ground operations and activities associated with the system comply with applicable Occupational Safety and Health Administration (OSHA) standards

and JPG 1700.112 so as to prevent personnel injury, damage to the system, and damage to other property/systems. Review and approve certification documentation. Review and assess problem reports and nonconformances for safety impacts. Ensure that system operational issues are identified and documented on a problem report and that corrective actions are implemented. Support project tests or analyze products not only at the expected operational conditions, but also at off-nominal conditions to determine margin or robustness. Ensure System Reliability System reliability shall be integrated into the life cycle development of the system of interest.2 Develop and execute a re liability plan. Provide regular reporting of system reliabilityrelated issues and status to project management. Perform criticality assessment of the system as part of the feasibility assessment. Develop and refine reliability prediction models. Establish and allocate reliability goals, fault tolerance requirements, and environmental design requirements. Review and approve verification/validation plan. Review and approve requirements documents and verification criteria. Develop environment test requirements and specifications for H/W qualification. Prepare an FMEA/critical items list (CIL) to support design decisions. FMEA/CIL is reviewed and approved by the appropriate R&M panel. Perform design trade studies covering issues such as the degree of redundancy, system availability, and reliability vs. maintainability. Support risk management by identifying design attributes that are likely to result in reliability problems and recommend appropriate risk mitigations. Identify and track limited life and cycle life items (e.g., JSC-2493713 ). Identify redundancy requirements. Perform analyses on qualification test data to verify reliability predictions and validate the system reliability prediction models, and to understand and resolve anomalies. Review and approve electrical/electronic equipment (EEE) parts specifications, if applicable. Conduct and/or approve EEE parts application analysis, if applicable.

4-49

Project Management: SE & Project Control Processes & Requirements

Perform testing for qualification and acceptance of EEE parts, if applicable. Review and approve certification documentation. Prepare fault-tree analysis to identify failures . Ensure System Maintainability System maintainability shall be integrated into the life cycle development of the system of interest.2 Develop and execute a maintainability plan. Provide regular reporting of system maintainability-related issues and status to project management. Establish and allocate maintainability and availability requirements. The requirements should be consistent with the maintenance concept and traceable to system-level availability objectives. Perform an engineering design analysis to identify maintainability design deficiencies and predictions. Develop maintainability predictions to support logistics (spares), operations (e.g., crew time for repairs), and manifest. Perform analyses to quantify the system maintenance resource requirements, and document them in the maintenance plan. Ensure System Quality System quality shall be integrated into the life cycle development of the system of interest.2 Develop and execute a QA plan (S/W and H/W). Provide regular reporting of system quality-related issues and status of project management. Identify issues of design, materials, workmanship, fabrication and verification processes, and other characters that could degrade product system quality in support of major system design reviews (e.g., SRR, PDR, and CDR). Ensure engineering designs meet project requirements and comply with Center and program quality requirements. The requirements are detailed in the following documents: ? JPG 5335.3, Quality Manual ? NSTS 5300.4(1D-2), Safety, Reliability, Maintainability, and Quality Provisions for the Space Shuttle Program ? SSP 41173, Space Station Program Quality Assurance Requirements ? JPG 8080.5, JSC Design and Procedural Standard Manual Conduct process, product, and quality management system audits. Ensure the completeness of CM plan, procedures, and documentation. Review and approve test procedures.

Review and approve PMPs and program/ project requirements documents. (NOTE: This is a joint review by all of S&MA.) Review and approve procurement documents. Participate in the evaluation and selection of procurement sources. Ensure NASA workmanship standards are used in the design and manufacture of EEE for high-reliability (flight H/W, critical ground support equipment, etc.) applications.14 Ensure S/W is designed and developed in accordance with NASA standards established by the following documents: NPD 2820.1, NASA Software Policies NASA-STD-2100-91, NASA Software Documentation Standard NASA-STD-2201-93, Software Assurance Standard NASA-STD-8719.13A, Software Safety NASA Technical Standard NASA-STD-8739.8, Software Assurance Perform QA contract surveillance. Ensure verification requirements are properly specified, especially with respect to test environments , test configurations, and pass/fail criteria. Evaluate manufacturing/fabrication plans and processes. Assign mandatory inspection points. Inspect items and facilities during manufacturing/fabrication as well as items delivered to the NASA field centers. Inspect facilities to assure equipment, certification, and calibration. Ensure the adequacy of personnel training and technical documentation to be used during manufacturing/fabrication. Monitor qualification and acceptance tests to ensure compliance with verification requirements and test procedures, and to ensure that test data are correct and complete. Approve the resolution of nonconformances and problem/failure reports (P/FRs), and verify the implementation and effectiveness of corrective action(s). Perform assessment of as-designed vs. asbuilt configurations. Verify each ADP is complete and correct. Verify each version description document as complete and correct. Verify completion of certification documentation. Assess S/W development folders. Ensure flight equipment that is being shipped for flight is ready for shipment and followon flight processing/integration.

4-50

Project Management Processes and Requirements

Investigate mishaps and process escapes. 4.1.11.7 Outputs Primary outputs from this process are: Safety and mis sion success program plans Safety and mission success requirements Hazard analysis Reliability prediction models FMEA/CIL Fault-tree analysis Safety and mission success status Review item dispositions (RIDs) QA surveillance data Flight H/W- and S/W-specific output, including: ADP Certification data package Pre-Shipment Readiness Review (JSC Form 1027) Government certification approval request (GCAR) 4.1.11.8 Exit criteria The Safety and Mission Success process is ongoing throughout the life cycle of the project and does not end until the mission is complete and project deliverables are decommissioned. 4.1.11.9 Measurement The table at the bottom of the page provides both base and derived measures that can be used in conjunction with the Safety and Mission Success process. See discussion of Measurement on page 4-1. 4.1.11.10 Methods and techniques Methods and techniques used in the Safety and Mission Success process depend, to some degree, on the nature of the system of interest. However, typical methods and techniques include: Base Measures S&MA Planning Milestone Dates (e.g., due dates on planning checklist) S&MA Planning Effort (FTEs)

Trade studies Risk assessment matrix Hazard analysis FMEA and criticality analysis Reliability block diagram Fault-tree analysis Event-tree analysis Combinatorial failure probability analysis Failure mode information propagation modeling Probabilistic design analysis Probabilistic risk assessment Tolerance stack-up analysis Design of experiments Brainstorming Checklists Reliability trend analysis Human reliability analysis Failure trend analysis

4.1.11.11 Software tools Standard office autom ation tools, which support documentation reviews and the development of various analyses, should generally be used; e.g., word processor, spreadsheet, and presentation S/W for PCs. Tools that help in the analysis of systems should also be used. One such tool is PSpice. 4.1.11.12 References The following documents, which were used to prepare this section, offer additional insights into the Safety and Mission Success process:
1

NPR 71xx.x (document number not yet assigned), NASA Systems Engineering Processes and Requirements . 2 SP 6105, NASA Systems Engineering Handbook , 1995.
3

NPR 7120.5B, NASA Program and Project Management Processes and Requirements, 2002.

Derived Measures S&MA Planning % Complete Planned vs. Actuals S&MA Planning Productivity S&MA Planning Effort Planned vs. Actuals

Mishap Rate

Mishaps/Year for Last 5 Years Cumulative Rate Projection Cause Category

Open Work Timeliness

% H/W and S/W Shipped with Open Certification QA Turnaround Time for Discrepancy Report Processing

4-51

Project Management: SE & Project Control Processes & Requirements

NASA-STD-2100-91, NASA Software Documentation Standard .


5

NSTS 1700.7, Safety Policy and Requirements for Payloads Using the STS . 6 NSTS 1700.7 Addendum, Safety Policy Requirements for Payloads Using the International Space Station. 7 SSP 50038, Computer-Based Control System Safety Requirements. 8 NASA-STD-8719.13A, Software Safety NASA Technical Standard .
9

NASA-GB-1740.13-96, NASA Guidebook for Safety Critical Software Analysis and Development . 10 KHB 1700.7, KSC Payload Ground Safety Handbook . 11 NSTS 13830, Payloads Safety Review and Data Submittal Requirements.
12

JPG 1700.1, JSC Safety and Total Health Handbook . 13 JSC-24937, Limited Life Time Cycle Items Program Requirements Document, 2002. 14 NASA-STD-8739 series. 15 INCOSE Systems Engineering Handbook , Version 2.0, 2000. 16 CMMI-SE/SW/IPPD/SS V1.1, Capability Maturity Model Integration (CMMI) for Systems Engineering, Software Engineering, Integrated Product and Process Development, and Supplier Sourcing, 2002.
17 18

EIA-632, Processes for Engineering a System. NASA-STD-2201-93, Software Assurance Standard .

4-52

Project Management Processes and Requirements

4.1.12 Control1 The SE Control process is performed to identify, allocate, track, and control significant attributes of the system of interest (e.g., technical performance, technical resources, cost, schedule, and interfaces). These significant system attributes are defined and controlled by this process and are reported to the Technical Work and Resource Management process (Section 4.1.10). The Technical Work and Resource Management process, in turn, is responsible for communicating technical performance status and resolving discontinuities reported by the Control process. Establishing TPMs is useful for tracking technical performance and progress as well as for evaluating trades when trying to derive the best technical solution since TPMs are typically based on key technical system attributes (e.g., weight, power, size, speed, performance, cost, and schedule). 4.1.12.1 Function1 In the SE Control process: Budgets and margins for significant system of interest attributes (e.g., power, weight) shall be defined and allocated. TPMs shall be established and tracked. Methods for tracking and reporting measures for technical resources, cost, and schedule shall be established. Interface controls shall be established, documented, and maintained. 4.1.12.2 Objective 2 The objective of this process is to establish, monitor, control, and report the technical performance, cost, and schedule attributes, methods, and measures of the system of interest. 4.1.12.3 Responsibilities The Project Manager makes the final decision concerning salient features and significant attributes of the control system. The Lead Systems Engineer is responsible for ensuring the completeness and integrity of the SE control system, identifying and allocating budgeted resources of system attributes, establishing and tracking technical measures, and establishing interface controls. The Project Control Officer is responsible for integrating the SE control systems into the overall project control function. Specialty Engineering Disciplines are responsible for supporting the Lead Systems Engineer with discipline-specific technical performance, cost, and schedule data and measures.

4.1.12.4 Life cycle The Control process is a crosscutting process that spans the entire project life cycle. Establishing methods for tracking, controlling, and reporting technical measures and attributes occurs during definition of the project. Identification of technical attributes and performance measures in support of SEMP development also occurs early in the project life cycle. Execution of process tracking, controlling, and reporting functions continues until the end of the project. 4.1.12.5 Inputs Typical inputs to this process include, but are not limited to: System architecture WBS SEMP System requirements Technical performance measurement baseline (PMB) ICD Interface requirements specification 4.1.12.6 Steps3,4 Adhering to the major steps of this process directs the project toward meeting its SE control requirements. For each major process step, additional guidance is provided as to the typical sub-process steps and products that are expected. These steps are shown in Figure 4.1-12 (at the top of the next page) and are discussed further below. Manage Technical Attributes Identify and Allocate Technical Attributes Budgets and margins for significant system of interest attributes shall be defined and allocated. Define technical budgets and margins for significant system of interest attributes (e.g., size, power, weight, cost, and schedule). Allocate technical budgets and margins for significant attributes across and down the system of interest hierarchy. Maintain and Control Technical Attributes Budgets and margins for significant system of interest attributes shall be maintained, tracked, and controlled. Periodically assess the adequacy of technical resources, including margins, to meet project requirements. Develop and implement a recovery plan when margins of technical attributes for the system of interest become inadequate.

4-53

Project Management: SE & Project Control Processes & Requirements

Manage Technical Attributes

Identify & Allocate Technical Attributes

System of Interest Technical Attributes

?
Maintain & Control Technical Attributes

Over-Budgeted Resources Recovery Plan

Establish Technical Performance Measures Manage Performance Measures

Track Technical Performance Measures

Analyze Technical Performance Measures

Technical Performance Measures

Report Technical Performance Measures

Technical Performance Results

Manage Interfaces

Establish Interface Controls

Interface Mgmt. Plans & Processes

Maintain & Control Interfaces

ICDs and Interface Request Specifications

KEY

Step/Activity

Product

Information/Output Flows

Figure 4.1-12. Control process diagram. Manage Performance Measures Establish Technical Performance Measures Identification of technical performance measures and of collection, analysis, and reporting requirements shall be established. Note that the Control process measurement steps are very similar to those defined in the Quality Management process (Section 4.3.4); however, the focus of each differs. The Control measurement steps are specific to performance measures, whereas the Quality Management measures are applicable only to process and product measures. Establish measurement objectives that are derived from technical needs and objectives. Specify TPMs that address resource, cost, and schedule measurement objectives, including attributes (e.g., owner, frequency of collection, roll-up of lower-level measures). Most useful TPMs are those that provide visibility into the technical performance of key elements of the WBS, especially those that are cost drivers on the program, lie on the critical path, or represent high-risk items . TPMs are key to progressively assessing technical progress and, once defined, should be documented in the SEMP (Section 4.1.10). Specify the critical technical parameters, including update frequencies and level of tracking depth, used to derive the defined TPMs. This may be achieved by developing a technical parameter hierarchy that identifies all measurable key technical elements and establishes their relative relationships and importance. Specify measurement data collection methods, tools, and storage procedures. Specify measurement data analysis methods, procedures, and tools. Specify measurement result report types and communication mechanisms. Manage and store measurement specifications in accordance with defined storage procedures. Track Technical Performance Measures Collection of technical performance measurement data shall be performed. Collect specified technical performance measurement data in accordance with the defined collection methods and tools. Track critical technical parameters rela tive to time, with dates established as to when progress will be checked and when full compliance will be met. Manage and store measurement data in accordance with defined storage procedures. Analyze Technical Performance Measures Analysis of technical performance measurement data shall be performed.

4-54

Project Management Processes and Requirements

Analyze specified technical performance measurement data in accordance with defined analysis methods, procedures, and tools . Apply statistical methods to understand performance measurement variation, where applicable. Analyze and interpret performance measurement data. Manage and store analysis results in accordance with defined storage procedures . Report TPMs Reporting of technical performance results to relevant stakeholders shall be performed. Report technical performance measurement and analysis results to the project manager and other relevant stakeholders (e.g., design and SE, customer). Periodically review project performance against the SEMP (see Section 4.1.10 for conducting progress reviews). Establish a correction plan for performance measurement discontinuities (see Section 4.3.4 for managing corrective actions). Manage Interfaces Establish Interface Controls The project technical plan for maintaining and controlling system interfaces shall be established. Development and documentation of the system of interest internal and external interfaces is performed as part of the SE Decomposition process (Section 4.1.4). Establish, document, and maintain the project interface controls (e.g., responsibilities, processes) in an interface management plan. Maintain and Control Interfaces Management of system interfaces shall be performed by providing oversight of interface definition, control, compatibility, approval, and coordination in accordance with the interface management plan. Monitor system development and manage technical staff, budget, and schedules to ensure project interface management plans are being followed and supporting processes are being used. Ensure supervision and resources are pro vided to enable the interface management plans to be executed and commitments met. Make data pertinent to interface management readily accessible to project teams throughout the system of interest life cycle. Ensure all internal and external functional and physical interfaces for each

element are identified, defined, assigned, documented, and managed. Ensure element design definitions are compatible in terms of form, fit, and function. Conduct frequent technical interchange meetings (TIMs) among systems engineers of each organization involved to promote understanding of the mission functional requirements of the fully integrated system, the contribution each product is expected to make in fulfilling those requirements, and the interfaces required for the system to perform as intended. Establish an interface control working group to maintain interface requirements, and to coordinate and resolve any discrepancies in system interfaces (requirements and implementations). Ensure interface changes affecting the element and affected by the element are controlled to prevent adverse consequences. Update and maintain ICDs and interface requirements, as required.

4.1.12.7 Outputs Primary outputs from this process are: System technical attributes TPMs TPM analysis results Earned value status, if available Plans (resource recovery plans, interface management plans) ICDs (updated) Interface requirements specification (updated) 4.1.12.8 Exit criteria The process is exited upon project termination. 4.1.12.9 Measurement The table at the top of the following page provides example base and derived measures that can be used in conjunction with executing the Control process. See discussion of Measurement on page 4-1.

4-55

Project Management: SE & Project Control Processes & Requirements

Base Measures Tracking Milestone Dates (e.g., mo nthly tracking book reviews, gate reviews) Issues/Actions Status Overall Technical Management Effort

Derived Measures % Tracking Milestones Met Planned vs. Actuals % Issues Closed Technical Management Effort Planned vs. Actuals Management Effort as % Total Engineering Effort

4.1.12.10 Methods and techniques5,6 Performance management methods include: Earned Value Management (EVM) Enables effective execution, management, and control as well as integrated evaluation of cost, schedule, and technical performance against the baseline. Performance Assessments Confirms satisfactory project performance and ensures timely identification of all problems throughout the life cycle. Schedule Management Ensures the establishment, management, and control of baseline master schedule and derivative schedules that provide the framework for time phasing and coordinating all project efforts into a master plan to ensure that objectives are accomplished within project or program commitments. Project performance against the baseline schedule represents a key element in managing risk. WBS Serves as the structure for project technical planning, scheduling, cost estimating and budgeting, contract scope definition, documentation, product development, and status reporting and assessment (including integrated cost/schedule performance measurement). TPM Is the ongoing process of predicting the value of performance parameters, which are critical to successful performance of the system, at completion of the system development; comparing the current actual values of those performance parameters to a planned profile of each parameter over development time; and identifying any design deficiency that could jeopardize system performance. The extent to which TPM is to be employed should be defined in the SEMP. TPM may also be used to: evaluate compliance with requirements; assess compliance to levels of technical risk; trigger development of recovery plans for identified deficiencies; and examine marginal cost benefits of performance in excess of requirements. Measurement and analysis methods include: Statistical analysis Cause and effect fishbone diagrams Control charts Flow diagrams

Affinity diagrams Interrelationship diagraphs Pareto charts Run charts Block diagrams Gantt charts

4.1.12.11 Software tools5 Many S/W tools are available to support the SE Control process. These S/W tools include typical spreadsheet, scheduling, database, and drawing tools for data visualization, planning, monitoring, controlling, and analysis with commercial products available from many vendors. Als o available are specialized tools for measuring management systems and statis tical modeling analysis. For cost estimating and analysis, see the JSC Cost Estimating Web page at www.jsc.nasa.gov/bu2/. For an extensive listing of commercially available systems analysis tools, see the table provided by INCOSE at the following: www.incose.org/tools/eia632tax/eia632top.html. This table lists tools that support the Control process requirements of EIA-632.5 4.1.12.12 References The following documents, which were used to prepare this section, offer additional insights into the Control process: 1 NPR 71xx.x (document number not yet assigned), NASA Systems Engineering Processes and Requirements . 2 SP 6105, NASA Systems Engineering Handbook , 1995.
3

CMMI-SE/SW/IPPD/SS V1.1, Capability Maturing Model Integration (CMMI) for Systems Engineering, Software Engineering, Integrated Product and Process Development, and Supplier Sourcing, 2002. 4 EIA-632, Processes for Engineering a System, 1999. 5 INCOSE Systems Engineering Handbook , Version 2.0, 2000.
6

NPR 7120.5B, NASA Program and Project Management Processes and Requirements, 2002.

4-56

Project Management Processes and Requirements

15 4.1.13 System Analysis The System Analysis process (e.g., stress, thermal, cost, performance, safety, etc.) is performed to provide a specific, quantitative, engineering assessment that is used in making systematic, technical, and economic decisions and establishing design alternatives, recommendations, allocations, and budgets. This process is used to (1) provide a rigorous basis for technical decision making, resolution of requirements conflicts, and assessment of alternative physical solutions; (2) determine progress in satisfying system of interest require ments; (3) support risk management; and (4) ensure that decisions are made only after evaluating the cost, schedule, performance, and risk effects on the system of interest. The System Analysis process is a structured approach to evaluating alternative solutions against established criteria to determine a recommended solution addressing an issue. A formal System Analysis process involves establishing criteria for evaluating alternatives, identifying alternative solutions, selecting methods for evaluating alternatives, evaluating solutions using established criteria and methods, and selecting recommended solutions from the alternatives based on the evaluation criteria. A formal System Analysis process reduces the subject nature of the decision and increases the probability of selecting a solution that meets the multiple demands of the relevant stakeholders. In particular, trade studies are used to evaluate solutions to optimize the cost, schedule, performance, and risk of selected alternatives.

4.1.13.3 Responsibilities3 The Lead Systems Engineer is responsible for all aspects of the System Analysis process, including construction of quantitative models, application of those models to identified alternatives, and analysis of resulting data. Alternative selection and documentation are also the responsibilities of the Lead Systems Engineer. Other participants in this process include the: Design Engineering Disciplines such as S/W, mechanical, electrical, etc., who are responsible for providing discipline and functional expertise in support of these analyses. Specialty Engineering Disciplines, including reliability, maintainability, logistics, test, production, transportation, human factors, QA, safety, and risk management, who are responsible for providing specific, specialty expertise in support of these analyses. Chief Financial Officer Representative, who is responsible for supporting, providing, and certifying financial information in these analyses. 4.1.13.4 Life cycle6 Technical issues requiring the System Analysis process must be identified during any phase of a program. The objective is to identify impending technical issues as early as possible in the life cycle to maximize the time available to deal with each issue. The greatest application of the System Analysis process is, therefore, during the early stages of the life cycle beginning with Pre-Phase A, Advanced Studies, and continuing through Phase A, Preliminary Analysis, and Phase B, Definition, and ending in Phase C, Design. However, the process is applicable to the remaining stages of the life cycle and should be applied any time a technical issues requires analysis. The System Analysis process may be involved from any of the other SE processes. 4.1.13.5 Inputs Inputs to the System Analysis process vary depending on the stage in the life cycle and the focus of the analysis. Typical inputs will consist of: Functional concepts Physical concepts Operations concepts Requirements Design Measures of effectiveness (evaluation criteria) Plausible alternatives

4.1.13.1 Function1 In the System Analysis process: Evaluation criteria (e.g., environment, dimensions, life cycle, weight, cost, etc.) shall be established and applied during the analysis. Analytical or physical modeling of the alternatives based on the established evaluation criteria shall be performed to obtain a quantitative prediction. A recommendation for the solution based on the quantitative outcome of the analytical or physical modeling shall be made. 4.1.13.2 Objective 3 The objective of system analysis is to help decision makers choose appropriate course of action. This is achieved by systematically examining the relevant objectives and alternative policies and strategies for achieving them and comparing quantitatively the economic costs, effectiveness, and risks of the alternatives.

4-57

Project Management: SE & Project Control Processes & Requirements

4.1.13.6 Steps3,4 The following diagram (FIG. 4.1-13) illustrates the major steps of the System Analysis process. Details of these steps are provided below.

fulfill its goals and objectives (see Section 4.1.4, Decomposition). Define Plausible Alternatives Create alternatives that can potentially achieve the

Prepare for System Analysis

START

Establish System Analysis Guidelines

Define/Identify Goals, Objectives, and Constraints

Perform Functional Analysis

Define Plausible Alternatives

Define Selection Criteria

A Conduct System Analysis

Define Figures of Merit

Define Measurement Methods

Collect Data on Each Alternative

Compute System Effectiveness, Performance or Technical Attributes

Compute Cost for Each Alternative

Compute Uncertainty Ranges

Perform Sensitivity Analyses

Perform Risk Analysis

No Select Solutions B Is Tentative Selection Acceptable?

Consider New Alternatives

Return to Start

Make a Tentative Selection

Yes

Document Systems Analysis Results

Analysis Report

END

KEY

Step/Activity

Product

Information/Output Flows

Connector

Decision

Figure 4.1-13. System analysis process diagram. Preparation for Systems Analysis Shall Be Performed Preparation for the analytical portion of systems analysis shall be performed, including functional analysis of the system of interest to help identify plausible alternative solutions. Establish Guidelines for System Analysis Establish and maintain guidelines to determine which issues are subject to a formal system analysis process. Guidelines should be reviewed with and accepted by the design team. Define/Identify Goals, Objectives, and Constraints State the goals, objectives, and constraints in general operational terms during early stages of the project life cycle and as the architecture and design matures. State them more in terms of performance require ments that an as pect of the system of interest must meet (see Section 4.1.1, Requirements Development). Perform Functional Analysis Systematically identify, describe, and relate the functions that the system of interest must perform to goals and objectives of the system. Solicit alternatives from relevant stakeholders. Use brainstorming sessions, literature searches, interviews, and working groups to uncover alternatives. The number of alternatives considered can drive the cost of the analysis, so consider only clearly viable choices. Define Selection Criteria Define how the figures of merit for each trade study or decision will be used to make a tentative selection of the preferred alternative. Define the range and scale (or weighting factors) for ranking the criteria, rank the criteria, assess the criteria and their relative importance, and document rationale for the selection and rejection of criteria. Systems Analysis of Alternatives Shall Be Performed Each plausible alternative shall be analyzed in sufficient detail to support selection of a course of action. Define Figures of Merit (also called measures of effectiveness) Define quantitatively

4-58

Project Management Processes and Requirements

accomplishment of the system goals and objectives. Figures of merit are often expressed as polynomials (e.g., cost per ton launched, mean time to repair, data return time). Define Measurement Methods Define which measurement methods are to be used to explicitly identify and model those variables associated with system effectiveness, system performance, technical attributes, and system cost, and that are important in meeting system of interest goals and objectives. Collect Data on Each Alternative Collect data on each alternative to support evaluation by selected measurement methods. Compute System Effectiveness, Performance, or Technical Attributes Compute an estimate of system effectiveness, performance, or technical attributes for each selected alternative. Compute Uncertainty Ranges Compute, for non-point solution outcomes, uncertainty ranges for each alternative. Perform Sensitivity Analyses Estimate, for uncertain key inputs, a range of output values to gauge the sensitivity of the alternative with regard to inputs. Especially in the early stages of design, weighting factors and some quantified data can be subjective, so the sensitivity analysis is crucial. If the solution can be changed by making relatively minor changes in data input, the study is probably invalid. Similarly, if significant changes in data input produce no change in output value, the methodology should be reviewed and revised. Perform Risk Analysis Analyze the technical, schedule, and cost risks associated with each alternative. A Solution Shall Be Selected Given the results of alternative analysis, a tentative solution shall be selected and a decision reached as to whether the solution meets the acceptance criteria. Make a Tentative Selection Combine the selection rule with results of the analysis, align alternatives from most preferred to least, and make a tentative selection. In making this selection, the following questions should be considered: Have the goals, objectives, and constraints been met? Is the tentative selection robust? Is it heavily dependent on a particular set of input values to the measurement methods? Does it hold up under a range of reasonable input values? What are the risks?

Is more analytical refinement needed to distinguish among alternatives? Have subjective aspects of the problem been addressed? Consider New Alternative Solutions Consider new alternative solutions, criteria, or methods if the proposed alternatives do not test well; repeat the evaluations until alternatives test well. Document System Analysis Results Establish and maintain a system analysis or trade study report documenting all aspects of the analysis. Archive this report to ensure traceability of decisions made throughout the SE process. Ideally, system analysis and trade study reports should be indexed to requirements and records of design decisions for the project. 4.1.13.7 Outputs3 The output of the System Analysis process is a report that describes: The system issue under analysis. The system goals and objectives (or requirements, as appropriate to the level of resolution) and constraints. The figures of merit used in analysis. The measurement methods (models) used. All data sources used. The alternatives chosen for analysis. The computational results, including uncertainty ranges and sensitivity analyses performed. The selection rule (or decision method) used. Recommended alternative and associated risks. Revisions to baselines for functional, physical, and operational concepts as a result of analysis. 4.1.13.8 Exit criteria Completely document the recommended solution with the associated analysis. 4.1.13.9 Measurement7 The table at the top of the following page provides example base and derived measures that can be used in conjunction with executing the System Analysis process. See discussion of Measurement on page 4-1. Each of the system analyses may have cost and schedule measures associated with planning and performing the analyses as well as progress measures with respect to completion of the analyses. Each type of analysis will also have specific technical measures related to the topic under analysis.

4-59

Project Management: SE & Project Control Processes & Requirements

Base Measures Planned Analysis Cost Planned Analysis Schedule Planned # of Alternatives

Derived Measures Planned Analysis Cost vs. Actual Cost Planned Analysis Schedule vs. Actual Schedule Planned # of Alternatives vs. Actual #

4.1.13.10 Methods and techniques2,3,7 The following are the methods and techniques used by the System Analysis process: Methods Tradeoff analysis Effectiveness analysis Cost effectiveness Total ownership cost Environmental impacts System effectiveness Risk analysis (technical, schedule, and cost) Functional analysis Decision analysis methods (e.g., analytic hierarchy process, etc.) Techniques Physical Modeling Wind tunnel model, mockup, engineering model, breadboard model, thermal model, acoustic model Virtual Modeling Graphical Modeling Functional flowcharts, behavior diagrams, timeline charts, N2 dia grams, PERT charts, logic trees, document trees, waterfall charts, floor plans, schematics, representative drawings, topographical representations, drawings of systems or components, QFD Mathematical Modeling Dynamic motion models, structural analysis, thermal analysis, vibration analysis, electrical analysis, finite elements, linear programming, cost modeling, network or nodal analysis, decision analysis, flow field studies, hydro-dynamics studies, control systems modeling, workflow analysis, reliability and availability models, human reliability analysis, maintainability analysis, process models, entity relationship models Statistical Modeling Monte Carlo, logistical support, process modeling, manufacturing layout modeling, sequence estimation modeling, discrete, continuous

4.1.13.11 Software tools7 Many S/W tools are available to support the System Analysis process. These include typical spreadsheet, database, and drawing tools for visualization, imaging, and analysis with commercial products available from many vendors. Also available are specialized tools for graphical modeling, mathematical modeling, and statistical modeling. For cost estimating and analysis, see the JSC Cost Estimating Web page at www.jsc.nasa.gov/bu2/. For an extensive listing of commercially available systems analysis tools, see the table that has been provided by INCOSE at www.incose.org/tools/eia632tax/eia632top.html. This table lists tools that support the System Analysis process requirements of EIA-632.2 4.1.13.12 References The following documents and Web site, which were used to prepare this section, offer additional insights into the System Analysis process: 1 NPR 71xx.x (document number not yet assigned), NASA Systems Engineering Processes and Requirements . 2 EIA-632, Processes for Engineering a System, ANSI/EIA -632-1998, 1999.
3

SP 6105, NASA Systems Engineering Handbook , 1995. 4 CMMI-SE/SW/IPPD/SS V1.1, Capability Maturity Model Integration (CMMI) for Systems Engineering, Software Engineering, Integrated Product and Process Development, and Supplier Sourcing, 2002. 5 NPR 7120.5B, NASA Program and Project Management Processes and Requirements, 2002.
6

EIA-731.1, Systems Engineering Capability Model, 2002. 7 INCOSE Systems Engineering Handbook , Version 2.0, 2000. 8 System Engineering Fundamentals, Defense Systems Management College, 2001.
9

JSC Cost Estimating Web page: www.jsc.nasa.gov/bu2/.

4-60

Project Management Processes and Requirements

4.1.14 Verification1,2 Verification is the methodical development of evidence of system of interest compliance with requirements (shalls). It is accomplished at each level of the system architectural hierarchy. 4.1.14.1 Function1,3 The system Verification process is used to ascertain that end items at each level of the system architecture, from the bottom up, meet specified requirements. In the Verification process: Verification methods (i.e., test, analysis, inspection, and/or demonstration) shall be developed and documented to identify how each requirement is met. Verification planning information shall be documented to described the detailed processes that will ensure the system of interest complies with its requirements. Verification success criteria shall be defined and documented that will indicate successful completion of each verification process. The method for submitting, reviewing, and tracking the results of the verification processes shall be defined and documented. Verification shall be performed and documented on each part of the system of interest at each level of the architecture hierarchy from the bottom to the top. 4.1.14.2 Objective The Verification process is performed to determine that the system of interest complies with requirements . 4.1.14.3 Responsibilities The Lead Systems Engineer reviews verification plans, ensures end-to-end verification is performed, reviews results as to adequacy and compliance, and recommends needs for retest or redesign.
Reqmt. No. Document Paragraph Shall Verification Verification of Origin Statement Success Method Quotation Criteria 1. System locks to forward link System at min./max. 3.2.1.1 shall pro- data rate Capability: vide a tolerance. JSC-nnnn support maximum 2. System Uplinked ground-to- locks forData station ward link at uplink the min. and max. operating frequency tolerances.

The Verification Lead ensures that requirements are verifiable, develops a verification plan, identifies most effective verification methods and verification criteria, and coordinates activities with verification facilities, participants, and other team members. The Verification Lead also executes the verification plan, develops or coordinates procedures, collects and documents results, and evaluates results for compliance or need for re -verification. The Test Operations Lead assures that the required test facilities have been verified to provide necessary conditions and have been scheduled and are available. The Project Manager assesses the verification plan, reviews results, determines the need for redesign, negotiates access to external facilities or resources, and reviews results with the customer. Also, the Project Manager assigns responsibility for resolution of unsuccessful verification activities and manages closure of discrepancy reports. 4.1.14.4 Life cycle Verification-related activity of some kind is usually in progress during all phases through the System Acceptance Review (SAR), with conceptual planning documentation required as early as the Concept Review (CR). Execution usually concludes by the SAR. However, for some systems verification continues by exception later in Phase D, Development, prior to launch, and even during Phase E, Operations (i.e., orbital testing). 4.1.14.5 Inputs The Verification process is principally tracked by means of a verification matrix. This matrix is the project record of the identity, performance, and outcome of the verification activity for each of the system shall requirements from all project requirement documents. It is used first to capture the plan for the verification, and it is then used to summarize results for the record. The table below illustrates the headings and one entry of such a matrix.
Facility or Lab ID Phase Acceptance Preflight Performing Requirement? Acceptance? Org. Results

P-1

Test

Electronic Systems Test Lab (ESTL)

[Is this 5 [Code for requirement formal sys- also verified tem-level during initial functional acceptance phase] testing of each unit?]

[Is this requirement also verified during any preflight or recurring acceptance testing of each unit?]

JSC/EV

Report nnn (indicates documents that contain objective evidence that the requirement was satisfied)

4-61

Project Management: SE & Project Control Processes & Requirements

The following should be inputs to the process of creating the verification matrix, both from the perspective of aggregating the shall requirements and from the perspective of understanding the environment surrounding those requirements. Concept of operations documentation Mission needs and goals Requirements and specifications ICDs Testing standards and policies Agency standards and policies 4.1.14.6 Steps The following diagram (FIG. 4.1-14) illustrates the major steps and products of the Verification process. The three major steps are (1) prepare for verification, (2) perform verification, and (3) analyze and document results. These steps are progressively and iteratively executed until the complete system is verified for all requirements.
Define & Document Verification Method(s), Verification Environment

inspection based on their ability to prove that the system meets its requirements. Develop the operational scenario, environment, or constraints for the verification activity and base these on a set of requirements to be verified. Verification criteria are established and documented. Verification criteria are approved by customers and S&MA. Procedures are developed for the verification activity and are approved by quality engineering. Project Shall Perform Verification Activity The verification activity is configured as appropriate to reflect the selected environment. H/W is configured, S/W is loaded, models are set up, tools are tested, and simulations are established as appropriate.

Prepare for Verification

Select Product for Verification

Develop & Document Verification Success Criteria

Establish & Document Verification Procedures & Plans

Verification Procedures & Plans Perform Verification Procedure Address Design Issues Analyze and Document Results Evaluate Results Against Criteria Record results (data or observations) Verification Procedure Results

Perform Verification

Configure or Model System

No OK to proceed? Yes Document results, analysis, and decisions Report of verification results, analysis, and decisions

KEY

Step/Activity

Information/Product

Information Flows/Output Flows

Decision

Figure 4.1-14. Verification process diagram. Project Shall Prepare for Verification Select system or subsystem components that are to be verified and the verification methods that will be used for each. The method is selected from test, analysis, demonstration, or The verification activity is performed and witnessed by QA. Quantitative results from the test, analysis, inspection, or demonstration activity are recorded as appropriate.

4-62

Project Management Processes and Requirements

Discrepancies should be documented via discrepancy reports. Project Shall Analyze and Document Results Data resulting from the verification activity are analyzed against defined verification criteria. Results of this analysis are used to determine whether the product at this point in the life cycle meets the requirements or fails to meet the requirements, resulting in a need for either a waiver or a decision on whether a modification to the design is warranted. All verification results, analyses, and conclusions concerning product adequacy are documented. 4.1.14.7 Outputs The ultimate need is for documentation of objective evidence that all shall requirements have been verified. The following outputs support fulfillment of that need: Verification plans Completed verification requirements matrix Verification results and analysis Verification procedures Test, demonstration, inspection, and analysis reports Waivers Discrepancy reports and descriptions of their closures 4.1.14.8 Exit criteria Process exit criteria include: Objective evidence of compliance or waiver of each system of interest shall requirements shall be documented. Base Measures Total # of Shall Requirements Total # of Shall Requirements Verified To Date Total # of Shall Requirements Complied With Total # of Shall Requirements Waivered Total # of Shall Requirements Re-verified Total Verification Effort (FTEs)

The verification process shall not be considered or designated as complete until all discrepancy reports are closed. 4.1.14.9 Measurement The table at the bottom of the pages provides example base and derived measures that can be used in conjunction with executing the Verification process. See discussion of Measurement on page 4-1. 4.1.14.10 Methods and techniques Verification may be accomplished by a number of techniques and methods that can be categorized as tests, analyses, inspections, and/or demonstrations. The following definitions are offered not to constrain verification planning with narrow a priori identities, but to stimulate ideas for planning, documenting, and employing the specific approaches that will be used in any given project to prove the fidelity of project unique designs and products to original requirements. Test A method of verification wherein formal project requirements are verified by measurement or functional test during or after the controlled application of functional and/or environmental stimuli. These measurements may require the use of laboratory equipment, recorded data, procedures, test support items, or specialized S/W. Analysis A verification method using techniques and tools such as math models, prior test data, simulations, analytical assessments, etc. Verification by similarity is acceptable if the subject article is similar or identical in design, manufacturer, manufacturing process, and quality control to another article that has been

Derived Measures

Total # of Shall Requirements Verified To Date vs. Total # of Shall Requirements, % Total # of Shall Requirements Complied With vs. Total # of Shall Requirements, % Total # of Shall Requirements Waivered vs. Total # of Shall Requirements, % Re-verifications vs. Total Shall Requirements Verified, % Verification Rates Verification Productivity

# of Major Verifications (above specific dollar or hour level)

# of Major Verifications vs. Total # of Shall Requirements Verified To Date

4-63

Project Management: SE & Project Control Processes & Requirements

previously verified to equivalent or more stringent criteria. Inspection A method of verification of physical characteristics that determines compliance using only vision and visible-spectrum optics (microscopes, fiberscopes, etc.) Demonstration A method of verification that evaluates the integrated properties of the subject end item by staging a loosely controlled operational scenario based on the operations concept. Demonstration participants are user-oriented; i.e., they interface with the subject and item primarily to employ it as fully as possible to meet user needs in that situation, with little emphasis on accommodating limitations of the item other than safety considerations. Demonstration can be conducted with or without special test equipment or instrumentation to verify required operational characteristics such as endurance, ruggedness, human engineering features, service and access features, transportability, and displayed data. 4.1.14.11 Software tools A S/W tool intended to support verification management should possess the ability to track the identity, origin, verification, method, facility, success criteria, and current degree of fulfillment of each requirement. For large or complex projects, COTS requirements management tools (e.g., DOORS and SLATE) usually include features that can convert requirements loaded in them into verification matrices with required elements of information. INCOSE offers an excerpt from an S/W productivity solutions review of such tools at: http://wwww.incose.org/tools/reqsmgmt.html . For small or simple projects, word processor or spreadsheet S/W is often adequate for manual tracking or building an elementary custom tool. 4.1.14.12 References The following documents, which were used to prepare this section, offer additional insights into the Verification process: 1 NPR 71xx.x (document number not yet assigned), NASA Systems Engineering Processes and Requirements .
2

93-C-0123). Prepared for Rome Laboratory, Air Force Materiel Command C3CB 525 Brooks Rd. Griffiss AFB, NY 13441, by Software Productivity Solutions, Inc., 122 4th Ave., Indalantic, FL 32903. 5 CMMI-SE/SW/IPPD/SS V1.1, Capability Maturity Model Integration (CMMI) for Systems Engineering, Software Engineering, Integrated Product and Process Development, and Supplier Sourcing, 2002.

NPR 7120.5B, NASA Program and Project Management Processes and Requirements, 2002. 3 EIA-632, Processes for Engineering a System, ANSI/EIA -632-1998, 1999. 4 Analysis of Automated Requirements Management Capabilities. Developed in support of Advanced System Engineering Automation (ASEA) CSC-2.7 Requirements/Design Manager (Contract no. F30602-

4-64

Project Management Processes and Requirements

4.1.15 Validation1,2 While verification proves whether the system was done right, validation proves whether the right system was done. That is, verification provides objective evidence that every shall was met, whereas validation is performed for the benefit of the customers and users to ensure that the system functions in the expected manner when placed in the intended environment. This is achieved by examining the products of the system at every architectural level. 4.1.15.1 Function1,2 Validation is performed on system of interest and subsystem products. The Validation process is conducted to ensure that system and subsystem products are ready for the uses, functions, and missions implied or suggested by both the requirements and any other relevant project or program information. In the Validation process: Validation method(s) (i.e., test, analysis, inspection, and/or demonstration) shall be defined and documented. Validation planning information shall be developed and documented to describe the processes that will ensure the system of interest will meet customer needs. Validation success criteria shall be defined and documented that will indicate successful completion of each Validation process. The methods for submitting, reviewing, and tracking the results of the Validation process shall be defined and documented. Validation shall be conducted and documented on each part of the system of interest at each level of the architecture hierarchy, from the bottom to the top. 4.1.15.2 Objective Validation is performed to determine whether customer needs can be met in the context of the expected operational scenarios of the system of interest. 4.1.15.3 Responsibilities The Lead Systems Engineer works with customers and users to identify desired validation activities, reviews the validation plan, ensures end-to-end validation is performed, and reviews results to determine adequacy. Validation Product #
1

The Validation Lead develops the validation plan, identifies the most effective validation method, and coordinates activities with validation facilities, participants, and other team members. The Validation Lead also executes the validation plan, develops procedures, and collects and documents results. The Project Manager assesses the validation plan, negotiates access to external facilities or resources, assigns responsibility for resolution of unsuccessful validation activities, and manages closure of issues and actions. 4.1.15.4 Life cycle Validation-related activity is usually in progress during all phases through the SAR, with conceptual planning documentation required as early as the PDR. Although execution usually concludes by the SAR, for some systems validation continues by exception later in Phase D, Development, prior to launch, and even during Phase E, Operations (i.e., orbital testing). 4.1.15.5 Inputs The Validation process is principally tracked by means of a validation matrix. This matrix which is the project record of the identity, performance, and outcome of each validation activity is used first to capture the plan for validation and then to summarize plan results for the record. The table at the bottom of the page illustrates the headings and one entry of such a matrix. The following should be inputs to the process of creating the validation matrix, both from the perspective of aggregating implied or suggested customer expectations beyond the shall requirements, and from the perspective of understanding the environment surrounding those needs: Concept of operations documentation Mission needs and goals Requirements and specifications ICDs Testing standards and policies Agency standards and policies 4.1.15.6 Steps3 Figure 4.1-15 illustrates the major steps and products of the Validation process. The major steps are to (1) prepare for validation, (2) perform validation, and (3) analyze and document results. These Facility or Lab ID
ESTL

Activity
The customer/ sponsor will evaluate the candidate displays

Objective
1. Ensure legibility is acceptance. 2. Ensure overall appearance is acceptable.

Method

Phase
1 [this number is code for During product selection process]

Performing Org.
JSC/EV

Results
Customer asserts that displays are both legible and acceptable overall.

Demonstration

4-65

Project Management: SE & Project Control Processes & Requirements

Prepare for Validation

Select Product for Validation

Define & Document Validation Method(s), Validation Environment

Develop & Document Validation Success Criteria

Establish & Document Validation Procedures & Plans

Validation Procedures & Plans

Perform Validation

Configure or Model System Address Design Issues

Perform Validation Procedures

Record Results (Data or Observation)

Validation Procedure Report

No OK to Proceed? Yes Document Results, Analysis, and Decisions Report of Validation Results, Analysis, and Decisions

Analyze and Document Results

Evaluate Results Against Criteria

KEY

Step/Activity

Product

Information/Output Flows

Decision

Figure 4.1-15. Validation process diagram. steps are progressively and iteratively executed until the complete system is validated for all expected environments. Project Shall Prepare for Validation Select system or subsystem components to be validated and the validation methods that will be used for each. The method is selected from test, analysis, demonstration, or inspection and is based on the ability of the system or subsystem components to prove that the user and customer needs are satisfied. Develop the operational scenario, environment, or constraints for the validation activity, and base these on customer and user needs and expectations. Ensure validation criteria are established and agreed to by users and customers. Develop and document procedures for the validation activity. Ensure that quality engineering approves procedures for the validation activity. Project Shall Perform the Validation Activity The validation activity is configured as appropriate to reflect the selected environment. H/W is configured, S/W is loaded, models are set up, tools are tested, and simulations are established as appropriate. The validation activity is performed and witnessed by QA, preferably with observation or participation by customer and users. Results of the validation activity are recorded as appropriate. User and customer subjective reactions to the activity are noted as are quantitative results from the test, analysis, inspection, or demonstration. Issues and actions arising from validation activity should be documented and tracked. Project Shall Analyze and Document Results Data resulting from the validation activity are analyzed against the defined validation criteria. Results of the analysis are used to determine whether the product at this point in the life cycle meets customer and user needs and expectations, or whether a modification to the design is warranted. All validation results, analysis, and conclusions as to product adequacy are documented. 4.1.15.7 Outputs The ultimate need is for documentation of objective evidence that shows all implied or suggested customer expectations have been validated. The following outputs support fulfillment of that need:

4-66

Project Management Processes and Requirements

Validation plans and procedures Validation evaluation results, including issues and actions found and descriptions of their resolution 4.1.15.8 Exit criteria Exit criteria for this process include: Objective evidence of performance and results of each system of interest validation activity shall be documented. The validation process shall not be considered or designated as complete until all issues and actions are resolved. 4.1.15.9 Measurement The following table provides example base and derived measures that can be used in conjunction with executing the Validation process. See discussion of Measurement on page 4-1: Base Measures Total # of Validation Products Total # of Project Changes Caused by Validation Total Validation Effort (FTEs)

ufacturer, manufacturing process, and quality control to another article that has been previously verified or validated to equivalent or more stringent criteria. Inspection A method of confirmation of physical characteristics that determines compliance using only vision and visible spectrum optics (microscopes, fiberscopes, etc.). Demonstration A qualitative method of validation that evaluates the integrated properties of the subject end item by staging a loosely controlled operational scenario based on operations concept. Demonstration participants are useroriented; i.e., they interface with the subject end item primarily to use it as fully as possible to meet user needs in that situation, with little emphasis on accommodating limitations of the item other than safety considerations. Derived Measures

Total # of Project Changes Caused by Validation vs. Total # of Project Changes, % Validation Rates Validation Productivity

# of Major Validation Products (above specific dollar or hour level) 4.1.15.10 Methods and techniques Validation may be accomplished by a number of techniques and methods that can be categorized as tests, analyses, inspections, and/or demonstrations. The following definitions are offered not to constrain validation planning with narrow a priori identities, but to stimulate ideas for planning, documenting, and employing specific approaches that will be used in any given project to examine whether system of interest products will satisfy the customer: Test A method of validation wherein requirements (performance, environment, etc.) are proven by measurement or functional test during or after the controlled application of functional and/or environmental stimuli. These measurements may require the use of laboratory equipment, recorded data, procedures, test support items, or specialized S/W. Analysis A validation method using techniques and tools such as math models, prior test data, simulations, analytical assessments, etc. Validation by similarity is acceptable if the subject article is similar to or identical in design, manDemonstrations can be conducted with or without special test equipment or instrumentation to validate implied customer expectations beyond shall requirements. 4.1.15.11 Software tools An S/W tool intended to support validation management should possess the ability to track the identity, objective, validation, method, facility, phase, performing organization, and results of each activity. For large or complex projects, COTS requirements management tools (e.g., DOORS and SLATE) usually include features that can convert the requirements loaded into them into verification matrices with the required elements of information. This feature can also be used in the same manner to produce validation matrices. INCOSE offers an excerpt from an S/W productivity solutions review of such tools at: http://www.incose.org/tools/reqsmgmt.html. For small or simple projects, word processor or spreadsheet S/W is often adequate for manual tracking or building an elementary custom tool.

4-67

Project Management: SE & Project Control Processes & Requirements

4.1.15.12 References The following documents, which were used to prepare this section, offer additional insights into the Validation process: 1 EIA-632, Processes for Engineering a System, ANSI/EIA -632-1998, 1999. 2 NPR 71xx.x (document number not yet assigned), NASA Systems Engineering Processes and Requirements.
3

NPR 7120.5B, NASA Program and Project Management Processes and Requirements, 2002.
5

CMMI-SE/SW/IPPD/SS V1.1, Capability Maturity Model Integration (CMMI) for Systems Engineering, Software Engineering, Integrated Product and Process Development, and Supplier Sourcing, 2002.

Analysis of Automated Requirements Management Capabilities. Developed in support of ASEA CSC2.7 Requirements/Design Manager (Contract No. F30602-93-C-0123). Prepared for Rome Laboratory, Air Force Materiel Command C3CB 525 Brooks Rd. Griffiss AFB, NY 13441, by Software Productivity Solutions, Inc., 122 4th Ave. Indalantic, FL 32903.

4-68

Project Management Processes and Requirements

4.1.16 Reviews1 Several types of reviews are used in the project management environment, each with its own purpose. Reviews generally fall into three major categories: programmatic reviews, external reviews, and technical reviews. Programmatic reviews, such as the Engineering Review Board and the Project Management Council reviews, are used to maintain broad governance over project processes. External reviews, such as non-advocate reviews and independent assessments, provide insight on the health of specific technical and managerial areas of projects from nonaffiliated expert authorities. This section deals with project technical reviews. The technical Reviews process is executed to establish an assessment of the system of interest status. This status is then used to determine readiness to proceed through a progressive maturation of processes to develop the final system of interest. Technical reviews required in support of the project life cycle are detailed in Chapter 3. 4.1.16.1 Function1,2 Reviews are conducted to communicate an approach, demonstrate an ability to meet requirements, or establish status. Reviews help to develop a better understanding among project participants, open and maintain communication channels, alert participants and management to problems, and open avenues for solutions. In the Reviews process: The purpose, scope, and entry/exit criteria for conducting the review shall be established. The technical products to be assessed, as part of the specified review, shall be identified. A technical assessment of the review products shall be conducted, and issues shall be documented and tracked to closure. Customer and stakeholders participation and role(s) in the review shall be established. Objective evidence that the review objectives are met shall be documented. 4.1.16.2 Objective 2 The purpose of a review is to furnish the forum and process through which to provide NASA management and their contractors assurance that the most satisfactory approaches, plans, or designs have been selected, that configuration items have been produced to meet specified requirements, or that configuration items are ready. 4.1.16.3 Responsibilities The Convening Authority is responsible for initiating major milestone project technical reviews. The PMP identifies the convening authority, which may be

review-dependent. Typically, in the case of an institutional support project, the Convening Authority resides within the project program or line management. The Project Manager is responsible for working with the convening authority to ensure technical reviews occur at the proper project level of maturity. In addition, the Project Manager ensures findings of the review panel/board are properly addressed to enable management decisions allowing project life cycle progression. The Lead Systems Engineer is responsible for facilitating the Reviews process and ensuring communication of project technical status to review participants. 4.1.16.4 Life cycle2 Typical reviews are found in or at the end of all project life cycle phases. 4.1.16.5 Inputs2 Reviews process input consists of a project with associated products possessing maturity that are consistent with the established review entry criteria. 4.1.16.6 Steps2 As with inputs and outputs, the specific steps of each review are unique. However, the general way of doing business for reviews is fairly consisted, as shown in Figure 4.1-16 at the top of the next page. Establish the Review The review convening authority, in coordination with the project manager, shall establish and document initial guidance as follows: Purpose Scope Entry and exit criteria Verify Entry Criteria Are Met The convening authority, in coordination with the project manager, shall determine whether requisite life cycle steps have been taken and documents, H/W, S/W, and other items that are to be examined possess maturity consistent with review entry criteria. Appoint Review Board/Panel members and Chair and Establish Participant Roles The convening authority shall appoint the members. Avoid appointing persons involved with the project as chair or as majority makeup of members. Highly Recommended In addition to board appointments, invite a review audience that includes both NASA and contractor personnel who are not directly associated with the project. This: Uses cross-discipline expertise.

4-69

Project Management: SE & Project Control Processes & Requirements

Agency/Center Guidelines & Requirements

KEY

Step/Activity

Verify That Entry Criteria Are Met Appoint Review Board/Panel Members & Chair Establish Review Participant Roles Project Team Customer Other Stakeholders Establish Review Ground Rules Publish Review Meeting Agenda Identify Technical Products to Assess Process(es) Describe CR & Action Item Disposition Conduct Technical Assessment Review Technical Products Hold Review Meeting Verify Whether Exit Criteria Are Met Document Evidence That Review Objectives Are or Are Not Met Information/ Information/Output Flows Product

Establish the Review Purpose Scope Entry/Exit Criteria

Review Report

Figure 4.1-16. Reviews process diagram. Helps to identify design shortfalls and recommend design improvements. Should include non-project specialists in the area under review, production/fabrication, testing, QA, reliability, and safety. If indicated, both contractor and NASA contracting officers should be included. The convening authority shall delineate roles and responsibilities for all participants, including: Project team Customer Other stakeholders Establish Review Ground Rules The chair shall publish and assure the availability of the: Agenda of the review meeting. Technical products to be assessed by the review, including all applicable documents necessary to support the review. Process for dispositioning requests for action and change requests. Conduct Technical Assessment Review Technical Products Copies of prepared materials (e.g., presentation charts) should be provided to the review board and meeting attendees in advance of the review meeting. For major reviews, this could be as far in advance as 30 calendar days. Specifications, drawings, analysis reports, and any other documents/technical products capturing the approaches, plans, and designs to be reviewed should be included. Board members and attendees may submit requests for action or change requests (CRs) in advance of the meeting that document a concern, deficiency, or recommended improvement in the presented approaches, plans, or designs. Hold the Review Meeting ? Conduct Oral Presentations with Cognizant Subsystem Engineers to: Explain applicable project requirements. Describe approaches, plans, or designs devised to date to satisfy requirements. Propose dispositions of CRs and action items submitted prior to the meeting to the chair.

4-70

Project Management Processes and Requirements

Describe documentation/technicalproduct maturity. Request Baselining of completed documentation/technical products that require CM. Continue Change/Action Traffic Board members and attendees may continue to submit requests for action or CRs at the meeting. Formulate and Record Decisions After developing consensus among members, the chair declares and records:* Dispositions of CRs and action items submitted both prior to and during the meeting. Either that the appropriate approaches, plans, or designs briefed at the meeting or submitted out-of-board are accepted and that the next steps of the project are authorized; or that there are issues with these items, and enunciates those issues and assigns appropriate action items for the record. Either that completed documents/technical products capturing the accepted approaches, plans, or designs are baselined and are to be taken under CM to support subsequent project action; or that there are issues with these items, and enunciates those issues and assigns appropriate action items for the record. Verify Whether Exit Criteria Are Met The board chair: Finalizes consensus on the findings of the board shortly following the review meeting, including: Recommendation for or against proceeding with subsequent project life cycle steps Products baselined Changes accepted, rejected, modified, and withdrawn

Actions assigned and the persons responsible for them All open issues and plans for closing them Risks from problem areas Decides, based on established review exit criteria, whether exit criteria have been met. Document Evidence That Review Objectives Are/Are Not Met The chair shall submit a written report to the convening authority capturing all of the above findings. 4.1.16.7 Outputs The output of the Reviews process consists of documented evidence produced by the review chair. This evidence addresses the results of the review, including the recommendation as to whether the project has or has not met the established review exit criteria. Characteristic output for individual technical reviews are listed in SP 6105.2 4.1.16.8 Exit criteria2 The Reviews process exit criteria shall consist of documentation that states that the review criteria have been met. 4.1.16.9 Measurement The table at the bottom of the page provides example base and derived measures that can be used in conjunction with executing the Reviews process. See discussion of Measurement on page 4-1. 4.1.16.10 Methods and techniques Methods and techniques useful and necessary to be used during the Reviews process include: Effective Communication Effective communication will be necessary to ensure that current project status is effectively conveyed to review board members and that all review participant inputs and concerns are effectively transmitted to the project team and, ultimately, to the convening authority.

Base Measures Duration of the Review Review Effort (FTEs)

Derived Measures Duration of the Review, Planned vs. Actuals Review Effort, Planned vs. Actuals

For most reviews, the chair is supported by CM and other administrative resources in taking notes, generating minutes, tracking action items and CRs, and tracking products under configuration control.

4-71

Project Management: SE & Project Control Processes & Requirements

Configuration Management This will be used to manage review of products and to ensure all concerns are captured and addressed. Review Checklists These are used to summarize items such as desired composition of the review team, lists of support technical documentation, standard entry/exit criteria, etc. Templates These are used to document the review plans, comments, reports, etc. 4.1.16.11 Software tools Tools available to support the Reviews process include a variety to enhance communications and maintain configuration control throughout the Re-

views process; including accessibility of review products to review participants, and generation and tracking of review comments and discrepancies to closure. 4.1.16.12 References The following documents, which were used to prepare this section, offer additional insights into the Reviews process:
1

NPR 71xx.x (document number not yet assigned), NASA Systems Engineering Processes and Requirements. 2 SP 6105, NASA Systems Engineering Handbook , 1995.

4-72

Project Management Processes

4.2 Project Control Processes The objective of the project control processes section of this document is to clearly re-define the scope of project control. Only after the proper scope of the project control function is clearly defined and agreed to can the issues of organization responsibility and assignment be addressed. It should be emphasized that project control is not a collection of independent, stand-alone functions. It is instead a process that requires the integration of all of its functions to derive benefits for effective project management. This section of the document presents a project control model for the various functions, practices, and processes that are essential in supporting the successful management of NASA JSC projects. Sound project control practices over the years have contributed to the remarkable accomplishments attained by our Agency and our Center. JSC Project control activities have four significant and key characteristics. These are to: 1. Continually focus project management attention on areas critical to successful project execution. (Focus on what is important.) 2. Establish and document a project baseline, including: A project requirements list. A project schedule consisting of significant project-level milestones. An interconnected, sequential network of tasks required to complete the project (through retirement). A time-phased life cycle cost (LCC) estimate achieved by resource loading (e.g., costs for facility, workforce, materials, other direct costs (ODCs), and indirect costs) of the project network. 3. Emphasize timely responses. 4. Provide a closed-loop system for measurement and analysis of the project that: Provides a common method for defining, collecting, analyzing, and reporting measurements . Provides guidance and requirements for identifying and managing measurement data. Is a useful tool for assessing progress, product, and process performance. Measurement and analysis is an integral part of project planning, project estimating, project management, and continuous improvement and spans the entire life cycle of a project. It supports the identification, collection, analysis, and reporting of three measurement types: Progress, Product, and Process. Progress measures are used to help work groups that build products assess the groups performance against project goals. Product measures are used to ensure that defects are found early in the development life cycle, resulting in reduced risk and cost.

Process measures are used to ensure processes meet customer expectations and are properly implemented. Proactive use of these measurement types enables managers to identify and monitor trends; determine potential cost, schedule, and performance impacts; analyze and prioritize risks and opportunities; and propose corrective action to minimize or eliminate risks through integrated schedules and/or project plan revisions. 4.2.1 Resource Management1,2,3 4.2.1.1 Function Resource Management plans and develops an integrated process that involves the preparation, review, and maintenance of project resource needs. It is responsible for reviewing, analyzing, and interpreting data in a timely manner to effectively support project implementation in support of the NASA Strategic Plan and associated Center roles and missions. A major responsibility of Resource Management is to define and lead the business process to ensure project success through the budget formulation and execution process. It also assesses the political environment, performs requirement analysis, performs metric analysis, and develops resource strategies to facilitate the project and Center budget process and schedules. The Resource Management process will be able to rapidly respond to both internal and external inquiries during the entire budget formulation cycle of the project. The Resources Management function shall: Ensure that all project needs are adequately covered and properly time phased in the budget submission and significant resource issues are identified during the POP process. Monitor cost performance on an ongoing basis by conducting plan vs. actual cost assessments and related analyses. Ensure that the flow of funds is being planned, expedited, tracked, and analyzed to guarantee timely use of project resources. Make sure that the data and information provided to the project management team is timely and accurate. Recognize and quantify risks and uncertainties by allowing for adequate reserves and allowances. The recognition of uncertainties and quantification of risks are vital to the success of any project; and having contingency funds with a judicious process for allocating them is an essential element for managing projects, especially in the research and development (R&D) environment. Resolve and defend unforeseen funding requirements Be available to advise project managers in all aspects of this critical project control function.

4-73

Project Management: SE & Project Control Processes & Requirements

A key product of the Resources Management function comprises formulating, monitoring, and maintaining a funding needs profile, including such drivers as facilities and labor requirements. Because labor drives a significant portion of development costs, keeping abreast of the status and trends in this area is critical. The project budget profile, established late in the Phase A effort to be consistent with the cost, schedule, and technical baseline of the project, will be main tained reflecting only the impact of changed project scope or schedule. In contrast, the project funding requirements will be continually updated to reflect the latest assessment of resource needs and incorporated in the POP process. A primary value of the cost collection effort in the resource management function is to predict future performance indications and to contribute to project managements decision-making process. The Resource Management process relies heavily on project performance measurement efforts, which integrate the development and maintenance of the cost, schedule, and technical baseline of the project. 4.2.1.2 Objective The objective of resource management is to establish and ensure consistency between resource availability and project resource needs. 4.2.1.3 Responsibilities The Project Control Officer is responsible for all aspects of the Resource Management process, including notifying the Project Team of when and what data are required, coordinating with any project-external organizations, ensuring timely project-internal review of the final product, and delivering the final product. Other participants in this process include the: Project Manager, who is responsible for ensuring the Project Control Officer has the facilities and workforce needed to accomplish this task. The Project Manager also acts as a customer to the Project Control Officer for this process. Entire Project Team, which also participates in this process by providing data, supporting rationale, and recommendations for improvement. 4.2.1.4 Life cycle Resource management begins in Phase A and is conducted throughout the life cycle of the project. 4.2.1.5 Inputs Inputs to the Resource Management process include: Civil service labor costs (planned) Civil service labor costs (actual) Contractor labor costs (planned) Contractor labor costs (actual) Facility costs (planned)

Facility costs (actual) Material costs (planned) Material costs (actual) 4.2.1.6 Steps Resources Management activities are initiated by the program operating plan (POP) process, as discussed in Section 2.8.3 and as described fully in LA-CWI-01, Budget Planning Process. The project manager shall prepare a POP in conformance with instructions and guidance provided by the Center Chief Financial Officer (CFO). The CFO is responsi ble for the POP process. Guidance for developing the POP is provided in the Center POP Call issued under signature of the CFO. In addition, common work in struction LA-CWI-01 documents the POP process at JSC. It is critical that the POP submission realistically project the cost required to proceed according to the project management plan (PMP). The project POP should also identify any over-guidelines require ments and associated impact statements assessing the risk to the technical performance of project schedules due to lack of required funds. The project manager should structure the POP submittal to minimize the risk associated with normal fluctuations in available funding as a result of the authorization, appropriation, and apportionment process or any delays. The project manager should also include a projection of the total LCC of the project. These steps are illustrated in Figure 4.2-1 at the top of the following page. 4.2.1.7 Outputs Outputs to the Resource Management process include: Annual project budget submissions (funding requirements) Completed POP (time-phased estimation to complete (ETC) by phase and to completion) Workforce forecasts (by phase and to completion) Cost forecasts (by phase and to completion) 4.2.1.8 Exit criteria The exit criterion for the Resource Management process is a completed work breakdown structure (WBS). 4.2.1.9 Measurement The following table provides example measures that can be used in conjunction with executing the Resource Management process. See discussion of Measurement on page 4-1. 4.2.1.10 Methods and techniques The methods and techniques that may be used in developing requirements are:

4-74

Project Management Processes

Define and document resource management plan including strategy, processes (including POP schedules), and procedures including reserves management ap proach and process metrics

Complete project resource needs by WBS

Check to ensure resource projections are realistic, accurate, and cover entire project scope and life cycles

Identify potential reserves level(s) Potential reserves level(s) approved by project manager

Review project resource needs and phasing, and identify potential issues (e.g., proper resource phasing for contracts, workforce, and facility support schedules, etc.), and mitigation plans

Document project resource budget, obligation, and cost plan (including phasing) i.e., POP

Project manager approves POP

Submit to Center/program POP call Project operating plan

New budget required per annual POP schedule

(budget) approved)

Modify resource management plan accordingly

Yes
Implement?

Project review of new performance/ process metric indicators

Identify potential metric indicators to identify this problem in future

Analyze issue including root cause and potential additional resource impact in future

Yes

Issue identified?

Reanalyze POP and process metrics on a monthly basis; identify process/ progress issues Form 533 inputs, if applicable

No

No
Develop monthly status reporting including potential issues

Figure 4.2-1. Resource management process diagram. Base Measures Total # of internal task agreements (ITAs) developed Total $ value of all ITAs (in full cost) Support contractor total $ value of contract Total # of civil servants on project Total # of contractors on project % of WBS development complete Total material costs (planned vs. actual), if not already captured in ITA Management reserve remaining ($) Purchase request (PR) tracking log Resource (workforce, cost, etc.) histogram Individual or group expert judgment Statistical analysis of historical data JSC SLP 4.20, Process Measurement and Improvement Contractor financial reporting systems for contractor-supported/NASA-managed projects 4.2.1.11 Software tools The two principal considerations for a tool that would support the Resource Management process are (1) the consistent, concise, and thorough documentation of the project funding status; and (2) common and convenient accessibility and visibility to all project team members and stakeholders. The following S/W tools satisfy these considerations: Excel Microsoft PowerPoint 4.2.1.12 References The following documents, which were used to prepare this section, offer additional insights into the Resource Management process: 1 SP 6103, NASA Readings in Project Control, 1994. 2 NPR 7120.5B, NASA Program and Project Management Processes and Requirements, 2002. 3 Full Cost Initiative Agencywide Implementation Guide: http://ifmp.nasa.gov/codeb/library/fcimplementation.pdf. Derived Measures Time to complete each ITA, from draft to final signature Average time for all ITAs to be completed, with final signature ITA $ costed to date (in full cost) Monthly ITA $ costed to date (planned vs. actual) Support contractor $ costed to date Monthly contractor $ costed (planned vs. actual) Monthly level of civil servants (planned vs. actual) Monthly level of contractor personnel (planned vs. actual) Monthly material costs (planned vs. actual) Monthly level of management reserve ($) available

4-75

Project Management: SE & Project Control Processes & Requirements

4.2.2 Planning1,2,3 4.2.2.1 Function Project planning is determining what needs to be done, by whom, when, and with what resources to accomplish the project. Without appropriate planning there can be no project control, because planning provides the baseline that makes control possible. The Planning process is an iterative process that requires the active participation of all knowledgeable project and support team members, and that defines requirements, schedules, cost, and the resulting PMP. This process shall be achieved by establishing requirements , an overall project budget, a project WBS, a detailed networked schedule baseline, and a risk management process. This would then allow the project to evaluate progress and determine and implement any midcourse corrections. 4.2.2.2 Objective The objective or project and management planning revolves around establishing the project roadmap from inception to completion of stated goals. A key element in the Planning process is the ability of the program to effectively plan and organize activities to meet overall objectives. Strategic planning is determining what needs to be done, by whom, when, and at what expense of resources throughout the life cycle of the project. It carefully considers customer needs and how project resources can be best managed. 4.2.2.3 Responsibilities The Project Control Officer is responsible for all aspects of the Planning process, including notifying the Project Team as to when and what data are required, coordinating with any project-external organiza tions, ensuring timely project-internal review of the final product, and delivering the final product. Other participants in this process include: Project Manager, who is responsible for ensuring the Project Control Officer has the facilities and workforce needed to accomplish this task. The Project Manager also acts as a customer to the Project Control Officer for this process. Entire Project Team, which also participates in this process by providing data, supporting rationale, and recommendations for improvement. 4.2.2.4 Life cycle Planning is conducted throughout the life cycle of the project. 4.2.2.5 Inputs Typical inputs to the Planning process are: Project requirements

Project product list Project schedule 4.2.2.6 Steps Project and management planning is an iterative process that entails layout out a unified strategy for project accomplishment and adjusting to changing conditions, updating the plan, and integrating requirements across all project disciplines. The basic elements of planning, which a business discipline will engage in, occur from the formulation phase throughout the implementation phase. These elements include: Developing objectives and requirements Developing WBS Developing project requirements, including the master schedule Assuring cost and schedule are commensurate with technical scope Assisting in cost/schedule trades as they relate to system and design changes Conducting what-if analyses Assessing workforce needs and skill mix Developing the PMP Developing acquisition strategies Although a significant initial effort is required during the formulation phase, the Planning process is a continual and iterative process of laying out and ensuring a unified effort in implementation, adjusting to changing conditions, maintaining the plan, and integrating technical, cost, and schedule requirements. Figure 4.2-2, which appears at the top of the next page, illustrates the steps in the Planning process. 4.2.2.7 Outputs Typical outputs to the Planning process are: Project WBS Master schedule Responsibility organization matrix Project organization and structure Resource loaded, integrated schedule Specific time-phased estimates should be developed for direct civil service labor and travel and for direct contractor labor and total cost. All other elements of project cost (service pools and general and adminis trative (G&A)) are planned and recorded as factors applied to labor or other direct costs and are not within the control of project management personnel. Planners should be familiar with the latest version of the Full Cost Initiative Agencywide Implementation Guide, which is available from the CFO.

4-76

Project Management Processes

Figure 4.2-2. The planning process diagram.

4.2.2.8 Exit criteria An integrated project baseline has been developed and accepted by the POP process as the exit criterion. 4.2.2.9 Measurement The following table provides example base and derived measures that can be used in conjunction with executing the Planning process. See discussion of Measurement on page 4-1.

4-77

Project Management: SE & Project Control Processes & Requirements

Base Measures # of project support plans identified (e.g., PMP, Systems Engineering Management Plan (SEMP), risk management plan, documentation and data management plan, acquisition management plan, etc.) % complete of responsibility organization matrix % complete of WBS development (% vs. schedule) # of detailed and high-level project schedules to be developed Organization structure LCC estimate completion schedule

Derived Measures # of project support plans completed to draft level (actual vs. planned) # of project support plans completed to final level (actual vs. planned) % complete of responsibility organization matrix (actual vs. planned) % complete of WBS development (% vs. schedule) (actual vs. planned) # of detailed and high-level project schedules developed (actual vs. planned) Draft version available Final version available LCC estimate completion schedule (actual vs. planned)

4.2.2.10 Methods and techniques The methods and techniques that may be used in developing requirements are derived from individual or group expert judgment. 4.2.2.11 Software tools The following S/W tools satisfy the Planning process: Microsoft Project Microsoft Project Server Excel Microsoft PowerPoint SuperProject Expert 4.2.2.12 References The following documents, which were used to prepare this section, offer additional insights into the Planning process: 1 Milosevic DZ, Project Management Toolbox, John Wiley & Sons, Inc., 2003.
2

Forsberg K, Mooz H, Cotterman H, Visualizing Project Management, 2nd edition, John Wiley & Sons, Inc., 2000.
3

Lewis JP, Fundamentals of Project Management, AMACOM, 2002.

4-78

Project Management Processes

4.2.3

Documentation and Data Management14 4.2.3.1 Function Documentation and data management establishes the data policies, responsibilities, and procedures for identifying, selecting, archiving, and providing access to project data not directly associated with product configuration. Examples of these types of information include the PMP, meeting minutes, design review pre sentations, the acquisition management plan, etc. It must be clearly understood that documentation and data management is separate and distinct from configuration management (CM), which focuses on the actual project product configuration. Further information on CM can be found in Section 4.3.3. The project shall make every effort to retain only the minimum items required by regulations and those items needed to permit cost-effective support of research, development, production, cataloging, provisioning, training, operation, maintenance, and related logistics functions over the project life cycle. The project team must have timely, authorized access to accurate data and documentation, regardless of where the data are stored, how they are formatted, or how they are accessed. Data and documentation must be available when needed to reduce cycle time, increase data accuracy, and ultimately improve decision-making. There should be frequent, informal interaction with the project team (and with the parent program, if applicable) to determine information requirements and preferences. Additionally, the documentation and data management system should ensure adequate control of the data and documents once they are provided. An additional aspect of documentation and data management includes the display of information. Time invested in designing effective formats for communication of project data and document early in the project advanced studies and definition phases will lead to significant returns, especially in the area of labor hours. Communication techniques should include the judicious use of candor by members of the project team, data visualization techniques (to depict and focus major points) and documentation, and data scope and depth to help establish credibility and reliability for the communicated products. For contractor-supported projects, the project team will establish similar documentation and data management requirements and formally document them as a deliverable that is subject to immediate access or that must be made available to the project team within a specified period of time. 4.2.3.2 Objective The objective of documentation and data management is to establish a formal and disciplined system for the scientific, technical, and management informa-

tion required to support a project. It assures that the appropriate project management data are captured and that proper control is established for data and documents created during and after the life of the project. 4.2.3.3 Responsibilities The Project Control Officer is responsible for all aspects of the Documentation and Data Management process, including notifying the Project Team as to when and what data are required, coordination with any project-external organizations, ensuring timely project-internal review of the final product, and delivery of the final product. Other participants in the process include the: Project Manager, who is responsible for ensuring the Project Control Officer has the facilities and workforce needed to accomplish the task. The Project Manager also acts as a customer to the Project Control Officer for this process. Entire Project Team, which also participates in this process by providing data, supporting rationale, and recommendations for improvement. 4.2.3.4 Life cycle Documentation and data management is conducted throughout the project life cycle. 4.2.3.5 Inputs Typical inputs to the Documentation and Data Management process include a detailed understanding of Federal, JSC, and, if appropriate, program-specific data and documentation regulations and requirements. 4.2.3.6 Steps The Documentation and Data Management process for the project begins with a clear understanding of the documentation and data management requirements levied on the project by Federal, NASA, and JSC requirements. The project will then proceed to identify the documentation and data management strategy, approach, processes, procedures, methods, and metrics to be used. After these steps have been successfully identified and documented, the project will identify a preliminary set of documentation and data to be retained and, potentially, archived throughout the complete project life cycle. As the project exe cutes the data and documentation plan over the project life cycle, it shall be necessary to perform a periodic audit of the processes. These audits will include performing a review of the process metrics, output products, and, as required, retained and archived documentation and data. If an issue is identified during the audits, the project team (and any other necessary external organization) shall analyze the issue to determine the root cause of

4-79

Project Management: SE & Project Control Processes & Requirements

the issue and the preventive or corrective action required. After successful implementation of a preventive or corrective action, the project team may re -audit this area during the following normally scheduled audit or, if necessary, perform a special audit that focuses solely on the specific top in question. Figure 4.2-3 illustrates the steps in the process.

Successful audit of the implementation of all data and documentation management tools and techniques 4.2.3.9 Measurement The table at the top of the following page provides example base and derived measures that can be used

Document documentation and data management strategy, approach, processes, procedures, methods, and metrics in a plan

Baseline plan in PMP

Identify preliminary documentation and data elements to be retained/archived

Periodically audit documentation and data management process metrics, output products, and retained/archived documentation and data

Issue identified

Yes

Analyze issue to determine root cause and preventive, corrective action required

No No

Execute Plan Over Project Life Cycle

Continuous improvement option identified?

Yes
Implement continuous improvement action Implement preventative/ corrective plan

Figure 4.2-3. Documentation and data management process diagram. in conjunction with the Documentation and Data Management process. See discussion of Measurement on page 4-1. 4.2.3.10 Methods and techniques The methods and techniques used in developing documentation and data management requirements are: Audit process Individual and group expert judgment 4.2.3.11 Software tools The following S/W tools satisfy the requirements of documentation and data management: Change tracking tool (e.g., Excel) Document and data storage tool (e.g., Windchill) Process modeling tool (e.g., Process Model)

4.2.3.7 Outputs Typical outputs to the Documentation and Data Management process are: Documented project strategy and process for data and documentation management List of identified project data and documentation to be controlled, reported, and archived List of data and documentation management tools and techniques to be used by the project Project change log Change request form 4.2.3.8 Exit criteria Exit criteria for the Documentation and Data Management process are: Project strategy and process for data and documentation management documented in the PMP Successful audit of the documentation and data process to ensure it adequately addresses all Federal, JSC, and, if applicable, programspecific regulations and requirements

4-80

Project Management Processes

Base Measures Documented audit results

Derived Measures Documented preventative and corrective actions (including closure date) resulting from the audits Total # of completed preventative and corrective actions (planned vs. actual) # of completed preventative and corrective actions per month (planned vs. actual)

4.2.3.12 References The following documents, which were used to prepare this section, offer additional insights into the Documentation and Data Management process: 1 JMI 2314.2L, Identifying and Processing JSC Scientific, Technical and Administrative Documents, 1993. 2 JPD 2200.1A, Release of JSC Scientific and Technical Information to External Audiences, 2000. 3 JPG 1440.3, JSC Files and Record Management Procedures, 2001.
4

NPD 1441.1D, NASA Record Retention Schedule, 2003.

4-81

Project Management: SE & Project Control Processes & Requirements

4.2.4 Cost Estimating15 4.2.4.1 Function Cost estimating and the development of accurate and defensible LCC estimates for JSC projects are critical for good project planning and execution. LCCs are the total of the direct, indirect, recurring, nonrecurring, and other related expenses incurred or estimated to be incurred in the design, development, verification, production, operation, maintenance, support, and retirement of a system over its planned lifetime. A project manager can use the LCC estimates as not only a project planning tool for workforce and deliverables, but also as an additional input or constraint into the design space for the project. Cost estimating may be done at the project level or at some lower level. Project-level cost estimates will be discussed in the following paragraphs. Cost estimates may also be done at lower levels; e.g., in individual change requests or as a comparison tool in trade studies. It is critical that the project team performing the cost estimate uses the proper tools and techniques for the project life cycle phase in which the estimate is being done. NPG 7120.5B3 provides the requirements and guidelines for the frequency and types of projectlevel cost estimates to be performed. Both types of estimates (i.e., project level and below) can be developed at the request of the project manager to the JSC Chief Financial Officer, Cost Estimating and Assessment Office. Basically, two types of project-level cost estimates are required during the life cycle of the project. These are the advocacy cost estimate (ACE) and the independent cost estimate (ICE). An ACE shall be required of all JSC projects and shall be documented in the PMP prior to approval. Although the project office can develop the LCC estimate for budgetary planning purposes based on its understanding of the technical requirements and schedules, it is strongly encouraged that the project coordinate this activity with the CFO Cost Estimating and Assessment Office. The ACE typically become the project baseline estimate and is performed during the Pre-Phase A and Phase A definition phases of a project. There may be several iterations of the ACE during these phases as trade studies are conducted and the project becomes more mature and better defined. An ICE shall be accomplished as required by the JSC Center Director or NPG 7120.5B.3 This independent cost review may also be accomplished as part of other independent reviews, such as a non-advocate review (NAR) or an independent assessment (IA). In each of these cases, members of the independent review team, as opposed to the project team, will develop the ICE. In addition to reviewing the project selection of cost methodologies and model inputs, the independent

review team will question project assump tions and identify and quantify technical and programmatic risks, risk mitigation strategies, and reserve strategies. Depending on the teams findings, the ICE from one of these reviews may result in a recommendation to change the project funding profile. 4.2.4.2 Objective The objective of effective cost estimating is to assess project performance and aid in project decision-making. Beginning early in the life cycle process and continuing throughout the project life, cost estimates must be generated that reflect realistic cost projects for achieving the documented technical requirements of a project. 4.2.4.3 Responsibilities The Project Control Officer is responsible for all aspects of the cost-estimating process, including notifying the Project Team of when and what data are required, coordination with any project-external organizations, ensuring timely project-internal review of the final product, and delivery of the final product. Other participants in this process include the: Project Manager, who is responsible for ensuring the Project Control Officer has the facilities and workforce needed to accomplish this task. The Project Manager also acts as a customer to the Project Control Officer for this process. Entire Project Team, which also participates in this process by providing data, supporting rationale, and recommendations for improvement. 4.2.4.4 Life cycle Cost estimating is conducted throughout the life cycle of the project. 4.2.4.5 Inputs Inputs to the Cost Estimating process are dependent on the cost estimation method and technique to be used. For example, potential inputs could include a wide range of parameters such as weight, year of technology, quantities, technical complexity, schedule, estimated number of lines of S/W code, etc. Inputs are also provided to the process by the cost analysis requirements description (CARD). 4.2.4.6 Steps The project team member: Should determine what the cost estimate scope and content should include. Care should be taken to ensure the cost estimate reflects all cost-generating areas within the scope of the estimate by establishing a comprehensive WBS. Should review the various models and techniques readily available for cost estimating during that

4-82

Project Management Processes

life cycle phase. If a cost-estimating commercial off-the-shelf (COTS) or NASA -developed parametric model is used, the project team member should ascertain whether individual training on the use and nuances of the model(s) is necessary. Develops and documents the input parameters to be used for the model chosen. Documentation includes the rationale behind selection of individual parameters and values so as to capture the thought process used to develop them. Finally runs the model. The resulting cost estimate is reviewed for reasonableness using engineering judgment. Care must be taken not to discard a cost estimate that is higher than the project team members experience. Therefore as a result, model changes that may be required should be incorporated and the model run again until a reasonable result occurs. A sensitivity analysis should be done to determine both the primary cost drivers and the potential range of the cost estimate given project-realistic changes in the input parameters.

Figure 4.2-4 (below) illustrates the steps taken in this process. 4.2.4.7 Outputs Typical outputs to the Cost Estimating process are: Cost estimate Project data to develop the CARD 4.2.4.8 Exit criteria Exit criteria for the Cost Estimating process are: Completion and documentation of cost estimate Method of cost estimate, including all input parameters and their rationales 4.2.4.9 Measurement The table, which appears at the top of the following page, provides example base and derived measures that can be used in conjunction with executing the Cost Estimating process. See discussion of Measurement on page 4-1.

Cost Estimate Determined to be Needed

Cost Estimate Scope and Content Decided

Determine Most Appropriate Model and Technique to be Used

Develop Cost Estimate

Develop and Document Input Parameters

Yes

Project Team Member Familiar with Model/Technique

No

Obtain Training

Review Output for Reasonableness No No Correct Model and Technique Used? No Yes Correct Input Parameters Used? Yes Solicit Expert Consultation from JSC CFO

Reasonable? Yes Conduct Sensitivity Analysis

Document Cost Estimate Results

Figure 4.2-4. Cost estimating process diagram.

4-83

Project Management: SE & Project Control Processes & Requirements

Base Measures # of cost estimates done

Derived Measures Time to accomplish cost estimate (in days)

4.2.4.10 Methods and techniques The methods and techniques that may be used in developing requirements are: Parametric Grass roots Analogy Individual or group expert judgment Historical costs of analogous H/W and S/W systems Inflation indices; e.g., the NASA (Code B) R&D New Start Index 4.2.4.11 Software tools The following S/W tools will support the Cost Estimating process: Parametric cost models; e.g., NAFCOM, PRICE, SEER, and COCOMO Ris k analysis tools; e.g., @RISK Cost-phasing algorithms; e.g., the Beta Curve

4.2.4.12 References The following documents and Web site, which were used to prepare this section, offer additional insights into the Cost Estimating process: 1 Milosevic DZ, Project Management Toolbox, John Wiley & Sons, Inc., 2003. 2 NASA Cost Estimating Handbook 2002 at http://www.jsc.nasa.gov/bu2/NCEH/index.htm.
3

NPR 7120.5B, NASA Program and Project Management Processes and Requirements, 2002. 4 SP 6103, NASA Readings in Project Control.
5

SP 6105, NASA Systems Engineering Handbook , 1995.

4-84

Project Management Processes

4.2.5 Performance Measurement14 Performance measurement is a management tool that shows the current system or process status and identifies problem trends or problem areas as they develop. The three major types of performance measurement are technical performance measurement (TPM), process performance measurement, and earned value management (EVM) performance measure. Although there are other taxonomies for performance measurement, they will not be addressed here. The first of these performance measurements, TPM, addresses attributes of the system of interest. By measuring or estimating TPMs, the subsystem engineer, lead systems engineer, and project manager gain visibility into whether the delivered system will actually meet performance requirements. The goal of TPM is to provide early warning that specific quantifiable threshold values for performance (e.g., accuracy, thrust, reliability, etc.) or limits of resources (e.g., weight, power demand, thermal output, memory availability, central processing unit (CPU) usage, etc.) are in jeopardy. These thresholds and limits are key attributes of the system of interest. They are not applicable to all elements of a project, and they may or may not be additive. A detailed discussion of TPMs is found in Section 4.1.12. The second type of performance measurement, process performance measurement, addresses the processes used in engineering the system of interest. SE metrics are included in this category, as are project control metrics involving production control, operations, and maintenance. Examples of SE and project control metrics are shown throughout Chapter 4. The focus of process performance measurement is on the progress of the project and the quality and productivity of the processes rather than on the performance of the system of interest. Such metrics will facilitate the detection of systemic problems (e.g., skills imbalances ) or project difficulties (e.g., requirements instability). Process metrics will also guide process improvement initiatives. Further detailed discussion of process performance measurements is found in Section 4.3.4. Both TPM and process performance measurement should be directed at issues in either the projects or the organizations in which the projects are performed. These measures are not universal and should not be applied to all of the elements of a project or an organization. Some issues requiring closer scrutiny and measurement will be identified in the early phases from project objectives (budgets, schedules, quality, performance, system capability), risk assessments, project constraints and assumptions, product acceptance requirements, or project external requirements. Finally, these issues may be identified from experience. Because the measurement process consumes

resources, when issues are resolved it may be wise to delete the measures addressing them unless there is concern that these issues may recur. The third and final type of performance measurement is EVM. EVM is a leading process whereby project tasks are arranged in resource-load schedules (a budget baseline) and checked off when accomplished. A detailed discussion of EVM is provided below. 4.2.5.1 Function EVM is an approach to project management (planning and control) that requires the project manager to quantify accomplishments. Earned value is the measure of progress in completing the project; i.e., its degree of completion. The goal of EVM is to provide early visibility into technical problems that, if unrecognized, may impact project cost or schedule goals. The earlier such problems are recognized, the more likely the corrective action will be fruitful and the less likely the problems will result in large project overruns or schedule slips. Before project management starts, a project must be defined. An effort becomes a project when the scope (with completion criteria), schedule (completion date and major milestones), and budget (the most likely level of resources that will be consumed) are clearly defined and conclusively agreed by the customer and the supplier or project manager. The EVM process starts when the project scope (statement of work (SOW)) is clearly divided into lower-level, re latively short-duration tasks that can be sequenced, scheduled, budgeted, and assigned by the project manager to responsible front-line managers for completion. A WBS is the most desired method of accomplishing this. The EVM process continues into project implementation with monthly or weekly project schedule assessments in which the responsible front-line managers quantify progress (earned value) against the budgeted, short-duration tasks defined in the planning phase. In this assessment a task is either complete, in which case the budget value is earned, or is not complete, in which case there is no earned value. Significant differences between the volume of work completed and the volume planned (schedule variance) must be thoroughly analyzed to identify the nature of the problem and the reason for this variance. Once the cause of variance is understood, its likely impact on the same or future tasks can be accurately assessed and corrective actions can be planned and set in motion to eliminate or mitigate the effect on downstream work. During these frequent assessments, front-line managers need to determine the actual cost of the completed work. The actual cost data must come from the accounting system. Significant differences between the volume of work completed and the actual cost incurred (cost

4-85

Project Management: SE & Project Control Processes & Requirements

variance) should be analyzed in a manner similar to that used to analyze the schedule variance. Once the front-line managers clearly understand the nature of the problems and make reasonable plans for corrective actions, they can make informed fore casts of when the tasks can be completed and what level of resources they are likely to consume. These estimates are consolidated to produce an ETC for the project. This cycle of quantifying progress against schedule and actual cost is repeated each period until project completion. If these assessments are to accurately reflect the project status and forecasts of future conditions, the plan (baseline) must be maintained. The goal of maintenance is that the baseline always reflects the agreement between the customer and the project manager. When the project changes (i.e., work is added, deleted, or moved in time), the baseline must change to reflect this new reality. The budgets for project tasks will change in total dollars or in phasing whenever significant work is added, deleted, or moved in time. The budgets will not change, however, unless the work changes. EVM is described in significant detail in EIA-748A.1 This standard has many parallels with EIA-632.2 The EIA-748A guidelines for EVM are as follows: Plan work scope for the project to completion. Break down the project work scope into finite pieces that can be assigned to a responsible person or organization for control of technical, schedule, and cost objectives. Integrate project work scope, schedule, and cost objectives into a performance measurement baseline plan against which accomplishments may be measured. Control changes to the baseline. Use actual costs incurred and recorded in accomplishing the work performed. Objectively assess accomplishments at the work performance level. Analyze significant variances from the plan, forecast impacts, and prepare an estimate at completion based on performance to date and work to be performed. Use earned value management system (EVMS) information in the center management process. EIA-748A 1 also includes 32 principles that further promote objective and accurate assessment of the status and outlook of projects. These principles are appropriate for large, long-term projects in which accuracy, objectivity, and baseline traceability are particularly importance. The principles are essentially the same as the Cost/Schedule Control Systems Criteria (C/SCSC) levied by the Department of Defense (DoD) on large weapons programs since the 1960s.

NASA policy for application of EVM can be found in NPD 9501.3A.3 This document applies only to contracts . It requires the contractor to apply EVM to R&D or production contracts larger than $25M and of a duration longer than one year. If the contracts are larger than $70M for R&D or $300M for production, the contractor is required to implement a system that observes the 32 principles from EIA-748A.1 It further requires validation, meaning that the EVMS actually used by the contractor has been demonstrated and verified in writing as complying with the 32 principles or criteria. Earned value is not required if the contract is predominantly level-of-effort (no products ). A draft policy (to replace NPD 9501.3A 3 but renumbered to be part of program formulation policy, NPD 7XXX) is in development at the Agency level. This document will broaden the application from contracts to projects. In the interim, JSC shall imple ment an EVMS for all projects that is tailored to the specific project and approved by the Center EVM Council representative. Only the Center PMC or Center Director may approve waivers of NPD 9501.3A.3 4.2.5.2 Objective The objective of EVM is to prove early visibility into project technical problems so that corrective actions might prevent unfavorable schedule or cost outcomes. 4.2.5.3 Responsibilities The Project Control Officer is responsible for all aspects of the performance measurement process. This includes notifying the Project Team of when and what data are required, coordination with any project-external organizations, ensuring timely project-internal re view of the final product, and delivery of the final product. Other participants in the process include the: Project Manager, who is responsible for ensuring the Project Control Officer has the facilities and workforce needed to accomplish this task. The Project Manager also acts as a customer to the Project Control Officer for this process. Entire Project Team, which also participates in this process by providing data, supporting rationale, and recommendations for improvement. 4.2.5.4 Life cycle EVM is applicable to any project life cycle phase that has conclusive completion criteria. 4.2.5.5 Inputs Typical inputs to the EVM Performance Measurement process are:

4-86

Project Management Processes

A product hierarchy (usually a WBS) with definitions for each element that clearly distinguish that element from all other elements and that provide conclusive guidance regarding completion criteria. Work authorization (scope, schedule, budget in terms of resource types, and signatures indicating a meeting of the minds): At the project level, between the customer and the performing organization. At the task level (scope entirely within a WBS element to be performed by a single functional organization), between the project manager and the task manager. Schedules that clearly define the period of performance, major enforced milestones dates, and delivery dates of customer-supplied products.
Solicitation

An EVM tool that will capture resource-loaded schedules. 4.2.5.6 Steps Figure 4.2-5 illustrates the steps that are taken in performing the EVM Performance Measurement process. These steps can be broken down into two phases : planning and control. Planning Phase A solicitation is received from the customer. The formality is less important than the specificity of the solicitation. It should clearly convey the functionality of the product as well as the major schedule milestones pertinent to the product. The directorate prepares a proposal describing the implementation, the budget in terms

Customer:
Proposed Change Review Urgent Change

Review

Directorate:
Proposal Agreement? No Initial Planning Yes Project Agreement (e.g., ITA)

Review

Project Manager:
Project Log Project Management Plan Review Review

Work Authorization Documents

Task Manager:
Review No

Agreement? Yes Detail Planning Record Baseline Actual Cost

Schedule Status Analyze Variances

Another Months Work Estimate Cost to Complete

Report

Replan

Figure 4.2-5. Performance measurement process diagram.

4-87

Project Management: SE & Project Control Processes & Requirements

of time -phased resources (in-house labor by organization, contractor labor, material, facilities, travel, service pool, general and administrative (G&A) by fiscal year), and any other pertinent schedule events. Review and negotiation continues until both parties reach a mutual agreement regarding scope, schedule, and time-phased resources (budget). This agreement is recorded in an ITA or another document that clearly defines the scope, schedule, and budget. It is then signed by the director and the customer. The project manager performs sufficient internal planning to do a preliminary allocation of project tasks and resource levels to performing organization units. These plans will also include target dates for commencing and completing the tasks. Negotiation between the project manager and the task manager will continue until they reach a mutual agreement regarding all salient provisions of the task. The project manager, task manager, and functional manager, who supervises the task manager, will sign the work authorization document (WAD). Once the WAD is signed, the task manager will perform the detailed planning that breaks the task into near-term work packages (subtasks) and farther-term planning packages, indicating specific periods of performance but with less granularity. Each work package and planning package will be composed of only a single resource type. Predecessor/ successor relationships among the work/planning packages will be defined. A work package represents units of work at levels where work is performed. As such, it is clearly dis tinguished from all other work packages. Among the factors that distinguish are: It is assigned to a single organizational element. It has scheduled start and comp letion dates and, as applicable, interim mile stones that are representative of physical accomplishment. It has a budget or an assigned value expressed in terms of dollars, labor-hours, or other measurable units. Its duration is limited to a relatively short time span, or it is subdivided by discrete value milestones to facilitate the objective measurement of work performed, or it is level of effort. It is integrated with detailed engineering, manufacturing, or other schedules.

Record this baseline information in the EVM tool. Baseline information includes schedule and budget data. Budget data will be broken into the performance measurement baseline representing work authorized formally to task managers, undistributed budget that represents work not yet authorized to task managers, and management reserve representing a contingency held by the project manager to authorize work that has always been part of the scope that has not been assigned to any task manager. Control Phase Each month, the task manager will status the task-level schedule. Milestones and work packages will be reported as complete, not yet started, or in process. The schedule status information, when com pared with the project baseline data, will indicate schedule variance. When compared with actual cost data, cost variances will be revealed. Both schedule and cost variances will be analyzed as to cause (i.e., the nature of the technical problem underlying the variance), impact on the current task and on successor tasks, and corrective action. A time-phased ETC will be prepared that reflects actual cost to date and knowledge of future conditions. The task manager will repeat this cycle each month, updating schedule status, analyzing variances, and building ETCs until the task is complete. Each month a report of this in formation will be provided to the project manager, directorate management, and customer. Occasions will arise when a work package or a milestone should be replanned. Replanning can take the form of a change in time (schedule) or implementation details (different work group, buy rather than make, etc.) within the overall schedule and budget constraints for the task as outlined in the work authorization. When such a need arises, a request will be prospectively prepared and forwarded to the project manager. When approved, the detail project baseline will be modified accordingly. On infrequent occasions, changes in overall project scope or schedule will be necessary. These changes will follow the steps taken when establishing the original project agreement. Sometimes elements of the changes are urgent and must be pursued immediately, even if the changes have not yet been

4-88

Project Management Processes

negotiated between the customer and the directorate. In such case, the near-term effort will be scheduled and budgeted. At the same time, a change request will be prepared, negotiated, and recorded to reflect appropriate, equitable changes to the baseline values. 4.2.5.7 Outputs The outputs of the process are: Variance analyses characterizing the cause and impact of only significant variances as well as corrective action plans intended to mitigate or minimize the effects of technical problems. Estimates of cost at completion. These estimates are based on performance to date, commitment values for material, and estimates of future conditions. Estimated project completion date, including forecasts for significant milestones. 4.2.5.8 Exit criteria There are no exit criteria since this process is continuous. 4.2.5.9 Measurement The following tables provides example base and derived measures that can be used in conjunction with executing the Performance Measurement process. See discussion of Measurement on page 4-1.

4.2.5.11 Software tools The following S/W tools satisfy the principal considerations of the EVM Performance Measuring process: MS Project MS Project Server EV tools perform several essential tasks, including: Schedule planning (duration, sequence, resource types, resource levels) Schedule baseline (recording and maintaining baseline approved by project manager) Schedule status by work package or milestone (completed, not started, or in work/ percent complete) Schedule forecast (estimated dates for baselined tasks) Record direct costs in a manner consist with budgets without allocation Report variances (schedule and cost) at task level Report to facilitate variance analysis (automatically decompose labor-cost variances into rate and efficiency variances and ma terial-cost variances into price and usage variances) Accommodate revisions to baseline for Internal task replanning Adding or deleting work from task Changes to indirect cost rates or factors Derived Measures Schedule variance (SV) ($, %, co mparative fit index (CFI), 6-month, etc.) Cost variance (CV) ($, %, CFI, 6-month, etc.) Variance at completion (VAC) (budget at completion (BAC)-estimate at completion (EAC)) Schedule performance index (SPI) (earned value (EV)/Plan) Cost performance index (CPI) (EV/ACWP) To complete performance index (TCPI) (BAC-EV)/ (EAC-actual cost (AC)) Defined as measured as opposed to level of effort (LOE) Age of unnegotiated changes (actual vs. project-defined yellow and red age levels) Consolidation for reporting purposes from task level to project level through hierarchies for organization (functional) and product (WBS).

Base Measures Project Plan (budgeted cost of work scheduled (BCWS) Earned value (budged cost of work performed (BCWP)) Actual cost (actual cost of work performed (ACWP)) BAC EAC

Fraction of work performed each period Age of unnegotiated changes

4.2.5.10 Methods and techniques The methods and techniques that may be used in developing requirements are defined by EIA-748-A1 principles.1

4-89

Project Management: SE & Project Control Processes & Requirements

4.2.5.12 References The following documents, which were used to prepare this section, offer additional insights into the EVM Performance Measuring process: 1 EIA-748A, Earned Value Management Systems, 2002. 2 EIA-632, Processes for Engineering a System, ANSI/EIAS-632-1998, 1999.
3

NPD 9501.3A, Earned Value Performance Management, 2002. 4 Milosevic DZ, Project Management Toolbox, John Wiley & Sons, Inc., 2003.

4-90

Project Management Processes

4.2.6 Schedule Management15 4.2.6.1 Function Schedule management provides for the overall development and maintenance of a master schedule, coupled with the detail from the interrelated, lowerlevel schedules covering the overall project from start to finish. Additional benefits of this scheduling strategy include automated summarizations of project cost and schedule data, resource leveling to effectively stay within existing workforce constraints, efficient and timely reporting of project status, and more accurate impact assessments on external project interfaces . Time and money are directly linked, and combining them in analysi s proves very beneficial. Logic networkdriven schedules should be resource-loaded in a simple and practical manner. These resource-loaded networked schedules provide a useful tool in understanding interdependencies. Schedule analysis techniques shall involve review and assessment of critical paths, logic relationships between activities, slack and reserve usage management, milestones and tasks progress against plans, and other schedule analysis criteria. This can then provide the capabilities for determining reliable cost and workforce estimates, EVM, trending for better EACs, what-if analysis for POP exercises and project workarounds, and generally better overall cost control. For contractor-supported projects, the contractor should be held to rolling wave accountability on near-term schedules. The term rolling wave means that there are very detailed schedules for near-term activities, specifically for the upcoming 6-month period. These schedules should be measured in inchstones, not milestones. The performer reports the budgeted value of the inch-stones met in a given month vs. the budged value of those planned. With this type of small, incremental planning and tracking, it is readily apparent how well the project is being executed. When the contractor reporting structure closely links schedule and cost-reporting milestones, care should be taken that the approach is not based on equal value milestone performance since this could lead to erroneous assessments. Slippages in a project schedule can be extreme ly expensive. A permanent record of all schedule changes should be documented to support trend analysis and the project assessment function. 4.2.6.2 Objective The objective of schedule management is to provide the key in implementing an effective integrated management process for NASA projects. It is the foundation for establishing a project baseline and effective performance measurement process. The goal of scheduling is to provide a framework to time-phase and coordinate tasks into a master plan to complete the

project within cost, schedule, and performance constraints. The schedule content, format, detail, and symbology shall be established. The key discipline in this area is taking time and effort early in the schedule development process to develop a detailed, logical, network-driven schedule. This scheduling technique is mandatory for successful control of both in-house and contractor efforts, and it proves invaluable in keeping management focused on the right tasks and knowing the right priorities for workforce assignments . 4.2.6.3 Responsibilities The Project Control Officer is responsible for all aspects of the schedule management process, including notifying the Project Team of when and what data are required, coordination with any project-external org anizations, ensuring timely project-internal review of the final product, and delivery of the final product. Other participants in this process include the: Project Manager, who is responsible for ensuring the Project Control Officer has the facilities and workforce needed to accomplish this task. The Project Manager also acts as a customer to the Project Control Officer for this process. Entire Project Team, which also participates in this process by providing data, supporting rationale, and recommendations for improvement. 4.2.6.4 Life cycle Schedule management is begun during Phase A and is conducted throughout the life cycle of the project. 4.2.6.5 Inputs Typical inputs to the Schedule Management process are: WBS WBS dictionary Project master schedule 4.2.6.6 Steps The project effort shall be broken into tasks and milestones at a level of detail to allow for discrete progress measurement and for management visibility into the overall definition, development, fabrication, integration, test, delivery, and operational phases of a project. The project should require the responsible lead engineer, along with other key project team members, to set aside time in the early stages of the project to review the WBS and determine associated task durations, resources required, and interdependencies. Each task should also be assessed for risk to determine the appropriate duration range to be used in the scheduling process. All of these efforts enable better organization of the work, improved estimates of task duration, better procurement planning, and reduced risk of accidental scope omission.

4-91

Project Management: SE & Project Control Processes & Requirements

A logic-driven schedule is then developed within the framework of the approved project WBS. This schedule must, by definition, contain the entire scope of the work. Each task and milestone should be horizontally integrated with the appropriate predecessor/ successor sequence relationships; they should also be vertically integrated to significant project milestones. This provides an end-to-end logic network of resource-loaded project tasks. As the project progresses, the scheduled effort will shift to schedule status reporting and analysis on a regular basis so as to reflect the most current status of the integrated project schedule. Schedule analysis activities must also take place on a regular basis to determine whether significant project schedule changes have occurred, such as a change in critical path. Figure 4.2-6 illustrates the steps in the process.

4.2.6.7 Outputs Typical outputs to the Schedule Management process are: Identified tasks for each appropriate WBS item Duration (range) for each task Resources required for each task Logic progression sequence of tasks (e.g., network) Integrated, resource-loaded project schedule Critical path analyses 4.2.6.8 Exit criteria Exit criteria for the Schedule Management process are: Completed top-level project schedule throughout the life cycle

Determine What Schedules Are Needed

Determine How Schedules Will Be Used (e.g., Task Planning and Oversight, Task Progress Tracking, Reporting to Upper Management, etc.)

Determine Appropriate Schedule Management Tool

Combine Tasks to Form Project Network

Develop Predecessor/Successor for Each Task, Through Project Completion

Develop Tasks (from WBS)

Define and Evaluate Risks for Each Task

Develop Risk Mitigation Actions and Add to Network

Determine Range of Duration for Each Task

Review Critical Path to Determine if It Is Possible to Shorten

Determine Critical Path

Assign Duration Range to Each Task

Yes

Shorten?

No

Plan Periodic Project-Level Schedule Status Reviews

Determine Current Tasks Schedule Status

Perform Variance Analysis

Figure 4.2-6. Schedule management process diagram.

4-92

Project Management Processes

Completed detail-level project schedule throughout the life cycle Defined and documented schedule definition and analysis process Successful schedule trace from start milestone through completion with no breaks 4.2.6.9 Measurement The following table provides example base and derived measures that can be used in conjunction with executing the Schedule Management process. See discussion of Measurement on page 4-1. Base Measures # of schedules to be developed Priority of schedules to be developed % complete for identification and documentation of each task duration (range) for each schedule % complete for identification and documentation of predecessor/successor for each task for each schedule % complete for identification and documentation for required resources for each task for each schedule Critical path analysis completion Slack/float (free and total) 4.2.6.10 Methods and techniques The methods and techniques that may be used in development requirements are: Cards-on-the-wall method Work flow diagram Individual and group expert judgment Start at completion and work backward Critical path analysis techniques (program evaluation review technique (PERT), graphical evaluation review technique (GERT), critical path method (CPM), etc.) Time -scaled arrow diagram Critical chain schedule Milestone charts Hierarchical schedule Line of balance B-C-F [baseline-current-future] analysis Backward pass method 4.2.6.11 Software tools The following S/W tools support the Schedule Management process: Microsoft Project Server Microsoft Project Microsoft PowerPoint (Gantt charts)

4.2.6.12 References The following documents, which were used to prepare this section, offer additional insights into the Schedule Management Process: 1 NPD 1440.6G, NASA Records Management , 2002.
2

JPG 1440.3, JSC Files and Records Management Procedures, 2001. 3 SP 6105, NASA Systems Engineering Handbook , 1995.

Derived Measures # completed (actual vs. planned) % complete for identification and documentation of each task duration (range) for each schedule (actual vs. planned) % complete for identification and documentation of predecessor/s uccessor for each task for each schedule (actual vs. planned) % complete for identification and documentation for required resources for each task for each schedule (actual vs. planned)

Forsberg K, Mooz H, Cotterman H, Visualizing Project Management, John Wiley & Sons, Inc., 2002. 5 Dragan ZM, Project Management Toolbox, John Wiley & Sons, Inc., 2003.

4-93

Project Management: SE & Project Control Processes & Requirements

1,2,3 4.2.7 Project Analysis 4.2.7.1 Function This section addresses the need for project leaders to perform an effective and timely analysis of project data for existing projects, proposed changes, and future projects. This analysis shall be performed to determine that the current performance analysis plan is understood and that future plans are in place to assure project success. The analysis shall also be used to assess proposed changes and new project plans.

4.2.7.2 Objective The objective of project analysis is to provide a dis ciplined process for analyzing and communicating existing project performance measurement data to determine project progress and issues, and to assess future plans. This analysis should result in an understanding of the accuracy of the data and progress on the project, project issues, and future plans to provide a basis for management action. Project analysis also provides a process for analyzing proposed changes and proposed project plans to determine whether the plans are sound and form the basis for accepting or rejecting the proposals. Project analysis shall be done at a level in the WBS that is appropriate to the complexity or risk of the task and at the overall project level. Project analysis shall be done throughout the life cycle of the project to provide increasingly reliable data concerning the viability of future projects or the performance on existing projects. 4.2.7.3 Responsibilities The Project Control Officer is responsible for all aspects of the project analysis process, including notifying the Project Team of when and what data are required, coordination with any project-external organizations, ensuring timely project-internal review of the final product, and delivery of the final product. Other participants in this process include the: Project Manager, who is responsible for ensuring the Project Control Officer has the facilities and workforce needed to accomplish this task. The Project Manager also acts as a customer to the Project Control Officer for this progress. Entire Project Team, which also participates in this process by providing data, supporting rationale, and recommendations for improvement. 4.2.7.4 Life cycle Project analysis applies during the entire life cycle of a project. 4.2.7.5 Inputs Typical inputs to the Project Analysis process are:

BCWS, which is the sum of the time-phased budgets for all efforts scheduled to be accomplished within a time period; associated with this budget is a baseline schedule that has resources assigned to it BCWP, which is the sum of the time-phased budgets for all efforts completed during a specified time period ACWP, which is the cost actually incurred and recorded in accomplishing the BCWP within a given time period CV, which is BCWP-ACWP SV, which is BCWP-BCWS CPI, which is cumulative BCWP divided by cumulative ACWP SPI, which is cumulative BCWP divided by cumulative BCWS TCPI, which is BAC-cumulative BCWP divided by EAC-ACWP Actual costs for similar projects, vendor quotes, or best estimates from subject matter experts Basis of estimate (BOE), which is the basis for estimating new projects and changes to existing projects TPMs appropriate to the project life cycle 4.2.7.6 Steps To analyze a proposed project in Pre-Phase A or Phase A, the project control officer and the team members acquire backup cost, schedule, and risk information from other similar projects or market surveys to form the basis of estimate and risk assessment. Where information is not available, subject matter experts (SMEs) can be used to provide a best engineering estimate using cost-estimating techniques appropriate for the product. SMEs can also be used to survey the market to assess the risk of available technologies to support the project. Team members and the project manager use this information to validate the proposed project cost, schedule, and risks. When assessing a vendors proposal, similar comparison data are acquired for purposes of reviewing both the original proposal for a project and subsequent changes to that project. When a project is sufficiently defined, the work is allocated to team members or vendor managers for implementation into an integrated project baseline. The project control officer, project manager, and other appropriate SMEs review and approve the baseline. If the project is a government-furnished item, the project control officer and team members implement the baseline. If the project is assigned to a vendor, the vendors project control function and managers implement the baseline with oversight by the NASA project team. The project control officer and vendors project control function strictly control project baseline changes

4-94

Project Management Processes

to assure that no unknown changes invalidate the baseline and subsequent data for analysis. The team members or vendor managers provide monthly status for both TPMs and EV reporting. The project control officer or vendors project control function takes these inputs and provides team members or vendor managers and the project manager with reports on project performance measurements for project analysis. The team members or vendor managers use these reports to assess variances in cost or schedule (usually greater than 10%) and provide corrective action plans. The project manager analyzes projectlevel indices and variance information for project trends. For variance analysis, CPI, SPI, and TCPI provide a quick rule-o f-thumb measure for project health. CPI represents how efficiently the work is performed (BCWP) vs. the money being spent

(ACWP). SPI represents how quickly the work is accomplished (BCWP) vs. what is baselined (BCWS). TCPI represents the cost efficiency required to achieve the project with the budget or EAC planned. In a perfect project, all three measures are a 1.0. Seeing usual variations in these indices indicates a need to look further. For example, if the project CPI is 0.56 yet the TCPI is 1.40, the indication is that a large increase in efficiency will be needed to successfully complete the plan. TPMs are analyzed to determine whether there are technical issues or risks in trends observed. For example, a high change rate could indicate that the project is insufficiently defined for the current phase. Similarly, a high defect rate could indicate a process problem within the project. Figure 4.2.7 illustrates the Project Analysis process.

Analyze Proposed Project

Collect Data from Similar Project

Assess Proposal

Proposal Assessment

Go? No

Yes

Stop Project

Analyze Project Change

Review Technical Proposal

Determine Should Cost

Assess Cost Proposal BOEs vs. Should Cost

Conduct Fact-Finding

B Negotiate Baseline Change Authorize Change and Update Baseline/POP

Develop Integrated Baseline

Define Cost Centers (CC) (WBS + Org.) C

Allocate Requirements to CC

Prepare Budget, Schedule, Metrics, and Risks for CC

Integrated Baseline and POP

Analyze Performance Data

Collect Performance Data

Analyze Variances, Issues, and Risks

Prepare Corrective Action Plans

ETC Update Variance Report Issues and Risks

KEY

Step/Activity

Product

Information/Output Flows

Decision

Connector

Figure 4.2-7. Project analysis process diagram.

4-95

Project Management: SE & Project Control Processes & Requirements

4.2.7.7 Outputs Typical outputs to the Project Analysis process are: An integrated project status and POP ETC, which provides an updated time -phased estimate for the remaining work on the project Variance analysis report (VAR), which provides an analysis of the problem, program impact, and corrective action plan Risk assessment and technical performance issues Corrective action plans 4.2.7.8 Exit criteria Exit criteria for the Project Analysis process are: A revised estimate that more accurately reflects project costs for the projects entire scope The corrective action plan in the variance analysis addresses the root cause of the technical, cost, or schedule issue A risk assessment and abatement plan for the potential future project problems 4.2.7.9 Measurement The following table provides example base and derived measures that can be used in conjunction with executing the Project Analysis process. See discussion of Measurement on page 4-1. 4.2.7.10 Methods and techniques The methods and techniques that may be used in developing requirements are: Statistical analysis of defect closure rate and change rate Analysis of EV performance measurements Cost-estimating methods

Individual or group expert judgment EVMS 4.2.7.11 Software tools S/W tools that will support the Project Analysis process are: Excel Word processor Cost-estimating models (e.g., SEER, NAFCOM, PRICE, etc.) 4.2.7.12 References The following documents and Web site, which were used to prepare this section, offer additional insights into the Project Analysis process:
1

NPR 9501.3, Earned Value Management Implementation on NASA Contract, 2002. 2 EIA-748-98, Industry Guidelines for Earned Value Management Systems, 1998. 3 NASA Cost Estimating Handbook 2002 at http://www.jsc.nasa.gov/bu2/NCEH/index.htm.

Base Measures # Requirements Added, Changed, or Deleted Defects in Requirements (by Phase) Defects in Design (by Phase) Defects in S/W Code (by Phase) Issues/Actions Status Risk Status (e.g., Open, In Work, Closed) CV SV CPI SPI TCPI

Derived Measures Requirements Volatility = % Added, Changed, or Deleted Requirements Defects Projected vs. Actuals Design Defects Projected vs. Actuals Code Defects Projected vs. Actuals % Issues Closed Projected vs. Actual Risk Status BCWP-ACWP BCWP-BCWS Cumulative BCWP divided by Cumulative ACWP Cumulative BCWP divided by Cumulative BCWS BAC-Cumulative BCWP divided by EAC-ACWP

4-96

Project Management Processes

4.3 Crosscutting Processes 4.3.1 Acquisition Management1,2 The Acquisition Management process is performed to acquire all products, materials, or services in support of the project. Project acquisitions are performed via acquis ition instruments such as contracts, grants, cooperative agreements, or a combination of these. Component activities of the Acquisition Management process include: Defining requirements Formulating acquisition strategies for the project, including determining acquisition instruments and appropriate contract types Executing the acquisition instruments Monitoring and evaluating performance of the acquisitions The end customer for the Acquisition Management process is the project manager. Acquisition management, which is a continuous process throughout the life cycle of the project, is exercised in accordance with project acquisition strategies. 4.3.1.1 Function1,2,3 In the Acquisition Management process: Technical requirements (e.g., detail specifications, interfaces, cost, schedule/long lead, etc.) and management requirements of the products, materials, or services being acquired shall be identified. Acquisition strategies to acquire required products, materials, and services shall be developed. Acquisition instruments in accordance with project acquisition strategies shall be executed. Execution of the acquisition instruments, including monitoring and performance evaluation, shall be managed. All project acquisitions are performed in accordance with the following established JSC procedures: JSC SLP 4.6, Procurement;4 and JPG 5335.2, Space Act Agreements.5 4.3.1.2 Objective 1,2 The primary objective of the Acquisition Management process is to acquire all required products, ma terials, and services to enable a firm commitment to accomplish project goals and objectives on schedule and within budget. 4.3.1.3 Responsibilities1 The Project Manager is responsible for formulating acquisition strategies for the project. The Project Manager also makes the final decisions concerning project acquisitions and approves any corrective actions relating to the performance of the acquisition mechanisms.

The Project Manager is supported by the Project Acquisition Team, whose principal participants include the Project Control Officer, the Lead Systems Engineer, the Procurement Representative, the Chief Financial Officer Representative, and, as necessary, the Office of the Chief Counsel Representative. The Project Control Officer is responsible for performing the process steps outlined below. The Project Control Officer also provides the primary management inputs on needs and requirements for the products, materials, and services to be acquired in support of the project. The Lead Systems Engineer provides primary technical input on needs and requirements for project acquisitions. The Lead Systems Engineer also supports execution of the acquisition instruments by participating in the development and review of solicitations and the evaluation process for selection of suppliers. Finally, the Lead Systems Engineer supports technical monitoring and evaluation of the acquisition instruments. The Procurement Representative interfaces with the Project Control Officer and the Lead Systems Engineer to solicit information in support of project acquisitions and provides advice both on conducting acquisitions and on acquisition regulations. The Chief Financial Officer Representative provides resource management, budget support, accounting, and financial transaction support for project acquis itions. Other responsibilities are outlined in JSC SLP 4.64 and JPG 5335.2.5 4.3.1.4 Life cycle3 The Acquisition Management process is applicable to all phases of the project life cycle whenever acquisitions are required. Acquisition strategies are formu lated based on project needs for products, materials, or services in support of the work performed at any given life cycle phase. Acquisition strategies may range from project-level strategies such as whether the contractor or outside organization should perform any (or all) of the project through focused acquisitions to procure products or materials to implement in-house designs. Once decisions are made to acquire from a contractor or outside organization, support of the contract execution and performance monitoring continues until acquisition is completed. 4.3.1.5 Inputs3,8 Typical inputs to the process include, but are not limited to: Concepts (mission, system, operations) Goals and objectives (mission, system) Needs (mission, system) Assumptions, guidelines, and constraints, including:

4-97

Project Management: SE & Project Control Processes & Requirements

Federal Acquisition Regulations (FARs) and other applicable NASA and JSC guidelines/ regulations Requirements (mission, system, interface), including: Specifications, interfaces, design data, cost, schedule, quantities, and standards related to the item being acquired Historical data (previous NASA projects and contracts) Market/industry data Plans (project plan project acquisition strategy) Procurement data, including: List of appropriate acquisition types Implementation timeline for each acquisition type

4.3.1.6 Steps1,2,3,7 The major steps and products that are implemented by this process are illustrated in Figure 4.3.-1.
Acquisition Requirements Definition

Consider using a draft request for proposal (DRFP) to obtain industry comments on the set of acquisition requirements. Communicate in advance with procurement support personnel to coordinate potential project procurement needs and potential procurement instruments. Project acquisition strategies shall be developed and maintained. Gather technical and management inputs and recommendations to the project acquisition strategies based on judgments related to technology maturity, knowledge and skill base of the civil service workforce, cost effectiveness, work complexity, existence of facilities or other infrastructure to perform the work, or other relevant considerations. Evaluate whether project components should be developed, purchased, or reused based on es-

Manage Acquisition Executions

Acquisition Requirements

Contract Performance Evaluation and Monitoring Data

Develop and Maintain Acquisition Strategies Project Acquisition Strategies Execute Acquisition Instruments Contracts, Grants, or Agreements

Information in support of the next acquisition

KEY

Step/Activity

Product

Information/Output Flows

Figure 4.3-1. Acquisition management process diagram. Project acquisition requirements shall be defined. Identify and document technical and management needs and requirements for the products , materials, and services that that need to be acquired to support the project. Includes, as applicable, SOWs, detailed specifications, deliverables, cost, schedule, and any other applicable documents. tablished criteria and the needs of the project (i.e., Make/Buy Analysis). Identification of work products, whether externally or internally acquired, helps to establish a top-level WBS to estimate the scope of the project. Determine the acquisition type for each product to be acquired (e.g., contract type such as sole source, full and open competition or piggyback on existing contract, grant, cooperative agreement, or interagency

4-98

Project Management Processes

funds transfer) (see discussion, Section 2.8, Project Management and Planning). Periodically review and maintain the project acquisition strategies to account for changing project needs and updated Federal regulations. The project shall execute the acquisition instrument in accordance with project strategies. Develop solicitation and evaluation instruments to support solicitation, negotiations, and selection of the supplier (e.g., agreement, SOWs, RFPs, requests for quotes (RFQs), announcements of opportunities, evaluation criteria). Provide technical and management inputs to supplier selection based on an evaluation of the suppliers ability to meet specified requirements and established criteria. Support activities leading to the award of the contract or approval of agreements per established JSC procedures. The project shall manage execution of the acquisition instruments, including monitoring and performing evaluation. Designate members of the project team to act as task monitors or contracting officers technical representatives (COTRs) to oversee the work performed. Develop a surveillance strategy. Note that, for contracts, the COTR and contracting officer are responsible for determining and implementing the level and type of performance monitoring required after considering risk factors associated with the work to be performed. Provide the necessary performance evaluation criteria and data to monitor and evaluate the suppliers performance. Base Measures Acquisition Requirements Definition (FTEs)

Analyze performance data vs. established criteria to assess the level of performance. Communicate the status to the project manager. Include recommendations for corrective actions as required (see Section 4.2). NOTE: These process steps are also applicable for the case where acquisitions are performed by adding deliveries to an existing contract. In this case, requirements would still need to be defined; the acquisition strategy will use the existing contractual vehicle; the supplier proposal would still need to be evaluated; and performance monitoring of the task would still need to be performed. 4.3.1.7 Outputs6,7,8 Primary outputs from this process are: Acquisition Requirements, including, as applicable, SOWs, detailed specifications, deliverables, cost, schedule, and any other applicable documents . Acquisition strategies. Surveillance plans. Acquisition instruments. Supplier performance evaluation and monitoring data. 4.3.1.8 Exit criteria3 Closeout activities are completed for each acquisition within the project. 4.3.1.9 Measurement7 The following table provides example base and derived measures that can be used in conjunction with the Acquisition Management process. See discussion of Management on page 4-1.

Derived Measures Acquisition Requirements Definition Productivity Acquisition Requirements Definition Effort Planned vs. Actuals Acquisition Requirements Definition Rate Charts Acquisition Requirements Definition Effort as % of Total Engineering Effort Planned vs. Actual Acquisition Products Acquisition Strategy Milestone Schedule Planned vs. Actuals Contract Deliverables Planned vs. Actual Dates Data Requirements List Items (DRLI) Delivery Status Summary # On Time vs. # Late; % On Time Deliveries Contract Deliverables Status Summary

# of Products to be Acquired

Contract Deliverables Milestone Dates

Contract Deliverables Status (e.g., DRLI in development, review, approval, delivered)

4-99

Project Management: SE & Project Control Processes & Requirements

4.3.1.10 Methods and techniques3,8 Several methods and techniques are available to support the Acquisition Management process. These are: Market research. Make/buy/reuse analysis. Technology assessment. Trade study. Risk-based acquisition management. 4.3.1.11 Software tools Some means of capturing evaluation criteria, computations, comparison, recommendations, and results associated with SE analyses is required. Typically a spreadsheet application is sufficient to capture, control, manipulate, present, and share this information. Access to historical data repositories should also be considered. Depending on the size, complexity, and amount of applicable data captured from previous projects, anywhere from standard office automation tools to large databases may be required. 4.3.1.12 References The following documents, which were used to prepare this section, offer additional insights into the Acquisition Management process:

NPR 7120.5B, NASA Program and Project Management Processes and Requirements, 2002.
2

NPR 71xx.x (document number not yet assigned), NASA Systems Engineering Processes and Requirements.
3

CMMI-SE/SW/IPPD/SS V1.1, Capability Maturity Model Integration (CMMI) for Systems Engineering, Software Engineering, Integrated Product and Process Development, and Supplier Sourcing, 2002. 4 JSC SLP 4.6, Procurement.
5 6

JPG 5335.2, Space Act Agreements. INCOSE Systems Engineering Handbook , Version 2.0, 2000.
7

EIA-632, Processes for Engineering a System, ANSI/EIA -632-1998, 1999. 8 SP 6105, NASA Systems Engineering Handbook , 1995. 9 JMI 5150.5F, Processing of JSC Procurements Through Delivery, Acceptance and Payment Stages.
10

JMI 5151.5B, Management of Support Contracts.

4-100

Project Management Processes

4.3.2 Risk Management1,2 The Risk Management process is performed to identify potential problems before they occur, so that risk-handling activities may be planned and invoked, as needed, across the life of the project in an efficient and effective manner and to mitigate adverse impacts. In the Risk Management process, the project team is responsible for identifying, analyzing, planning, tracking, controlling, and communicating effectively the risks (and the steps being taken to handle them) both within the team and with management and stakeholders. Risk management is a continuous, iterative process with the ultimate goal of enabling mission success. It should be a key element and an integral part of project management and engineering processes. 4.3.2.1 Function3 In the Risk Management process: Continuous and iterative risk analysis that des cribes and quantifies the safety, performance, schedule, and cost risk (i.e., likelihood vs. consequences) shall be conducted. Controls and approach, including mitigation options for identified risks, shall be documented. Risks shall be tracked. Risks that impact mission success, performance, cost, and schedule shall be controlled. 4.3.2.2 Objective The Risk Management process is performed to reduce the probability of adverse impacts and, as a result, maximize the probability of achieving system goals. 4.3.2.3 Responsibilities The Project Control Officer has primary responsibilities in the tracking, control, and communication aspects of the Risk Management process. The Project Manager is the primary customer in that the Risk Management process supports project resource allocation decisions. All other Project Team Members are responsible for risk identification, analysis, and planning. 4.3.2.4 Life cycle Risk management is conducted throughout the project life cycle. A preliminary risk management plan is required at the end of Phase A, Preliminary Analysis, and an update to this plan is required by the end of Phase B, Definition. 4.3.2.5 Inputs4 Inputs include the following: Program data Project data Constraints

Fault-tree analysis (FTA) results Failure modes and effects analysis (FMEA) results Test data Expert opinion Hazard analysis Lessons learned Technical analysis Resources 4.3.2.6 Steps1 The project team shall document the Risk Management process within a risk management plan, and the project manager shall approve that process. Content requirements of the risk management plan are listed in NPR 8000.4, Section 2.7.4.2. Figure 4.3-2, which appears at the top of the following page, illustrates this process. The project Risk Management process shall in clude at a minimum: (a) risk identification, (b) risk analysis , (c) risk planning, (d) risk tracking, (e) risk control, and (f) identification of process responsibilities. These are outlined as shown below. Identify Risks Identify all project risks, including safety, performance, schedule, and cost risks. State the risks in terms of conditions and consequence(s). Capture the context of the risks; e.g., what, when, where, how, and why. Methods such as FMEA and fault-tree analysis can help to identify risks. Key areas to assess include safety, performance, schedule, budget, requirements, technology, management supportability, logistics and maintenance operations, and programmatic. Analyze Risks Evaluate risks, including: Probability Impact/severity Timeframe (when action needs to be taken) Classify/group similar/related risks. Prioritize. Methods such as probabilistic risk assessment (PRA) can help to analyze risks. Plan for Action Assign responsibility for each risk. Determine approach for each risk (research, accept, mitigate, or monitor). Typical risk attributes for each approach are as follows: Research High-cost mitigation, long time to effect, uncertainty in analysis of likelihood and consequence

4-101

Project Management: SE & Project Control Processes & Requirements

Project Data Risk Management Plan FTA FMEA Results Constraints

Lessons Learned PRA Results Expert Opinion Test Data Other Technical Analysis Hazard Analysis

START Identify Risks

Statements of Risks Risk Evaluation, Classification, and Prioritization

Analyze Risks

Resources Project Goals and Constraints

Plan for Action

Risk Mitigation Plans Risk Acceptance Criteria Risk Tracking Plan

Project Data Resources

Track

Risk Status Reports

NOTE: Communication and

documentation occurs throughout all of the activities

Control

KEY

Step/Activity

Information/Products

Information/Output Flows

Figure 4.3-2. Risk management process diagram. Accept Low consequence, fairly low likelihood, any timeframe, any cost Mitigate High-medium consequence, high and medium likelihood, near to mid term, high-medium and low cost to mitigate Monitor Low-medium likelihood, lowmedium consequence, mid and far term, high-medium and low cost to mitigate For each risk that will be mitigated, define mitigation level (e.g., action item list or more detailed task plan) and goal, and include budget estimates. Track Acquire/update, compile, analyze, and organize risk data. Report results/status. Verify and validate mitigation actions. Control Analyze results of mitigation actions. Decide how to proceed (re-plan, close the risk, invoke contingency plans, continue tracking). Execute the control decisions. The project manager shall personally review the formal acceptance and closure of all project risks. Communicate and Document Communicate essential risks status to the entire team on a regular basis. The project manager shall report project risk status, especially a status concerning primary risks (i.e., those with both high probability and high impact/severity) to the program manager, directorate-level organization (DLO) management, and appropriate project governing management forums (e.g., directorate project management board, JSC Engineering Review Board (ERB), or JSC Project Management Council (PMC)). Implement a system for documenting and tracking risk decisions. 4.3.2.7 Outputs The Risk Management process is performed over the entire life cycle of the system of interest. A preliminary risk management plan is required during Phase A, with an update required during Phase B. In addition, outputs include risk: Statements Evaluations Mitigation plans Acceptance criteria

4-102

Project Management Processes

Tracking plans Status reports 4.3.2.8 Exit criteria Since risk management is conducted throughout the project life cycle, the overall exit criterion is the safe and orderly achievement of system of interest disposal. 4.3.2.9 Measurement The following provides example base and derived measures that can be used in conjunction with executing the Risk Management process. See discussion of Measurement on page 4-1. Base Measures Identify Total # of Risks Identified Analyze Total # of Risks of High Probability and/or High Impact (primary risks) Identified Plan # of Risks with Chosen Approach Research # of Risks with Chosen Approach Accept # of Risks with Chosen Approach Monitor # of Risks with Chosen Approach Mitigate Total # of Mitigation Plans Developed

4.3.2.10 Methods and techniques1,5 Methods and techniques applicable to the Risk Management process include: Individual or group expert judgment. Statistical analysis of historical data. Uncertainty analysis of cost, performance, and schedule projects (consists of building and running a probabilistic model of the system under investigation, including the chance variation inherent in real-life cost, performance, and schedule).

Derived Measures

# of Primary Risks Encountered vs. Total # of Risks Identified % Risks Identified Rate Charts

Total # of Risks Identified vs. Total # of Risks with Chosen Approach Research % Total # of Risks Identified vs. Total # of Risks with Chosen Approach Accept % Total # of Risks Identified vs. Total # of Risks with Chosen Approach Monitor % Total # of Risks Identified vs. Total # of Risks with Total # of Mitigate % Mitigation Plan Development Rate Charts Total # of Mitigation Plans Developed vs. Total # of Risks Identified % # of Mitigation Plans for Primary Risks Developed vs. Total # of Mitigation Plans Developed Total # of Risks Eliminated vs. Total # of Risks Identified % # of Primary Risks Eliminated vs. Total # of Risks Eliminated # of Primary Risks Eliminated vs. Total # of Primary Risks Identified Risk Elimination Rate Charts

Track Total # of Risks Eliminated

Overall Process Risk Management Effort (FTEs) Risk Management Productivity Risk Management Effort Planned vs. Actuals Risk Management Effort as % of Total Engineering Effort

4-103

Project Management: SE & Project Control Processes & Requirements

PRA (also known as probabilistic safety assessment (PSA) and quantitative risk assessment (QRA)). FTA and FMEA. Ordinal risk scales. Comparison to analogous systems. Risk assessment matrix. 4.3.2.11 Software tools Principal considerations for a S/W tool that would support the Risk Management process are the consistent, concise, and thorough documentation both of the risk characterization (probability and impact) and of the mitigation progress of each risk. Common and convenient accessibility and visibility to all project team members and stakeholders is also a primary consideration. The Integrated Risk Management Application (IRMA) is a custom-built database tool that is used by the International Space Station Program. JSC projects should consider use of this already existing tool as their risk management application. A plan is being considered for adopting IRMA NASA-wide to support unifying the risk management effort across the Agency. 4.3.2.12 References The following documents and Web sites, which were used to prepare this section, offer additional insights into the Risk Management process: 1 NPR 8000.4, Risk Management Procedures and Guidelines, 2002. 2 CMMI-SE/ SW/IPPD/SS V1.1, Capability Maturity Model Integration (CMMI) for Systems Engineering, Software Engineering, Integrated Product and Process Development, and Supplier Sourcing, 2002.
3

College, Second Edition, 1999. This document can be downloaded from: http://www.dsmc.dsm.mil/pubs/pubsgen.htm 9 SSP 51079, International Space Station Program Risk Management Plan , Revision A, 2002. Information on: Risks associated with computer systems can be found in the National Institute of Standards and Technology (NIST) publication: SP 800-12, An Introduction to Computer Security: the NIST Handbook , available at http://csrc.nist.gov/publications/nistpubs/800-12/. Implementation of risk-based acquisition management (R-BAM) can be found at http://www.grc.nasa.gov/WWW/spaceiso/rbam/ . The Continuous Risk Management process may be found at http:///www.srqa.jsc.nasa.gov/riskmgmt/.

NPR 71xx.x (document number not yet assigned), NASA Systems Engineering Processes and Requirements . 4 NPR 7120.5B, NASA Program and Project Management Processes and Requirements, 2002. 5 RP 1358, Systems Engineering Toolbox for Design-Oriented Engineers, 1994.
6

Probabilistic Risk Assessment Procedures Guide for NASA Managers and Practitioners, Version 1.1, http://www.hq.nasa.gov/office/doeq/doctree/pragui de.pdf 7 NTIS AD-319533KKG, DTIC#:AD-A319 533\6\ XAB, Continuous Risk Management Guidebook , Software Engineering Institute at Carnegie Mellon University, 1996. 8 The Department of Defense, Risk Management Guide for DoD Acquisition. Defense Acquisition University and Defense Systems Management

4-104

Project Management Processes

4.3.3 Configuration Management1,2 Configuration management (CM) is performed on projects to establish and maintain the integrity of a system of interests products and controlling project baselines using configuration planning, configuration identification, configuration control, configuration status accounting, and configuration verification. The requirements on the part of the SE and project control efforts are to provide technical support to the overall project CM established by the project manager per NPG 7120.5B.3 4.3.3.1 Function1 In the Configuration Management process: The projects overall plan and process for achieving CM shall be developed. The work products that are to be placed under configuration control shall be identified. The configuration of selected work products that compose the baselines at given points in time shall be identified. The control and communication of changes to configuration items (CIs) shall be conducted. Status accounting and current configuration data for configuration-controlled items shall be provided. Configuration verification shall be supported. 4.3.3.2 Objective The primary objective of the SE and project control Configuration Management process is to assure that the physical configuration of a product is adequately identified, documented, and controlled to a level of detail sufficient to repeatedly produce that product and meet anticipated needs for operation, quality management, maintenance, repair, and replacement. 4.3.3.3 Responsibilities2 The Lead Systems Engineer is responsible for ensuring the completeness and technical integrity of the techLife Cycle Phase Preliminary Analysis Definition Design

nical baseline and for ensuring that it is consistent with the costs and schedules in the business baseline. The Project Manager is responsible for establishing a Configuration Management process for the project, including a Configuration Control Board (CCB) or equivalent. The Project Control Officer conceives, implements, and manages the CM system, and documents it in a CM plan; acts as secretary of the project CCB (controls the change review process); controls baseline changes and releases; and initiates and acts on the results of configuration verification activities, including audits. The Quality Assurance Engineer supports the configuration audits to evaluate the evolution of a product to ensure compliance to specifications, policies, and agreements. The Engineering Disciplines support configuration identification for their specific areas, are extensive users of the CM system, and rely on configuration status accounting to manage their CIs and request the proper baselines. The Engineering Disciplines also support the Configuration Manager and the Quality Assurance Engineer with applicable configuration audits. 4.3.3.4 Life cycle The Configuration Management process is concerned with all system of interest products and everything that describes those products from their name to their requirements and documentation. Therefore, CM begins d uring the preliminary analysis phase and continues throughout the life cycle of the system of interest. A CM plan is developed during the preliminary analysis phase. 4.3.3.5 Inputs Typical inputs to the Configuration Management process consist primarily of product baselines and CRs to baselines. Examples of these inputs and their associated life cycle phase are as follows: CM Process Input Operations Concept System/Subsystem Requirements Interface Requirements Specification Architectural Design Interface Design Test Plan and Procedures Operational and Support Manuals Training Materials Product Delivery Technical Performance Data Lessons Learned Disposal Plan

Operations Termination

4-105

Project Management: SE & Project Control Processes & Requirements

4.3.3.6 Steps4 The following diagram (FIG. 4.3-3) illustrates the major steps and products of the SE Configuration Management process. Adhering to the major steps of this process directs the project toward meeting its CM re quirements. For each major process step, additional guidance is provided as to the typical sub-process steps and products that are expected.
Perform CM Planning

Identification Steps Identify CIs and Baselines CIs that will be placed under CM shall be identified. Typical items placed under CM control include plans, processes, designs, drawings, requirements, products, tools, technical baselines, change control forms, and program documentation.

Identify CIs and Baselines

Perform Configuration Audits

Establish CM Records

CM Plans and Processes

Audit Results Project CI and Baseline Definitions

Configuration Reports

Establish CM Systems

CM Systems

Manage CRs Change Control Forms

Control CIs

Release Baselines

CI Baselines

KEY

Step/Activity

Product

Information/Output Flows

Figure 4.3-3. Configuration management process diagram. Planning Steps Perform CM Planning A plan for performing CM on the project shall be defined. Develop the projects overall plan for achieving CM and include as part of the SEMP and PMP, as applicable. Define the projects CM roles and responsibilities. Develop the appropriate CM policies, processes, procedures, and guidelines required to meet the projects CM plan. Provide the project manager with cost and schedule inputs related to CM life cycle activities in support of the project planning effort. Ensure that at least a top-level/partial version of the CM plan is available at Mission Definition Review (MDR), and a final/approved version is available at System Design Review (SDR). Select the CIs and the work products that compose the CIs based on documented criteria. Assign unique identifiers to CIs using a predetermined method. Specify important characteristics of each CI (e.g., author, document or file type, publication date or version identifier, and pro gramming language for S/W code files). Specify when each CI is placed under CM. Example criteria for determining when to place work products under CM include the stage of the project life cycle, when the work product is ready for test, degree of control desired on the work product, cost and schedule limitations, and customer requirements. Identify the owner responsible for each CI. Identify CI baselines that may be used for internal use and for delivery to the customer.

4-106

Project Management Processes

Establish a CM System A CM system, including a change management process for controlling work products, shall be established and maintained. Establish a mechanism to manage multiple control levels of CM; e.g., mechanisms for managing the differences in the levels of control needed at different times in the project life cycle, differences in the levels of control needed for different types of systems, and differences in the levels of control needed to satisfy privacy and security requirements for the CIs. Create CM reports from the CM system. Preserve the contents of the CM system (i.e., backup, archiving, and recovery functions). Control Steps Manage CRs CRs to CIs shall be tracked. Initiate and record CRs in the CR repository. Problem/change report Specification change notice Engineering change proposal Request for deviation/waiver Analyze the impact of changes and fixes proposed in the CRs. Review CRs that will be addressed in the next baseline with those organizations that will be affected by the changes and get their agreement. Track the status of CRs to closure. Control CIs Changes to CIs, throughout the life of the product, shall be controlled. Configuration control maintains the integrity of the CIs identified by facilitating approved changes and prevents the incorporation of unapproved changes into the baseline. Verify appropriate authorization was obtained before changed CIs are entered into the CM system. Authorization may be in the form of approval from a projectestablished CCB. Check in and check out CIs from the CM system for incorporation of changes in a manner that maintains the correctness and ingenuity of the CIs. Perform reviews to ensure that changes have not caused unintended effects on the baselines (e.g., ensure that changes have not compromised the safety and/or security of the system). Record changes to CIs and the reasons for the changes, as appropriate.

Release Baselines Baselines for internal use and for delivery to the customer shall be released. Release of a baseline involves approving a set of configuration data for the agreed-on set of CIs from the CM systems and releasing the baseline for further development. Multiple baselines may be used to define an evolving product during its development cycle. Obtain authorization from the CCB before creating or releasing baselines of CIs. Create or release baselines only from CIs in the CM system. Document the set of CIs that is contained in a baseline. Make the current set of baselines readily available. Status Steps Establish CM Records Records describing CIs shall be established and maintained. Record CM actions in sufficient detail so that the content and status of each CI is known and previous versions can be recovered. Ensure that relevant stakeholders have access to and knowledge of the configuration status of the CIs. Specify the latest version of the baselines . Identify the version of the CIs that constitute a particular baseline. Describe the differences between successive baselines. Revise the status and history (i.e., changes and other actions) of each CI, as necessary. Audit Steps Perform Configuration Verification Configuration audits to maintain integrity of the configuration baselines and ensure process integrity shall be supported. Assess the integrity of the baselines. Confirm that the configuration records correctly identify the configuration of the CIs. Review the structure and integrity of the items in the CM system. Confirm the completeness and correctness of the items in the CM system. Confirm compliance with applicable CM standards and procedures. Track action items from audit to closure. 4.3.3.7 Outputs4 Primary outputs from this process are: CM plans/processes/CM procedure(s) CM system

4-107

Project Management: SE & Project Control Processes & Requirements

Project CIs CI baselines Change control forms configuration reports Configuration audit results

4.3.3.8 Exit criteria Since CM is an ongoing function throughout the system of interest life cycle until retirement, there are no specific exit criteria. However, there are some items that are required to move from one life cycle phase to the next. Some examples of these are: Released and approved CM plan or updated version Established list of project CIs Implemented CM system containing the identified CIs Established and controlled CI baselines Published configuration audit results 4.3.3.9 Measurement The following table provides example base and derived measures that can be used in conjunction with the Configuration Management process. See discussion of Measurement on page 4-1. Base Measures # of CIs and Associated Size (or complexity) CI Status CR Status (classifications include change, problem, deviation, waiver) Effort for CM (FTEs)

lead to changes in formal baselines and internally controlled items. The following examples provide an organized approach to change tracking: Problem/Change Report To document problems and recommend enhancements to CIs or complementary documentation. Can be used to identify problems during design, development, integration, test, and operations. Specification Change Notice To propose, transmit, and record changes to baselined specifications. Engineering Change Proposal To propose changes to the customer. This proposal describes the advantages and disadvantages of the proposed change as well as available alternatives and the schedule and funding needed to proceed. Request for Deviation/Waiver To request and document temporary deviations from configuration identification requirements when permanent changes to provide conformity to an established baseline are not acceptable. 4.3.3.11 Software tools Suggested tools are: A database management system to capture and control CIs; to identify, control, and release baselines; and to provide status accounting reports . Derived Measures CI Content Planned vs. Actuals CI Status Summary (monthly as a minimum) CR Status Summary # Open, Approved, Rejected, InProcess, Closed, Common Reason for Change CM Effort Planned vs. Actuals CM Effort as % Total Engineering Effort

CM Activity Status CM Records Status

CM Activities Status Summary CM Records Status Summary CM Effort Planned vs. Actuals; per CR Type; per Life Cycle Phase CM Rate Charts Change Rate, Change Process, Cycle Time CM Effort as % Total Engineering Effort

4.3.3.10 Methods and techniques Several methods and techniques, such as general auditing techniques, are available. Additional process tools and techniques are listed in JSC International Standards Organization (ISO) SLP 4.20, Process Measurement and Improvement.5 Also, change control forms provide a standard method of reporting problems and enhancements that

Standard office automation products to create standardized change control forms and audit reports. A workflow system to handle CR tracking and approval.

4-108

Project Management Processes

4.3.3.12 References The following documents, which were used to prepare this section, offer additional insights into the Configuration Management process: 1 NPR 71xx.x (document number not yet assigned), NASA Systems Engineering Processes and Requirements. 2 SP 6105, NASA Systems Engineering Handbook , 1995. 3 NPR 7120.5B, NASA Program and Project Management Processes and Requirements, 2002.
4

CMMI-SE/SW/IPPD/SS V1.1, Capability Maturity Model Integration (CMMI) for Systems Engineering, Software Engineering, Integrated Product and Process Development, and Supplier Sourcing, 2002. 5 SLP 4.20, Process Measurement and Improvement.
6

INCOSE Systems Engineering Handbook , Version 2.0, 2000. 7 EIA-632, Processes for Engineering a System, 1999.

4-109

Project Management: SE & Project Control Processes & Requirements

4.3.4 Quality Management16 The Quality Management process is performed to assure the use and integration of high standards of quality within the PM effort to reduce technical risk. This process addresses the quality of the processes that are being used to create the system of interest. High-quality products can only be produced, on a continuous basis, if a process exists to continuously measure and improve the quality of processes used to produce the system of interest products. This process emphasizes establishment of goals and subsequent measurements, analysis, and implementation of corrective actions to attain those goals. The intent of quality is to ensure products or services are offered that meet defined needs, satisfy stakeholders expectations, and comply with applicable standards and procedures. The Quality Management process involves (1) objectively evaluating performed processes, work products, and services against applicable process descriptions, standards, and procedures; (2) identifying and documenting noncomp liance issues; (3) ensuring that noncompliance issues are addressed; (4) capturing, reporting, and reviewing lessons learned; and (5) providing feedback to project staff and managers on the results of quality activities. This process supports the delivery of high-quality products by providing project staff and managers at all levels with appropriate visibility into, and feedback on, processes and associated work products throughout the life of the project. NASA and JSC policies, procedures, and guidelines (ref. NPD 1280.1,7 JPD 5335.1,8 and JPG 5335.34 ) establish organizational and project expectations to objectively evaluate processes and products. These e xpectations encompass assurances that (1) customer requirements are determined, maintained, and satisfied; (2) products and services are planned, developed under controlled conditions, measured, reviewed, and improved; and (3) processes and their interactions used to provide products and services are planned, measured, reviewed, and improved. This Quality Management process provides a mechanism for implementing many of these policies, procedures, and guidelines. See Section 4.1.11 for details on quality assurance (QA) activities. 4.3.4.1 Function1 In the Quality Management process: Reliable and repetitive procedures and processes shall be identified and established. Established procedures and processes shall be used to manage the project and design of the system. The quality process shall ensure that system of interest products meet the design (i.e., as-built meets the as designed) and the records of compliance are maintained.

Continuous improvement and lessons learned within the procedures and processes shall be incorporated. 4.3.4.2 Objective 2,7 The objective of this process is to identify and establish processes and procedures to manage and design the system, to measure process performance, and to perform continuous improvement of the processes based on objective data. Not only is quality ex pected of the system of interest as it matures but the processes used to build in quality are under continuous review for effectiveness, value to stakeholders, and improvement opportunities. 4.3.4.3 Responsibilities9 It is the responsibility of the Project Manager to ensure that project planning documents include welldefined, quality-related processes and strategies that will be followed by the project team and that are in accordance with the JSC Quality Management System.4 The Project Manager and the Lead Systems Engineer need to have confidence that the system of in terest produced and delivered is in accordance with its functional, performance, and design requirements. The Project Control Officer is responsible for implementing the Quality Management process for the project with technical support from the Lead Systems Engineer. 4.3.4.4 Life cycle The Quality Management process is pervasive throughout the project life cycle. Quality Management process expectations begin at project conception and are applied increasingly as the system of interest matures through design, development, integration, test, deployment, operation, and disposal. During the early stages of the life cycle, the focus is on ensuring that the quality management system policy is being properly applied; i.e., appropriate processes and procedures are established based on the needs of the project. As the project matures, the emphasis shifts to assessments of process applications; i.e., are the processes being executed as described, and are the work products being produced in accordance with requirements and specifications. 4.3.4.5 Inputs The following are typical inputs to the Quality Management process: Project plans Center processes, standards, and work instructions Process tailoring guidelines

4-110

Project Management Processes

4.3.4.6 Steps3,10,11 The following diagram (FIG. 4.3-4) illustrates the major steps of the Quality Management process. Details of these steps are provided below.
Apply Processes and Practices Review Lessons Learned Identify Applicable Processes Tailor Processes Project Processes

to process owners any particular strengths or weaknesses of the selected processes.

Identify Lessons Learned

Evaluate Process Performances

Project Processes

Select Processes for Evaluation

Establish and Maintain Process Evaluation Criteria

Select Process Measures

Monitor Processes

Evaluate Selected Processes

Identify Lessons Learned

Evaluate Work Products

Work Products

Select Work Products for Evaluation

Establish and Maintain Work Product Evaluation Criteria

Select Product Measures

Monitor Work Products

Evaluate Selected Work Products

Identify Lessons Learned

Ensure Resolution of Noncompliance Issues

Resolve Noncompliance Issues

Document Unresolved Issues

Escalate Unresolved Issues

Analyze Trends

Inform Relevant Stakeholders

Review Open Issues

Track Noncompliance Issues

Establish Records

Capture Lessons Learned

Lessons Learned

Record Activities

Revise Status

Quality Process Status Report

KEY

Step/Activity

Product

Information/Output Flows

Connector

Figure 4.3-4. Quality management process diagram. Apply Processes and Practices All projectrelated processes and practices shall be properly established and tailored as required, and addressed in the project plan and associated project documentation. Review Lessons Learned Review lessons learned to establish an awareness of issues and problems previously identified. Identify Applicable Processes Determine which JSC processes are applicable to the project. Tailor Processes for the Project Tailor identified processes to meet specific needs of the project. Identify Lessons Learned Identify and capture lessons learned and best practices that could improve future projects and their processes. In particular, identify and report Evaluate Process Performance Performed processes shall be objectively evaluated against applicable process descriptions, standards, and procedures. Select Processes for Evaluation Identify the processes that will be evaluated based on criticality of the process to meet project needs. Establish and Maintain Process Evaluation Criteria Establish and maintain clearly stated criteria for process evaluations to determine appropriate levels of process performance based on project needs. Select Process Measures Select a set of measurements that supports the evaluation criteria (see Section 4.2.5, Performance Measurement). Monitor Process Performance and Collect Process Measures

4-111

Project Management: SE & Project Control Processes & Requirements

Evaluate Selected Processes Use the stated criteria to evaluate performed processes. Identify Lessons Learned Identify and capture lessons learned and best practices that could improve future projects and their processes. Evaluate Work products Work products and services shall be objectively evaluated against the applicable product descriptions, standards, and procedures. Select Work Products for Evaluation Identify work products to be evaluated based on documented sampling criteria, if sampling is used. Establish and Maintain Work Product Evaluation Criteria Clearly state criteria by which to evaluate work products. The intent is to provide criteria based on project needs such as: What will be assessed during the evaluation of a work product? When or how often will a work product be evaluated? How will the evaluation be conducted? Who must be involved in the evaluation? Select Product Measures Select a set of measurements that supports the evaluation criteria (see Section 4.2.5, Performance Measurement). Monitor the Development of Work Products and Collect Product Measures Evaluate Work Products Evaluate work products by: Using the standard criteria during evaluations of work products. Evaluating work products before they are delivered to the customer. Evaluating work products at selected milestones in their development. Performing in-progress or incremental evaluations of work products and services against process descriptions, standards, and procedures. Identifying each case of noncompliance found during the evaluations. Identify Lessons Learned Identify and capture lessons learned and best practices that could improve future projects and their work products. Ensure Resolution of Noncompliance Issues Quality issues and resolution of noncompliance issues shall be communicated with project staff and management, regardless of whether issues are process or work product related.

Resolve Noncompliance Issues Resolve each noncompliance issue with the appropriate members of the project where possible. Document Unresolved Issues Document noncompliance issues when they cannot be resolved within the project. Escalate Unresolved Issues Escalate noncompliance issues that cannot be resolved within the project to the appropriate level of management. Analyze Trends Analyze nonconformance issues to see if there are any quality trends that can be identified and addressed. Identify whether nonconformance issues are caused by noncompliance with established processes or by process deficiencies. Inform Relevant Stakeholders Ensure that relevant stakeholders are aware of the results of the evaluations and the quality trends. Communicate process deficiencies or improvement opportunities to the process owner so that they are addressed as part of continuous process improvement. The process owner can be at the project, directorate, or Center level. Examples of Center-level process owners include the JSC Systems Engineering Working Group (J-SEWG), the Software Engineering Process Group (SEPG), and the Project Management Working Group (PMWG). Review Open Noncompliance Issues Periodically review open noncompliance issues and trends with the manager who is designated to receive and act on noncompliance issues. Track Noncompliance Issues Track noncompliance issues to resolution. Establish Records Quality records shall be established and maintained. Capture Lessons Learned Record lessons learned that were identified in previous steps in this process. Ensure lessons learned are available for review. Report lessons learned, as required. Record Activities Record process and product quality management activities in sufficient detail such that status and results are known . Revise Status Revise status and history of the quality management activities, as necessary. 4.3.4.7 Outputs2,3 Outputs of the Quality Management process are: Project-specific processes and work instructions. Process and work product evaluation criteria. Process and work product evaluation reports.

4-112

Project Management Processes

Lessons learned, best practices, and improvement opportunities. Trouble/noncompliance reports. Corrective action reports. Quality trends. 4.3.4.8 Exit criteria2 Quality management is an ongoing process that is never actually completed until project termination. However, throughout the project life cycle the following criteria shall be evident: Corrective action identification and mitigation plans Lessons learned identification, capture, and dissemination Improvement opportunity identification, capture, and dissemination 4.3.4.9 Measurement The following table provides example base and derived measures that can be used in conjunction with executing the Quality Management process. See discussion of Measurement on page 4-1. Base Measures Tailoring Report Completion # of Processes Tailored (i.e., modified or tailored out)

Cause analysis tools Analysis tools Mathematical modeling tools Process illustration and simulation tools Process checklists

4.3.4.12 References The following documents, which were used to prepare this section, offer additional insights into the Quality Management process: 1 NPR 71xx.x (document number not yet assigned), NASA Systems Engineering Processes and Requirements. 2 EIA-731.1, Systems Engineering Capability Model, 2002.
3

CMMI-SE/SW/IPPD/SS V1.1, Capability Maturity Model Integration (CMMI) for Systems Engineering, Software Engineering, Integrated Product and Process Development, and Supplier Sourcing, 2002. 4 JPG 5335.3, JSC Quality Management System Quality Manual, 2003. Derived Measures Planned vs. Actual Tailoring Dates % Process Compliance % Processes Modified or Tailored Out

# of Process Assessments # of Corrective Actions (e.g., discrepancy reports)

Planned vs. Actual Process Assessments # of Corrective Action Items vs. # of Corrective Actions Resolved # of Days Past Due for Corrective Action

4.3.4.10 Methods and techniques2 The following are typical methods and techniques used in quality management: Cause and effects diagram Trend analysis Pareto analysis Fishbone (Ishikawa) diagrams Process maps and models Process simulations Surveys, assessments, and audits 4.3.4.11 Software tools2 Typical S/W tools used in the Quality Management process are analysis, simulation, and modeling tools as well as standard office products such as spreadsheets, work processors, and databases. Many of these tools fall into the following categories:

NPR 7120.5B, NASA Program and Project Management Processes and Requirements, 2002.
6

ISO 9001:2000, Quality Management Systems Requirements, 2000. 7 NPD 1280.1, NASA Management System Policy, 2003. (NOTE: This NPD cancelled NPD 8730.3, NASA Quality Management System Policy.) 8 JPD 5335.1, JSC Quality Policy, 2003.
9

SP 6105, NASA Systems Engineering Handbook , 1995. 10 INCOSE Systems Engineering Handbook , Version 2.0, 2000. 11 AG-CWI-001, JSC Lessons Learned Process.

4-113

JSC Project Management: System Engineering & Project Control Processes & Requirements

Appendices

Appendix A

Appendix A Project Management Plan Content Requirements1 A.1 Title Page Includes, at a minimum, signatures of: Center Director or chair, directorate-level board if delegated Program manager (if project is in support of a program) Project manager S&MA organization A.2 Introduction The project is identified by an officially approved title, a NASA program, a program commitment agreement (PCA), and/or unique project number. A brief general history and summary are given, including the projects purpose, goals, overall approach, and timeframe. For multiple NASA center projects, describe the NASA centers project in relationship to the other participating NASA centers. A.3 Objectives State the specific project objectives, the performance goals, and their relationship to the program objectives and goals. Performance goals should be expressed in an objective, quantifiable, and measurable form. A.4 Customer Definition and Advocacy State the main customers of the project (e.g., principal investigator (PI), science community, technology community, public, education community, program and Enterprise sponsor) and the process to be used to ensure customer advocacy. A.5 Project Authority Identify the center where the project manager resides and other center responsibilities, and the Governing Project Management Council (GPMC) responsible for oversight of the project. Provide a chain of accountability and decision path that outlines the roles and responsibilities of the project manager, program manger, Center Director, and other authorities as required. A.6 Management Describe the project management structure, including organization and responsibilities, its integration into the program management structure, and NASA center participation. Identify all significant interfaces with other contributing organizations. Identify specific
1

management tools to support management in planning and controlling the project. Describe any use of special boards and committees. Address any requirement for a NASA Resident Office, including duties and authority. A.7 Project Requirements Document the project requirements, including performance requirements and success criteria, as a flowdown from the program requirements. This includes allocation of these requirements and success criteria among the systems to be developed, both hardware (H/W) and software (S/W). A.8 Technical Summary Present a technical description of the project. This includes the systems to be developed (H/W and S/W), use of the international system of units (SI) measurement system, facilities, flight plans, operations and logistics concepts, and planned mission results analysis and reporting. The technical summary includes the following: System(s) System operations concept System constraints Ground systems and support Facilities Mission results analysis and reporting End of life cycle A.9 Logistics Describe the project logistics requirements; e.g., spares, shipping and handling equipment, transportation, user manuals, simulators, training and training materials, and supporting personnel. A.10 Schedules Document the project master schedule for all major events, independent reviews, and other activities throughout the life cycle of the project. Include approval dates for principal project documentation, life cycle transitions, major reviews, program-controlled milestones, and significant contractor milestones. Identify lower-level schedules to be developed and maintained. A.11 Resources The following resources are to be addressed: a. Funding Requirements Present a funding requirements chart that includes the same elements as for the acquisition summary. Indicate the new obligation authority (NOA) in real-year dollars for the prior, current, and remaining fis cal years. The displayed detail should cover major elements of cost (typically reflecting at least at the second level of the work breakdown structure (WBS) or its equivalent).

NPR 7120.5B, NASA Program and Project Management Processes and Requirements , 2002.

A-1

Project Management: SE & Project Control Processes & Requirements

b. Institutional Requirements Present institutional requirements (use of or development of facilities, workforce) for the entire project throughout its life cycle. Include civil service workforce require ments on the providing organizations for the prior (e.g., actuals), current, and remaining years. A.12 Controls All technical performance, cost, or schedule parameters specified as requiring approval by the Administrator, the Enterprise Associate Administrator (EAA), Center Director, program manager, or appropriate controlling authority should be identified. Examples include funding by year, success criteria, program requirements, project objectives, management structure, and major program/project documentation. Identify the thresholds associated with each parameter that could cause a change request. Describe the process by which project requirements are validated for com pliance with program requirements. Describe the process for controlling changes to these requirements. A.13 Implementation Approach The implementation approach of the project is provided (e.g., in-house, NASA center, contractor prime) as well as a project WBS as follows: Implementation approach Project summary WBS (tied to the higher-level project or program) WBS dictionary A.14 Acquisition Summary Provide summary information on procurement items, such as element (engineering design study, H/W and S/W development, mission and data operations support); type of procurement (competitive, Announcement of Opportunity (AO) for instruments ); type of contract (cost-reimbursable, fixed-price); source (institutional, contractor, other government organizations); procuring activity; and surveillance. A.15 Program/Project Dependencies Other NASA, U.S. agency, and international activities, studies, and agreements are summarized with emphasis on their effect on the program as follows: Related activities and studies; e.g., space communications, launch services, crosscutting technology Related non-NASA activities and studies A.16 Agreements List all agreements necessary for project success and the projected dates of approval. Include all agreements concluded with the authority of the project manager and reference agreements concluded with the authority of the program manager and above as listed below:

NASA agreements; e.g., space communications, launch services Non-NASA agreements Domestic International A.17 Safety and Mission Success Safety and mission success planning is developed either as a section of this project plan or as a separate document. Address the activities and steps to be taken to ensure the safety of the public, the NASA astronauts and pilots, the NASA workforce, and NASAs highvalue equipment and property. Address both H/W and S/W aspects of the project, and identify all activities; e.g., safety, reliability, maintainability, quality assurance, and environmental-related design and test, including orbital debris mitigation, project surveillance, and failure reporting/resolution that are used to ensure the success and safety of the mission. A.18 Risk Management Summarize the risk management approach to be used for the project, including appropriate project de-scope plans. Also identify primary risks consistent with NPR 7120.5B, paragraph 4.3.2d. A risk management plan is also developed and includes the content shown in NPR 8000.4, Risk Management Procedures and Guidelines. A.19 Environmental Impact Identify the documentation and schedule of events associated with environmental compliance considerations (NEPA and other requirements). This may inclu de environmental assessment (EA) or an environmental impact statement (see NPR 7120.5B, paragraph 4.6.5). A.20 Test and Verification Describe the project approach to test and verification for assurance of project success. This should address requirements for H/W and S/W verification and validation, as well as S/W independent verification and validation per NPD 8730.4, NASA Software In dependent Verification and Validation (IV&V) Policy. A.21 Technology Assessment Identify the NASA crosscutting or other technology thrusts to be used by the project. Identify the technologies the project expects to mature during the life of the program. Briefly describe how these technologies will be developed and infused. Describe how and when the project will evaluate the feasibility, readiness, cost, risk, and benefits of the new technologies. A.22 Commercialization Identify near-term opportunities for commercializa tion. Describe the methods to be used to identify additional opportunities throughout the project life cycle.

A-2

Appendix A

A.23 Reviews Provide the names, purposes, content, and timing of all reviews. Explain the reporting requirements for program and project reviews. A.24 Termination Review Criteria Provide the technical, scientific, schedule, cost, and other threshold criteria that will be used to initiate a termination review. A.25 Tailoring Identify those requirements for which the approach to compliance has been tailored consistent with project characteristics such as scope, complexity, visibility, cost, safety, and acceptable risk. Provide the rationale for such tailoring. A.26 Change Log Changes to the project plan should be documented in a change log.

A-3

Appendix B

Appendix B Systems Engineering Management Plan Outline The Systems Engineering Management Plan (SEMP) is the top-level, integrated planning document for managing the technical effort. The SEMP defines how the project will be organized, structured, and conducted, and how the total engineering process will be controlled to provide a product that satisfies customer requirements. The SEMP should incorporate what the project needs to do to accomplish the technical efforts, describing how the efforts will be carried out, who will accomplish them, how they will be controlled, and how technology will be transitioned from the technology base to system-ofinterest products. This appendix provides a preferred outline for an SEMP. This outline is presented as an aid to the user of this Johnson Space Center (JSC) Procedures and Guidelines (JPG). The user may tailor the actual content of the SEMP. B.1 Description of the System of Interest Describe the: a. System of interest structure to include the products (subsystems or system elements) that will make up the system of interest and also the enabling systems that will be related to the system of interest over its life. b. Describe the key technical objectives and expected deliverables applicable to the systems engineering (SE) effort based on the entry and exit criteria of the applicable system life cycle stage.

What work will be done in executing the process. Who has overall responsibility for the success of the process, and who provides support in the execution of the process. Who will do the work, when will the work be done, and where will the work be done. The specific inputs required to conduct the process, including dependencies among work efforts such as what information will be needed to perform the work, where the work will come from, and when the work will be needed. The actual steps to be followed and their sequence of occurrence. Indicate any deviations from the recommended approach. The expected products and outcomes to be produced in the execution of the process, including tracking with respect to who will use and/or require the results. Any measurements to be used in tracking and managing the execution of the process. How exit criteria will be satisfied. Any specific methods, techniques, and tools to be used to conduct the process. B.3 Software Development (can refer to a standalone plan if one is applicable) Software development entails describing: a. The processes and tasks to be completed for developing software (S/W) products. b. Methods and tools that are used to accomplish S/W development processes and/or tasks. c. Any special organizational approaches to ensure that efficient use of embedded or standalone computer and S/W products will be accomplished in the SE efforts related to the system-of-interest structure.

B.2

Description of the Technical Processes For each system of interest, describe implementation of the following technical process from Section 4 of this JPG: Requirements development Requirements management Operations concept development Decomposition Feasibility study Technology planning Design Attainment Integration Systems analysis Verification Validation For each process describe:

B.4

Project Technical Management Processes The project technical management process involves the following: a. Describe how each of the following technical management processes from Section 4 of this JPG is used to support the technical work defined in Section B.2 above: Acquisition management Technical work and resource management Risk management Configuration management (CM) Safety and mission success Control

B-1

Project Management: SE & Project Control Processes & Requirements

Quality management Reviews b. Describe the hooks/relationships to NASA NPR 7120.5 and other such management policy guidance documents. c. Provide reference, as appropriate, to each standalone plan that provides more complete descriptions of processes such as cost and schedule control, risk management, logistics support, CM, interface management, quality assurance (QA), requirements management, change management, and information management. B.5 Organization (Team) Structure For the organization structure: a. Describe the special skills and expertise required to provide members to teams involved with engineering the system of interest.

b. Describe any gaps in skills and/or knowledge of the existing workforce, and identify and describe training that will be accomplished to provide needed skills and/or knowledge. c. Explain how personnel will be assigned to teams to ensure that integrated, multi-disciplinary teamwork will be accomplished to define, design, and realize required products. B.6 Other Systems Engineering Concerns Other SE concerns include: Budget Schedule Planned technology transitions Long lead items Other considerations for support required from the project or customer

B-2

Appendix C Trace of Project Management Processes to Life Cycle

C-1

Appendix D

Appendix D Project Tailoring Guidelines The basic requirements expected from a Johnson Space Center (JSC) project are detailed in this document. However, because of the wide variety and size of projects, it may be necessary to allow some form of tailoring. This is acceptable as an effort to optimize the project processes and requirements and to encourage development of innovative practices. The project should assess a wide variety of factors to determine both the appropriate and the necessary level of tailoring required. These factors include: Type of project Approach of project Project funding (including funding profile) Project timeline Level of risk acceptable to the customer Level of insight/control acceptable to the customer

Criticality of the project (if any) Experience level of the project team members and support team members Lessons learned from other tailoring efforts by other projects Acquisition approach Every project is strongly encouraged to hold tailoring discussions, which include the customer, to identify areas that might be possible candidates. These discussions and any final decision should be documented as part of the project documentation. As a final step, any project tailoring that is to be implemented on the project is recorded in the project management plan prior to formal directorate and JSC Project Management Council approval (see Section 1.2).

D-1

Appendix E Terms and Definitions

Term(s)
Acquisition Recommendations

Definition
Recommendations to the project acquisition strategies that include: Inputs based on technical judgments items such as: technology maturity, civil service workforce knowledge and skill base, cost effectiveness, work complexity, and existence of facilities or other infrastructure to perform the work Lists of products to be acquired and the applicable acquisition type based on a Make/Buy Analysis Evaluation of suppliers based on their ability to meet specified requirements and established criteria The acquisition team generates a requirement set for each acquisition, including, as applicable, statements of work (SOWs), solicitations (request for proposal (RFP), request for quotes (RFQ)), detailed specifications, documentation deliverables, cost, schedule/ long lead, and any other applicable documents. Technical inputs related to the acquisition requirements are provided by the systems engineering (SE) function. The transformation of a solution into a product. Typically used to document requirements (deliverables and quantities, budget plans, and schedules) and responsibilities; examples include an internal task agreement (ITA), a memorandum of agreement (MOA), and an interdivisional agreement (IA). A formal approval provided by the Johnson Space Center (JSC) Project Management Council (PMC) to implement a JSC project. This approval marks a commitment by the Center to execute the project within the plans and resource envelopes authorized at the time this approval is given. The technical performance and content, technology application, schedule milestones, and budget (including contingency and APA) that are documented in approved program and project plans. Official version of a configuration-controlled item that can only be changed through a formal review, evaluation, or approval procedure (Configuration Management (CM) Process section) Flight system certification documents the results of successful hardware (H/W) qualification testing of the qualification unit and H/W and/or software (S/W) acceptance testing of the flight unit. Certification documentation includes the following: identification (part number, part name), baseline requirements and associated verifications, safety data package, baseline test and analysis, documentation (qualification and acceptance plans, procedures, reports), limited-life item list, approved waivers, or deviations and material usage agreements (MUAs), etc. A management decision process, by the designated review authority, that marks progress in project maturity and risk reduction. A control gate is a process rather than a single formal meeting. It is a tool to achieve consensus about the status of the project. It is a gate in the sense that the effort must successfully complete the associated prerequisite review(s) to move to the next step or life cycle phase in the project. An aggregation of work products that is designated for CM and treated as a single entity in the CM process. A management discipline applied over the product life cycle to provide visibility, and to control performance and functional and physical characteristics. The individual designated by the project management plan (PMP) as being responsible for initiating a milestone review. The convening authority establishes review purpose, scope, and entry and exit criteria as well as assigns a review board chairperson.

Reference (if applicable)

Acquisition Requirements

Attainment Agreement

Authorization to Proceed (ATP)

Baseline

NPR 7120.5B

Certification

Control Gate

Configuration Item Configuration Management

NPR 7120.5B

Convening Authority

E-1

Project Management: SE & Project Control Processes & Requirements

Term(s)
Customer

Definition
A customer is the party (individual, project, or organization) responsible for accepting the product or for authorizing payment. The customer is external to the project, but not necessarily external to the organization. The customer may be a higher-level project. Customers are a subset of stakeholders. Any individual, organization, or other entity to which a project or project provides a product(s) and/or service(s).

Reference (if applicable)


CMMI v1.1

NPR 7120.5B

Decomposition Enabling System

The division and allocation of high-level systems, requirements, or customer needs into lower-level components or parts. A system that complements the system of interest but does not contribute directly to its functionality. Each system of interest has a set of enabling systems that allows the system of interest to perform its life cycle functions. A collection of documents, decisions, and previously scheduled events that must be accomplished or available at the start of stage processes. A collection of documents, decisions, and previously scheduled events that must be accomplished at the end of the stage before proceeding to a subsequent stage. The total of direct, indirect, recurring, nonrecurring, and other related NPR expenses incurred or estimated to be incurred in the design, development, verification, production, operation, maintenance, support, and retirement of a system over its planned lifespan. Plans that describe what logistics activities are planned and how they will be conducted and integrated into the SE process. Logistics activities include maintenance, personnel and training, supply support, test and support equipment, transportation and handling, facilities, and disposal. A measurement taken over a period of time that communicates vital information about a process or an activity. A metric should derive appropriate action. A major activity required to accomplish an Agency goal or to effectively pursue a scientific, a technological, or an engineering opportunity directly related to an Agency goal. Mission needs are independent of any particular system or technological solution. Operational scenarios are a step-by-step description of how the proposed system should operate and interact with its users and its external interfaces (e.g., other systems). An active member of the project or program. A major activity within an Enterprise that has defined goals, objectives, requirements, and funding levels, and consists of one or more projects. An organized activity with a finite time span that has defined goals, objectives, requirements, and LEE, and that consumes resources and yields either: a. a new or revised product or service that meets the Agencys strategic needs. b. A new capability applicable to current or future products or processes that will support future Agency needs. A statement that identifies a product or process operational, functional, or design characteristic or constraint that is unambiguous, testable or measurable, and necessary for product or process acceptability (by consumers or internal quality assurance (QA) guidelines. The combination of the likelihood of various outcomes and their distinct consequences. NPR 7120.5B NPR 7120.5B NPR 71xx.x (document number not yet assigned)

Entrance Criteria

Exit Criteria

Life Cycle Cost (LCC)

Logistics Support Plans

SP 6105

Metric

NPR 7120.5B

Mission

NPR 7120.5B

Operational Concepts

Participant Program

Project

Draft NPR 7120.5C

Requirement

IEEE 1220-1998

Risk

SP 6105

E-2

Appendix E Terms and Definitions

Term(s)
Risk Management

Definition
An organized, systematic decision-making process that efficiently identifies, analyzes, plans, tracks, controls, communicates, and documents risk to increase the likelihood of achieving program/ project goals. The application of specific knowledge and analytic methods in support of SE processes. Specialty engineering disciplines typically include safety, reliability, maintainability, quality assurance, S/W assurance, environment, fabrication, test and verification, human factors, training, operations, information systems, logistics, and maintenance. A stakeholder is a group of an individual that is affected by or in some way accountable for the outcome of an undertaking. Stakeholders may include project members, suppliers, customers, end users, and others. An individual or organization having no interest (or stake) in the outcome or deliverable of a program or project. The combination of elements that functions together to produce the capability required to meet a need. Elements include all H/W, S/W, equipment, facilities, personnel, and processes and procedures needed for this purpose. The entity that the engineering team is responsible for designing, developing, integrating, and testing. SE is defined as a disciplined approach for the definition, implementation, integration, and operation of a system (product or service). The emphasis is on achieving stakeholder functional, physical, and operational performance requirements in the intended use environments over the systems planned life and within cost and schedule constraints. SE includes the engineering processes and technical management processes that consider the interface relationships across all elements of the system, other systems, or as a part of a larger system. A documented plan that addresses all relevant technical and engineering management planning items necessary to achieve the mutual understanding, commitment, and performance of individuals, groups, and organizations that must execute or support the technical effort . The SEMP defines all aspects of the technical effort, tying together in a logical manner: project life cycle considerations; technical and management tasks; budgets and schedules; milestones; data management, risk identification, resource and skill requirements; and stakeholder identification and interaction. Infrastructure descriptions include responsibility and authority relationships for the technical staff, management, and support organizations. Depending on the nature of the project, SEMP content may be contained in a standalone document or embedded in the PMP. Key indicators of key performance that, if not met, put the project at cost, schedule, and performance risk. The most useful TPMs are those that provide visibility into the technical performance of key elements of the work breakdown structure (WBS), especially those that are cost drivers on the program, lie on the critical path, or represent high-risk items. TPMs are key to progressively assessing technical progress. Proof that the product accomplishes the intended purpose. May be determined by a combination of test, analysis, and demonstration. Proof of compliance with specs. May be determined by a combination of test, analysis, demonstration, and inspection.

Reference (if applicable)


NPR 7120.5B

Specialty Engineering

Stakeholder

CMMI v1.1

NPR 7120.5B NPR 7120.5B

System

System of Interest Systems Engineering

NPR 71xx.x (document number not yet assigned)

Systems Engineering Management Plan (SEMP)

CMMI Project Planning Process

Technical Performance Measure (TPM)

IEEE 1220-1998

Validation Verification

NPR 7120.5B NPR 7120.5B

E-3

Appendix F Acronyms

AC ACE ACWP ADP AIAA AMACON ANSI AO APA ATP B-C-F BAC BCWP BCWS BOE C/SCSC CARD CCB CD CDDF CDR CFI CFO CI CIL CM CMMI CofF COTR COTS CPI CPM CPU CR CV CWI DCMA DDMS DDTE

actual cost advocacy cost estimate actual cost of work performed acceptance data package American Institute of Aeronautics and Astronautics American Management Association American National Standards Institute Announcement of Opportunity allowance for program adjustment authorization to proceed baseline-current-future budget at completion budgeted cost of work performed budgeted cost of work scheduled basis of estimate Cost/Schedule Control Systems Criteria cost analysis requirements description configuration control board Center Director Center Director Discretionary Fund Critical Design Review comparative fit index Chief Financial Officer configuration item critical items list configuration management Capability Maturity Model Integration construction of facilities contracting officer technical representative commercial off-the-shelf cost performance index critical path method central processing unit change request Concept Review cost variance Common Work Instruction Defense Contract Management Agency design and data management system design, development, test, and evaluation

DLE DLO DO DoD DPM DR DRFP DRLI DTO EA EAA EAC EEE EIA EMC/EMI EPC ERB ESTL ETC EV EVM EVMS

discipline lead engineer directorate-level organization delivery order Department of Defense deputy project manager Definition Review draft request for proposal data requirements list items detailed test objective environmental assessment Enterprise Associate Administrator estimate at completion electrical/electronic equipment Electronics Industries Alliance electromagnetic compatibility/ electromagnetic interference engineering-procurementconstruction Engineering Review Board electronic systems test laboratory estimation to complete earned value earned value management earned value management system Federal Acquisition Regulation functional flow block diagram failure mode and effects analysis Facility Review board Flight Readiness Review fault-tree analysis full-time equivalent general and administrative government certification approval request graphical evaluation review technique government-furnished equipment Governing Project Management Council group support equipment hardware hardware/software integration independent assessment interdivisional agreement interface control document independent cost estimate

FAR FFBD FMEA FRB FRR FTA FTE G&A GCAR GERT GFE GPMC GSE H/W HSI IA ICD ICE

F-1

Project Management: SE & Project Control Processes & Requirements

IDEF0 IFWG INCOSE IRD IRMA ISO IT ITA IV&V

integration definition for function modeling interface working group International Council on Systems Engineering Information Resources Directorate Integrated Risk Management Application International Organization for Standardization information technology internal task agreement independent verification and validation JSC Systems Engineering Working Group JSC Policy Directive JSC Procedures and Guidelines Johnson Space Center Kennedy Space Center local area network life cycle cost level of effort lead systems engineer Mission Control Center Mission Definition Review memorandum of agreement material usage agreement non-advocate review Next -Generation Space Telescope National Institute of Standards and Testing NASA Management Instruction new obligation authority NASA Policies and Directives NASA Procedures and Requirements NASA Safety and Reporting System other direct cost Operational Readiness Review outside of board Occupational Safety and Health Administration problem/failure report preplanned product improvement

PC PCA PDR PERT PI PMB PMC PMP PMWG POP PQA PR PRA ProRR PSA PSRP QA QFD QRA R-BAM R&D R&M RAS RFP RFQ RID RP RR RTOP

J-SEWG JPD JPG JSC KSC LAN LCC LOE LSE MCC MDR MOA MUA NAR NGST NIST NMI NOA NPD NPR NSRS

personal computer program commitment agreement Preliminary Design Review program evaluation review technique principal investigator performance measurement baseline Project Management Council project management plan Project Management Working Group program operating plan procurement quality assurance Purchase Request probabilistic risk assessment Production Readiness Review probabilistic safety assessment Payload Safety Review Panel quality assurance quality functional deployment quantitative risk assessment risk-based acquisition management research and development reliability and maintainability requirements allocation sheet request for proposal request for quotes review item disposition reference publication Requirements Review Research and Technology Objectives and Plans safety and mission assurance software System Acceptance Review Small Business Innovation Research System Definition Review systems engineering Systems Engineering Management Plan Software Engineering Process Group international system of units subsystem lead engineer system-level procedure Safety and Mission Assurance Review Team specific, measurable, achievable, resource constrained, and time constrained

S&MA S/W SAR SBIR SDR SE SEMP SEPG

ODC ORR OSB OSHA

SI SLE SLP SMART

P/FR P3 I

F-2

Appendix F Acronyms

SME SMO SOW SPI SRP SRR SV TBD TBS TCPI TDRSS TIM TLS TPM TRL TRR TS VAC VAR VASIMR

subject matter expert Systems Management Office statement of work schedule performance index Safety Review Panel System Requirements Review schedule variance to be determined to be supplied to complete performance index tracking and data relay satellite system technical interchange meeting timeline analysis sheet technical performance measure technology readiness level Test Readiness Review technical solution variance at completion variance analysis report variable specific impulse magnetoplasma rocket work authorization document work breakdown structure

WAD WBS

F-3

Appendix G Photograph Captions

Chapter 1:
P 1-2

P 2-20 left

ISS004-E-11792 (26 April 2002) STS110-730-079 (17 April 2002)


This full view of the International Space Station (ISS) was recorded by the STS-110 crewmembers on board the Space Shuttle Atlantis following the undocking of the two spacecraft some 247 statute miles above the North Atlantic.
P 1-7

Astronaut Carl E. Walz, Expedition 4 flight engineer, works on the Elektron Oxygen Generator in the Zvezda Service Module on the ISS. P 2-22

p2-22 ISS004-E-11958 (16 May 2002)


This image features fire scars and smoke plumes resulting from biomass burning in the savannahs of the southern Democratic Republic Congo. Expedition 4 crewmembers observed the seasonal increase in savannah burning.

JSC2001-E-18949 (December 2001)


The Space Shuttle Atlantis launched this railcar, called the Mobile Transporter (MT), and an initial 43-foot section of track as it delivered the first segment of the ISS exterior truss. Designated S0 (S-zero), this first section of truss was carried aloft during the mission of STS-110.

Chapter 3:
P 3-1

Chapter 2:
P 2-6

ISS007-E-17880 (20 October 2003)


European Space Agency (ESA) astronaut Pedro Duque of Spain prepares to set up the Cervantes program of tests by starting with the Microgravity Science Glovebox (MSB) in the Destiny laboratory on the ISS. Duque is working on an experiment that will investigate the growth processes of proteins during weightless conditions.
P 3-3

STS110-S-039 (19 April 2002)


The Space Shuttle Atlantis heads for touchdown on the runway at the KSC landing facility to complete a nearly 11day journey.
P 2-10

ISS008-E-05181 (31 October 2003)


Astronaut C. Michael Foale, Expedition Eight mission commander and NASA ISS science officer, works with the Russian biomedical Pilot experiment in the Zvezda Service Module on the ISS. The experiment looks at psychological and physiological changes in crew performance during long-duration space flight.
P 3-6

STS105-E-5226 (16 August 2001)


Now a member of the STS-105 crew, departing Expedition 2 Flight Engineer Susan J. Helms works out on the ergometer device on the mid deck of the Space Shuttle Discovery.
P 2-11 top

ISS005-E-16521 (9 October 2002)


Backdropped against a blue and white Earth, this view of the Space Shuttle Atlantis was photographed by an Expedition 5 crewmember on board the ISS during rendezvous and docking operations.
P 2-11 bottom

ISS008-E-12281 (9 January 2004)


Cosmonaut Alexander Y. Kaleri, Expedition 8 flight engineer, works at the Vozdukh CO2 scrubber in the Zvezda Service Module on the ISS.
P 3-10

ISS005-E-10926 (23 August 2002)


This image shows some of the devastating late summer 2002 European flooding. The image, captured on board the ISS during Expedition 5, shows flooding around the Danube Bend area just north of Budapest near the city of Vc, Hungary
P 2-20 top right

STS109-S-020 (1 March 2002)


The Space Shuttle Columbia passes through some predawn clouds as it soars into the sky to begin its 27th flight, STS-109.
P 3-13

STS112-326-015 (12 October 2002)


Astronaut Piers J. Sellers, STS-112 mission specialist, uses a handrail on the Destiny Laboratory and a foot restraint on the SSRMS or Canadarm2 to remain stationary while performing work at the end of the STS-112 mission's second spacewalk.
P 3-14 left

ISS004-E-8652 (14 March 2002)


Astronaut Daniel W. Bursch, Expedition 4 flight engineer, works the controls of the Canadarm2, or Space Station Remote Manipulator System (SSRMS) in the Destiny laboratory on the ISS.
P 2-20 bottom right

ISS004-E-10288 (21 April 2002)


This view featuring the San Francisco Bay Area was photographed by an Expedition 4 crewmember on board the ISS.

STS112-E-05901 (16 October 2002)


Astronaut Sandra H. Magnus, STS-112 mission specialist, works out on a bicycle ergometer on the middeck of the Space Shuttle Atlantis .

G-1

Project Management: SE & Project Control Processes & Requirements

P 3-14 right

STS112-304-005 (12 October 2002)


This scene, showing a portion of the forward section of the Space Shuttle Atlantis , was photographed by a space walking astronaut. Astronauts Jeffrey S. Ashby, STS-112 mission commander; Pamela A. Melroy, pilot; and cosmonaut Fyodor N. Yurchikhin, mission specialist, can be seen through an overheard aft flight deck window.
P 3-15

(EMU) spacesuit, is pictured in the Quest Airlock on the Lopez-Alegria was about to begin the first of three scheduled spacewalks to perform work on the Station.
P 4-22 bottom

STS113-370-012 (2 December 2002)


The horizon of a blue and white Earth and the blackness of space form the backdrop as two miniature satellites are released from the Space Shuttle Endeavour as part of an experiment referred to as MEPSI. Funded by the Defense Advance Research Projects Agency (DARPA), the two small satellites, which are tethered together, were released from Endeavours payload bay (visible in foreground) to fly free for three days as a technology demonstration of the launcher and use of micro- and nano-technologies in space systems.
P 4-30

STS112-702-002 (7 18 October 2002)


Egypts triangular Sinai Peninsula lies in the center of this view, photographed from the Space Shuttle Atlantis , with the dark greens of the Nile delta lower right.
P 3-24

STS113-E-05201 (28 November 2002)


Astronaut Michael E. Lopez-Alegria, STS-113 mission specialist, works on the newly installed Port One (P1) truss on the ISS during the missions second scheduled spacewalk The spacewalk lasted 6 hours, 10 minutes.

STS107-400-004 (16 January 1 February 2003)


This Earth view featuring the Sinai Peninsula, Red Sea, Egypt, Nile River, and Mediterranean was photographed by an STS-107 crewmember on board the Space Shuttle Columbia.
P 4-32 fragment, top right

Chapter 4:
P 4-8 top

STS113-332-035 (14 December 2002)


The STS-113 crewmembers used a 35mm still camera to record this image of Mt. Etna Volcano erupting on the island of Sicily. The oblique, south-looking view shows Mt. Etnas dark ash plume.
P 4-34 top right

ISS008-E-13212 (26 January 2004)


This image of the El Paso-Juarez area on the U.S.-Mexico border, photographed by an Expedition 8 crewmember, is the 100,000th photograph of Earth that astronauts have taken from the ISS.
P 4-8 bottom

STS113-305-007 (26 November 2002)


Astronaut John B. Herrington, STS-113 mission specialist, participates in the missions first spacewalk. The opened hatch of the Quest Airlock is reflected in Herringtons helmet visor.
P 4-34 bottom

STS112-709-073K (10 October 2002)


Astronaut David A. Wolf, STS-112 mission specialist, anchored to a foot restraint on the SSRMS or Canadarm2, carries the Starboard One (S1) outboard nadir external camera. The camera was installed on the end of the S1 Truss on the ISS during the missions first scheduled spacewalk.
P 4-11

STS113-336-015 (2 December 2002) STS111-307-017 (11 June 2002)


Astronaut Philippe Perrin, STS-111 mission specialist representing CNES, the French Space Agency, participates in the second scheduled spacewalk for the mission. During the spacewalk, Perrin and Chang-Diaz attached power, data and video cables from the ISS to the Mobile Base System (MBS) and used a power wrench to complete attachment of the MBS onto the MT.
P 4-18

Backdropped by a blue and white Earth, this full view of the ISS was photographed by a crewmember on board the Space Shuttle Endeavour following the undocking of the two spacecraft.
P 4-41 left

STS111-321-024 (5 19 June 2002)


This sunset over the Sahara Desert was photographed by the STS-111 crewmembers aboard the Space Shuttle Endeavour. When this photograph was taken, the Shuttle was in a position over the Sudan near the Red Sea coast.
P 4-41 right

STS113-S-007 (23 November 2003)


Against a black night sky, Space Shuttle Endeavour heads toward Earth orbit and a scheduled link-up with the ISS.
P 4-22 top right

STS111-367-014 (5 19 June 2002)


This view featuring Canadian forest fires was taken by STS-111 crewmembers aboard Space Shuttle Endeavour. It represents an oblique view northward of one of the numerous fires observed and reported burning in the dry boreal forests of Saskatchewan and Manitoba during the month of June.

STS113-360-030 (26 November 2002)


Astronaut Michael E. Lopez-Alegria, STS-113 mission specialist, attired in his Extravehicular Mobility Unit ISS.

G-2

Appendix G Photograph Captions

P 4-46 top

ISS007-E-09860 (21 July 2003)


This view of Earths horizon as the sunsets over the Pacific Ocean was taken by an Expedition 7 crewmember on board the ISS. Anvil tops of thunderclouds are also visible.
P 4-46 bottom

of the Space Shuttle Endeavour remote manipulator system (RMS) robotic arm during the four-hour, 12-minute session spacewalk.
P 4-78

STS108-350-009 (10 December 2001) ISS007-E-10807 (8 July 2003)


Astronaut Edward T. Lu, Expedition 7 NASA ISS science officer and flight engineer, wearing squat harness pads, performs knee-bends using the Interim Resistive Exercise Device (IRED) equipment in the Unity node on the ISS.
P 4-52 top

Astronaut Linda M. Godwin, STS-108 mission specialist, works during a four-hour, 12-minute spacewalk. The main objective of the spacewalk was to install thermal blankets on mechanisms that rotate the ISS main solar arrays
P 4-81 left

STS107-E-05359 (22 January 2003) JSC2003-E-31962 (24 April 2003)


The Soyuz rocket is erected at the launch pad at the Baikonur Cosmodrome, Kazakhstan. Expedition 7 is scheduled to launch on board the Soyuz on Saturday April 26, 2003.
P 4-52 bottom

SPACEHAB Research Double Module as seen from Columbias aft flight deck during STS-107.
P 4-81 right

STS107-E-05537 (25 January 2003)


One of the STS-107 crewmembers used a digital still camera to capture this image of clouds, shadows and sunglint during a moment away from Flight Day 10 science research aboard the Space Shuttle Columbia.
P 4-84

ISS008-E-12109 (6 January 2004)


Five-year-old icebergs near South Georgia Island are featured in this image photographed by an Expedition 8 crewmember on board the ISS. This oblique image shows two pieces of a massive iceberg that broke off from the Antarctica Ronne Ice Shelf in October 1998.
P 4-55

STS104-315-013 (1224 July 2001)


Holding onto the end effector of the Canadarm on the Space Shuttle Atlantis , astronaut Michael L. Gernhardt, STS-104 mission specialist, participates in one of three STS-104 spacewalks. The spacewalk was designed to help wrap up work on the second phase of the ISS.
P 4-90 top

STS110-353-023 (8 19 April 2002)


Docked to the ISS, a Soyuz vehicle (foreground) and the Space Shuttle Atlantis were photographed by an STS-110 crewmember in the Pirs docking compartment on the orbital outpost.
P 4-64

ISS006-E-05070 (4 December 2002)


The new crewmembers aboard the ISS were able to document a rare occurrence early into their tour on the outpost. The dark area near Earths horizon at center frame is actually a shadow cast by the Moon during the total solar eclipse of Dec. 4, 2002.
P 4-90 bottom

STS113-S-005 (23 November 2002)


Against a black night sky, the Space Shuttle Endeavour heads toward Earth orbit and a scheduled link-up with the ISS.
P 4-68

ISS006-E-07133 (9 December 2002) STS111-373-001 (15 June 2002)


Backdropped by the blackness of space and a blue and white Earth, the ISS is now separated from the Space Shuttle Endeavour following the undocking of the two spacecraft over western Kazakhstan.
P 4-72

Astronaut Donald R. Pettit, Expedition 6 NASA ISS science officer, works to set up Pulmonary Function in Flight (PuFF) hardware in preparation for a Human Research Facility (HRF) experiment in the Destiny laboratory on the ISS.
P 4-93

STS112-705-011 (7 18 October 2002)


The light-blue region in the middle of this view, photographed from the Space Shuttle Atlantis , is the shallow flat platform known as the Great Bahama Bank.
P 4-96

JSC2003-E-59333 (20 October 2003)


This overall view of the Station flight control room (BFCR) in JSCs Mission Control Center (MCC) was photographed during rendezvous and docking operations between the Soyuz TMA-3 spacecraft and the ISS.
P 4-77

STS111-373-018 (15 June 2002) STS108-311-010 (10 December 2001)


Astronauts Linda M. Godwin (red stripes) and Daniel M. Tani, STS-108 mission specialists, are pictured near the end Silhouetted over Earth, this full view of the ISS was photographed by a crewmember on board the Space Shuttle Endeavour following the undocking of the two spacecraft over western Kazakhstan.

G-3

Project Management: SE & Project Control Processes & Requirements

P 4-100

P B-2

STS110-716-026 (13 April 2002)


Some 240 miles above the blue and white Earth, astronaut Lee M.E. Morin totes one of the S0 (S-zero) keel pins that was removed from its functional position on the truss and attached on the truss exterior for long-term stowage.
P 4-104

STS109-713-014 (8 March 2002)


Astronauts John M. Grunsfeld (right) and Richard M. Linnehan, STS-109 payload commander and mission specialist, respectively, are photographed near the giant Hubble Sp ace Telescope temporarily hosted in the Space Shuttle Columbias cargo bay at the close of the fifth and final session of spacewalks.
P D-1

ISS007-E-09855 (8 July 2003)


Astronaut Edward T. Lu, Expedition 7 NASA ISS science officer and flight engineer, exercises on the Cycle Ergometer with Vibration Isolation System (CEVIS) in the Destiny laboratory on the ISS.
P 4-109 top

STS108-E-5349 (10 December 2001)


Astronaut Linda M. Godwin, STS-108 mission specialist, is pictured near the end of the Space Shuttle Endeavour RMS arm during a four-hour spacewalk.
P F-3 top

STS109-326-008 (5 March 2002)


Astronaut Michael J. Massimino, mission specialist, works at the stowage area for the Hubble Space Telescope port side solar array. Astronauts Massimino and James H. Newman removed the old port solar array and stowed it in Columbias payload bay for a return to Earth. They then went on to install a third-generation solar array and its associated electrical components.
P 4-109 bottom

ISS005-E-19267 (1 November 2002)


A Soyuz spacecraft approaches the Pirs docking compartment on the ISS carrying the Soyuz 5 taxi crew, Commander Sergei Zalyotin, Belgian Flight Engineer Frank DeWinne, and Flight Engineer Yuri V. Lonchakov for an eight-day stay on the Station. The new Soyuz TMA1 vehicle was designed to accommodate larger or smaller crewmembers, and is equipped with upgraded computers, a new cockpit control panel and improved avionics.
P F-3 bottom

STS109-329-021 (1 12 March 2002)


The horizon of a blue and white Earth and the blackness of space form the backdrop for this view of the cargo bay of the Space Shuttle Columbia, as seen through windows on the aft flight deck during the STS-109 mission. Pictured in the cargo bay is the Rigid Array Carrier (RAC) holding the new Hubble Solar Arrays. In its stowed position at right center of the frame is the Canadian-built RMS arm.

ISS005-E-19024 (30 October 2002)


The three-member crew of the Expedition 5 mission on board the ISS was able to observe Mt. Etnas spectacular eruption, and photograph the details of the eruption plume and smoke from fires triggered by lava as it flowed down the 11,000 ft mountain. This image provides a three-dimensional profile of the eruption plume. This eruption was one of Etnas most vigorous in years.

Appendices:
P A-3 top

Below ISS008-E-08453 (10 December 2003)


This view of a full Moon was photographed by one of the Expedition 8 crewmembers on board the ISS.

ISS007-E-10246 (15 July 2003)


The crew of the ISS had a great seat from which to observe tropical storm Claudette as she turned into a hurricane and came ashore with high winds and heavy rains that drenched their Houston home base and other Texas areas.
P A-3 bottom right

ISS007-E-14440 (4 September 2003)


Astronaut Edward T. Lu, Expedition 7 NASA ISS science officer and flight engineer, wearing a Russian Sokol suit, floats in the Destiny laboratory on the ISS.
P A-3 bottom left

ISS007-E-11507 (31 July 2003)


Cosmonaut Yuri I. Malenchenko, Expedition 7 mission commander, is pictured with the Plasma Crystal Experiment in the Zvezda Service Module transfer compartment on the ISS.

G-4

Appendix H Spiral Development Process

n+1 TRL (n) n

Key:
Planning Develop Prototype Build Evaluate, Determine Alternatives

H-1

National Aeronautics and Space Administration Lyndon B. Johnson Space Center Houston, Texas