mccarthy

Industry Perspective:Challenges to Program Management: 

Industry Perspective: Challenges to Program Management Dennis McCarthy Vice President, Swales Aerospace December 2003

Perspective: 

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

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

Perspective: 

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

Underestimating InstrumentCost and Schedule: 

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

Underestimating InstrumentCost and Schedule CONTINUED: 

Underestimating Instrument Cost 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

Underestimating InstrumentCost and Schedule CONTINUED: 

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

Programmatic Experience on Previous Programs: 

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

Schedule Execution andRecovery Considerations: 

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

Schedule Execution andRecovery Considerations CONTINUED: 

Schedule Execution and Recovery 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

Schedule Execution andRecovery Considerations CONTINUED: 

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

Recommendations: 

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

Recommendations CONTINUED: 

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

Recommendations CONTINUED: 

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

RecommendationsSection 5 continued: 

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

RecommendationsSection 5 continued: 

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

RecommendationsSection 5 continued: 

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!

RecommendationsSection 5 continued: 

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

RecommendationsSection 5 continued: 

Recommendations Section 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

RecommendationsSection 5 continued: 

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

RecommendationsSection 5 continued: 

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

RecommendationsSection 5 continued: 

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

RecommendationsSection 5 continued: 

Recommendations Section 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

RecommendationsSection 5 continued: 

Recommendations Section 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 ELAPS MSC/NASTRAN MSC/PATRAN FEMAP 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

RecommendationsSection 5 continued: 

Recommendations Section 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

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

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

Summary: 

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