Industry Perspective: Challenges to Program Management

Dennis McCarthy Vice President, Swales Aerospace December 2003

Perspective
Swales

Aerospace has provided engineering services to NASA in-house programs for 25 years Core Teams were at NASA / GSFC
e.g.

COBE, EUVE, XTE, TRMM, HST, GOES, TIROS is changing

RSDO procure spacecraft Instrument at P.I.s Institution Ground System P.I. / NASA Operations P.I. / NASA

Late

90s to Today
More work is done by Contractor

Character e.g.

Industry Perspective

Perspective
With

the exception of the NASA evaluation teams, the industry vendors read (and perform) more proposals than any other single group
Appreciate

range of PI / institution capabilities and experience levels View a broad selection of mission / instrument expectations Quickly acquire an understanding of missions

Mostly likely competed for team position, so performed a reasonable analysis before joining team Must interface both to science / instrument team and mission ops / ground team

Industry Perspective

Perspective
Typically,
Driven

the industry entity on a team, has correspondingly major responsibilities for schedule and performance
by business factors, as well as science goals show a profit to the stockholders, in a contract environment Almost always involved when a mission has cost or schedule issues (cause and/or effect) Often tasked with assisting PI in developing programmatic solutions to problems

Issues

impacting project cost performance can arise from any of the three major mission segments
Instruments
Spacecraft Mission

/ science

operations / ground station

Industry Perspective

Underestimating Instrument Cost and Schedule

Competition

(most exciting science) encourages PIs to offer leading edge instruments (higher resolution, greater sensitivity, greater spectral coverage, etc.), i.e., Most science for available AO budget
Impression

that high science with higher risk wins over medium science with low risk Build-to-print of earlier instruments inappropriate / unexciting Proposed instruments often have little or partial prototype substantiation prior to selection More competitors than funds available from instrument programs (AOs, NRAs, etc.)

Industry Perspective

Underestimating Instrument Cost and Schedule CONTINUED

Frequently,
Significant

Phase A and Phase B are the primary periods of instrument development

instrument design and performance verification activities Limited funds / limited schedule, especially Phase A, preclude / restrict prototyping and hardware risk reduction Overall schedule and confirmation review milestones require spacecraft vendor activity in parallel with instrument activity reduced opportunity to iterate

Industry Perspective

Underestimating Instrument Cost and Schedule CONTINUED

Optimistic

expectation for advanced instrument performance goals and cost cap pressures, combined with nominal 36-month / 42-month program schedule, encourage successoriented planning
No

allowances for learning / failure Cost reserves generally in alignment with AO guidelines (what does it take to check the box) Instrument delivery usually has limited slack or is on critical path

Industry Perspective

Programmatic Experience on Previous Programs

Changing oversight rules during program execution has impacted past programs. This is often the result of problems experienced on other programs. While this additional oversight is value-added, it adds cost and impacts schedule relative to what was originally proposed Level of acceptable risk is inversely proportional to remaining time before launch Technology continues to be fragile, and therefore costs more than originally planned

Advanced technology components often have technical problems. This is especially true for new components, but even impacts true heritage, off-theshelf, components at times. So where the science is driving advanced technology, there is a need for increased reserves (technical, schedule, and cost) to deal with the unknown

Industry Perspective

Schedule Execution and Recovery Considerations

Design

Phases (A and B) must converge to allow on-time, on-cost program execution; instruments and mission dictate requirements and program flow
Late

decisions on instrument parameters impede progress of spacecraft and ground and operations segments Instrument-to-SC ICDs should be signed and frozen well before the end of Phase B Late changes often cause interface domino effect with cost and schedule consequences (interface changes ripple through subsystem / system) After ICDs finalized, manage to avoid requirements creep

Industry Perspective

Schedule Execution and Recovery Considerations CONTINUED

Robust
Plan

integrated schedule, with margins, must be enforced

for reserve in instrument deliveries

Schedule

deviations drive costs beyond specific schedule item everything interacts

Personnel
Facilities

and test equipment Subcontracts

Industry Perspective

10

Schedule Execution and Recovery Considerations CONTINUED

Some

schedule recovery tasks cannot be compressed without incurring major risk, especially those tasks following instrument delivery for observatory integration (path becomes predominantly single string)
Environmental

