Industry Perspective: Challenges to Program Management

1
Industry PerspectiveChallenges to Program
Management

• Dennis McCarthy
• Vice President, Swales Aerospace
• December 2003

2
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
• Late 90s to Today
• Character is changing
• More work is done by Contractor
• e.g. RSDO procure spacecraft Instrument
  at P.I.s Institution Ground System P.I. /
  NASA Operations P.I. / NASA

3
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

4
Perspective

• Typically, the industry entity on a team, has
  correspondingly major responsibilities for
  schedule and performance
• Driven 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 / science
• Spacecraft
• Mission operations / ground station

5
Underestimating InstrumentCost 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.)

6
Underestimating InstrumentCost and Schedule
CONTINUED

• Frequently, Phase A and Phase B are the primary
  periods of instrument development
• Significant 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

7
Underestimating InstrumentCost and Schedule
CONTINUED

• Optimistic expectation for advanced instrument
  performance goals and cost cap pressures,
  combined with nominal 36-month / 42-month
  program schedule, encourage success-oriented
  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

8
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-the-shelf, 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

9
Schedule Execution andRecovery 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

10
Schedule Execution andRecovery Considerations
CONTINUED

• Robust integrated schedule, with margins, must be
  enforced
• Plan for reserve in instrument deliveries
• Schedule deviations drive costs beyond specific
  schedule item everything interacts
• Personnel
• Facilities and test equipment
• Subcontracts

11
Schedule Execution andRecovery 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 gt schedule recovery has cost impacts
• The closer to launch, the fewer the options

12
Recommendations

• 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
• To reduce late instrument changes, require signed
  instrument-to-spacecraft ICDs at confirmation
  review

13
Recommendations CONTINUED

• 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

14
Recommendations CONTINUED

• 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

15
RecommendationsSection 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
• Sensitivity Analyses
• Cost as Independent Variable
• Cost Benefit Analysis
• Systems Engineering Management
• Requirements Analysis

• Functional Analysis
• Design Synthesis
• Verification
• Work Breakdown Structure
• Technical Reviews and Audits
• Trade Studies
• Modeling and Simulation
• Metrics
• Risk Management
• Descope Plan
• Trigger Points
• Product Improvement Strategies
• Organizing and Integration of System Development
• Contractual Considerations

16
RecommendationsSection 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

17
RecommendationsSection 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!

18
RecommendationsSection 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

19
RecommendationsSection 5 continued

• Systems Engineering Management continued
• Develops requirements
• Identifies technical issues
• Performance
• Effectiveness criteria
• Acceptable levels of risk
• Defines Tasks
• Analyses
• Trade Studies
• Risk Assessment
• Tracks technical performance, achievement

• 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

20
RecommendationsSection 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 intra-system 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

21
RecommendationsSection 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

22
RecommendationsSection 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

23
RecommendationsSection 5 continued

• Available Resources
• Requirements Development Tools
• Slate
• Doors
• Raptor
• GSFC
• Systems Engineering Toolbox for Design Oriented
  Engineers
• Computer-Aided Systems Engineering and Analyses,
  CASEA
• End-to-End Flight Software Systems Engineering
• Configuration Management
• JPL
• 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

24
RecommendationsSection 5 continued

• Available Resources continued
• LaRC
• Configuration Development / CAD
• PRO-ENGINEER
• I-DEAS
• SMART
• ACAD
• Aerodynamic Analysis
• FELISA
• APAS
• UDP
• HABP
• WDES
• Aeroheating Analysis
• MINIVER
• Thermal Analysis
• SINDA
• MSC/THERMAL
• Structural Analysis

• Flutter Analysis
• DLFLUT
• ZONA
• WINDWing
• Structural Sizing and Optimization
• COLAPS
• Vehicle Sizing, Mission / Trajectory Analysis and
  Optimization
• POST3D/POST6D/IPOST
• FLOPS/XFLOPS
• CONSIZ
• System Optimizers
• KSOP
• DOT
• Design Expert

• WAVEDRAG
• AERO2S/3S
• AWAVE
• CDF

• HyperSizer
• TESTBED/EZDESIT
• ANSYS

25
RecommendationsSection 5 continued

• Available Resources continued
• Reliability, Maintainability, and Safety Analysis
• RMAT
• SLAM
• EXTEND
• ASD Safety Tool
• Scramjet Engine Design / Analysis
• SRGULL
• CFD Analysis
• GRIDGEN
• GRIDTOOLS
• GASP
• SHIP3D
• SCRAM3L
• SAMcfd
• USM3D
• VULCAN

• Data Visualization
• TECPLOT
• PVWAVE
• FIELDVIEW
• Flutter Analysis
• Web-Based Interfaces and Virtual Reality
  Environments
• IDS
• MUSE
• Cost Analysis
• PRICE H/M/HL
• Planning and Scheduling
• ARTEMIS
• Computational Platforms
• PCs and Macs
• Unix Workstations
• CRAYs
• Networked Systems

26
Let us not unlearn what we have already learned.

• Diogenes

27
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