Programme Management | Systems Engineering | Engineering

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

2

so performed a reasonable analysis before joining team Must interface both to science / instrument team and mission ops / ground team Industry Perspective 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.

 Driven the industry entity on a team. as well as science goals – show a profit to the stockholders. has correspondingly major responsibilities for schedule and performance by business factors.Perspective  Typically. 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 4 .

greater sensitivity.e.Underestimating Instrument Cost and Schedule  Competition (most exciting science) encourages PIs to offer leading edge instruments (higher resolution. i. NRAs. etc. 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. greater spectral coverage.) Industry Perspective 5 .). etc..

Underestimating Instrument Cost and Schedule CONTINUED  Frequently. especially Phase A.  Significant Phase A and Phase B are the primary periods of instrument development instrument design and performance verification activities  Limited funds / limited schedule. 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 6 .

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 7 . combined with nominal 36-month / 42-month program schedule.Underestimating Instrument Cost and Schedule CONTINUED  Optimistic expectation for advanced instrument performance goals and cost cap pressures.

and therefore costs more than originally planned  Advanced technology components often have technical problems. This is especially true for new components. there is a need for increased reserves (technical. While this additional oversight is value-added. schedule. This is often the result of problems experienced on other programs. So where the science is driving advanced technology. components at times. but even impacts true heritage. and cost) to deal with the unknown Industry Perspective 8 . off-theshelf.Programmatic Experience on Previous Programs    Changing oversight rules during program execution has impacted past programs. 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.

Schedule Execution and Recovery Considerations  Design Phases (A and B) must converge to allow on-time. on-cost program execution. manage to avoid requirements creep Industry Perspective 9 . 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.

Schedule Execution and Recovery Considerations CONTINUED  Robust  Plan integrated schedule. 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 . with margins.

the fewer the options Industry Perspective 11 . Comprehensive Performance Tests)  While tasks can be reordered to accommodate work-arounds. core staff most likely cannot be reduced substantially.g.Schedule Execution and Recovery Considerations CONTINUED  Some schedule recovery tasks cannot be compressed without incurring major risk.. difficult to start and stop => schedule recovery has cost impacts  The closer to launch. 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.

6 month instrument development phase (includes nominal support from spacecraft vendor for interface guidance) to beginning of Phase B 2.Recommendations 1. require signed instrument-to-spacecraft ICDs at confirmation review 12 Industry Perspective . 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 . Advanced instrument offerings indicate need for early start of instrument development. To reduce late instrument changes.

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.Recommendations CONTINUED 3. not directive. and timely Consider adding schedule review milestone midway between confirmation review and instrument delivery Industry Perspective 13 . 4.

Systems Management / Engineering role is critical    Should plan for.Recommendations CONTINUED 5.e. establish. i. and utilize a Systems Team Identify and flowdown requirements. 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 . early Minimize changes.

g.Recommendations Section 5 continued  Develop    Standardized Systems Management to Support Individual Programs Standard processes Internal Program Reviews Standardized Milestones       e. 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 .

spacecraft.Recommendations Section 5 continued  Definitions     Program Management – Performing the function which plans. guides. controls.e. It varies depending on your point of reference. subsystem. and schedule performance of a project System – The entirety needed to meet a defined set of requirements. and controls the technical. guides. 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 . instruments. observatory. costs. mission Systems Management – Performing an overview function which plans. i.

test engineering. 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. development. including the planning and control for successful. and manufacturing engineering   The purpose is to meet the technical performance. timely completion of the study. and test evaluation tasks required in the execution of the systems engineering process 18 Industry Perspective . specialty engineering. objectives of the program The management. design.Recommendations Section 5 continued  Systems  Engineering Management The management / engineering and technical efforts required to transform mission requirements into an operational system.

controls. guides. 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  Systems   Engineering Management continued Develops requirements Identifies technical issues       Evaluates impact of risks Integrates system definition Performs in a management overview function which plans.

Recommendations Section 5 continued  System  Engineering      A logical and iterative sequence of activities and decisions. design. interfaces. development. which result in the development of performance. including the planning and control for successful.and intrasystem level analyses. 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 mission operations A totally intellectual process Industry Perspective 20 . timely completion of the study. test and evaluation. 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. operational.

all internal and external functional interfaces and the higher level requirements allocated to the functions. and updates to user requirements. and interfaces Performance Requirements – define what an item must accomplish and how well it must perform. which must be verified by appropriate demonstrations and tests Industry Perspective 21 . They provide the metrics. program decisions.provide a description of the functions / sub-functions that must be accomplished. sub-functions. 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.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 .

production. statements of work.Recommendations Section 5 continued  Requirements    Design Requirements – are described by drawings. material lists. and other supporting documents for the fabrication. These are generally derived from the synthesis of a solution for one or more functional requirements Contractually binding requirements are stated in approved specifications. 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 . or manufacturing of a system element. process descriptions.

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 .

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  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.

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 . Maintainability.Recommendations Section 5 continued  Available Resources continued   Data Visualization  Reliability.

“Let us not unlearn what we have already learned.” Diogenes .

seasoned systems manager  Provide the proper mentoring of junior systems engineers Industry Perspective 27 .Summary  Awareness that a Systems Perspective is vital for mission success  Awareness that ALL Organizations must  Provide senior.

Sign up to vote on this title
UsefulNot useful

Master Your Semester with Scribd & The New York Times

Special offer for students: Only $4.99/month.

Master Your Semester with a Special Offer from Scribd & The New York Times

Cancel anytime.