testing tasks essentially incompressible Certain observatory-level tests incompressible (e.g., Comprehensive Performance Tests) While tasks can be reordered to accommodate work-arounds, core staff most likely cannot be reduced substantially; difficult to start and stop => schedule recovery has cost impacts The closer to launch, the fewer the options

Industry Perspective

11

Recommendations
1.

Advanced instrument offerings indicate need for early start of instrument development, decoupled from spacecraft development

Current Phase A funds too small for hardware risk reduction Current Phase B requires spacecraft vendor to be working toward PDR in order to have sufficient progress to receive confirmation (confirmation review); reduces opportunity for iteration Possible solution: add 4 - 6 month instrument development phase (includes nominal support from spacecraft vendor for interface guidance) to beginning of Phase B

2.

To reduce late instrument changes, require signed instrument-to-spacecraft ICDs at confirmation review
12

Industry Perspective

Recommendations CONTINUED
3.

4.

Evaluate and allocate program and technical margins / reserves according to TRL rather than across the board Include periodic third-party schedule reviews into basic program

Currently only used after trouble occurs too late Must be constructive, not directive, and timely Consider adding schedule review milestone midway between confirmation review and instrument delivery

Industry Perspective

13

Recommendations CONTINUED
5.

Systems Management / Engineering role is critical

Should plan for, establish, and utilize a Systems Team

Identify and flowdown requirements, early Minimize changes, i.e. requirements creep

Should be an industry member on Systems Team

Continuity Program understanding Understanding of Industry capabilities Ability to get to problem resolution quicker and cheaper

Industry Perspective

14

Recommendations
Section 5 continued
Develop

Standardized Systems Management to Support Individual Programs

Standard processes Internal Program Reviews Standardized Milestones

e.g. PDR Products and Exit Criteria

Document Tree and Documents Require Standard Software Tools Configuration Management

Hardware and Documents

Functional Analysis Design Synthesis Verification Work Breakdown Structure Technical Reviews and Audits Trade Studies Modeling and Simulation Metrics Risk Management
Descope

Sensitivity Analyses

Cost as Independent Variable Cost Benefit Analysis

Plan Trigger Points

Systems Engineering Management Requirements Analysis

Product Improvement Strategies Organizing and Integration of System Development Contractual Considerations
15

Industry Perspective

Recommendations
Section 5 continued
Systems

Engineering Objectives

Derive a coherent total system design capable of achieving the stated requirements Continuously challenge and/or validate requirements Specify everything necessary to design, document, implement, and conduct the mission Logically consider and evaluate through various analyses and trade studies each of the many variables involved in a total system design Verify system performance

Industry Perspective

16

Recommendations
Section 5 continued
Definitions

Program Management Performing the function which plans, guides, and controls the technical, costs, and schedule performance of a project System The entirety needed to meet a defined set of requirements. It varies depending on your point of reference, i.e. instruments, subsystem, spacecraft, observatory, mission Systems Management Performing an overview function which plans, guides, controls, and monitors the technical execution of a project Systems Engineering Identifying required analyses and conducting those analyses and trade-studies in accordance with the direction of the Systems (Engineering) Manager

There is a difference between systems management and systems engineering!

Industry Perspective 17

Recommendations
Section 5 continued
Systems

Engineering Management

The management / engineering and technical efforts required to transform mission requirements into an operational system. It includes

Defining the system performance parameters Developing the preferred system configuration Planning and control of technical program tasks Integrating engineering specialties Managing integrated effort of design engineering, specialty engineering, test engineering, and manufacturing engineering

The purpose is to meet the technical performance, objectives of the program The management, including the planning and control for successful, timely completion of the study, design, development, and test evaluation tasks required in the execution of the systems engineering process
18

Industry Perspective

Recommendations
Section 5 continued
Systems

Engineering Management continued

Develops requirements Identifies technical issues

Evaluates impact of risks Integrates system definition Performs in a management overview function which plans, guides, controls, and monitors the technical execution of the project

Performance Effectiveness criteria Acceptable levels of risk Analyses Trade Studies

Defines Tasks

Risk Assessment

Tracks technical performance, achievement

Industry Perspective

19

Recommendations
Section 5 continued
System

Engineering

A logical and iterative sequence of activities and decisions, which transform a need into a preferred system configuration and demonstrating that the system is capable of performing as required An end-to-end process which involves the conduct of inter- and intrasystem level analyses, which result in the development of performance, operational, interfaces, and verification requirements for the total system An interdisciplinary approach to evolve and verify an integrated and optimally balanced set of product and process designs that satisfy user needs and provide information for management decision making A system for developing a hierarchal list of requirements to allow traceability and for iterating that list as required The management, including the planning and control for successful, timely completion of the study, design, development, test and evaluation, and mission operations A totally intellectual process

Industry Perspective

20

Recommendations
Section 5 continued
Requirements Technical requirements are derived from

User needs and requirements statements (SRD and/or MRD) Process of identifying needed system functionality Allocation of that functionality

Requirements identify the accomplishment levels needed to achieve specific objectives Functional Requirements - provide a description of the functions / sub-functions that must be accomplished, all internal and external functional interfaces and the higher level requirements allocated to the functions, sub-functions, and interfaces Performance Requirements define what an item must accomplish and how well it must perform. These technical requirements are initially derived from user needs / requirements statements through requirements analyses and trade studies. They are refined during each application of the systems engineering process based on outputs from previous iterations of the process, program decisions, and updates to user requirements. They provide the metrics, which must be verified by appropriate demonstrations and tests

Industry Perspective

21

Recommendations
Section 5 continued
Requirements

Design Requirements are described by drawings, material lists, process descriptions, and other supporting documents for the fabrication, production, or manufacturing of a system element. These are generally derived from the synthesis of a solution for one or more functional requirements Contractually binding requirements are stated in approved specifications, statements of work, and interface control documents You must continually demonstrate the traceability of each derived requirement through each next higher level requirement up to the specified Level I requirements

Industry Perspective

22

Recommendations
Section 5 continued
Available

Resources

Requirements Development Tools

Slate Doors Raptor Systems Engineering Toolbox for Design Oriented Engineers Computer-Aided Systems Engineering and Analyses, CASEA End-to-End Flight Software Systems Engineering Configuration Management MIDAS Interplanetary Impulsive Optimization Code OTIS Aircraft / Spacecraft Trajectory Simulator and Optimizer SNAP High-Fidelity N-Body Trajectory Integration Code CHEBYTOP Approximate Low-Thrust Interplanetary

GSFC

JPL

Industry Perspective

23

Recommendations
Section 5 continued

Available Resources continued

LaRC

Configuration Development / CAD

Flutter Analysis

PRO-ENGINEER I-DEAS SMART ACAD FELISA APAS UDP HABP WDES MINIVER SINDA MSC/THERMAL ELAPS MSC/NASTRAN MSC/PATRAN FEMAP

DLFLUT ZONA WINDWing COLAPS

Structural Sizing and Optimization

Aerodynamic Analysis

WAVEDRAG AERO2S/3S AWAVE CDF

Vehicle Sizing, Mission / Trajectory Analysis and Optimization

POST3D/POST6D/IPOST FLOPS/XFLOPS CONSIZ KSOP DOT Design Expert

Aeroheating Analysis

System Optimizers

Thermal Analysis

Structural Analysis

HyperSizer TESTBED/EZDESIT ANSYS

24

Industry Perspective

Recommendations
Section 5 continued

Available Resources continued

Data Visualization

Reliability, Maintainability, and Safety Analysis

RMAT SLAM EXTEND ASD Safety Tool SRGULL GRIDGEN GRIDTOOLS GASP SHIP3D SCRAM3L SAMcfd USM3D VULCAN

TECPLOT PVWAVE FIELDVIEW Flutter Analysis

Web-Based Interfaces and Virtual Reality Environments

Scramjet Engine Design / Analysis

IDS MUSE PRICE H/M/HL ARTEMIS

CFD Analysis

Cost Analysis

Planning and Scheduling

Computational Platforms

PCs and Macs Unix Workstations CRAYs Networked Systems

Industry Perspective

25

Let us not unlearn what we have already learned.

Diogenes

Summary
Awareness

that a Systems Perspective is vital for mission

success Awareness that ALL Organizations must

Provide

senior, seasoned systems manager Provide the proper mentoring of junior systems engineers

Industry Perspective

27